From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Stas Sergeev <stsp@list.ru>
Cc: Lennart Poettering <lpoetter@redhat.com>,
linux-media@vger.kernel.org,
"Nickolay V. Shmyrev" <nshmyrev@yandex.ru>,
Devin Heitmueller <dheitmueller@kernellabs.com>,
ALSA devel <alsa-devel@alsa-project.org>,
lennart@poettering.net
Subject: Re: [patch][saa7134] do not change mute state for capturing audio
Date: Tue, 19 Jul 2011 11:10:53 -0300 [thread overview]
Message-ID: <4E25906D.3020200@infradead.org> (raw)
In-Reply-To: <4E258B60.6010007@list.ru>
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
next prev parent reply other threads:[~2011-07-19 14:10 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4E19D2F7.6060803@list.ru>
[not found] ` <4E1E05AC.2070002@infradead.org>
[not found] ` <4E1E0A1D.6000604@list.ru>
[not found] ` <4E1E1571.6010400@infradead.org>
[not found] ` <4E1E8108.3060305@list.ru>
[not found] ` <4E1F9A25.1020208@infradead.org>
2011-07-17 9:44 ` [patch][saa7134] do not change mute state for capturing audio Stas Sergeev
2011-07-17 11:51 ` Mauro Carvalho Chehab
2011-07-17 12:24 ` Stas Sergeev
2011-07-18 23:16 ` Lennart Poettering
2011-07-19 6:31 ` Stas Sergeev
2011-07-19 12:25 ` Lennart Poettering
2011-07-19 13:00 ` Mauro Carvalho Chehab
2011-07-19 13:13 ` [alsa-devel] " Lennart Poettering
2011-07-19 13:49 ` Stas Sergeev
2011-07-19 14:10 ` Mauro Carvalho Chehab [this message]
2011-07-19 14:56 ` Stas Sergeev
2011-07-19 15:27 ` Mauro Carvalho Chehab
2011-07-19 15:50 ` Stas Sergeev
2011-07-19 18:06 ` Mauro Carvalho Chehab
2011-07-19 18:38 ` Stas Sergeev
2011-07-19 19:29 ` Mauro Carvalho Chehab
2011-07-19 21:57 ` Stas Sergeev
2011-07-20 0:55 ` Mauro Carvalho Chehab
2011-07-20 5:28 ` Stas Sergeev
2011-07-20 10:32 ` Mauro Carvalho Chehab
2011-07-20 10:41 ` Mauro Carvalho Chehab
2011-07-20 10:45 ` Stas Sergeev
2011-07-20 10:48 ` Mauro Carvalho Chehab
2011-07-20 10:55 ` Stas Sergeev
[not found] ` <4E292BED.60108@list.ru>
[not found] ` <4E296D00.9040608@infradead.org>
[not found] ` <4E296F6C.9080107@list.ru>
[not found] ` <4E2971D4.1060109@infradead.org>
[not found] ` <4E29738F.7040605@list.ru>
[not found] ` <4E297505.7090307@infradead.org>
[not found] ` <4E29E02A.1020402@list.ru>
[not found] ` <4E29E02A .1020402@list.ru>
[not found] ` <4E2A23C7.3040209@infradead.org>
[not found] ` <4E2A7BF0.8080606@list.ru>
[not found] ` <4E2AC742.8020407@infradead.org>
[not found] ` <4E2ACAAD.4050602@list.ru>
[not found] ` <4E2AE40F.7030108@infradead.org>
[not found] ` <4E2C5A35.9030404@list.ru>
[not found] ` <4E2C6638.2040707@infrade ad.org>
2011-07-24 18:36 ` Mauro Carvalho Chehab
2011-07-24 19:00 ` Stas Sergeev
2011-07-25 11:15 ` Stas Sergeev
2011-09-18 15:18 ` Stas Sergeev
2011-09-24 10:57 ` Mauro Carvalho Chehab
2011-09-24 11:12 ` Stas Sergeev
2011-09-24 12:12 ` Mauro Carvalho Chehab
2011-09-24 12:36 ` Stas Sergeev
2011-09-24 12:48 ` Mauro Carvalho Chehab
2011-09-24 13:20 ` Stas Sergeev
2011-09-24 15:09 ` Mauro Carvalho Chehab
2011-09-24 15:51 ` Stas Sergeev
2011-12-03 20:40 ` Stas Sergeev
2011-09-24 12:05 ` Mauro Carvalho Chehab
2011-09-24 12:33 ` Stas Sergeev
2011-09-24 12:46 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E25906D.3020200@infradead.org \
--to=mchehab@infradead.org \
--cc=alsa-devel@alsa-project.org \
--cc=dheitmueller@kernellabs.com \
--cc=lennart@poettering.net \
--cc=linux-media@vger.kernel.org \
--cc=lpoetter@redhat.com \
--cc=nshmyrev@yandex.ru \
--cc=stsp@list.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).