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. > > 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? Cheers, Arun
