On Tue, 2007-09-04 at 15:14 +0800, Leijin Tang wrote:> Hi all,> > When the audio codec is used in the smartphone, we get the problem how to define and control the route in the alsa driver. The scenario is only in the phone device. The application need switch the routes based on the different scenes.
This is something I've been looking into for the last year and sadlyhave not had any development time to commit to it. It's also somethingthe openmoko guys are looking at too. Atm there is no ALSA API or configfile format for changing/defining scenarios.
Fwiw, the OpenZaurus machines do ALSA scenario atm using an alsactl dumpfor each scenario. This is changed by user space when the devicescenario is changed. (google for zaurusd for info)
> > Example: the coedec is wm9713L.> > the in port: LINEL，LINER，MONOIN，MIC1，MIC2, ac97_in > > the out port: HEADSET, SPEAKER, RECEIVER, ac97_out > > When the phone is coming, we need chose the route LINE to receiver. After the calling and playing the mp3, we should switch the route ac97_in to speaker on.> > This scenario doesn’t appear in the PC. So how to carry out the function in the alsa architecture is so difficulty. The router names how to define, the alsa-lib how to do the control.There has no design to the phone device in the alsa by now. > > Does anybody have some ideas? We can do some discussion and resolve the issue. >
Ideally, we should be able to specify scenarios in a text file. Thisfile could either list the sources and sinks within each scenario (foran autorouter to set - (I have some autorouter code)) or list a seriesof kcontrol settings for each scenario or both.
e.g. (for autorouter)
Scenario "Headphone Playback" { Source "Left DAC" Source "Right DAC" Sink "Left Out1" Sink "Right Out1" Volume "Out1 Playback Volume" Mute "Out1 Playback Switch"}
e.g. (for kcontrol series)
Scenario "Headphone Playback" { Control "Out1 Left Mixer Playback Switch" Value "true" Control "Out1 Right Mixer Playback Switch" Value "true" Volume "Out1 Playback Volume" Mute "Out1 Playback Switch"}
Note: These are just example formats, they need some thought.
The scenarios should also be able to re alias volumes, mutes etc as wellas altering internal codec routes. This is because the changing routeoften changes the alsa controls for volume, mute etc as well. This way"master volume" will always be "master volume" to user apps regardlessof the actual scenario.
We should probably also add some new function calls to alsa-lib in orderget/set scenario e.g.
snd_scenario_get() - gets the current scenariosnd_scenario_set() - sets the scenariosnd_scenario_list() - lists all the available scenarios supported bysound card.
Finally, I also would define a set of standard scenarios. This wouldallow application software to become far more portable between devices.i.e. the app would just need to ask for "Voice Call Handset" instead ofknowing the scenario name for each machine. Custom scenarios should alsobe permitted.
This is just a brain dump atm, I'll try and clarify it a bit to makemore sense later. I also have to post a similar mail to the ohm-devellist so I'll cross post if no one minds.
Liam
_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
