>> Wow. Run-time changes and discoverability? This sounds wild. what type >> of solutions are we talking about here? >> All the DSP implementations I've seen are pretty dumb, the firmware is >> downloaded at the request of the host when a specific service is >> requested; discoverability isn't an issue since the driver and >> possibly user-space know what's been downloaded and how the downloaded >> parts interact with the rest of the firmware. > > Having the driver figure out what's going on isn't usually much of an > issue, it's letting the application know about the configuration that's > available. In situations where the DSP can support flexible routing > (eg, if it's got multiple audio interfaces and can route or mix between > them and also to and from the CPU) with per-flow algorithm selection it > gets unmanagable if you try to show everything possible via the current > ALSA APIs. Things get worse the more algorithms and so on the DSP can > support. Ok I get your point and agree with the analysis. Still, isn't UCM going to address some of the complexity by abstracting the routing/agorithms with some predefined configurations? Or are you talking about going beyond static UCM configurations into something more flexible based on the Media Controller API? -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
