[alsa-devel] Qustions on dmix - aplay - hw_ptr - appl_ptr

Matthew Foster matt at breakcode.com
Tue Apr 17 19:12:07 CEST 2007

I am a driver developer that is new to ALSA. I have read the tutorial as an
example on how to write an ALSA driver. I appreciate the documentation you
have provided online. I was wondering if you might have time to possibly
answer a question. I am having trouble understanding things in the
memory/buffer management area. 


 I am not writing a driver for a PCI device, I am writing a driver that acts
as an interface from the ALSA to a render device. So I essentially have a
circular buffer I am transferring the ALSA data to.  I set up the ALSA
buffer like this:


snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS,




And later on in my driver after open is called I have a buffer polling loop
that does the period notification and constantly monitors my render (ouput)
buffer. I have my asound.conf setup like this:


    pcm.mix {

        type dmix

        ipc_key 1024

        slave {

        pcm "hw:0,0"

            rate 48000




    pcm.!default {

        type plug

        slave.pcm "mix"




This is to enable the dmix plugin so I can run aplay more than once and have
the two streams mixed in.  


The problem I am having is that it seems that when I run aplay like this:
"aplay close.wav" I only see this pointer moving:



And if I run aplay like this: "aplay -D plughw:0,0 close.wav" I only see
this pointer moving:



This seems odd to me and currently in my code I just check which pointer
moves and use that to calculate how much data I need to write to my render
device. This is so I can support both use cases.


Another major problem is that when I play a short wav file 25KB or so and
use the dmix "aplay close.wav" it randomly doesn't play at sometimes. Also
if I run "aplay close.wav" and then very quickly run "aplay close.wav" again
at the same prompt I get corruption of the data which produces screeching.
In the case where I run aplay one right after the other I notice that the
hw_ptr moves differently (less) than if I run it, wait, run again. 


I am also noticing also that when I do the aplay over and over quickly that
these values change (get lower) in my snd_pcm_prepare callback:

  chip_data->buf_size        = snd_pcm_lib_buffer_bytes(substream);

  chip_data->period_buf_size = snd_pcm_lib_period_bytes(substream);


It seems like those value should remain constant, and I use those values to
calculate later in my polling thread to notify of a period lapse. It's
almost like the runtime is telling me the period has changed and the buffer
size has changed. But this only happens in this case with a short wav file
and running aplay over and over quickly. 


Is there a way to make sure the hw_ptr doesn't get affected by multiple
instances of aplay trying to render out small clips. It seems like maybe I
am setting up something incorrectly or maybe not blocking/ waiting


I am at a loss in trying to figure this out, wondering if you would be so
kind as to comment on my situation. I really appreciate your time in reading
this email. 




More information about the Alsa-devel mailing list