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

[Jaroslav Kysela]

Date 16.5.2013 08:31, David Henningsson wrote:
> On 05/15/2013 06:28 PM, Takashi Iwai wrote:
>> At Wed, 15 May 2013 17:25:08 +0200,
>> Jaroslav Kysela wrote:
>>>
>>> Date 15.5.2013 17:06, Takashi Iwai wrote:
>>>> Enough for...?  It restores the value without the new TLV, thus it
>>>> doesn't show it's a softvol element.
>>>
>>> Yes, for the first call, but then PA will open the pcm device and this
>>> call will add the softvol information to TLV which inactivates the
>>> softvol control in the mixer.
>>
>> Yes, but the invocation of PCM softvol isn't guaranteed to be first
>> before the reference to the already existing user ctl element.
>> snd_mixer_open() can be called before that.
> 
> So this is a transient problem, right? As soon as the first PCM is 
> opened, the TLV would be corrected, and then stay corrected for all 
> times to come.
> 
> And looking at the current PulseAudio code, it does open the pcm device 
> before it opens the mixer/ctl device.
> So, if this isn't possible to solve in a better way, maybe we need to be 
> pragmatic about it - PulseAudio is the only application we know that 
> would care, and it opens the pcm device first. So in practice, it looks 
> like the TLV approach would work.

It would work even if the mixer is opened before PCM, because the mixer
will get notified about the TLV change and can make the PCM element
inactive after. PA should only handle this situation correctly.

>>>>>> You may think of adding the code to softvol plugin to automatically
>>>>>> rewrite TLV of the existing ctl element if it contains no new TLV
>>>>>> type.  But, PA shall skip softvol.  Thus, it won't be touched.  And
>>>>>> yet, PA would like to skip the control elements that have been created
>>>>>> beforehand.
>>>>>
>>>>> The alsa-lib code can be modified to create or modify the user space
>>>>> control also in the SND_PCM_NO_SOFTVOL case, so the mixer API will be
>>>>> informed that the PCM controls belongs to softvol.
>>>>
>>>> But how would you know exactly?  Parsing the PCM definition at each
>>>> time if a user ctl element is found and check whether it *might*
>>>> belong to softvol plugin defined in some of card's default config?
>>>
>>> No. The information in TLV would be enough to determine the softvol
>>> functionality.
>>>
>>>> What if a user takes own definition temporarily?
>>>
>>> Then user is responsible to remove this control later.
>>
>> That's messy.  We provide no such tool.

Perhaps amixer should be extended.

>>>> There can be endless corner cases.
>>>
>>> I'm not sure what you talk about. Yes, everything can be misused, but
>>> we're talking about the standard usage. You can do weird things with the
>>> softvol user controls anyway (remove them during runtime, because
>>> they're not locked).
>>
>> I know I'm picky, but adding a new metadata *onto* the existing data
>> structure has to be always done carefully.  Otherwise it'll hit back
>> us later.
> 
> I think it's good that you are picky. Missing a use case can cause 
> problems indeed. But is there another solution to this problem which is 
> better?
> 
>> For example, another corner case I can think of easily is that user
>> downgrades alsa-lib.  Then softvol overrides the TLV again without the
>> new tag (the current softvol code assumes the single TLV and overrides
>> if it doesn't fit), and it can be saved so...
>>
>>>> BTW, does the alsaloop device just work as is, i.e. without specifying
>>>> anything in PA's configuration?
>>>
>>> The alsaloop can run on top of the snd-aloop, so it behaves like a
>>> standard hardware, only the mixer controls can be rerouted using the
>>> user controls to the real card.
>>
>> OK.  But, looking at the current implementation, you are allowed to
>> map freely the source ctl element.  It can lead to the same problem in
>> PA.
>>
>> The very reason we'd like to filter out the mixer control created by
>> softvol is that this mixer element confuses PA as if it actually

Why it can confuse PA? It behaves like standard soundcard and user can
select the forwarded controls (for example Master and PCM or Front
only). PA don't have any hint that the audio is rerouted and it's correct.

>> changes the volume (e.g. "PCM") although PA ignores the softvol.  If
>> user creates PCM volume in alsaloop in a different fashion as PA
>> expected, the similar problem may happen.  How can we detect this
>> logically...?  In other words, how can PA adjust the mixer elements
>> for alsaloop properly?
> 
> So if alsaloop is run, only once, that could cause a control to be added 
> for all future, due to alsactl saving and restoring it?
> 
> If so, that looks like a problem with alsaloop. If it adds controls, it 
> should also remove them.

These controls are removed when alsaloop exits.

					Jaroslav

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