At Wed, 15 May 2013 12:26:51 +0200, Jaroslav Kysela wrote:
Date 15.5.2013 11:55, Arun Raghavan wrote:
Hello, A number of users have intermittently(?) been hitting a crash in alsa-lib 1.0.27 [1, 2] related to the softvol plugin. I'm not able to reproduce this reliably, so can't find an easy way to debug/fix.
The problem is that the offsets are not in sync in this case [1]:
src_offset = 38560 dst_offset = 38568 frames = 16374
Could you reproduce this bug in any way? At least snd_pcm_dump() before the failing snd_pcm_mmap_commit() call might help to determine what was the status before the assert() was entered.
Yep. And this path is actually with volume 0dB, that is, a simply passthrough in softvol. Thus the bug may hit essentially any plugins, not specifically softvol.
However, this raises a tangential question - why do we need softvol to be plugged for 'front' at all? David explained to me that this is to guarantee the existence of a PCM control. Perhaps I don't fully understand this, because I'm unconvinced by the reason. Could someone explain/refute?
This is especially bad for us, from PulseAudio's perspective, because we aren't getting a zero-copy path.
If the softvol is set to 0dB (no attenuation or gain), then the ring buffer pointers are moved without any sample processing, so the zero-copy functionality is kept.
Yeah, a sort of. The mmap is cleared in the slave PCM, so actually there will be copy operations in underlying layers even though softvol itself does zero copy.
Actually it makes no sense to keep softvol for PA, but the problem is always the regression. There are certainly users without PA, which might still rely on the softvol for such hardware without the amp control.
Maybe We can add some flag to indicate whether to handle softvol or not, e.g. defaults.pcm.skip_softvol, and let PA set this in its config space. Setting a config item itself would break anything, so it'll still work with old alsa-lib (but with softvol).
thanks,
Takashi