Re: [alsa-devel] [patch][saa7134] do not change mute state for capturing audio
15.07.2011 05:38, Mauro Carvalho Chehab wrote:
If you want, feel free to propose a patch fixing that logic at saa7134, instead of just removing it.
Hi, I've just verified that pulseaudio indeed does the sound capturing on startup: --- saa7134[0]/alsa: saa7134[0] at 0xfe8fb800 irq 22 registered as card 2 saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: irq: field oops [even] ---
So your proposal is not going to fix anything at all.
Can we get back to discussing/applying mine then? And if the other drivers has that autounmute logic, then I suggest removing it there as well. You have not named any use-case for it, so I think there is none. I also think that the whole auto-unmute logic in your drivers is entirely flawed: for instance, I don't think recording from the sound card will automatically unmute its line-in or something else, so you are probably not following the generic alsa style here. I am adding alsa-devel to CC to find out what they think about that whole auto-unmute question.
Hi Stas,
Em 17-07-2011 06:44, Stas Sergeev escreveu:
15.07.2011 05:38, Mauro Carvalho Chehab wrote:
If you want, feel free to propose a patch fixing that logic at saa7134, instead of just removing it.
Hi, I've just verified that pulseaudio indeed does the sound capturing on startup:
saa7134[0]/alsa: saa7134[0] at 0xfe8fb800 irq 22 registered as card 2 saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=1 => fmt=0xcd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: rec_start: afmt=2 ch=2 => fmt=0xdd swap=- saa7134[0]/alsa: irq: field oops [even]
(Added Lennart to the c/c list)
If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there. I fail to understand why pulseaudio would start capturing sound from a V4L audio at startup.
I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here.
I don't know enough about pulseaudio to help on this issue, nor I'm using it currently, so I can't test anything pulsaudio-related.
Lennart,
Could you please help us with this issue?
Thanks! Mauro
So your proposal is not going to fix anything at all.
Can we get back to discussing/applying mine then? And if the other drivers has that autounmute logic, then I suggest removing it there as well. You have not named any use-case for it, so I think there is none. I also think that the whole auto-unmute logic in your drivers is entirely flawed: for instance, I don't think recording from the sound card will automatically unmute its line-in or something else, so you are probably not following the generic alsa style here. I am adding alsa-devel to CC to find out what they think about that whole auto-unmute question.
17.07.2011 15:51, Mauro Carvalho Chehab wrote:
(Added Lennart to the c/c list) If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there.
Why?
I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here.
I've seen such a problem mentioned on the russion linux resource a few years ago... The reason why it was never mentioned on that list, is probably that noone tracked it down to the saa7134_alsa driver yet. But maybe the reason is different, ok, lets see what Lennart thinks.
Heya,
On 17.07.2011 13:51, Mauro Carvalho Chehab wrote:
If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there. I fail to understand why pulseaudio would start capturing sound from a V4L audio at startup.
I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here.
I don't know enough about pulseaudio to help on this issue, nor I'm using it currently, so I can't test anything pulsaudio-related.
Lennart,
Could you please help us with this issue?
ALSA doesn't really have a enumeration API which would allow us to get device properties without opening and configuring a device. In fact, we can't even figure out whether a device may be opened in duplex or simplex without opening it.
And that's why we have to probe audio devices, even if it sucks.
Lennart
19.07.2011 03:16, Lennart Poettering wrote:
ALSA doesn't really have a enumeration API which would allow us to get device properties without opening and configuring a device. In fact, we can't even figure out whether a device may be opened in duplex or simplex without opening it.
And that's why we have to probe audio devices, even if it sucks.
Hi Lennart, thanks for your opinion.
I am puzzled with the "even if it sucks" part, what does it mean? I see 2 possible interpretations of it:
1. "Even if it sucks with some drivers that have bugs, like the saa7134_alsa one". If that interpretation is what you implied, then could you please also evaluate the fix like this one: http://www.spinics.net/lists/linux-media/msg35237.html
2. "Even if it sucks in general". In this case, what solution would you propose to get the problem of the white noise fixed?
On Tue, 19.07.11 10:31, Stas Sergeev (stsp@list.ru) wrote:
- "Even if it sucks in general". In this case, what solution
would you propose to get the problem of the white noise fixed?
Well, for removing the probing in PA we'd need a way to reliably figure out in which combinations of input and output we can open a sound card. i.e. we want to know if we can run surround 5.1 output and spdif output at the same time, or surround 5.1 output and stereo input and so on. And we'd need a lot of other attrbites about the sound card, and all that without having to open any PCM device.
But that would be really hard to do, the current format neagotiation in ALSA PCM works very differently. And that's the reason why so far nobody has bothered with getting this right.
The current code in PA to figure this out is somewhat ugly. It's slow, since we open the card in a lot of different combinations to test what works. It's fragile, since if somebody else has opened the soundcard we get an EBUSY which we take as hint that a specific combination didn't work, and so on.
It's a hard problem,
Lennart
Em 18-07-2011 20:16, Lennart Poettering escreveu:
Heya,
On 17.07.2011 13:51, Mauro Carvalho Chehab wrote:
If pulseaudio is starting sound capture at startup, then it is either a pulseaudio miss-configuration or a bug there. I fail to understand why pulseaudio would start capturing sound from a V4L audio at startup.
I think that this is not the default for pulseaudio, though, as you're the only one complaining about that, and I never saw such behavior in the time I was using pulseaudio here.
I don't know enough about pulseaudio to help on this issue, nor I'm using it currently, so I can't test anything pulsaudio-related.
Lennart,
Could you please help us with this issue?
ALSA doesn't really have a enumeration API which would allow us to get device properties without opening and configuring a device. In fact, we can't even figure out whether a device may be opened in duplex or simplex without opening it.
And that's why we have to probe audio devices, even if it sucks.
Lennart,
The thing is that starting capture on a video device has some side effects, as it will start capturing from a radio or TV station without specifying the desired frequency.
Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream.
So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise.
The right thing to do is to get rid of capturing on a video device, if you're not sure that the device is properly tuned.
It is easy to detect that an audio device is provided by a v4l device. All you need to do is to look at the parent device via sysfs.
Cheers, Mauro
On Tue, 19.07.11 10:00, Mauro Carvalho Chehab (mchehab@infradead.org) wrote:
Heya,
The thing is that starting capture on a video device has some side effects, as it will start capturing from a radio or TV station without specifying the desired frequency.
Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream.
So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise.
The right thing to do is to get rid of capturing on a video device, if you're not sure that the device is properly tuned.
It is easy to detect that an audio device is provided by a v4l device. All you need to do is to look at the parent device via sysfs.
So what we actually support in PA, is that you can disable the probing for specific sound cards if you supply a file that describes what should be exposed in PA for the sound card instead. We use that for a number of pro audio cards, where we want to show nicer human readable strings for specific configurations.
This is configured in /usr/share/pulseaudio/alsa-mixer/paths/, /usr/share/pulseaudio/alsa-mixer/profile-sets/* and /lib/udev/rules.d/90-pulseaudio.rules.
The udev rules files binds a profile set to a specific sound device. The profile set then declares in which combinations a sound card can be opened for input and output, and which mixer paths to expose.
Note that the profile sets/mixer paths are supposed to be user-friendly. Hence instead of exposing all options they are designed to expose only the minimum that is useful in the UI. And the emphasis is on usefulness here, so the options the user can choose should be few, not overwhlemingly many.
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html
It might make sense to add that for your TV card to PA as well.
Lennart
19.07.2011 17:00, Mauro Carvalho Chehab wrote:
Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream. So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise.
This needs to be clarified a bit (for Lennart). Initially, before the board is tuned to some station, the sound is wisely muted. It is muted for both the capturing and the pass-through cable. As far as I can tell, if you want to probe the card by capturing, you can capture the silence, you don't need any real sound to record. The problem here is that the particular driver has a "nice code" (or a hack) that unmutes both the capturing and the pass-through cable when you capture anything.
Em 19-07-2011 10:49, Stas Sergeev escreveu:
19.07.2011 17:00, Mauro Carvalho Chehab wrote:
Several video boards have the option of plugging a loop cable between the device output pin and the motherboard line in pin. So, if you start capturing, you'll also enabling the output of such pin, as the kernel driver has no way to know if the user decided to use a wire cable, instead of the ALSA PCM stream. So, if users with such cables are lucky, it will play something, but, on most cases, it will just tune into a non-existing station, and it will produce a white noise.
This needs to be clarified a bit (for Lennart). Initially, before the board is tuned to some station, the sound is wisely muted. It is muted for both the capturing and the pass-through cable. As far as I can tell, if you want to probe the card by capturing, you can capture the silence, you don't need any real sound to record. The problem here is that the particular driver has a "nice code" (or a hack) that unmutes both the capturing and the pass-through cable when you capture anything.
It is not something for "a particular driver". All v4l alsa drivers have similar logic: they assume that, if some application is streaming, the device should be unmuted, otherwise capture won't work.
From my POV, exactly that leads to the problem. Simply removing that piece of code makes the peace in the world: the app that tunes the board, also unmutes the sound anyway.
It is not clear, from an application POV, to know what audio pin should be unmuted. Some devices, like, for example, em28xx may have an ac97 connected on it, with lots of muxes on it. For each different video input port, a different mixer set should be used, and the configuration is board-dependent.
For example, on Prolink PlayTV USB2, this is wired as:
AC97 mono volume => PCM output AC97 master volume => Line out pin AC97 video volume => TV tuner input AC97 line in volume => Svideo or composite input
As this is an USB device, in general, people don't connect the line out pin. So, typically, in order to unmute this particular device for TV, one should unmute both AC97 MONO and AC97 VIDEO, and mute AC97 LINE IN.
If the application latter changes to SVideo, the AC97 VIDEO should be muted, and AC97 LINE IN should be unmuted.
There's no way for an userspace application to know that, since: 1) The device internal connections are not visible on userspace; 2) This is board-dependent. For example, Supercomp USB 2.0 TV has just the opposite setup for TV/svideo: AC97 video volume => Svideo or Composite Input AC97 line in volume => TV Input and doesn't have any output volume connected. 3) On some cases, there are two or even three mutes that need to be changed.
Moving such logic to happen at userspace would be very complex, and will break existing applications.
Cheers, Mauro.
My question was and still is: do we need to search for any other solution at all? Do we need to modify PA, if it is entirely fine with capturing the silence for probing audio? -- 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
19.07.2011 18:10, Mauro Carvalho Chehab wrote:
As this is an USB device, in general, people don't connect the line out pin. So, typically, in order to unmute this particular device for TV, one should unmute both AC97 MONO and AC97 VIDEO, and mute AC97 LINE IN.
If the application latter changes to SVideo, the AC97 VIDEO should be muted, and AC97 LINE IN should be unmuted.
Unless I am missing the point, you need some mixer control that will just unmute the "currently-configured things". If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps.
Moving such logic to happen at userspace would be very complex, and will break existing applications.
If this is the case, then how does the simplest xawtv's mute/unmute thing works with all these boards right now? (not that I have checked it does, but I hope so. :)
Em 19-07-2011 11:56, Stas Sergeev escreveu:
19.07.2011 18:10, Mauro Carvalho Chehab wrote:
As this is an USB device, in general, people don't connect the line out pin. So, typically, in order to unmute this particular device for TV, one should unmute both AC97 MONO and AC97 VIDEO, and mute AC97 LINE IN.
If the application latter changes to SVideo, the AC97 VIDEO should be muted, and AC97 LINE IN should be unmuted.
Unless I am missing the point, you need some mixer control that will just unmute the "currently-configured things". If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps.
That is the current logic, except that we don't create an additional virtual mixer control like the one you've proposed via ALSA API.
The business logic coded into the Kernel is that, when audio stream is started or a different input is selected, the driver checks the current applicable mute/volumes and sets the pertinent ones to unmute, muting the others.
Yet, they allow users to manually adjust the volume controls, as someone may want for example to use the mixer to mix the original TV audio with a microphone, for example, connected at the LINE IN input that some boards offer.
Also, some newer devices are coming with the capability of mixing video inputs (s5p driver recently added a video mixer). It makes sense for applications that use it, to also allow controlling the audio mixer.
That's basically why we want to expose such controls to userspace: to allow users to control the audio mixer when they need, for whatever reason.
If I understood PA concepts, its philosophy seems to hide those controls that aren't meant to be used by the default usecase. As such, it should not be exposing any mixer/mute at all from a V4L device.
The proper fix seems to make PA to use libmedia_dev[1] to detect what audio input devices are associated with a V4L board and removing them for the list of controlled devices by default, eventually allowing the users to add them again via some configuration parameter.
[1] http://git.linuxtv.org/v4l-utils.git?a=blob;f=utils/libmedia_dev/README
Moving such logic to happen at userspace would be very complex, and will break existing applications.
If this is the case, then how does the simplest xawtv's mute/unmute thing works with all these boards right now? (not that I have checked it does, but I hope so. :)
Xawtv mute/unmute probably needs fix. It uses 3 different API's for that: V4L2, ALSA and OSS. Most of the logic there is for OSS, witch can be removed nowadays.
Feel free to submit patches for it.
Yet, as you may be aware of that, the V4L2 API offers a few audio controls (volume, mute, balance, bass, treble), that applies to the current stream, on the drivers that provide them. So, a video application may opt to not control the alsa mixers directly, but, instead, use the V4L2 controls.
Thanks, Mauro
19.07.2011 19:27, Mauro Carvalho Chehab wrote:
Unless I am missing the point, you need some mixer control that will just unmute the "currently-configured things". If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps.
That is the current logic, except that we don't create an additional virtual mixer control like the one you've proposed via ALSA API.
Unless I am mistaken, this control is usually called a "Master Playback Switch" in the alsa world. So, am I right that the only problem is that it is not exported to the user by some drivers right now? And, if it is made exported, what will still prevent us from dropping the auto-unmute stuff?
Yet, as you may be aware of that, the V4L2 API offers a few audio controls (volume, mute, balance, bass, treble), that applies to the current stream, on the drivers that provide them. So, a video application may opt to not control the alsa mixers directly, but, instead, use the V4L2 controls.
In this case, I think, the alsa mixer control should just mirror the one of the v4l2 for the most cases. Maybe for some boards they can actually do the different things - doesn't matter right now though.
Em 19-07-2011 12:50, Stas Sergeev escreveu:
19.07.2011 19:27, Mauro Carvalho Chehab wrote:
Unless I am missing the point, you need some mixer control that will just unmute the "currently-configured things". If you can unmute all the right things when an app just starts capturing, then you can as well unmute the same things by that _single_ mixer control. And if the app changes the output to SVideo, as in your example, you can first mute everything, and then unmute the new lines, but only if the old lines were unmuted. IMHO, that logic will not break the existing apps.
That is the current logic, except that we don't create an additional virtual mixer control like the one you've proposed via ALSA API.
Unless I am mistaken, this control is usually called a "Master Playback Switch" in the alsa world.
No, you're mistaken: on most boards, you have only one volume control/switch, for capture. So, it would be a "master capture switch", but I don't think that there's such alsa "generic" volume control. Even in the case where you have a volume control for the LINE OUT pin[1], in general, you also need to unmute the capture, so, it would be a "master capture and LINE OUT switch", and, for sure alsa currently not provide anything like that.
So, am I right that the only problem is that it is not exported to the user by some drivers right now?
No, you're mistaken again. Such "master capture and LINE OUT switch" type of control _is_exported_ via the V4L2 API as V4L2_CID_AUDIO_MUTE.
And, if it is made exported, what will still prevent us from dropping the auto-unmute stuff?
Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. (mplayer is not symmetric with regard to the usage of this control, as it uses V4L2_CID_AUDIO_MUTE to mute the device after the end of a capture).
So, changing the logic at the drivers will break existing applications.
It should be noticed that the alsa module is only enabled on devices that provides PCM output via the PCI or USB bus.
On the other hand, the V4L2_CID_AUDIO_MUTE control is available for all devices that are capable of muting/unmuting the audio. That's why V4L applications rely on it, instead of using alsa mixers.
I dunno what's your specific saa7134 device model, but, from what I understood, instead of using the PCM output, you're using the LINE OUT pin.
It is probably doable to split the mute control for the LINE OUT pin from the mute control of the PCM capture. Such patch would make sense, as the alsa capture doesn't need to touch at the line out pin, but the patch should let V4L2_CID_AUDIO_MUTE control to affect both LINE OUT and PCM capture mutes, otherwise applications will break.
Yet, as you may be aware of that, the V4L2 API offers a few audio controls (volume, mute, balance, bass, treble), that applies to the current stream, on the drivers that provide them. So, a video application may opt to not control the alsa mixers directly, but, instead, use the V4L2 controls.
In this case, I think, the alsa mixer control should just mirror the one of the v4l2 for the most cases. Maybe for some boards they can actually do the different things - doesn't matter right now though.
We need a solution that works for both simple and complex devices.
-
[1] IMHO, "LINE OUT" pin doesn't fit very well on playback/capture concept. The capture volume/switch controls the A/D circuits for capture, while the playblack controls the D/A circuits. However, the LINE OUT pin gets audio from the captured data, and doesn't allow to direct any other PCM data into the D/A. So, it is not a "complete" playback type of control. So, it won't fit at the "Master Playback Switch" type.
Cheers, Mauro
19.07.2011 22:06, Mauro Carvalho Chehab wrote:
Unless I am mistaken, this control is usually called a "Master Playback Switch" in the alsa world.
No, you're mistaken: on most boards, you have only one volume control/switch, for capture. So, it would be a "master capture switch",
Well, for such a cards we don't need to export the additional element, they are fine already. We can rename it to "Master Capture Switch", or may not.
but I don't think that there's such alsa "generic" volume control. Even in the case where you have a volume control for the LINE OUT pin[1], in general, you also need to unmute the capture, so, it would be a "master capture and LINE OUT switch", and, for sure alsa currently not provide anything like that.
I think you can still call it a "Master Capture Switch", if it enables everything.
So, am I right that the only problem is that it is not exported to the user by some drivers right now?
No, you're mistaken again. Such "master capture and LINE OUT switch" type of control _is_exported_ via the V4L2 API as V4L2_CID_AUDIO_MUTE.
Sorry, I meant the _alsa_ drivers here. So, to rephrase:
So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now?
Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. (mplayer is not symmetric with regard to the usage of this control, as it uses V4L2_CID_AUDIO_MUTE to mute the device after the end of a capture).
So, changing the logic at the drivers will break existing applications.
I do not propose changing any V4L2 ioctls, my change concerns only the alsa driver.
It is probably doable to split the mute control for the LINE OUT pin from the mute control of the PCM capture. Such patch would make sense, as the alsa capture doesn't need to touch at the line out pin, but the patch should let V4L2_CID_AUDIO_MUTE control to affect both LINE OUT and PCM capture mutes, otherwise applications will break.
That's exactly what I was talking about from the very beginning, saying that the single control currently controls way too much, and providing an examples about 2 separate controls. But... I haven't found the way to implement that, not sure of this is possible at all. :(
Em 19-07-2011 15:38, Stas Sergeev escreveu:
19.07.2011 22:06, Mauro Carvalho Chehab wrote:
Unless I am mistaken, this control is usually called a "Master Playback Switch" in the alsa world.
No, you're mistaken: on most boards, you have only one volume control/switch, for capture. So, it would be a "master capture switch",
Well, for such a cards we don't need to export the additional element, they are fine already. We can rename it to "Master Capture Switch", or may not.
Adding a new volume control that changes the mute values for the other controls or renaming it don't solve anything.
but I don't think that there's such alsa "generic" volume control. Even in the case where you have a volume control for the LINE OUT pin[1], in general, you also need to unmute the capture, so, it would be a "master capture and LINE OUT switch", and, for sure alsa currently not provide anything like that.
I think you can still call it a "Master Capture Switch", if it enables everything.
That would be wrong.
So, am I right that the only problem is that it is not exported to the user by some drivers right now?
No, you're mistaken again. Such "master capture and LINE OUT switch" type of control _is_exported_ via the V4L2 API as V4L2_CID_AUDIO_MUTE.
Sorry, I meant the _alsa_ drivers here. So, to rephrase:
So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now?
I fail to see why this would be a problem.
The problem I see is that PA is trying to handle a V4L device as if it would be a normal audio capture pin, and starting a capture while the device is not ready for that, as no input or TV/radio station were selected at the time PA starts capturing.
Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. (mplayer is not symmetric with regard to the usage of this control, as it uses V4L2_CID_AUDIO_MUTE to mute the device after the end of a capture).
So, changing the logic at the drivers will break existing applications.
I do not propose changing any V4L2 ioctls, my change concerns only the alsa driver.
It is probably doable to split the mute control for the LINE OUT pin from the mute control of the PCM capture. Such patch would make sense, as the alsa capture doesn't need to touch at the line out pin, but the patch should let V4L2_CID_AUDIO_MUTE control to affect both LINE OUT and PCM capture mutes, otherwise applications will break.
That's exactly what I was talking about from the very beginning, saying that the single control currently controls way too much, and providing an examples about 2 separate controls. But... I haven't found the way to implement that, not sure of this is possible at all. :(
It is doable, although it is probably not trivial.
Devices with saa7130 (PCI_DEVICE_ID_PHILIPS_SAA7130) doesn't enable the alsa module, as they don't support I2S transfers, required for PCM audio. So, we need to take care only on saa7133/4/5 devices.
The mute code is at saa7134-tvaudio.c, mute_input_7134() function. For saa7134, it does:
if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) /* 7134 mute */ saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? SAA7134_MUTE_MASK | SAA7134_MUTE_ANALOG | SAA7134_MUTE_I2S : SAA7134_MUTE_MASK);
Clearly, there are two mute flags: SAA7134_MUTE_ANALOG and SAA7134_MUTE_I2S.
I2S is for PCM (as it is a digital audio interface). The other flag is for analog.
So, if the device is a saa7134, it is easy to split the analog output and the PCM one. For saa7133 and saa7135, you probably need to double check at the datasheet, is is there a way to disable/enable just the I2S interface, but, from saa7134_enable_i2s(): /* Start I2S */ saa_writeb(SAA7134_I2S_AUDIO_OUTPUT, 0x11);
I bet that there is some value (maybe 0?) that disables I2S transfers, muting the PCM stream. It should be tested if saa7133/5 devices accept to enable/disable PCM streams if the device is already streaming.
Cheers, Mauro
19.07.2011 23:29, Mauro Carvalho Chehab wrote:
the additional element, they are fine already. We can rename it to "Master Capture Switch", or may not.
Adding a new volume control that changes the mute values for the other controls or renaming it don't solve anything.
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, and the auto-unmute logic can be removed from the alsa driver. v4l2 is left as it is now. So that's the proposal, what problems can you see with it?
So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now?
I fail to see why this would be a problem.
But that was the problem _you_ named. That is, that right now the app will have difficulties unmuting the complex boards via the alsa interface, because it will have to unmute several items instead of one. I propose to add the single item for that, except for the drivers that already have only one mute switch. With this, the problem you named, seems to be solved. And then, perhaps, the auto-unmute logic can go away. What am I missing?
It is doable, although it is probably not trivial. Devices with saa7130 (PCI_DEVICE_ID_PHILIPS_SAA7130) doesn't enable the alsa module, as they don't support I2S transfers, required for PCM audio. So, we need to take care only on saa7133/4/5 devices.
The mute code is at saa7134-tvaudio.c, mute_input_7134() function. For saa7134, it does:
if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) /* 7134 mute */ saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? SAA7134_MUTE_MASK | SAA7134_MUTE_ANALOG | SAA7134_MUTE_I2S : SAA7134_MUTE_MASK);Clearly, there are two mute flags: SAA7134_MUTE_ANALOG and SAA7134_MUTE_I2S.
I was actually already playing with that piece of code, and got no results. Will retry the next week-end to see exactly why... 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.
Em 19-07-2011 18:57, Stas Sergeev escreveu:
19.07.2011 23:29, Mauro Carvalho Chehab wrote:
the additional element, they are fine already. We can rename it to "Master Capture Switch", or may not.
Adding a new volume control that changes the mute values for the other controls or renaming it don't solve anything.
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.
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? PA is doing the wrong thing here, due to the lack of a better API support: it is starting stream on a device as a hacky way of probing it. As Lennart pointed, even considering a pure audio device, this is ugly and takes time.
IMO, the right long term fix is to provide alsa some ioctl that allows PA to get the needed info without needing to start streaming, and, for the short term, to prevent it to start capture on tuner/grabber devices.
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.
So, am I right that the only problem is that it is not exported to the user by some _alsa_ drivers right now?
I fail to see why this would be a problem.
But that was the problem _you_ named. That is, that right now the app will have difficulties unmuting the complex boards via the alsa interface, because it will have to unmute several items instead of one. I propose to add the single item for that, except for the drivers that already have only one mute switch. With this, the problem you named, seems to be solved. And then, perhaps, the auto-unmute logic can go away. What am I missing?
It is doable, although it is probably not trivial. Devices with saa7130 (PCI_DEVICE_ID_PHILIPS_SAA7130) doesn't enable the alsa module, as they don't support I2S transfers, required for PCM audio. So, we need to take care only on saa7133/4/5 devices.
The mute code is at saa7134-tvaudio.c, mute_input_7134() function. For saa7134, it does:
if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) /* 7134 mute */ saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? SAA7134_MUTE_MASK | SAA7134_MUTE_ANALOG | SAA7134_MUTE_I2S : SAA7134_MUTE_MASK);Clearly, there are two mute flags: SAA7134_MUTE_ANALOG and SAA7134_MUTE_I2S.
I was actually already playing with that piece of code, and got no results. Will retry the next week-end to see exactly why...
Maybe your device is not a saa7134. For saa7133/saa7135, the mute/unmute seems to be done via GPIO, and via amux.
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).
As I said before, before adding this patch upstream, we need to double check if it will work with saa7134, saa7133 and saa7135, preserving the old behavior on those devices.
-
saa7134: Don't touch at the analog mute at the alsa driver
Instead of setting both analog and digital parts of the driver, alsa just needs to enable/disable the I2S capture.
Signed-off-by: Mauro Carvalho Chehab mchehab@redhat.com
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c b/drivers/media/video/saa7134/saa7134-alsa.c index 10460fd..2edcdd2 100644 --- a/drivers/media/video/saa7134/saa7134-alsa.c +++ b/drivers/media/video/saa7134/saa7134-alsa.c @@ -720,7 +720,7 @@ static int snd_card_saa7134_capture_close(struct snd_pcm_substream * substream)
if (saa7134->mute_was_on) { dev->ctl_mute = 1; - saa7134_tvaudio_setmute(dev); + saa7134_i2s_mute(dev, dev->ctl_mute); } return 0; } @@ -777,7 +777,7 @@ static int snd_card_saa7134_capture_open(struct snd_pcm_substream * substream) if (dev->ctl_mute != 0) { saa7134->mute_was_on = 1; dev->ctl_mute = 0; - saa7134_tvaudio_setmute(dev); + saa7134_i2s_mute(dev, dev->ctl_mute); }
err = snd_pcm_hw_constraint_integer(runtime, diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c b/drivers/media/video/saa7134/saa7134-tvaudio.c index 57e646b..9cc81ed 100644 --- a/drivers/media/video/saa7134/saa7134-tvaudio.c +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c @@ -184,6 +184,15 @@ static void tvaudio_setcarrier(struct saa7134_dev *dev, #define SAA7134_MUTE_ANALOG 0x04 #define SAA7134_MUTE_I2S 0x40
+void saa7134_i2s_mute(struct saa7134_dev *dev, unsigned int mute) +{ + if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) + saa_andorb(SAA7134_AUDIO_FORMAT_CTRL, SAA7134_MUTE_I2S, + mute ? SAA7134_MUTE_I2S : 0); + else + saa_writeb(SAA7134_I2S_AUDIO_OUTPUT, mute ? 0x11 : 0); +} + static void mute_input_7134(struct saa7134_dev *dev) { unsigned int mute; @@ -220,10 +229,11 @@ static void mute_input_7134(struct saa7134_dev *dev) /* 7134 mute */ saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? SAA7134_MUTE_MASK | - SAA7134_MUTE_ANALOG | - SAA7134_MUTE_I2S : + SAA7134_MUTE_ANALOG : SAA7134_MUTE_MASK);
+ saa7134_i2s_mute(dev, mute); + /* switch internal audio mux */ switch (in->amux) { case TV: ausel=0xc0; ics=0x00; ocs=0x02; break; diff --git a/drivers/media/video/saa7134/saa7134.h b/drivers/media/video/saa7134/saa7134.h index bc8d6bb..7b104cc 100644 --- a/drivers/media/video/saa7134/saa7134.h +++ b/drivers/media/video/saa7134/saa7134.h @@ -821,6 +821,7 @@ int saa7134_tvaudio_do_scan(struct saa7134_dev *dev); int saa_dsp_writel(struct saa7134_dev *dev, int reg, u32 value);
void saa7134_enable_i2s(struct saa7134_dev *dev); +void saa7134_i2s_mute(struct saa7134_dev *dev, unsigned int mute);
/* ----------------------------------------------------------- */ /* saa7134-oss.c */
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!
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
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c b/drivers/media/video/saa7134/saa7134-alsa.c index 10460fd..cbc665a 100644 --- a/drivers/media/video/saa7134/saa7134-alsa.c +++ b/drivers/media/video/saa7134/saa7134-alsa.c @@ -77,7 +77,6 @@ typedef struct snd_card_saa7134 {
unsigned long iobase; s16 irq; - u16 mute_was_on;
spinlock_t lock; } snd_card_saa7134_t; @@ -718,9 +717,10 @@ static int snd_card_saa7134_capture_close(struct snd_pcm_substream * substream) snd_card_saa7134_t *saa7134 = snd_pcm_substream_chip(substream); struct saa7134_dev *dev = saa7134->dev;
- if (saa7134->mute_was_on) { + if (dev->mute_was_on) { dev->ctl_mute = 1; saa7134_tvaudio_setmute(dev); + dev->mute_was_on = false; } return 0; } @@ -775,7 +775,7 @@ static int snd_card_saa7134_capture_open(struct snd_pcm_substream * substream) runtime->hw = snd_card_saa7134_capture;
if (dev->ctl_mute != 0) { - saa7134->mute_was_on = 1; + dev->mute_was_on = true; dev->ctl_mute = 0; saa7134_tvaudio_setmute(dev); } diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c b/drivers/media/video/saa7134/saa7134-tvaudio.c index 57e646b..535aa75 100644 --- a/drivers/media/video/saa7134/saa7134-tvaudio.c +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c @@ -190,6 +190,9 @@ static void mute_input_7134(struct saa7134_dev *dev) struct saa7134_input *in; int ausel=0, ics=0, ocs=0; int mask; + bool change_analog_mute; + + change_analog_mute = dev->mute_was_on ? false : true;
/* look what is to do ... */ in = dev->input; @@ -204,7 +207,8 @@ static void mute_input_7134(struct saa7134_dev *dev) in = &card(dev).mute; }
- if (dev->hw_mute == mute && + + if (dev->hw_mute == mute && !dev->mute_was_on && dev->hw_input == in && !dev->insuspend) { dprintk("mute/input: nothing to do [mute=%d,input=%s]\n", mute,in->name); @@ -216,13 +220,18 @@ static void mute_input_7134(struct saa7134_dev *dev) dev->hw_mute = mute; dev->hw_input = in;
- if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) + if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) { + u32 mask = ~0; + u32 mute_val = SAA7134_MUTE_MASK; + + if (!change_analog_mute) + mask ^= SAA7134_MUTE_ANALOG; + if (mute) + mute_val |= SAA7134_MUTE_I2S | SAA7134_MUTE_ANALOG; + /* 7134 mute */ - saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? - SAA7134_MUTE_MASK | - SAA7134_MUTE_ANALOG | - SAA7134_MUTE_I2S : - SAA7134_MUTE_MASK); + saa_andorb(SAA7134_AUDIO_MUTE_CTRL, mask, mute_val); + }
/* switch internal audio mux */ switch (in->amux) { @@ -241,7 +250,7 @@ static void mute_input_7134(struct saa7134_dev *dev) saa_andorb(SAA7134_SIF_SAMPLE_FREQ, 0x03, 0x01);
/* switch gpio-connected external audio mux */ - if (0 == card(dev).gpiomask) + if (0 == card(dev).gpiomask || !change_analog_mute) return;
mask = card(dev).gpiomask; @@ -725,6 +734,9 @@ static int mute_input_7133(struct saa7134_dev *dev) u32 xbarin, xbarout; int mask; struct saa7134_input *in; + bool change_analog_mute; + + change_analog_mute = dev->mute_was_on ? false : true;
xbarin = 0x03; switch (dev->input->amux) { @@ -750,9 +762,8 @@ static int mute_input_7133(struct saa7134_dev *dev)
saa_writel(0x594 >> 2, reg);
- /* switch gpio-connected external audio mux */ - if (0 != card(dev).gpiomask) { + if (0 != card(dev).gpiomask && change_analog_mute) { mask = card(dev).gpiomask;
if (card(dev).mute.name && dev->ctl_mute) diff --git a/drivers/media/video/saa7134/saa7134.h b/drivers/media/video/saa7134/saa7134.h index bc8d6bb..ae34f68 100644 --- a/drivers/media/video/saa7134/saa7134.h +++ b/drivers/media/video/saa7134/saa7134.h @@ -602,6 +602,7 @@ struct saa7134_dev { int ctl_saturation; int ctl_freq; int ctl_mute; /* audio */ + bool mute_was_on; int ctl_volume; int ctl_invert; /* private */ int ctl_mirror;
Em 20-07-2011 07:32, Mauro Carvalho Chehab escreveu:
Em 20-07-2011 02:28, Stas Sergeev escreveu:
20.07.2011 04:55, Mauro Carvalho Chehab wrote:
[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:
- on saa7134, don't touch at the ANALOG_MUTE at alsa unmute call;
- 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.
[PATCHv3] 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 don't touch at the ANALOG_MUTE at alsa unmute call, for saa7134. Not sure if this will produce any effect, as it will depend on how the board is wired, but it is a worth trial.
Patch is untested.
Signed-off-by: Mauro Carvalho Chehab mchehab@redhat.com
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c b/drivers/media/video/saa7134/saa7134-alsa.c index 10460fd..cbc665a 100644 --- a/drivers/media/video/saa7134/saa7134-alsa.c +++ b/drivers/media/video/saa7134/saa7134-alsa.c @@ -77,7 +77,6 @@ typedef struct snd_card_saa7134 {
unsigned long iobase; s16 irq; - u16 mute_was_on;
spinlock_t lock; } snd_card_saa7134_t; @@ -718,9 +717,10 @@ static int snd_card_saa7134_capture_close(struct snd_pcm_substream * substream) snd_card_saa7134_t *saa7134 = snd_pcm_substream_chip(substream); struct saa7134_dev *dev = saa7134->dev;
- if (saa7134->mute_was_on) { + if (dev->mute_was_on) { dev->ctl_mute = 1; saa7134_tvaudio_setmute(dev); + dev->mute_was_on = false; } return 0; } @@ -775,7 +775,7 @@ static int snd_card_saa7134_capture_open(struct snd_pcm_substream * substream) runtime->hw = snd_card_saa7134_capture;
if (dev->ctl_mute != 0) { - saa7134->mute_was_on = 1; + dev->mute_was_on = true; dev->ctl_mute = 0; saa7134_tvaudio_setmute(dev); } diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c b/drivers/media/video/saa7134/saa7134-tvaudio.c index 57e646b..11631f4 100644 --- a/drivers/media/video/saa7134/saa7134-tvaudio.c +++ b/drivers/media/video/saa7134/saa7134-tvaudio.c @@ -190,6 +190,9 @@ static void mute_input_7134(struct saa7134_dev *dev) struct saa7134_input *in; int ausel=0, ics=0, ocs=0; int mask; + bool change_analog_mute; + + change_analog_mute = dev->mute_was_on ? false : true;
/* look what is to do ... */ in = dev->input; @@ -204,7 +207,8 @@ static void mute_input_7134(struct saa7134_dev *dev) in = &card(dev).mute; }
- if (dev->hw_mute == mute && + + if (dev->hw_mute == mute && !dev->mute_was_on && dev->hw_input == in && !dev->insuspend) { dprintk("mute/input: nothing to do [mute=%d,input=%s]\n", mute,in->name); @@ -216,13 +220,18 @@ static void mute_input_7134(struct saa7134_dev *dev) dev->hw_mute = mute; dev->hw_input = in;
- if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) + if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev->pci->device) { + u32 mask = ~0; + u32 mute_val = SAA7134_MUTE_MASK; + + if (!change_analog_mute) + mask ^= SAA7134_MUTE_ANALOG; + if (mute) + mute_val |= SAA7134_MUTE_I2S | SAA7134_MUTE_ANALOG; + /* 7134 mute */ - saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ? - SAA7134_MUTE_MASK | - SAA7134_MUTE_ANALOG | - SAA7134_MUTE_I2S : - SAA7134_MUTE_MASK); + saa_andorb(SAA7134_AUDIO_MUTE_CTRL, mask, mute_val); + }
/* switch internal audio mux */ switch (in->amux) { diff --git a/drivers/media/video/saa7134/saa7134.h b/drivers/media/video/saa7134/saa7134.h index bc8d6bb..ae34f68 100644 --- a/drivers/media/video/saa7134/saa7134.h +++ b/drivers/media/video/saa7134/saa7134.h @@ -602,6 +602,7 @@ struct saa7134_dev { int ctl_saturation; int ctl_freq; int ctl_mute; /* audio */ + bool mute_was_on; int ctl_volume; int ctl_invert; /* private */ int ctl_mirror;
20.07.2011 14:32, Mauro Carvalho Chehab wrote:
I won't keep discussing something that won't be merged, as it will cause regressions.
Please explain what regressions it will make! I am asking that question over and over again, and every time you either ignore it, or refer to an apps that use v4l2 ioctls, which are unaffected. I wonder why you don't want to explain what regressions do you have in mind...
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.
Well, until you explain the exact breakage of my proposal, I won't trust this. :)
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.
I'll test at a week-end whatever we'll have to that date.
Em 20-07-2011 07:45, Stas Sergeev escreveu:
20.07.2011 14:32, Mauro Carvalho Chehab wrote:
I won't keep discussing something that won't be merged, as it will cause regressions.
Please explain what regressions it will make! I am asking that question over and over again, and every time you either ignore it, or refer to an apps that use v4l2 ioctls, which are unaffected. I wonder why you don't want to explain what regressions do you have in mind...
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.
Well, until you explain the exact breakage of my proposal, I won't trust this. :)
I've said already: mplayer for example relies on such behavior to work. Reverting it breaks mplayer. This is enough for me to NACK your patch.
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.
I'll test at a week-end whatever we'll have to that date.
20.07.2011 14:48, Mauro Carvalho Chehab wrote:
Well, until you explain the exact breakage of my proposal, I won't trust this. :)
I've said already: mplayer for example relies on such behavior to work. Reverting it breaks mplayer. This is enough for me to NACK your patch.
What you said, was: --- Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. --- "starting video also unmutes audio" is what my patch _does not touch_! And that certainly happens not even in the alsa driver, but somewhere in the v4l2 code.
So, please please please, could you actually precisely explain how exactly mplayer breaks with my patch? That's the only thing I need! :))
participants (5)
-
Lennart Poettering -
Lennart Poettering -
Mauro Carvalho Chehab -
Mauro Carvalho Chehab -
Stas Sergeev