alsa device on startup)
Signed-off-by: Stas Sergeev s...@users.sourceforge.net
From d8c8a05449b06ee7599e7c7d9e8aaeaa07d0fadb Mon Sep 17 00:00:00 2001
From: Stas Sergeev s...@users.sourceforge.net
Date: Sun, 4 Dec 2011 00:32:06 +0400
Subject: [PATCH] [saa7134] fix automute logic
---
drivers/media
24.09.2011 14:57, Mauro Carvalho Chehab wrote:
Please, one patch per email. Patchwork (or any kernel maintainer script)
won't catch more than one patch per email. See:
Sorry about that.
With respect to this patch:
http://patchwork.linuxtv.org/patch/7941/
I don't see any sense on it. Video
24.09.2011 16:05, Mauro Carvalho Chehab wrote:
Better to post it as a separate patch, and to simplify the code with:
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index 57e646b..a61ed1e 100644
---
24.09.2011 16:12, Mauro Carvalho Chehab wrote:
The scan audio logic only enables multiple audio standard detection if the
userspace
application tells it to do.
No: the _first_ scan is done on the driver init.
It is a multi-standard one, and a long one, too.
Do we need it at all? It seems to me
24.09.2011 16:48, Mauro Carvalho Chehab wrote:
A first scan at driver's init can be removed, IMO.
OK, that's the great news.
Will write a new patch then.
There's nothing the driver can do if the hardware
missdetects a carrier. Dirty tricks to try solving it
are not good, as they'll do the
24.09.2011 19:09, Mauro Carvalho Chehab wrote:
If someone is using the board on an environment
without udev and pulseaudio, this trick will break the first tuning.
I feel this somehow contradicts with your suggestion
to remove the first scan, so could you clarify?
What I meant to say is that
unrelated to the automute one, it is
here just in case.
What do you think?
From ccdfa126e98b5484f4a08de591ac8d89f775251c Mon Sep 17 00:00:00 2001
From: Stas Sergeev s...@users.sourceforge.net
Date: Sun, 18 Sep 2011 19:06:21 +0400
Subject: [PATCH 1/2] saa7134: fix automute
---
drivers/media/video
24.07.2011 22:36, Mauro Carvalho Chehab wrote:
The automute code works fine. Maybe you have a strong interference
at the default tuning frequency, leading into saa7134 miss-detection.
OK, so my accusation to the automute code is
that it gets disabled unconditionally, no matter
have the scan
23.07.2011 19:09, Mauro Carvalho Chehab wrote:
In this case, it will not be autounmuted after tuning.
Hard to tell about your solution without seeing a patch.
OK, it turns out the automute code is already there,
but it doesn't work. The driver for some reasons
starts the scan on
24.07.2011 22:36, Mauro Carvalho Chehab wrote:
So, only people that has saa7134 with alsa stream that opted
to wire the saa7134 device to the sound card, and with a strong
interference at the default tunning frequency (400 MHz) would
notice a problem.
No, the strong interference thing have
23.07.2011 05:28, Mauro Carvalho Chehab wrote:
Mplayer was just one example of an application that I know
it doesn't call V4L2_CID_AUDIO_MUTE to unmute.
I would suggest fixing all such an apps, even if we
are not going to change that in the driver.
Your approach of moving it to
23.07.2011 17:06, Mauro Carvalho Chehab wrote:
I would suggest fixing all such an apps, even if we
are not going to change that in the driver.
If application needs to change due to a patch, this is a
regression,
I said even if we are not going to change that in the
driver, which, imho, removes
23.07.2011 19:09, Mauro Carvalho Chehab wrote:
As I said, I propose the automute state to be a separate,
_third_ state. mute/unmute/automute.
Automute state is only set initially, but if the app
explicitly sets any other state, it is no longer affected.
Since an app can't rely on the state
23.07.2011 19:09, Mauro Carvalho Chehab wrote:
Anyway, we're discussing a lot for a kernel fix for PA,
Please note that right now we are discussing the
fix for mplayer or anything else that forgets to
just explicitly enable/disable the audio!
IMHO, that should better be fixed first.
--
To
Ok, Mauro, so may I take your silence as an evidence
that this reiterating myth about the mplayer breakage
is just a myth?
Look, I spent time on investigating the problem, on
trying the different approaches to fix it, on explaining
the problem to you, etc. So maybe I deserve something
more than
22.07.2011 16:28, Mauro Carvalho Chehab wrote:
In this specific case, applications like mplayer,
using the alsa parameters for streaming will stop work, as mplayer
won't touch at the mixer or at the V4L mute control. So,
it will have the same practical effect of a kernel bug at the
audio part
22.07.2011 16:49, Mauro Carvalho Chehab wrote:
Let me rephase it:
Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a
video device. They assume the current behavior that starting audio on a
video board also unmutes audio.
Could you please give me a command line I can use
22.07.2011 17:03, Mauro Carvalho Chehab wrote:
Here, I add the following line at my .mplayer/config:
tv =
driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1
Thanks for starting to answer what I was asking for
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
33 matches
Mail list logo
