From: Jim Jackson <jj@scs.leeds.ac.uk>
To: linux-sound@vger.kernel.org
Subject: Re: documentation on SNDCTL_DSP_SETFRAGMENT exist?
Date: Wed, 16 Feb 2000 09:13:42 +0000 [thread overview]
Message-ID: <marc-linux-sound-95069272427405@msgid-missing> (raw)
In-Reply-To: <marc-linux-sound-95065201132560@msgid-missing>
There's not much to cover. It is used to set the size of the buffer
fragments and how many of them you want. The only complication is
is that the fragment size is specified as the power of 2 of the size of
the fragment - e.g. for 1024byte frags the value 10 is used, 1024=2^10.
The number of buffers is held in the top 16bits of an int and the
power of 2 of the buffer fragment in the bottom 16 bits.
If /dev/dsp is open on fd, N is the number of fragments, and E is the
power of 2 of the fragment size....
int fr=(N<<16)+E;
if (ioctl(fd, SNDCTL_DSP_SETFRAGMENT , &fr) < 0) {
Error_Stuff;
}
Choosing a fragment size depends on the application. If you have somesort
of "interactive" app generating audio samples then you probably want
smallish fragments holding somewhere between 10 or 100 millisecs of
samples (depending on what you concept of interactive is :-) and as few as
possible so you don't have too much buffered ahead, yet have enough
samples buffered so you don't get breakup due to running out of samples.
If there is no "interactive" element, often a few large fragments will
suffice.
On Tue, 15 Feb 2000, Eric Mitchell wrote:
>
> http://www.4front-tech.com/pguide/audio2.html
>
> see the section, "Selecting buffering parameters"
>
> Britton Leo Kerin wrote:
> >
> > Does anyone know of any documentation of any kind (book, howto,
> > anything) out there which covers this feature?
> >
> > Thanks,
> > Britton Kerin
>
>
prev parent reply other threads:[~2000-02-16 9:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-15 12:38 documentation on SNDCTL_DSP_SETFRAGMENT exist? Britton Leo Kerin
2000-02-15 22:35 ` Eric Mitchell
2000-02-16 9:13 ` Jim Jackson [this message]
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=marc-linux-sound-95069272427405@msgid-missing \
--to=jj@scs.leeds.ac.uk \
--cc=linux-sound@vger.kernel.org \
/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