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

[Jaroslav Kysela]

Date 15.5.2013 13:03, David Henningsson wrote:
> On 05/15/2013 12:53 PM, 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..
> 
> The problem is knowing whether PCM is a softvol or not. In some cases, 
> we need to set PCM to control hardware volume.
> 
> Maybe, if we could figure this out somehow, we could ignore the PCM 
> mixer control (or possibly set it to zero) in case PCM is a softvol,
> and actually use it if PCM is not a softvol.
> 
> It does not look like this is currently possible from the simple mixer 
> interface, but I might be missing something?

It is not possible. Perhaps, we may create a new dummy mixer control (in
an inactive state) which will identify the presence of the softvol
plugin, like:

"Softvol PCM Playback Volume" - full name for the raw control API
"Softvol PCM" - simple mixer name

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.