https://bugs.kde.org/show_bug.cgi?id=490633
Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |89q1r1...@relay.firefox.com
--- Comment #2 from Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
