[SDL] Re: Re: Feeding the audio buffer

[Greg Lee]

Craig Edwards wrote:
> On Thu, 28 Oct 2004 01:50:51 -1000, Greg Lee <greg at ling.lll.hawaii.edu>  
> wrote:
> 
>>  <snip> a lot of good stuff </snip>
> 
> 
> Thanks very much for the detailed reply.  It is slowly starting to sink 
> in  :-)
> 
> If I can indulge your patience one more time...  I am curious as to how 
> it  would work if the application is cooking fragments *faster* than the 
> chip  can process.

Then it has to wait, giving the time up to the system for other tasks,
or find something else useful to do.

> I know that AC97 has 32 available descriptors for  
> fragments... I wonder what happens if the driver gets 33 fragments from  
> the application code before the chip has finished playing the first 
> one?

The situation can't arise (speaking only about Alsa, where the
term is "period", not "fragment").  When you open, you choose
a buffer size, the number of periods, and a period size, and the
driver tells you what the size limits are.  Once you've chosen,
protocol is to ask what you were actually given, in case it's
not what you asked for.  The periods have to fit inside the buffer
(I think).  If you try writing a period when there's not enough
free room in the buffer to hold it, the driver just says "No"
(-EAGAIN).  It's the driver that maintains the buffer.  (You could
implement your own private buffer, of course, in addition to the 
driver's buffer.)

>  Would the driver buffer it internally?  Or would is just 
> overwrite the  next descriptor (which happens to be the currently 
> playing one)?  It  probably will never happen... I am just curious.  
> Thanks again for your  patience and explanations.

Greg