On 3/16/2011 7:21 PM, Koul, Vinod wrote:
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.
I think it would work to certain extend but what if DSP can instantiate
elements at run-time, how can we deal with this use case under current
ALSA framework?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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
