All of lore.kernel.org
 help / color / mirror / Atom feed
From: Britton <fsblk@aurora.uaf.edu>
To: linux-sound@vger.kernel.org
Subject: Re: how to find the maximum fragment size for SNDCTL_DSP_SETFRAGMENT?
Date: Thu, 08 Jun 2000 22:25:46 +0000	[thread overview]
Message-ID: <marc-linux-sound-96050332718065@msgid-missing> (raw)
In-Reply-To: <marc-linux-sound-96049072503276@msgid-missing>


On Fri, 9 Jun 2000, Hannu Savolainen wrote:
> On Thu, 8 Jun 2000, Britton wrote:
> 
> > 
> > The guide of 4front's web page says total_buffer_size/2.  I know the
> > kernel buffer size used to be defined at kernel compile time.  How does
> > one go about determining it now?  DSP_GETBLKSZ?
> Wy would you need this information? 

I'm letting my users specify the fragment size, and I try to check things
like whether what they specify is out of range before actually making the
syscall.

> If you like to get as large fragments as possible just set the fragment
> size to very big. The driver will then select the largest one it could
> support.

Ok, I didn't know it would do that.  I guess there is no real reason the
user needs to know if their large fragment size was not actually set (they
already get a warning if the fragment size they request is big enough that
it will likely cause latency).  That behavior might be something to add to
the 4front page.

> However changing the fragment size bigger than the default doesn't give
> any benefit. You can always write/read multiple fragments at time to get
> the same effect.
> 
> > Does DSP_GETBLKSZ still
> > fix the block size so that the device must be closed and opened again in
> > order to set the fragment size?
> This is the current and future behaviour.

Thanks,
Britton

      parent reply	other threads:[~2000-06-08 22:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-08 18:26 how to find the maximum fragment size for SNDCTL_DSP_SETFRAGMENT? Britton
2000-06-08 21:59 ` Hannu Savolainen
2000-06-08 22:25 ` Britton [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-96050332718065@msgid-missing \
    --to=fsblk@aurora.uaf.edu \
    --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 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.