SUMMARY It seems the volume OSD's feedback sound immediately interrupts itself when re-triggered before the full sound has played. When any audio file's volume goes instantly to 0 (or a different value), this causes a click/pop noise. If the sound instead smoothly (but still quickly) faded to 0, there would be no clicks/pops and it would be much less abrasive to hear, and would be perceived as much less glitchy. When the volume down key is *held* (depending on how fast your key repeat rate is set), there's all kinds of ugly-sounding glitches; maybe there should additionally be a limit to how rapidly the sound can be played? STEP TO REPRODUCE 1. Press the volume down (or up) key rapidly, such that the feedback sounds interrupt each other OBSERVED RESULT Clicks and pops are heard EXPECTED RESULT No clicks or pops are heard OS: openSUSE Krypton (today's git master)
Video of the problem: https://streamable.com/qydtkc Operating System: Bazzite 40 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.12-202.fsync.fc40.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × AMD Ryzen 3 5300U with Radeon Graphics Memory: 6,6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 82KD System Version: Lenovo V15 G2 ALC PipeWire 1.0.7
I could very much be wrong but, I think, part of the problem is that it's playing back 44.1 kHz sample stream whereas most hardware is running at 48 kHz, so the audio daemon either needs to switch the hardware to 44.1 kHz sample rate or it has to insert a resampler, which is what usually happens. I'm not really able to explain how it works but resamplers need a certain number of samples to work on. And with such short sounds it's likely that some of the samples will be either from what's left over in the buffer or silence. This together with maybe some PW bugs or current defaults/limitations and the fact that each input event seems to be its own canberra stream results in some unpleasant glitches. One good news is that on my system running nearly git master of PW 1.3 the glitching is somewhat better, so upgrading PIpeWire down the road might help with the nastiest part of the resulting sound. That being said it also seems to dependent on the chosen quantum with unusually low values behaving better (assuming HW can cope with very low latency operation without bugging out). A few ideas to help more: 1. Do not force use of 44.1 kHz. I'm a bit worried that it might not be optional with canberra but ultimately 44.1 kHz has long been on the way out and it would be best to either provide the effects at multiple sample rates similar to bitmap icon sizes or at least switch to 48 kHz as the default. Or try to synthesize the effects at runtime, which is technically doable but I'm not sure if the people actually designing the sounds will be thrilled (but maybe they'll be?). 2. I'm not sure, if the trouble is worth the complication but keeping a stream open might help somewhat. Yes, this is arguably a bug in PA/PW, unless upstream decides that there's some minimum stream length below which there be bugs and glitches. I'm no expert but I'm not aware of any current limitation, so, I think, technically a client could probably open a stream, write one sample. quit and then repeat that tens or hundreds of times per second and the audio daemon is expected to get that innovative use of the API sounding "right". 3. Redesigning the effect might help but I'm not sure how much it's a bug in the sample itself and how much it would be working around limitations in the first two issues. 4. Perhaps just keeping the canberra stream open a bit longer to see if there's either a follow up or just to ramp down into silence might help but at this point I'm just throwing ideas at the wall. 5. Thinking some more, perhaps WirePlumber could be leveraged here, since it was designed for automotive use and having a car play some beeps or chimes while the radio or a phone call is being played is definitely part of its problem space. But beyond knowing about this, I can't really help any more than that.
Hmm, this could be related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3421#note_2563664
Sample rate aside (which is probably worth filing a bug against the sound theme separately) I think this ultimately needs fixing in pipewire. We set the canberra cache control to permanent > ca_context_play(context, cindex, > CA_PROP_EVENT_ID, "audio-volume-change", > CA_PROP_CANBERRA_CACHE_CONTROL, "permanent", // For better performance > nullptr); which ultimately seems to result in > if (pa_stream_connect_upload(out->stream, (size_t) ca_sound_file_get_size(out->file)) < 0) { respectively the play call of the sample. So technically pipewire could just cache the resample, if it had to resample. Indeed, since pipewire is entirely in the driver seat because of the cache, any workaround to this could and probably should ultimately be made on the pipewire side anyway. Any thoughts?
Hmm I'm not sure about the sample rate, but good questions. Maybe we could ask in PipeWire gitlab?