At Fri, 25 Apr 2008 11:34:40 +0100, Liam Girdwood wrote: > > On Fri, 2008-04-25 at 11:42 +0200, Takashi Iwai wrote: > > At Fri, 25 Apr 2008 11:30:40 +0200, > > Daniel Mack wrote: > > > > > > On Fri, Apr 25, 2008 at 11:22:10AM +0200, Takashi Iwai wrote: > > > > > Add more routing controls to AIC3x chips to allow things like routing > > > > > the left PGA input to right line out. > > > > > > > > > > Signed-off-by: Daniel Mack <daniel@xxxxxxxx> > > > > > > > > It should be implemented rather with stereo mixer switches in > > > > general... > > > > > > Not necessarily as left and right inputs of let's say the line input can > > > be used for entierly different things. Same is counts for the outputs. > > > This is the case in my setup and I guess for mobile phone (what the chip > > > is made for) there will be more cases. > > > > > > Controlling them with stereo mixers would just cause more confusion in > > > the already over-engineered chip, I fear. > > > > Well, for such a complex system, switches don't suite well as the end > > point representation. A switch is the easiest way to implement in a > > driver, but you'll have a mess in the end if there are too many > > switches. > > > > We can hide these in an higher abstraction layer (e.g. alsa-lib mixer > > interface) if it were implemented. Otherwise, think about a more > > reasonable (can be less-flexible though) setup, e.g. using enum > > controls to represent the hardware configuration intead of combination > > of lots of switches. > > > > I'm not too keen on using custom enums to represent the use cases on > embedded devices - I don't think it's very application independent. I'd > rather provide all the controls in the codec and have user space > abstract the use cases (as above) in a standard device neutral API. > > The main problem I think we have on phones is that the audio routing is > incredibly complex compared to a PC. i.e. a lot of mixers/controls have > to be changed when we have a use case change. Surely the implementation depends on the use cases, and phones and embedded devices have different use cases than desktop ones... > > Honestly, in the case of existing asoc drivers, I don't care much, and > > likely I'll let it be. But, this is an issue we need to reconsider > > for the future development. > > Fwiw, the ALSA scenario/use case library (future/current development to > handle the above abstractions) now has a public git. The code compiles, > although doesn't do much atm except parsing and storing the current > sound card state. :-/ > > I'm looking for some help in completing the library as it's quite low on > my todo list atm. Imo it's probably only about a couple of days work > involved (by someone knowledgeable with alsa-lib) to get something basic > working. I can give git commit access if required. Any takers ? Yes, scenario is a promising stuff for solving this kind of problem. I'm willing to check it if I have free time later... Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
