| Message ID | 4E19D2F7.6060803@list.ru (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
Em 10-07-2011 13:27, Stas Sergeev escreveu: > Hi. > > When pulseaudio enables the audio capturing, the > driver unmutes the sound. But, if no app have properly > tuned the tuner yet, you get the white noise. > I think the capturing must not touch the mute state, > because, without tuning the tuner first, you can't capture > anything anyway. > Without this patch I am getting the white noise on every > xorg/pulseaudio startup, which made me to always think > that pulseaudio is a joke and will soon be removed. :) Nack. We shouldn't patch a kernel driver due to an userspace bad behavior. I've pinged Lennart about that and he is suggesting that we should use a non-standard name for the controls, in order to avoid pulseaudio to touch on them. We need first to double check if applications like tvtime and xawtv will work with a different name for the audio volumes. If the existing apps are ok, then maybe all we need to do is to rename all media volumes as something like "<foo> Grabber" or "<foo> V4L". Cheers, Mauro -- 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
14.07.2011 00:53, Mauro Carvalho Chehab wrote: >> When pulseaudio enables the audio capturing, the >> driver unmutes the sound. But, if no app have properly >> tuned the tuner yet, you get the white noise. >> I think the capturing must not touch the mute state, >> because, without tuning the tuner first, you can't capture >> anything anyway. >> Without this patch I am getting the white noise on every >> xorg/pulseaudio startup, which made me to always think >> that pulseaudio is a joke and will soon be removed. :) > Nack. We shouldn't patch a kernel driver due to an userspace bad behavior. But I really think that the driver behaves badly here. Suppose we had 2 separate mute switches: the input mute, that mutes the signal as it just enters the saa chip, and the output mute, that mutes only the output of the tuner card, that is connected to the sound card's line input. With that configuration, we'd allow the alsa driver to unmute only the input switch, so that it can record, but leave the output switch still muted, so that the sound not to come to the sound card directly. Now that we don't have the output mute switch, we allow the alsa driver to unmute not only the recording that it may need, but also the sound output that goes to the sound card! IMHO, this is the entirely unwanted side effect, so I blame the saa driver, and not the pulseaudio. There are also other things to consider: 1. You can't record anything (except for the white noise) before some xawtv sets up everything. So what is the use-case of the current (mis)behaveur? 2. The alsa driver, trying to manage the mute state on its own, badly interwinds with the mute state of the (xawtv) program. 2 programs cannot control the same mute state for good, and of course the xawtv must have the preference, as the alsa driver have no slightest idea about the card's state. 3. The problem is very severe. Hearing the loud white noise on every startup is not something the human can easily tolerate. So deferring it for the unknown period is simply not very productive. Can you please name a few downsides of the approach I proposed? -- 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
Em 13-07-2011 18:11, Stas Sergeev escreveu: > 14.07.2011 00:53, Mauro Carvalho Chehab wrote: >>> When pulseaudio enables the audio capturing, the >>> driver unmutes the sound. But, if no app have properly >>> tuned the tuner yet, you get the white noise. >>> I think the capturing must not touch the mute state, >>> because, without tuning the tuner first, you can't capture >>> anything anyway. >>> Without this patch I am getting the white noise on every >>> xorg/pulseaudio startup, which made me to always think >>> that pulseaudio is a joke and will soon be removed. :) >> Nack. We shouldn't patch a kernel driver due to an userspace bad behavior. > But I really think that the driver behaves badly here. > Suppose we had 2 separate mute switches: the input > mute, that mutes the signal as it just enters the saa > chip, and the output mute, that mutes only the output > of the tuner card, that is connected to the sound card's > line input. > With that configuration, we'd allow the alsa driver to > unmute only the input switch, so that it can record, but > leave the output switch still muted, so that the sound > not to come to the sound card directly. Well, on such configuration, there are, in fact, 4 mutes: the two ones you've mentioned, plus the sound card LINE IN mute and the sound card master output. The media drivers should control the input that belongs to saa7134. The userspace applications like pulseaudio should control the sound card volume/mute, but the driver should control the saa7134 mute/audio switch. > Now that we don't have the output mute switch, we > allow the alsa driver to unmute not only the recording > that it may need, but also the sound output that goes > to the sound card! IMHO, this is the entirely unwanted > side effect, so I blame the saa driver, and not the pulseaudio. Why this is unwanted? You shouldn't expect that the poor users to control each mute control. They just need to control one: the sound card outut. > There are also other things to consider: > 1. You can't record anything (except for the white noise) > before some xawtv sets up everything. So what is the > use-case of the current (mis)behaveur? If you're getting a white noise, then there's a bug either at xawtv, at the driver or both. It is likely board-specific, as, at least the last time I tested, saa7134 audio were working properly. > 2. The alsa driver, trying to manage the mute state on > its own, badly interwinds with the mute state of the > (xawtv) program. 2 programs cannot control the same > mute state for good, and of course the xawtv must have > the preference, as the alsa driver have no slightest > idea about the card's state. There's no sense on keeping the device unmuted after stop streaming. > 3. The problem is very severe. Hearing the loud white > noise on every startup is not something the human can > easily tolerate. So deferring it for the unknown period > is simply not very productive. As I said before, the white noise bug should be fixed. With what xawtv versions are you noticing problems? Are you using xawtv 3.101? If so, xawtv 3.101 assumes that you're using digital streams. Maybe your board entry is broken for digital streams. > > Can you please name a few downsides of the approach > I proposed? -- 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
14.07.2011 02:00, Mauro Carvalho Chehab wrote: >> Now that we don't have the output mute switch, we >> allow the alsa driver to unmute not only the recording >> that it may need, but also the sound output that goes >> to the sound card! IMHO, this is the entirely unwanted >> side effect, so I blame the saa driver, and not the pulseaudio. > Why this is unwanted? You shouldn't expect that the poor > users to control each mute control. They just need to control > one: the sound card outut. Controlling the sound card output makes no sense here: I don't want to mute the entire sound only when I want to mute the TV-tuner. On the other hand, why exactly would you unmute the output when capturing? Obviously to allow the capturing itself. Why, at the same time, would you enable the pass-through link to the sound card? Unwanted side-effect: it is not needed for capturing, and it gives the noise. That have to be fixed. So: even if pulseaudio wants to record the white noise for one reason or another, at least it doesn't output it to the sound card, so what it does is perfectly safe. Enabling the pass-through link to the sound card is a bug here. >> There are also other things to consider: >> 1. You can't record anything (except for the white noise) >> before some xawtv sets up everything. So what is the >> use-case of the current (mis)behaveur? So is there a use-case? > If you're getting a white noise, then there's a bug either > at xawtv, at the driver or both. It is likely board-specific, > as, at least the last time I tested, saa7134 audio were working > properly. I don't see your point, I described the bug precisely. The capture unmutes the pass-through link to the sound card, so whatever is captured (white noise), gets also immediately outputed to the speakers, even though pulseaudio does not feed that to the sound card. > As I said before, the white noise bug should be fixed. > With what xawtv versions are you noticing problems? Are you using > xawtv 3.101? If so, xawtv 3.101 assumes that you're using digital There is nothing to do with xawtv here: as I said, the noise happens on xorg startup. Starting xawtv actually makes it to disappear, but I can't always start xawtv just for that. -- 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
Em 14-07-2011 02:39, Stas Sergeev escreveu: > 14.07.2011 02:00, Mauro Carvalho Chehab wrote: > >>> Now that we don't have the output mute switch, we >>> allow the alsa driver to unmute not only the recording >>> that it may need, but also the sound output that goes >>> to the sound card! IMHO, this is the entirely unwanted >>> side effect, so I blame the saa driver, and not the pulseaudio. >> Why this is unwanted? You shouldn't expect that the poor >> users to control each mute control. They just need to control >> one: the sound card outut. > Controlling the sound card output makes no sense > here: I don't want to mute the entire sound only when > I want to mute the TV-tuner. > On the other hand, why exactly would you unmute > the output when capturing? Obviously to allow the > capturing itself. > Why, at the same time, would you enable the pass-through > link to the sound card? Unwanted side-effect: it is > not needed for capturing, and it gives the noise. > That have to be fixed. > So: even if pulseaudio wants to record the white > noise for one reason or another, at least it doesn't > output it to the sound card, so what it does is perfectly > safe. Enabling the pass-through link to the sound card > is a bug here. > >>> There are also other things to consider: >>> 1. You can't record anything (except for the white noise) >>> before some xawtv sets up everything. So what is the >>> use-case of the current (mis)behaveur? > So is there a use-case? > >> If you're getting a white noise, then there's a bug either >> at xawtv, at the driver or both. It is likely board-specific, >> as, at least the last time I tested, saa7134 audio were working >> properly. > I don't see your point, I described the bug precisely. Huh? The first time, you said it were due to pulseaudio. Then, you said it were due to xawtv, and now you're blaming Xorg startup. Starting X should not be touching on anything, as Xorg itself doesn't have any code to handle an alsa device. Let's reset this thread to the beginning. See bellow. > The capture unmutes the pass-through link to the > sound card, so whatever is captured (white noise), > gets also immediately outputed to the speakers, even > though pulseaudio does not feed that to the sound > card. > >> As I said before, the white noise bug should be fixed. >> With what xawtv versions are you noticing problems? Are you using >> xawtv 3.101? If so, xawtv 3.101 assumes that you're using digital > There is nothing to do with xawtv here: as I said, > the noise happens on xorg startup. Starting xawtv > actually makes it to disappear, but I can't always > start xawtv just for that. The expected behavior of the driver should be to unmute the device only if TV and/or radio starts streaming, and muting it at stream stop. Detecting that radio is streaming is complex, as the API allows to start stream, while keeping the radio device closed. Anyway, in this case, radio applications need to manually unmute the device. Also, the alsa driver doesn't have any business to do when the audio is wire connected, excepting by providing the mixer controls. The mute/unmute logic is there due to the fact that, nowadays, most boards provide audio PCM output, and such setup is generally preferred, as it doesn't require an extra cabling, and gives more quality to the audio, as it avoids an extra Digital/Analog and Analog/Digital conversion, thus reducing the quantization noise and any analog interferences. In any case, all V4L drivers should have the same behavior on that matter. By looking at the alsa driver, the logic is muting/unmuting at device open and not at device capture. So, it is not doing the expected behavior. The proper fix seems to move that logic to capture start/stop. We need to take care through, as capture start/stop happens at IRQ time. so, it can't sleep. We may likely need to start a workqueue to mute/unmute the driver at capture. We had to do something similar to that at the em28xx, as the DMA start sequence there calls msleep(), and this is not allowed at IRQ time. If you want, feel free to propose a patch fixing that logic at saa7134, instead of just removing it. Cheers, Mauro -- 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
15.07.2011 05:38, Mauro Carvalho Chehab wrote: > Huh? The first time, you said it were due to pulseaudio. Then, you Yes: pulseaudio does some capturing at startup. (or, possibly, just opens the capture device). Without it, nothing bad happens, but I never said the bug is in pulseaudio. > said it were due to xawtv, No, I was mentioned xawtv as an app that have to set everything up properly, before you can capture anything else than the white noise. So my point was, and is, that, before something like xawtv sets up the tuner, unmuting the audio makes _zero_ sense. > and now you're blaming Xorg startup. I am not _blaming_ it, just mentioning it. Indeed, the pulseaudio starts on the xorg startup, at least on fedora. So, from the mere user's point of view, you start xorg and get the noise. > Starting X should not be touching on anything, as Xorg itself doesn't > have any code to handle an alsa device. But, with some magic scripts, it starts pulseaudio. > The expected behavior of the driver should be to unmute the device only > if TV and/or radio starts streaming, and muting it at stream stop. What does "streaming" means here, exactly? > Also, the alsa driver doesn't have any business to do when the > audio is wire connected, excepting by providing the mixer controls. The problem is exactly here: the single mixer control controls both the pass-through wire and the input for capturing. Be there the 2 separate controls, or be there a control _only_ for the pass-through write, the problem would not exist. But currently the single mixer control controls too much. > The mute/unmute logic is there due to the fact that, nowadays, most boards > provide audio PCM output, and such setup is generally preferred, as it > doesn't require an extra cabling, and gives more quality to the audio, as > it avoids an extra Digital/Analog and Analog/Digital conversion, thus > reducing the quantization noise and any analog interferences. Please clarify that part a bit. How exactly the expected mute/unmute logic should affect the pass-through wire, and how exactly should it affect the PCM capture. > By looking at the alsa driver, the logic is muting/unmuting at device open > and not at device capture. So, it is not doing the expected behavior. > > The proper fix seems to move that logic to capture start/stop. We need to What if pulseaudio really captures something, rather than just opens the device? Not that I have checked it does, but it may be the case if he wants to calibrate some clocks by recording something. Why just recording from the alsa device, without feeding the sound to the sound card, should ever produce any sound from the speakers? No program in the world would expect that behaveor, and the pulseaudio's case may or may not be fixed by that (depends on luck, and, possibly, the pulseaudio version), so why doing such a change? -- 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
15.07.2011 05:38, Mauro Carvalho Chehab wrote:
> In any case, all V4L drivers should have the same behavior on that matter.
I am not sure how exactly the other drivers behave,
and I agree they should behave more or less similar
(as long as the particular hw allows, not the case with
saa7134). But if we can't even agree on what the mixer
control should do, or whether the sound capture should
result in any sound from the speakers, then I would
suggest adding the alsa list to CC. After all, these
rules are set by them, not by you or me.
--
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
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. -- 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
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. -- 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
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. -- 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
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 -- 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 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? -- 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
On Tue, 19.07.11 10:31, Stas Sergeev (stsp@list.ru) wrote: > 2. "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 -- 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
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. 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. 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
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 -- 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. :) -- 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
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 -- 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 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. -- 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
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 -- 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 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. :( -- 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
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 -- 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 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. -- 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
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c b/drivers/media/video/saa7134/saa7134-alsa.c index 10460fd..d566468 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; @@ -715,13 +714,6 @@ static int snd_card_saa7134_hw_free(struct snd_pcm_substream * substream) 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) { - dev->ctl_mute = 1; - saa7134_tvaudio_setmute(dev); - } return 0; } @@ -774,12 +766,6 @@ static int snd_card_saa7134_capture_open(struct snd_pcm_substream * substream) runtime->private_free = snd_card_saa7134_runtime_free; runtime->hw = snd_card_saa7134_capture; - if (dev->ctl_mute != 0) { - saa7134->mute_was_on = 1; - dev->ctl_mute = 0; - saa7134_tvaudio_setmute(dev); - } - err = snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); if (err < 0)
Hi. When pulseaudio enables the audio capturing, the driver unmutes the sound. But, if no app have properly tuned the tuner yet, you get the white noise. I think the capturing must not touch the mute state, because, without tuning the tuner first, you can't capture anything anyway. Without this patch I am getting the white noise on every xorg/pulseaudio startup, which made me to always think that pulseaudio is a joke and will soon be removed. :) Signed-off-by: Stas Sergeev <stsp@list.ru>