Re: [alsa-devel] Compressed Audio Playback/Capture through ALSA framework

[pl bossart <bossart.nospam@gmail.com>]

>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html