Em 22-07-2011 17:40, Stas Sergeev escreveu: > 22.07.2011 17:03, Mauro Carvalho Chehab wrote: >> Here, I add the following line at my .mplayer/config: >> >> tv = "driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1" > Thanks for starting to answer what I was asking for over a week. :) > If this is the case (not verified yet), there may be the simple > automute logic that will fix that in an absense of an auto-unmute > in alsa. > Initially, the driver may be put in an auto-mute state. > It is mute until the tuner is tuned: after the tuner is tuned, > the audio gets immediately automatically unmuted. > If the app does not want this to happen, it may use > the V4L2_CID_AUDIO_MUTE before tuning, to put the device > in a permanent-mute state. > So, in short, I suggest to bind the auto-unmute to the > tuner tune, rather than to the capture start. And that > should be a separate, third mute state, automute. If the > app explicitly wants the mute or unmute, this automute > logic disables. > Do you know any app that will regress even with that? Mplayer was just one example of an application that I know it doesn't call V4L2_CID_AUDIO_MUTE to unmute. I didn't check for other applications and scripts that may break with such change. Your approach of moving it to VIDIOC_S_FREQUENCY (if I understood well) won't work, as, every time someone would change the channel, it will be unmuted, causing troubles on applications like "scantv" (part of xawtv). You can't associate such logic to any ioctl, due to the same reasons. Also, associating with V4L open also will cause side effects, as udev opens all V4L devices when the device is detected. You should also remind that it is possible to use a separate application (like v4l2-ctl) while a device is opened by other applications, and even to not have the device opened while streaming (radio applications allow that). Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html