[alsa-devel] ALSA always writes _whole_ periods, right?

[Takashi Iwai]

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