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!
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
