n the pulseaudio startup.
(pulseaudio reads the saa7134 alsa device on startup)
Signed-off-by: Stas Sergeev
From d8c8a05449b06ee7599e7c7d9e8aaeaa07d0fadb Mon Sep 17 00:00:00 2001
From: Stas Sergeev
Date: Sun, 4 Dec 2011 00:32:06 +0400
Subject: [PATCH] [saa7134] fix automute logic
---
drivers/media/
a7134 alsa device on startup)
Signed-off-by: Stas Sergeev
From d8c8a05449b06ee7599e7c7d9e8aaeaa07d0fadb Mon Sep 17 00:00:00 2001
From: Stas Sergeev
Date: Sun, 4 Dec 2011 00:32:06 +0400
Subject: [PATCH] [saa7134] fix automute logic
---
drivers/media/video/saa7134/saa7134-core.c|1 -
drivers/
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 bo
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 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:05, Mauro Carvalho Chehab wrote:
Better to post it as a separate patch, and to simplify the code with:
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index 57e646b..a61ed1e 100644
--- a/drivers/media/video/saa7134/saa713
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 sta
t is completely 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
Date: Sun, 18 Sep 2011 19:06:21 +0400
Subject: [PATCH 1/2] saa7134: fix automute
---
drivers/media/vid
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 fail
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 not
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 initializatio
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 unsubs
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 before
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, remove
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 VIDIOC_S_FREQUE
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 o
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 us
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
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 jus
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,
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 v4l
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
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
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
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
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 ch
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 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 w
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 complain
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 a
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 w
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 dri
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 ca
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
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 10
Hi.
Jean-Francois Moine wrote:
Looking at the video drivers, I found that only half of these ones have
this parameter. Then, I think it should be better to remove it
everywhere!
OK, that might be a solution too. :)
In fact, setting the video number in the right driver before plugging
any vide
36 matches
Mail list logo
