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?
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, to unmute. And my proposal only affects alsa, so what's the breakage?
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
saa7134_i2s_mute(dev, mute);
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 saa7134-alsa.c.
Thanks!