From: Abramo Bagnara <abramo.bagnara@libero.it>
To: Paul Davis <paul@linuxaudiosystems.com>
Cc: David Stuart <dave@sipquest.com>, alsa-devel@lists.sourceforge.net
Subject: Re: periods? fragments?
Date: Mon, 19 May 2003 10:06:54 +0200 [thread overview]
Message-ID: <3EC8909E.7090904@libero.it> (raw)
In-Reply-To: <E19Hbv6-0004zW-00@sc8-sf-list1.sourceforge.net>
Paul Davis ha scritto:
>>Greetings! Fledgeling alsa developer here,
>>
>>After reading a bunch of documentation, it's unclear to me exactly what
>>a period/fragment is used for. Could anyone expand on it a bit to fill
>>me in?
>
>
> there is a hardware buffer. its N frames long. you rarely want to deal
> with the entire buffer at once. its therefore divided into sections of
> a certain length, often (but not always) specified in numbers of
> frames. these sections are called "periods" and typically (but not
> always) the hardware will interrupt the CPU every time it finishes
> dealing with a "period", and you in turn get to deal with it in 1 (or
> more) periods at a time. the number of periods per h/w buffer (or
> alternately, their size) is a hardware parameter; how many periods
> have to have been processed by the h/w before the driver will wake up
> your code to read/write more data is a software parameter.
>
> a "fragment" is an older OSS term for the same concept.
Caution there Paul, your definitions are wrong.
A period in ALSA is exactly the distance (measured in frames or time)
between two consecutive periodic interrupts generated by PCM hardware.
There is no mandatory correlation between buffer size and period for
ALSA (as there is no mandatory correlation in all hardware).
This is fundamentally different from OSS where a fragment sizes are
forced to be buffer_size/K (with an integer K).
This is exactly the reason why I've substituted fragment concept with
period some time ago.
--
Abramo Bagnara mailto:abramo.bagnara@libero.it
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful,
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge
next prev parent reply other threads:[~2003-05-19 8:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-19 3:53 periods? fragments? David Stuart
2003-05-19 4:12 ` Paul Davis
2003-05-19 8:06 ` Abramo Bagnara [this message]
2003-05-19 8:04 ` Giuliano Pochini
2003-05-19 8:12 ` Jaroslav Kysela
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=3EC8909E.7090904@libero.it \
--to=abramo.bagnara@libero.it \
--cc=alsa-devel@lists.sourceforge.net \
--cc=dave@sipquest.com \
--cc=paul@linuxaudiosystems.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.