[saa7134] do not change mute state for capturing audio

Em 20-07-2011 02:28, Stas Sergeev escreveu:
> 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
>>> it,
>> 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?

I won't keep discussing something that won't be merged, as it will
cause regressions.

>>> 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.

If the application is starting streaming, audio should be expected on devices 
where the audio output is internally wired with the capture input.
This seems to be the case of your device. There's nothing that can be
done to fix a bad hardware design or the lack of enough information
from the device manufacturer.

>> The enclosed patch probably does the trick (completely untested).
> I'll be able to test it on avertv 307 the next week-end.

The patch is not that simple. The driver needs to set the device inputs
accordingly, otherwise it will break support for digital audio. 

In the specific case of avertv 307, this patch alone may not work. I suspect
that there is a problem at the GPIO settings for mute on its board entry:

[SAA7134_BOARD_AVERMEDIA_STUDIO_307] = {
...
                .inputs         = {{
                        .name = name_tv,
                        .vmux = 1,
                        .amux = TV,
                        .tv   = 1,
                        .gpio = 0x00,
                },{
...
                .mute  = {
                        .name = name_mute,
                        .amux = LINE1,
                        .gpio = 0x00,
                },

See: mute GPIO's are equal for TV GPIO. That means that it will select the
TV gpio for "mute".

-

[PATCHv2 - BROKEN] saa7134: Don't touch at the analog mute at the alsa driver

Via the alsa driver, it is possible to start capturing from an audio input.
When capture is started, the driver will unmute the audio input associated
with the selected video input, if it were muted. 

However, if the device is using a wire for the audio output, it may produce 
audio at the speakers. This patch changes the mute logic to:
	1) on saa7134, don't touch at the ANALOG_MUTE at alsa unmute call;
	2) don't change the GPIO's.

I suspect, however, that not changing the GPIO's is a very bad idea, and
it will actually break audio for devices with external GPIO-based input
switches, but, as this version was already done, it might be useful for some
tests. A version 3 will follow shortly.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[saa7134] do not change mute state for capturing audio

Commit Message

Comments

Patch