On Wed, 2011-03-16 at 23:38 +0530, Mark Brown wrote: > On Wed, Mar 16, 2011 at 01:00:09PM -0500, pl bossart wrote: > > On Wed, Mar 16, 2011 at 12:53 PM, Mark Brown > > > > It'd make the tie up with algorithms part much easier as we could have > > > an interface for transferring the compressed data alone and then > > > externally describe how that's plumbed into any other DSP that's going > > > on and the physical outputs - it'd help with treating the data transfer > > > as a standalone problem. > > > Still not convinced. Why would you need to 'externally describe' how > > compressed data is linked to post-processing. It's all part of DSP > > firmware, why should anyone care how the decoder provides data to > > post-processes? You can control post-processes with ALSA controls as > > for regular PCM. > > The problem is figuring out which controls are where and what can be > joined up with what. This is a problem with regular PCM too but it gets > much worse when everything is virtual. Media controller should provide > a route to allowing applications to figure out what's going on in the > hardware. Wouldn't a virtual sound card solve this? I was thinking of representing all DSP elements in a virtual card. From userland, we know when decoder, algorithms etc are active and can control them. The virtual card output gets connected to actual sound card. -- ~Vinod -- 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
