On Sun 6 Jan 2008 05:15, Joachim Foerster pondered:

Hi Cliff,

On Wed, 2008-01-02 at 06:26 +0000, cailinhua wrote:

...

I want to enable dmix for our sound card. Unfortunately for some reason the sound card driver don't support 'mmap' way,it only support 'copy' callback to copy data from upper level to DMA.

A little background - the driver in question is actually doing format conversion. We take a PCM stream from userspace, and re-format it so we can talk to an AC'97 (like) codec via a standard TDM bus. This is why we don't allow userspace to talk to the hardware directly via mmap.

...

So ,I think maybe I can modify the alsa-lib dmix source code to let it use 'copy' way to send data to the driver. Is it possible？ Could you please give me some ideas?

I don't know how difficult it would be to change alsa-lib's dmix sources, but my suggestion - in general - would be to alter the driver of your sound card to use the "intermediate buffer" technique (using pcm-indirect.h): Setup a buffer in RAM, which can be mmap'ed by applications and copy the contents of this buffer to the hardware in a background process for example. (See Takashi's "Writing an ALSA Driver" guide.)

OK - I see in: http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/x1405.htm ------------- Some chips have their own hardware buffers and the DMA transfer from the host memory is not available. In such a case, you need to either 1) copy/set the audio data directly to the external hardware buffer, or 2) make an intermediate buffer and copy/set the data from it to the external hardware buffer in interrupts (or in tasklets, preferably). The second case allows the mmap of the buffer, although you have to handle an interrupt or a tasklet for transferring the data from the intermediate buffer to the hardware buffer. You can find an example in vxpocket driver. ------------- I assume that is what you mean? If so, I'm still confused - since the pcmcia/vx (vxpocket driver) doesn't seem to do that... ?? I do see the driver in pci/rme32.c - it is using pcm-indirect.h and the snd_pcm_indirect_xxx functions - if that is the one we should be looking at? My only question is - if you allow a mmaped intermediate buffer, how does the driver notice when ALSA writes into this buffer? Thanks -Robin Thanks -Robin

On Fri 11 Jan 2008 10:01, Joachim Foerster pondered:

...

My only question is - if you allow a mmaped intermediate buffer, how does the driver notice when ALSA writes into this buffer?

It's the ack() callback. ALSA writes/reads something into/from the intermediate buffer and calls the driver's ack() callback - if there is any. In the ack() callback the driver should call one of the snd_pcm_indirect_*_transfer() functions. There, the difference between current and last seen appl_ptr gives the "new position" of the PCM Layer in your intermediate buffer (where it will write/read next time).

OK - thanks. From just thinking about it - won't this will cause problems for things that need to understand where the audio device is in the PCM stream (like AEC, and lip-sync)? Since now everything from userspace is in reference to the position in the intermediate buffer - rather than what is actually coming out the DACs?