Hi.
On 10/06/2011 01:49 PM, ext Tanu Kaskinen wrote:
On Wed, 2011-10-05 at 18:43 +0300, Mark Brown wrote:
On Tue, Oct 04, 2011 at 02:30:17PM +0300, Tanu Kaskinen wrote:
I'm not sure that would work in this case. The mixer element is an
enumeration with states "Off", "Rx" and "Tx". I've been told that it
controls whether the FM radio is powered on (and whether it's in the
reception or transmission mode). Of course, the logic could also include
a rule that if one of the options for an enumeration is "Off", that will
be used unless something else is specified.
It should only be powered if someone routes audio to it. Is that the
case?
I don't think so. I have now asked from the driver writer (Matti
Aaltonen) why the driver doesn't power off the radio automatically, and
the answer was the following (I'll also quote the question):
On Wed, 2011-10-05 at 13:16 +0300, Matti J. Aaltonen wrote:
And still one thing: what's the reason for not powering off the fm radio
automatically when nobody's using the device, but requiring userspace to
set the "Mode" mixer element to "Off" manually? See also this thread:
http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/11283
Any comments to this? Pulseaudio upstream doesn't want features that are
only used to work around kernel bugs, and there's some concern that this
case is a kernel bug.
Is it a bug or a feature? That's the question.... Off hand I don't
remember seeing such a requirement for the driver. And how do you define
when the radio is not off? It also offers analog audio.
Anyway, there was/is a reason for not turning the radio off
unnecessarily: the firmware patch needs to be uploaded to the chip every
time it gets turned on. However, it should be rather simple to change
the on/off behavior of the driver once the conditions have been agreed upon.
Cheers,
Matti
Matti, do you have anything to add? I didn't fully understand how
offering analog audio is a problem here - is the driver unable to detect
whether someone is using the analog output or not?
...I actually already have Matti's answer, since I handled this
discussion in a bit "funny" way... Here's Matti's reply, and my reply to
that:
On Thu, 2011-10-06 at 09:56 +0300, Matti J. Aaltonen wrote:
Yeah the driver is unable to detect directly if someone wants to use
the analog signal. But that's not a big problem, there still could
exist the facility for explicitly turning the radio on and off. It's
also possible to imagine a use case where only RDS data is of
interest.
Sorry, I have some difficulty understanding this paragraph. Are you
arguing for or against turning off the radio automatically? What do you
mean by "that's not a big problem"? (That's the sentence that causes my
confusion.) If the driver doesn't know if someone is using the analog
output (or RDS), isn't that a showstopper, if the goal is to turn off
the radio automatically without any explicit request?
We are clearly thinking this in a bit differently... It's not a show
stopper or a big deal if you are willing to
live with the following facts:
1. you can have the automatic on/off control with digital audio and you
can also have similar with RDS
read and write (even without any audio)...
2. in the case of analog audio you turn the device on and off explicitly
I kind of assumed that the current Lankku use case with digital audio is
the most important one and
implicitly in addition assumed that operating under the above conditions
also would be acceptable.....
Above, in the earlier message, I just tried to explain how "we" ended
up with the current design. At the moment I don't (in principle) see
reason why this new feature of controlling the radio state (on/off)
from the audio codec couldn't be implemented, it's just that all use
cases need to be considered.
By the way have you noticed that the driver in the n950 tree and the
one in the official kernel are quite different?
Nope, I don't follow kernel development. By "the official kernel", do
you mean the upstream mainline kernel? If they are very different, does
it mean that the mainline kernel doesn't (and won't?) support this chip
very well?
Yes the up-stream mainline kernel is the official Linux kernel (in my
book at least). I wouldn't say that the support is worse. But the driver
interface is different
due to the fact that the interface and also the driver structure that
was accepted in the local review wasn't acceptable to the up-stream
maintainers. It was a long story.... three subsystem maintainers to
deal with (Alsa, V4L2 and MFD).
Cheers,
Matti
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
