Re: PCM buffering ussues ( or probably the lack of understanding )

[Lars-Peter Clausen <lars@metafoo.de>]

On 04/20/2013 12:59 PM, marcelg wrote:
> Lars Peter,
> 
> Thanks for your reply.
> 
> Some things are more clear now, however one issue I still wonder.
> 
> 
> Quote
> 
> "
>> Suppose I want to have some buffering inside my pcm driver, how will I be
>> able to get some samples in advance before starting playback ? Can I just
>> call pcm_period_elapsed() a few times in  a row to get the buffer filled
>> before starting the actual playcback, or does this cause side effects ?
>>
> Why'd you want to do that?
> "
> 
> 
> If Alsa is not having an internal buffer as you pointed out. An my driver
> for example advertises
> min periods = 1  and max_periods = 10.   Then it means my drivers is capable
> of buffering up to 10 periods.
> 
> However what I notice is that the Alsa layer pcm_copy()  always supplies
> "period_bytes" after each call to period_elapsed()
> 
> This would imply that even my driver is able to buffer 10 periods, it never
> receives more data as one period, because I call period_elapsed()
> as soon as the data is consumed.


The ALSA core keeps track of how many bytes are available in your buffer. It
will supply your driver with as many bytes as there is space in the buffer.
So if you start playback you should see it supplying you more than one
period worth of bytes. Once the buffer is full you'll naturally only get one
new period of each period that has elapsed.

But as I said before if you don't do anything other then copying data to
your buffer in the copy callback, you should probably get rid of the copy
callback altogether and let ALSA take care of writing the data to your
buffer. This will also allow you to use for example mmap.

- Lars