Thanks for the ideas!
On Tue, May 20, 2014 at 01:18:34AM +0100, Mark Brown wrote:
On Fri, May 16, 2014 at 06:59:41PM +0800, Nicolin Chen wrote:
- P2P, peripheral to peripheral, regards ASRC as a FE (front end link) corresponding to a BE (back end link like ESAI<->CS42888). The P2P function resolves a problem of unsupported sample rates for BE that we can convert the unsupported audio format to a supported one before we send the data into BE. It also has better quality and less CPU loading comparing to ALSA-lib's SRC function.
- For this function, I don't see any critical problem here. But...
This is moderately common in mainline already. You shouldn't need to have any custom code - we should just be able to figure out that the SRC is needed (and a quick glance at your out of tree code shows now ioctl() so that's fine as you say).
I was thinking about just leaving P2P as an initial version and reserving some essential interfaces for M2M function so that I can add it up later in our internal branch or we can figure out a better approach in community style. And now, it looks like a good idea for me to try this way so as to move on quickly.
- M2M, memory to memory, can simply make ASRC as a sample rate converter without playback via any BE sound card, just like using any software to convert a WAV file in one sample rate to another WAV in a required sample rate. The driver has its self-designed application to compelte this function by sending the audio data from a wave file into a misc device via non-generic ioctl:
I would expect this to be handled by just routing the audio between the two front ends using DAPM/DPCM rather than by having a new kernel API.a
Two front ends: one for ASRC and the other is...? And how does it transfer audio data with user space?
DPCM is mostly Liam's area so I'll defer to him on exactly how DPCM would figure that out - even with pure DAPM it's something we should do better with than we do. I don't know if there are examples in the Intel code people could refer to?
If nothing else representing the ASRC block as a CODEC would do the trick though that doesn't entirely play well with DPCM, it is kind of doing the right thing though in that the ASRC block terminates two digital paths. I'm not loving the elegence there though.
Sorry I can't understand this CODEC approach either...
Yes, ASRC has two digital ends but each of them is just a FIFO register , input FIFO and output FIFO, waiting for DMA to handle the Tx/Rx job, not like a normal CODEC that has DAI outwards.
Thank you, Nicolin