[alsa-devel] ALSA always writes _whole_ periods, right?
Hi ALSA devs,
I have a quick question regarding the filling of the usual ring buffer in RAM (used by sound controllers via DMA), just to be really sure:
Is it true, that ALSA always writes (via mmap'ing) _whole_ periods?
I took snd-dummy and modified it to use "ack()" method and tried to confirm, if the above is true _without_ memory mapping (classical read/write). It seem's to be true, ALSA is "filling up" the last (not always complete) period - e.g. if the played wav file is not a multiple of periodsize in length. But well, with mmap, I cannot see the copying action (done by ALSA library, right?) ... so, thus my question ;-) .
Thanks, Joachim
At Wed, 13 Jun 2007 18:23:38 +0200, Joachim Förster wrote:
Hi ALSA devs,
I have a quick question regarding the filling of the usual ring buffer in RAM (used by sound controllers via DMA), just to be really sure:
Is it true, that ALSA always writes (via mmap'ing) _whole_ periods?
The whole buffer is, of course, used. Otherwise you'll get obvious noises :)
But if you're asking about the timinig, then no. How much data is written at which timing isn't strictly defined in mmap mode. The PCM core just checks the available size at each snd_pcm_period_elapsed(), and reports XRUN if needed. That's all.
I took snd-dummy and modified it to use "ack()" method and tried to confirm, if the above is true _without_ memory mapping (classical read/write). It seem's to be true, ALSA is "filling up" the last (not always complete) period - e.g. if the played wav file is not a multiple of periodsize in length. But well, with mmap, I cannot see the copying action (done by ALSA library, right?) ... so, thus my question ;-) .
Right, copy / ack aren't involved with mmap mode...
Takashi
Hi Takashi,
thanks for your answer,
On Thu, 2007-06-14 at 12:39 +0200, Takashi Iwai wrote:
I have a quick question regarding the filling of the usual ring buffer in RAM (used by sound controllers via DMA), just to be really sure:
Is it true, that ALSA always writes (via mmap'ing) _whole_ periods?
The whole buffer is, of course, used. Otherwise you'll get obvious noises :)
But if you're asking about the timinig, then no. How much data is written at which timing isn't strictly defined in mmap mode. The PCM core just checks the available size at each snd_pcm_period_elapsed(), and reports XRUN if needed. That's all.
Ok, ahm, I think my question was not about what I really wanted to know - sorry. I have to reformulate it: In fact I would like to know, how the ALSA-library mmap code behaves regarding the last chunk of samples, for example: Consider aplay, playing a wav file and the wav file's size/number of samples does _not_ fit to a multiple of a period's size. Then, does the mmap code copy these last samples as is _or_ does it copy one whole last period (which is filled with zeros)?
Thanks, Joachim
At Sat, 16 Jun 2007 23:35:15 +0200, Joachim Förster wrote:
Hi Takashi,
thanks for your answer,
On Thu, 2007-06-14 at 12:39 +0200, Takashi Iwai wrote:
I have a quick question regarding the filling of the usual ring buffer in RAM (used by sound controllers via DMA), just to be really sure:
Is it true, that ALSA always writes (via mmap'ing) _whole_ periods?
The whole buffer is, of course, used. Otherwise you'll get obvious noises :)
But if you're asking about the timinig, then no. How much data is written at which timing isn't strictly defined in mmap mode. The PCM core just checks the available size at each snd_pcm_period_elapsed(), and reports XRUN if needed. That's all.
Ok, ahm, I think my question was not about what I really wanted to know
- sorry. I have to reformulate it: In fact I would like to know, how the
ALSA-library mmap code behaves regarding the last chunk of samples, for example: Consider aplay, playing a wav file and the wav file's size/number of samples does _not_ fit to a multiple of a period's size. Then, does the mmap code copy these last samples as is _or_ does it copy one whole last period (which is filled with zeros)?
No, you have to fill silence by yourself before committing the mmap chunk. The mmap code itself doesn't care about it.
Takashi
participants (2)
-
Joachim Förster -
Takashi Iwai