[pulseaudio-discuss] Configuring alsa mixers in the "off" profile.

[Matti J. Aaltonen]

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