[alsa-devel] [patch][saa7134] do not change mute state for capturing audio
stsp at list.ru
Wed Jul 20 07:28:57 CEST 2011
20.07.2011 04:55, Mauro Carvalho Chehab wrote:
>> The proposed solution is to have the mute
>> control, that can be valid for all the cards/drivers.
>> Presumably, it should have the similar name
>> for all of them, even though for some it will be
>> a "virtual" control that will control several items,
>> and for others - it should map directly to their
>> single mute control.
>> If we have such a mute control, any app can use
> Any app can do it right now via the V4L2 api.
I am just following your logic, you said that
Moving such logic to happen at userspace would be very complex, and will
break existing applications.
To solve that, I proposed adding such mixer control
to where it is missing right now.
But if this is no longer a problem and the app
can just use v4l2 for that instead, then what still
keeps us from removing the auto-unmute things?
>> and the auto-unmute logic can be removed
>> from the alsa driver. v4l2 is left as it is now.
> What is the sense of capturing data for a device that is not ready
> for stream?
This may be a PA's hack, or a user's mistake, or
whatever, but whatever it is, it shouldn't lead to
any sounds from speakers. Just starting the capture,
willingly or by mistake, should never lead to any
sound from speakers, IMO. So that's the bug too.
And the simpler one to fix.
>> So that's the proposal, what problems can you see
>> with it?
> Userspace application breakage is not allowed. A change like
> that will break the existing applications like mplayer.
No, because, as you said, it uses v4l2, not alsa,
And my proposal only affects alsa, so what's the
> Maybe your device is not a saa7134. For saa7133/saa7135, the
> mute/unmute seems to be done via GPIO, and via amux.
Yes, and that's exacly why unmuting only I2S
does nothing: the muxes are still set up for mute.
>> IIRC the problem was that this does not mute the
>> sound input from the back panel of the board, which
>> would then still go to the pass-through wire in case
>> you are capturing. The only way do mute it, was to
>> configure muxes the way you can't capture at the
>> same time. But I may be wrong with the recollections.
> Well, the change seems to be simple, as we don't actually need to
> split the mute. We just need to control the I2S input/output at
> the alsa driver.
> The enclosed patch probably does the trick (completely untested).
I'll be able to test it on avertv 307 the next week-end.
But what is the expected effect of that patch?
It looks much like mine: mostly just removes auto-unmute,
doing that in a not-so-obvious way.
The card is muted by setting up the muxes.
Now you unmute it by enabling I2S, but the muxes
are still set to mute, so nothing happens, and you
will capture the silence.
I think this patch is _correct_, as it removes the
auto-unmute logic; exactly what I proposed. :)
Just a slightly different implementation, unless
I am missing something obvious...
By the way, do you need to do
from mute_input_7134() ? Maybe leaving that I2S
control entirely for alsa, and not touching it elsewhere?
The function itself can probably then be moved to
More information about the Alsa-devel