<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=gb2312"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="chsdate"/> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>  <style>  </style> </head> <body lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation'> <div class=Section1 style='layout-grid:15.6pt'> Hi<o:p></o:p>      Thanks for the Takashi's idea.<o:p></o:p>      It's agreement that controlling the scenarios is needed in the alsa-lib. To the mobile device, the policy about the router switch or volume control is so complex that we can't resolve all issues by modified the alsa-lib.<o:p></o:p> Whether we can develop a simple server which carries out the policy? <o:p></o:p> But we still need define the control element, it's very important to the server's portability. Because the definition makes BSP to write driver which have the same interface. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> -----邮件原件----- 发件人: Takashi Iwai [mailto:tiwai@suse.de] 发送时间: <st1:chsdate IsROCDate="False" IsLunarDate="False" Day="19" Month="10" Year="2007" w:st="on">2007年10月19日</st1:chsdate> 17:15 收件人: Liam Girdwood 抄送: <st1:PersonName ProductID="Leijin Tang" w:st="on">Leijin Tang</st1:PersonName>; alsa-devel; ohm-devel 主题: Re: [alsa-devel] [RFC] ALSA scenario API <o:p> </o:p> At Wed, 17 Oct 2007 01:12:13 +0100,<o:p></o:p> Liam Girdwood wrote:<o:p></o:p> > <o:p></o:p> > A little late with this but "better late than never".....I did promise a<o:p></o:p> > few people that I would post what was imho needed for ALSA scenarios.<o:p></o:p> > <o:p></o:p> > Also, apologies for cross posting, but it some of this probably applies<o:p></o:p> > to both lists... <o:p></o:p> > <o:p></o:p> > ALSA probably needs functionality to define and set audio usage<o:p></o:p> > scenarios. A scenario is simply a list of sound card mixer settings for<o:p></o:p> > a given use case. This is quite important for mobile devices (e.g.<o:p></o:p> > Smartphones, GPS, PDA, etc) with complex audio routing and power<o:p></o:p> > requirements. Some example scenarios could be :-<o:p></o:p> > <o:p></o:p> > "HiFi Headphone Playback"<o:p></o:p> > "HiFi Speaker Playback"<o:p></o:p> > "Handset Phone Call"<o:p></o:p> > "Headset Phone Call"<o:p></o:p> > etc...<o:p></o:p> > <o:p></o:p> > Scenarios are changed atm by either manually setting each control (e.g.<o:p></o:p> > using alsamixer or alsa-lib in apps) or by using alsactl to restore a<o:p></o:p> > scenario. The above two methods are not very portable between devices<o:p></o:p> > and applications. We would ideally like to just say "set Phone Call<o:p></o:p> > Handset" for a regular handset phone call or "set HiFi Headphones" for<o:p></o:p> > MP3 playback.<o:p></o:p> > <o:p></o:p> > ALSA also needs to have functionality to alias mixer controls. This<o:p></o:p> > would allow a single master volume/mute control to be exposed to user<o:p></o:p> > space and have it aliased to different hardware controls based upon the<o:p></o:p> > current scenario. e.g. Many mobile devices have different physical<o:p></o:p> > volume controls for speaker and headphones. This makes it somewhat<o:p></o:p> > difficult for user space apps to change the correct volume (without<o:p></o:p> > being bound to the hardware). We would like to be able to just say "set<o:p></o:p> > volume to 0dB" and have the alias take care of the correct physical<o:p></o:p> > CODEC mixer for the current scenario.<o:p></o:p> > <o:p></o:p> > Proposal:<o:p></o:p> > ========<o:p></o:p> > <o:p></o:p> > 1. Add some new scenario functions to (s)alsa-lib. e.g.<o:p></o:p> > <o:p></o:p> > snd_scenario_set();<o:p></o:p> > snd_scenario_get();<o:p></o:p> > snd_scenario_list();<o:p></o:p> > <o:p></o:p> > _set() would set the scenario e.g.<o:p></o:p> > <o:p></o:p> > snd_scenario_set(card, SND_VOICE_CALL_HANDSET);<o:p></o:p> > <o:p></o:p> > We would need to have a list of standard scenarios so that applications<o:p></o:p> > could be more portable. Vendor scenario's should also be supported.<o:p></o:p> > <o:p></o:p> > _get() would return the current scenario.<o:p></o:p> > <o:p></o:p> > _list() would return a list of supported scenarios for the given device.<o:p></o:p> > <o:p></o:p> > <o:p></o:p> > 2. Add some new mixer alias functions to set/get the current "master"<o:p></o:p> > volume/mute. e.g.<o:p></o:p> > <o:p></o:p> > snd_kcontrol *snd_scenario_volume_set(card, type, volume);<o:p></o:p> > snd_kcontrol *snd_scenario_switch_set(card, type, switch);<o:p></o:p> > <o:p></o:p> > where type is playback, capture, sidetone, bypass, etc<o:p></o:p> > <o:p></o:p> > This would set the volume for the current scenario and would guarantee<o:p></o:p> > always to get/set the _correct_ volume/switch.<o:p></o:p> > <o:p></o:p> > 3. Add a new function to return the active PCM for a given scenario.<o:p></o:p> > e.g.<o:p></o:p> > <o:p></o:p> > snd_scenario_get_pcm(card, scenario);<o:p></o:p> > <o:p></o:p> > Would return the given PCM for a particular scenario. i.e. the WM9713<o:p></o:p> > driver has PCM 0.0 for high quality (higher power) audio (MP3), PCM 0.1<o:p></o:p> > for lower power voice and PCM 0.2 for lowest power and quality system<o:p></o:p> > sounds.<o:p></o:p> > <o:p></o:p> > Note: scenarios may need to be more tightly bound to PCM's rather than<o:p></o:p> > cards. <o:p></o:p> > <o:p></o:p> > 4. Define a file format to represent each scenario. Probably base this<o:p></o:p> > upon alsactl's format as alsamixer could be used to quickly generate<o:p></o:p> > good settings and then save them with alsactl. Alias, scenario names and<o:p></o:p> > PCM would need to be added later somehow.<o:p></o:p> > <o:p></o:p> > 5. (Optional) Allow scenarios to define active kcontrols. This would<o:p></o:p> > allow tools like alsamixer to only display mixer controls for the given<o:p></o:p> > scenario. Controls that don't effect the scenario would not be rendered.<o:p></o:p> > (similar to alsamixers Playback|Capture|All tab)<o:p></o:p> > <o:p></o:p> > 6. (OHM list) Add input driver (or similar) for sound card user events.<o:p></o:p> > We need to be able to send events like "Headphone Jack Insertion", "Mic<o:p></o:p> > Jack Insertion", etc to user space. This would allow changing of<o:p></o:p> > scenario and power configuration depending on policy and configuration. <o:p></o:p> > <o:p></o:p> > Just my 2p<o:p></o:p> > <o:p></o:p> > Unfortunately I'm not in a position to implement any of this<o:p></o:p> > functionality. However, it's probably useful to folks working on mobile<o:p></o:p> > devices. Maybe a good project for Google SoC.<o:p></o:p> <o:p> </o:p> It's an interesting idea.  Similar things are needed vastly for other<o:p></o:p> purposes, such as speaker setup.  But, my first thinking is whether we<o:p></o:p> need this in the upper (user-space alsa-lib) level or in the driver<o:p></o:p> level.<o:p></o:p> <o:p> </o:p> Certainly the driver must know at best what scenario is available and<o:p></o:p> how it should react.  I've thought this kind of thing could be<o:p></o:p> implemented better, more elegantly, on user-space.  But, thinking<o:p></o:p> twice, the driver implementation can be much easier in many cases.<o:p></o:p> Suppose the switching (aliasing) the control name depending on the<o:p></o:p> given scenario.  The scenario state is global and must be stored in a<o:p></o:p> global position.  The easiest one is in the driver -- this will solve<o:p></o:p> the access permission and race problem automatically, too, which the<o:p></o:p> shared-memory solution always suffers.<o:p></o:p> <o:p> </o:p> Thus, it would be maybe good to implement the secnario as a control<o:p></o:p> element (not necessarily as a mixer element but we can give a<o:p></o:p> different IFACE attribute, e.g. SND_CTL_ELEM_IFACE_CARD).  Then the<o:p></o:p> above snd_scenario_set/get/list functions becomes simple snd_ctl_*().<o:p></o:p> <o:p> </o:p> <o:p> </o:p> About PCM: if we implement again this kind of things in the driver, we<o:p></o:p> may have a virtual PCM stream for the default use and other fixed PCM<o:p></o:p> streams.  They can be opened exclusively, and the default stream opens<o:p></o:p> different H/W stream according to the current scenario.  (BTW, still a<o:p></o:p> question remains: when the scenario switch happens on the fly during a<o:p></o:p> PCM stream being used, what should be done?)<o:p></o:p> <o:p> </o:p> Or, simply alsa-lib checks the current scenario value and chooses the<o:p></o:p> appropriate preset setup.  This would work well (at least for<o:p></o:p> alsa-lib, not salsa-lib - such a complicated implementation is outside<o:p></o:p> the scope of salsa-lib).  This user-space solution (for PCM) has<o:p></o:p> another advantage that it's easier to handle PCM setups for multiple<o:p></o:p> streams.  For example, suppose we use "scenario" for speaker setup.<o:p></o:p> emu10k1 uses multiple PCM streams for 4.0/5.1 surrounds, and the<o:p></o:p> driver-side implementation wouldn't work unless it reflects to<o:p></o:p> alsa-lib setup.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> My another $0.02.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Takashi<o:p></o:p> </div> </body> </html>