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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
