ALSA always writes _whole_ periods, right?

ALSA always writes _whole_ periods, right?

[Joachim Förster]

[-- Attachment #1.1: Type: text/plain, Size: 677 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ALSA always writes _whole_ periods, right?

[Takashi Iwai]

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

Re: ALSA always writes _whole_ periods, right?

[Joachim Förster]

[-- Attachment #1.1: Type: text/plain, Size: 1187 bytes --]

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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: ALSA always writes _whole_ periods, right?

[Takashi Iwai]

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

Re: 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