buffers, periods, cycles.. oh my!

buffers, periods, cycles.. oh my!

[Davy Durham]

Hi,
   Something I don't seem to grasp is exactly what the difference is 
between, and min/max ranges of, periods and buffers.  I know that a 
sound card uses a buffer to which it reads/writes data (via DMA) and 
that an interrupt can be configured to trigger n times during that 
buffer's filling (these are periods and period count?)  Well, then 
there's API functions for buffer time and sizes (I assume you can set by 
time OR by size in frames, whichever you please, but you don't need to 
set by both).

  I've looked but to no avail.. is there some higher level documentation 
that explains the big picture here?

  When I fist started using the API I had a 1/4 second latency or so for 
playback.. I tried and tried to figure out why but couldn't.  Finally I 
coped JACKs use of the lib and eliminated that. 

  Now, I'm working on capture, but I can't seem to set the buffering 
time to more than 2*8192 frames.  I'd like to set it as high as possible 
to avoid studders in the recording and would rather not buffer the data 
myself if ALSA can already do that.

Thanks,
  Davy


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Davy Durham]

I just wish this stuff was documented somewhere...

Ok, so periods are different than buffers.

I can set the period size and the number of periods.   And then separate 
from that seems to be setting a buffer size/time.

A sound card has to read/write to some area of memory for data 
transfer.  What's a buffer and what's a period?

Thanks,
   Davy

Manuel Jander wrote:

>Hi,
>
>On Sat, 2004-08-28 at 01:46, Davy Durham wrote:
>  
>
>>Hi,
>>   Something I don't seem to grasp is exactly what the difference is 
>>between, and min/max ranges of, periods and buffers.  I know that a 
>>sound card uses a buffer to which it reads/writes data (via DMA) and 
>>that an interrupt can be configured to trigger n times during that 
>>buffer's filling (these are periods and period count?)  Well, then 
>>there's API functions for buffer time and sizes (I assume you can set by 
>>time OR by size in frames, whichever you please, but you don't need to 
>>set by both).
>>    
>>
>
>NO! The max buffer size, period size and periods count are hardware
>dependant parameters ! You can't assume that any combintation will be
>available to you application.
>When you "try" a certain buffer setup, there happens to be a sort of
>"negotiation" with the hardware driver. That means that you may end up
>with a buffer setup that is NOT exactly what you wanted, but as close as
>possible.
>
>  
>
>>  I've looked but to no avail.. is there some higher level documentation 
>>that explains the big picture here?
>>
>>  When I fist started using the API I had a 1/4 second latency or so for 
>>playback.. I tried and tried to figure out why but couldn't.  Finally I 
>>coped JACKs use of the lib and eliminated that. 
>>    
>>
>
>Well, AFAIK, jack was designed for low latency :)
>
>  
>
>>  Now, I'm working on capture, but I can't seem to set the buffering 
>>time to more than 2*8192 frames.  I'd like to set it as high as possible 
>>to avoid studders in the recording and would rather not buffer the data 
>>myself if ALSA can already do that.
>>    
>>
>
>The buffer sizes are hardware dependant. So you will have to obey the
>values that are possible by the hardware, instead of just arbitrary
>selecting certain size/counts. Many application developer don't seme to
>understand that, which is very bad. The result are hardware dependant
>applications :P.
>Its pretty reasonable that you can't get more that 2 periods of 8192
>frames each. Many soundcards have a maximal buffer size of 64KiB, or
>smaller (a larger buffer is just silly). The maximal period size usually
>is 4KiB (page size). On i386 hardware, a period can't be larger than
>that, except if some sort of emulation is performed by the driver (and
>there would be no advantage). You may try to ask for more periods
>instead. But again, if the alsa-lib denies certain settings, your app
>should be able to cope with that. 
>
>Best Regards
>
>Manuel J.
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Davy Durham]

I just wish this stuff was documented somewhere...

Ok, so periods are different than buffers.

I can set the period size and the number of periods.   And then separate 
from that seems to be setting a buffer size/time.

A sound card has to read/write to some area of memory for data 
transfer.  What's a buffer and what's a period?

Thanks,
  Davy

Manuel Jander wrote:

>Hi,
>
>On Sat, 2004-08-28 at 01:46, Davy Durham wrote:
>  
>
>>Hi,
>>   Something I don't seem to grasp is exactly what the difference is 
>>between, and min/max ranges of, periods and buffers.  I know that a 
>>sound card uses a buffer to which it reads/writes data (via DMA) and 
>>that an interrupt can be configured to trigger n times during that 
>>buffer's filling (these are periods and period count?)  Well, then 
>>there's API functions for buffer time and sizes (I assume you can set by 
>>time OR by size in frames, whichever you please, but you don't need to 
>>set by both).
>>    
>>
>
>NO! The max buffer size, period size and periods count are hardware
>dependant parameters ! You can't assume that any combintation will be
>available to you application.
>When you "try" a certain buffer setup, there happens to be a sort of
>"negotiation" with the hardware driver. That means that you may end up
>with a buffer setup that is NOT exactly what you wanted, but as close as
>possible.
>
>  
>
>>  I've looked but to no avail.. is there some higher level documentation 
>>that explains the big picture here?
>>
>>  When I fist started using the API I had a 1/4 second latency or so for 
>>playback.. I tried and tried to figure out why but couldn't.  Finally I 
>>coped JACKs use of the lib and eliminated that. 
>>    
>>
>
>Well, AFAIK, jack was designed for low latency :)
>
>  
>
>>  Now, I'm working on capture, but I can't seem to set the buffering 
>>time to more than 2*8192 frames.  I'd like to set it as high as possible 
>>to avoid studders in the recording and would rather not buffer the data 
>>myself if ALSA can already do that.
>>    
>>
>
>The buffer sizes are hardware dependant. So you will have to obey the
>values that are possible by the hardware, instead of just arbitrary
>selecting certain size/counts. Many application developer don't seme to
>understand that, which is very bad. The result are hardware dependant
>applications :P.
>Its pretty reasonable that you can't get more that 2 periods of 8192
>frames each. Many soundcards have a maximal buffer size of 64KiB, or
>smaller (a larger buffer is just silly). The maximal period size usually
>is 4KiB (page size). On i386 hardware, a period can't be larger than
>that, except if some sort of emulation is performed by the driver (and
>there would be no advantage). You may try to ask for more periods
>instead. But again, if the alsa-lib denies certain settings, your app
>should be able to cope with that. 
>
>Best Regards
>
>Manuel J.
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Paul Davis]

>Ok, so periods are different than buffers.
>
>I can set the period size and the number of periods.   And then separate 
>from that seems to be setting a buffer size/time.
>
>A sound card has to read/write to some area of memory for data 
>transfer.  What's a buffer and what's a period?

just about every single contemporary audio interface defines a
"hardware buffer". this consists of memory owned either by the audio
interface or the host; in either case, the audio interface can
read/write the memory directly (although there are a few devices that
always require assistance from the host CPU to move data to/from this
memory).

there will be 1 hardware buffer for each direction (playback or
capture); depending on the audio interface architecture, there may be
1 buffer per direction per channel (non-interleaved mode) or 1 buffer
per direction for all channels (interleaved mode).

the hardware buffer has a maximum size, and a size currently in
use. so for example, a specific piece of hardware may be able to use a
buffer up to 64kB, but given the current settings, uses only 4kB. read
on to see why.

whatever the effective buffer size is, the hardware will use that
space as a circular buffer, read and writing data to the buffer and
wrapping around whenever it reaches the end.

obviously, the hardware keeps its own record of where in the buffer(s)
it is reading and/or writing data. at various positions within the
buffer, the hardware will generate an interrupt to tell the CPU that
data and/or space is available. the obvious location for such
interrupts is at the wrap around point.

however, this is not necessarily the most useful configuration, and
most audio interfaces can be told to generate an interrupt at other
intervals as the hardware moves through the buffer. this subdivides
the hardware buffer into a series of "periods", punctuated by an
interrupt:


   |-------------- maximum possible buffer size --------------------|
   |----------- current buffer size -----------|
   |           |                |              |
   intr       intr              intr           intr

(note that the "intr" at the start/end of the buffer are equivalent to
each other - its really an interrupt at the wrap point)

so, in the above diagram, the hardware buffer is divided into 3
periods; as the hardware "pointer" crosses each divide, the CPU is
interrupted, and the CPU can read/write data into the buffer
before/after the hardware pointer, as appropriate.

in the above example, the interrupts are evenly spaced, typically
using a power-of-2 number of audio samples, and thus the total buffer
size is nperiods * period size. the general relationship is:

     buffer_size = nperiods * period_size;

with all the permutations that suggests.

you can measure the sizes of buffers and periods in samples, bytes or
units of time. the conversion factors between them depends on the
sample bit width and the sample rate.

--p


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Davy Durham]

Ok, thanks guys.  [Paul and Manuel]  This pretty much clears it up.  I 
knew most of that.  I was one of the few that paid out the butt and got 
the sound blaster development kit WAY back when, and I got to have all 
the fun of programming DMA and directly handling interrupts in DOS. [I 
even discovered that I could do full-duplex on the SB16 as long as the 
recording was 8bit and playback 16bit, or vice-versa.. because the bits 
on the interrupt flags made the reason for the interrupt 
distinguishable.. that was one happy late middle of the night when it 
actually worked and my voice ECHOED echoed echhoed ... :)  ]

The key here to my understanding was that a period is a part of the 
larger buffer construct.  I was thinking that, but nothing in the docs 
indicated it for sure.

For my needs (I'm developing a native ALSA implementation for ReZound), 
I want a small playback buffer time.  I want the GUI's play position to 
closely corrispond to the audio being heard. 

But I want a large capture buffer time when doing recording because I'm 
streaming the data directly to disk thru my own file I/O layer [which 
maps a linear logical space into a fragmented physical space].

Manuel's explanation sounded as if buffer times are very dependant on 
hardware specifics.  Just to get Paul's take.. Does it depend on the 
hardware as to what I can set the buffer time for recording?  Is this 
buffering layer not something that ALSA is implementing where buffers of 
whatever size are being handled by software.  Now, periods on the other 
hand (I would guess) probably are hardware specific because they relate 
directly to interrupt triggers caused by the hardware.  Am I probably 
safest going with a power of 2 for a period size, and safest going with 
an integral multiple of the period size for the buffer size?

I've got playback pretty much how I want it.  But for my capture code, I 
would prefer to have maybe a second or so of buffer time if it becomes 
necessary [streaming to disk and all].  I'm willing to go with the 
nearest power of 2 if necessary of course.  Is this possible given any 
hardware, or will I need to buffer captured data myself to be on the 
safe side?

Thanks again,
  Davy



Paul Davis wrote:

>>Ok, so periods are different than buffers.
>>
>>I can set the period size and the number of periods.   And then separate 
>>    
>>
>>from that seems to be setting a buffer size/time.
>  
>
>>A sound card has to read/write to some area of memory for data 
>>transfer.  What's a buffer and what's a period?
>>    
>>
>
>just about every single contemporary audio interface defines a
>"hardware buffer". this consists of memory owned either by the audio
>interface or the host; in either case, the audio interface can
>read/write the memory directly (although there are a few devices that
>always require assistance from the host CPU to move data to/from this
>memory).
>
>there will be 1 hardware buffer for each direction (playback or
>capture); depending on the audio interface architecture, there may be
>1 buffer per direction per channel (non-interleaved mode) or 1 buffer
>per direction for all channels (interleaved mode).
>
>the hardware buffer has a maximum size, and a size currently in
>use. so for example, a specific piece of hardware may be able to use a
>buffer up to 64kB, but given the current settings, uses only 4kB. read
>on to see why.
>
>whatever the effective buffer size is, the hardware will use that
>space as a circular buffer, read and writing data to the buffer and
>wrapping around whenever it reaches the end.
>
>obviously, the hardware keeps its own record of where in the buffer(s)
>it is reading and/or writing data. at various positions within the
>buffer, the hardware will generate an interrupt to tell the CPU that
>data and/or space is available. the obvious location for such
>interrupts is at the wrap around point.
>
>however, this is not necessarily the most useful configuration, and
>most audio interfaces can be told to generate an interrupt at other
>intervals as the hardware moves through the buffer. this subdivides
>the hardware buffer into a series of "periods", punctuated by an
>interrupt:
>
>
>   |-------------- maximum possible buffer size --------------------|
>   |----------- current buffer size -----------|
>   |           |                |              |
>   intr       intr              intr           intr
>
>(note that the "intr" at the start/end of the buffer are equivalent to
>each other - its really an interrupt at the wrap point)
>
>so, in the above diagram, the hardware buffer is divided into 3
>periods; as the hardware "pointer" crosses each divide, the CPU is
>interrupted, and the CPU can read/write data into the buffer
>before/after the hardware pointer, as appropriate.
>
>in the above example, the interrupts are evenly spaced, typically
>using a power-of-2 number of audio samples, and thus the total buffer
>size is nperiods * period size. the general relationship is:
>
>     buffer_size = nperiods * period_size;
>
>with all the permutations that suggests.
>
>you can measure the sizes of buffers and periods in samples, bytes or
>units of time. the conversion factors between them depends on the
>sample bit width and the sample rate.
>
>--p
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Davy Durham]

Manuel Jander wrote:

>>would prefer to have maybe a second or so of buffer time if it becomes 
>>necessary [streaming to disk and all].  I'm willing to go with the 
>>nearest power of 2 if necessary of course.  Is this possible given any 
>>hardware, or will I need to buffer captured data myself to be on the 
>>safe side?
>>    
>>
> I've got playback pretty much how I want it. But for my capture code, I
>
>
>One second of buffer time... that would be around 176KB ! I very doubt
>that any soundcard would handle that. If you want such a large buffer, i
>guess you will need a own buffer implementation in your app. Are you
>really sure that you need such a large buffer ? Remember that disk
>drivers and filesystem I/O layers provide additional buffers, so you
>don't have to bother about actual hardware latencies.
>
>  
>
Well I figured that if it's a software buffering implementation then 
what does the software much care about how much buffer time I ask for.
Now, I'm pretty sure I've got an 8k buffer working, so whatever the 
buffering mechanism is, it's not straight DMA which was limited by 4k 
you said.

thats all


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Lee Revell]

On Sat, 2004-09-04 at 21:38, Davy Durham wrote:
> Manuel Jander wrote:
> >One second of buffer time... that would be around 176KB ! I very doubt
> >that any soundcard would handle that. If you want such a large buffer, i
> >guess you will need a own buffer implementation in your app. Are you
> >really sure that you need such a large buffer ? Remember that disk
> >drivers and filesystem I/O layers provide additional buffers, so you
> >don't have to bother about actual hardware latencies.
> >
> >  
> >
> Well I figured that if it's a software buffering implementation then 
> what does the software much care about how much buffer time I ask for.
> Now, I'm pretty sure I've got an 8k buffer working, so whatever the 
> buffering mechanism is, it's not straight DMA which was limited by 4k 
> you said.

I believe you are each referring to a different buffer.  "Buffer" in
ALSA terminology almost always refers to the DMA buffer, which is the
one that is divided into periods, etc.  Your app would read() (or
better, mmap()) the capture data from the DMA buffer into a much larger
buffer in memory, then it would get written out from there to the disk. 
This should be done by two different threads so that delays in disk
output will not cause you to lose audio data.

8K buffer works because you have 2 (or more) periods per buffer, and
your app can only "see" one period at a time, because the hardware will
be DMA'ing to/from the other half.

Lee




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: buffers, periods, cycles.. oh my!

[Manuel Jander]

Hi,

On Sat, 2004-08-28 at 20:08, Davy Durham wrote:
> I just wish this stuff was documented somewhere...
> 
> Ok, so periods are different than buffers.

Yes. With buffer in ALSA semantic, its the entire memory area where
audio data is being buffered for DMA a transfer. A period is a subbuffer
(a smaller chunk) inside of this buffer. 
Why use subdivisions of the buffer (why use periods) ?
- As soon as a DMA transfer has been started, we can't touch the buffer
anymore. Using periods for various smaller DMA transfer, we know which
portion of the buffer is the one that can't be touched, so we can still
work on the others for processing, data copy, application interaction
etc.
- A single DMA transfer can't be any longer than 4KiB (i386), due to
nonlinear physical to logical memory address mappings. Using periods,
the entire buffer can be larger than 4KiB, by concatenating many
periods. We need to program each DMA tranfer for each period, thought.
- Setting up a DMA transaction on a soundcard takes some time, so if we
use one single chunk for DMA, while we are programming a new DMA
transfer, we would get a underrun. Even if the card has a fifo, it won't
last long enough. If we use several subbuffers, DMA transfer can be
programmed ahead of time, while another DMA transfer is still running.

Some remarks:
- Depending on the hardware capabilities of a particular soundcard:
buffer size == period count * period size
is NOT necessarily true. Because not all periods are necessarily the
same size. Usually the last one will be the odd sized period to fit into
the buffer. Many soundcards need this relation to be true, and ALSA
ensures that such restrictions are met.
The following expresion would be correct in any case:
buffer_size == sum(period_size[i], 1, period_count)

Just as a comment, some soundcards emulate more periods than they really
support in hardware. This needs a little bit more computations at the
interrupt handler, but it still allows the usage of bigger buffers. 

> I can set the period size and the number of periods.   And then separate 
> from that seems to be setting a buffer size/time.

ALSA provides different ways for selecting a specific period
count/period size/buffer size combination. They depend on each other.
If you really only care about how much time the buffer lasts (max time
you have to deliver new data), then just use a time based buffer setup.
In that case, you probably don care about how many periods and their
size.
You have to take into account that:
- The applicaction asks for some parameters. Unspecified parameters are
choosen by ALSA.
- The soundcard imposes some restrictions. These can be simple size
restriction, upto very complex ones (only allowing certain set of
values).
- The ALSA lib has to find an intersection between the app requirements
and the soundcard. If it does not find it, well, maybe Takashi or
Jaroslav can explain better than I what happens :). Somehow ALSA deals
with that, not necesarily in a successful manner.

>From that facts, i would say that giving some playroom to ALSA for
parameter choice, is desirable, so a parameter set that meets the
hardware restrictions can be easily found. If the application needs more
tighter control about buffer setup, then it should take care about what
parameters are actually being used afterwards.

> A sound card has to read/write to some area of memory for data 
> transfer.  What's a buffer and what's a period?

A period is a piece of the buffer. For each PCM device you have only one
buffer, divided into periods.

Hope that helps. 

Best Regards

Manuel




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click