On 06/26/2013 08:59 AM, Arun Raghavan wrote: > On Thu, 2013-05-16 at 08:31 +0200, David Henningsson wrote: >> On 05/15/2013 06:28 PM, Takashi Iwai wrote: > [...] >>> 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. >> > [...] >>> 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 >>> changes the volume (e.g. "PCM") although PA ignores the softvol. If > > Actually, we don't currently ignore softvol. I guess we could add the > no-softvol flag once we're able to make sure we don't have any softvol > controls. Correct. >>> 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. >> >> If no, I don't think we need to worry. Alsaloop is probably mostly used >> on non-PA systems (as PA has module-loopback which does the same thing). > > Seems this thread died out. I didn't quite understand the > alsaloop/alsactl-specific concerns, tbh. What do we need to do to take > this forwards? It was suggested that softvol controls would store this information in TLV, which leads to a transient problem on upgrading, but nobody suggested anything better. The transient problem is caused by alsactl loading the control from asound.state, which contains the old TLV information. But as soon as a PCM stream is opened, this will be corrected, AFAIU, and then the correct TLV information will be stored in asound.state at next reboot. So I'm guessing that patches are welcome for that solution (in combination with a CTL_OPEN_NO_SOFTVOL flag), and nobody volunteered yet to implement it. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic
