Em 24-09-2011 09:33, Stas Sergeev escreveu:
24.09.2011 16:05, Mauro Carvalho Chehab wrote:
Better to post it as a separate patch, and to simplify the code with:
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c b/drivers/media/video/saa7134/saa7134-tvaudio.c index 57e646b..a61ed1e 100644 --- a/drivers/media/video/saa7134/saa7134-tvaudio.c +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c @@ -332,6 +332,12 @@ static int tvaudio_checkcarrier(struct saa7134_dev *dev, struct mainscan *scan) { __s32 left,right,value;
- if (!dev->tvnorm->id& scan->std)) {
Missing open bracket?
Yes. patch were of course not tested ;)
I meant to say:
if (!(dev->tvnorm->id & scan->std)) {
@@ -546,6 +546,7 @@ static int tvaudio_thread(void *data) dev->tvnorm->name, carrier/1000, carrier%1000, max1, max2); dev->last_carrier = carrier;
dev->automute = !(dev->thread.scan1> 1);Why?
Unfortunately, that's the trick. :(
If the carrier is good, this should be enough:
dev->automute = 0;Unfortunately, sometimes it misdetects.
There's nothing the driver can do if the hardware missdetects a carrier. Dirty tricks to try solving it are not good, as they'll do the wrong thing on some situations.
Testing dev->thread.scan1 means that at least the first scan, done on the driver init, won't unmute. So either that, or this whole patch is unhelpful. I realize that this is a dirty hack, yes.
This is a dirty hack, and it assumes that the first scan should be discarded. This is true only on certain environments. If someone is using the board on an environment without udev and pulseaudio, this trick will break the first tuning.
The rest looked sane on my eyes, but I didn't double-checked it by running on my cards. Had you test calling it with just a single standard, and with a multiple standards mask?
With just a single standard. That's the problem too. There are the fallbacks, like last_carrier etc, and do we need to unmute there or not? :(
The right fix that pulseaudio should not touch at the audio mixers for the video boards.
That's where we disagree. I wonder what other people think. I don't see the compelling reason for making the alsa interface to the v4l devs a special case. If there is just a mute control exported, there is no more a special case, and no more hacks and problems.
Not all boards have an audio carrier detection like saa7134.
Having the mute control exported would make this not a problem.
Well, if you think that this would solve, then just write a patch exporting the mute control via ALSA. I have no problems with that.
Regards, Mauro.