Managing alsa scenarios and possible issues

[Al Johnson]

On Wednesday 14 July 2010, Nicola Mfb wrote:
> Hi!
> 
> What's the best pattern to write a simple mixer application capable of
> persisting values in alsa scenarios in a reliable way?
> There is a "SaveScenario" dbus call but it seems to be not safe, I'm
> not sure if what I'm saying here is right, please correct me if I'm
> wrong or I'm missing somethings.
> 
> Consider the following case:
> 
> * an incoming call arrives, scenario is stereoout, the phone rings
> * the user answers, scenario is now gsmhandset
> * during the call the user adjusts volumes multiple times and the
> mixer app saves the gsmhandset scenario automatically or manually (a
> save button) by calling SaveScenario(gsmhandset)
> 
> if for some reason the scenario switches to stereoout again (for
> example because by design when a call ends the stereoout one is
> restored), we have a race condition, and may happen that the
> gsmhandset scenario will contain values from the stereoout one, with
> the immediate consequence that on the next call there will be no sound
> from/to GSM.

I believe this is correct, and I think it was encountered by someone testing 
my simplemixer. The symptom fitted, and neither of us managed to reproduce it, 
so that was my best guess as to the cause.

I'm sure I proposed an API modification to get around this, but I can't find 
it now :-/ Essentially I wanted to add SaveCurrentScenario() as that's what an 
app usually wants to do anyway. In the race case we lose the scenario we 
wanted to save, but we don't overwrite another scenario. It would probably be 
good to have some feedback as to which scenario was saved so that we know if 
we lost what we wanted. Keeping SaveScenario(s) means we don't break legacy 
apps, and we still have the option of saving to named scenarios if we really 
need to.

> Finally a couple of "issues":
> 
> * when switching audio scenarios the displays turns on (is this a bug
> or a feature?)
> * the "Scenario" signal is not emitted, so apps have to poll
> periodically to be sure some other ones did not switched the current
> scenario, as the method is documented, is that going to be
> fixed/implemented?

This used to work - is this another case of fso2 implementation not being 
complete yet?

> 
> Regards
> 
>      Niko
> 
> _______________________________________________
> Smartphones-userland mailing list
> Smartphones-userland at linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland