[pulseaudio-discuss] [alsa-devel] PulseAudio and softvol

[Takashi Iwai]

At Wed, 15 May 2013 12:53:30 +0200,
Jaroslav Kysela wrote:
> 
> Date 15.5.2013 12:48, Takashi Iwai wrote:
> > 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).
> 
> We have already SND_PCM_NO_SOFTVOL open mode for this purpose, so I
> wonder, why PA does not use it..

Oh, yeah, I completely forgot it!


Takashi