From: Davy Durham <ddurham@davyandbeth.com>
To: alsa-devel@lists.sourceforge.net
Cc: mjander@users.sourceforge.net
Subject: Re: buffers, periods, cycles.. oh my!
Date: Sat, 28 Aug 2004 18:52:19 -0500 [thread overview]
Message-ID: <41311AB3.9070705@davyandbeth.com> (raw)
In-Reply-To: <1093718182.2150.26.camel@localhost>
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
next prev parent reply other threads:[~2004-08-28 23:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-28 5:46 buffers, periods, cycles.. oh my! Davy Durham
[not found] ` <1093718182.2150.26.camel@localhost>
2004-08-28 23:52 ` Davy Durham [this message]
2004-08-29 0:08 ` Davy Durham
2004-08-29 16:48 ` Paul Davis
2004-08-30 21:53 ` Davy Durham
[not found] ` <1094237841.2082.22.camel@localhost>
2004-09-05 1:38 ` Davy Durham
2004-09-05 2:13 ` Lee Revell
2004-08-29 16:50 ` Manuel Jander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41311AB3.9070705@davyandbeth.com \
--to=ddurham@davyandbeth.com \
--cc=alsa-devel@lists.sourceforge.net \
--cc=mjander@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox