All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.