At Sun, 24 Jun 2007 11:34:56 +0200, Joachim Förster wrote:
Hi Takashi,
thanks for your answer.
On Wed, 2007-06-20 at 12:45 +0200, Takashi Iwai wrote:
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.
By "fill silence by yourself", you mean the application (user-space) which is using ALSA library (with mmap), right? So this is not in the responsibility of the sound driver, right?
Right. The driver has some functionality to fill silence automatically, but it's better to avoid to play with it :)
Hmmm, so if an application does _not_ transfer sound data in a multiple of period size, the _last_ "period" will be "incomplete". Then, my question is: Does ALSA expect to receive a call of snd_period_elapsed() after these last samples are played, although the it was _not_ a complete period?
I think it might depend on the hardware. Some hardwares are available to stop at the exact position, but most hardware are not. So, it's _safer_ to send always the data in the period size. And, yes, for the last period with less data, the app should fill the data to align to the period size.
Takashi