On Wed, Mar 16, 2011 at 04:29:22PM +0530, Koul, Vinod wrote: > On Wed, 2011-03-16 at 16:08 +0530, Mark Brown wrote: > > Nobody's really tried to do more yet but this may end up being the best > > choice overall as there's substantial variation in how the DSPs are > > structured both physically and OS wise which make the abstractions below > > the userspace API level less clear. > I was thinking more on having a generic framework which coexists with > alsa, asoc (dapm), and provided a way to write driver for your dsp to do > decoder, sink + decoder and other variations. > The implementation of these can be specific to DSP in question, but > framework should be able to push and pull data, timing information > around with a standard way which coexists with current frameworks It would be nice to have a standard userspace API for this but I'm not aware of anyone who's looked at it in detail and you start having to also take into account other algorithms that are running on the device so there's nothing to point people at right now and no real prospect of there being. I don't know if it's something we can resolve entirely in the kernel as I'm aware that some of the DSP implementations have non-trivial management code in userspace that they talk to which may mean that the standard API has to be a userspace one. There's also the difference between memory to memory implementations (which fit into a userspace chain much more readily) and tunneled implementations (which do need new infrastructure). I think this'll get substantially easier to look at once the media controller API is merged and starts to be used in the audio subsystem. -- 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
