[alsa-devel] [RFC] A question regarding open ioctl for user space in ASoC driver.
Guangyu.Chen at freescale.com
Tue May 20 06:43:24 CEST 2014
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:
> > 1) 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.
> > 2) 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.
More information about the Alsa-devel