At Tue, 17 Apr 2007 10:12:07 -0700, Matthew Foster wrote:
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, snd_dma_continuous_data(GFP_KERNEL), ALSA_BUF_SIZE, ALSA_BUF_SIZE)) < 0);
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:
substream->runtime->status->hw_ptrbir
And if I run aplay like this: "aplay -D plughw:0,0 close.wav" I only see this pointer moving:
substream->runtime->control->appl_ptr
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.
The behavior of dmix is somehow special. It mmaps a buffer to multiple instances and runs continuously without XRUN check as long as clients are connected. Dmix assumes the driver running a la DMA. That is, hw_ptr can be constantly updated in a ring buffer. Since it disables the XRUN check by adjusting stop_threshold, appl_ptr is meaningless here.
Thus, for supporting dmix on your device, you may need to ignore appl_ptr and simply transfer the period-size chunk at each time.
Currently, the support of non-DMA style hardwares is poor on ALSA, which I'd like to improve in near future. At least, we should provide a proper framework.
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.
Possibly depending on the behavior above?
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.
This sounds odd. Do you call snd_pcm_lib_malloc() in hw_params callback?
Takashi