[Om2008.9] gsmspeakerout.state

[Alastair Johnson]

Vasco Névoa wrote:
> I really don't like the fact that the state files have ALL the  
> controls in there.
> Can't we eliminate the unnecessary controls inside each file?
> I don't see why a "speakerout.state" file should have microphone  
> settings... it just adds to the confusion, and creates competition  
> between apps.

Because the other controls are _not_ unnecessary. If you just ignore the 
  mic settings you could end up with Mic2 enabled with high gain, 
routing through to the speaker and generating horrible feedback. Other 
unexpected weird audio routing problems will crop up, and be next to 
impossible to debug since it won't be clear which combination of 
settings applied in which order were responsible for creating the 
problem, let alone which app was 'responsible' for the problem.

> Citando Alastair Johnson <alastair at truebox.co.uk>:
> 
>> Matthias Apitz wrote:
>>> El día Wednesday, November 19, 2008 a las 08:46:27AM +0530, Carl  
>>> Lobo escribió:
>>>
>>>> I think you need to restore the gsm*.state files only when you are on
>>>> call. the ringing from speaker requires mappings from stereoout.state.
>>> Ok, I think that without deeper knowledge about the files I'm lost. Can
>>> some kindly soul sheet a bit light into this darkness? I.e.
>>> - Why there are different files?
>> Because depending on what you are doing you want to send sound to
>> different places, and with different levels. It is simpler to have a
>> small set of files containing the mixer states for known situations than
>> it is for every app to store all the mixer settings itself.
>>
>>> - Which process is reading them, in which order and when?
>> Anything that wants to, whenever it wants to, more or less. Essentially
>> if an app wants to use a particular mixer state then it makes a call to
>> set the mixer to that state. FSO has a dbus API to make this a little
>> more orderly, and qtopia may have something similar, but this doesn't
>> prevent an app setting things directly.
>>
>> Because it is up to the app to do the setting you may find that an app
>> doesn't switch to the state you want, for example when you answer a call
>> the phone app may switch to the gsm-handset state even though you have
>> the headset plugged in.
>>
>>> The Wiki http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem
>>> speaks about 'states' like 'State: GSM <-> Built-in Handset (file
>>> gsmhandset.state)', but does not explain what a given 'state' is and how
>>> the transit between them happens...
>>>
>>> Thx
>>>
>>> 	matthias