Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Glenn Maynard <g_sf@zewt.org>
To: ALSA development <alsa-devel@alsa-project.org>
Subject: Re: [PATCH] Fixes: Re: intel8x0 has stopped working.
Date: Thu, 5 Feb 2004 14:15:22 -0500	[thread overview]
Message-ID: <20040205191522.GE26089@zewt.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0402051154080.1864@pnote.perex-int.cz>

On Thu, Feb 05, 2004 at 12:01:28PM +0100, Jaroslav Kysela wrote:
> > My point is, I don't think setting start_threshold to buffer_size is 
> > even "wrong" at all. Some people might want the buffer to be full before 
> > it starts, and my patch allows for that.
> 
> It's not wrong semantics. I see - it's logical, but I don't want to follow
> some rule as some API designers does - control magically some things. I
> want that developer which uses our API knows what the library / driver
> exactly does.
> 
> We have clear conditions when the stream is started. That's it.

If this isn't guaranteed to work, I'd suggest making it never work.
Otherwise, programs will work on some hardware and not others, which is
a case that should be minimized as much as possible; it's these kinds
of subtle differences that make it very hard to write reliable (sound,
video, etc) code.  I've had to play games with setting hardware settings:
always set the sample rate even if I don't care, use a 32k buffer size
and not a 4k or 8k one--in order to make it work on as many systems as
possible without failing mysteriously or triggering alsa-lib asserts.

(I don't quite understand why start_threashold == buffer_size doessn't
mean "start when the buffer is full", though.)

-- 
Glenn Maynard


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

  reply	other threads:[~2004-02-05 19:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-02 17:41 intel8x0 has stopped working James Courtier-Dutton
2004-02-02 17:59 ` Takashi Iwai
2004-02-02 19:34   ` Prakash K. Cheemplavam
2004-02-02 19:42   ` James Courtier-Dutton
2004-02-02 23:12     ` [PATCH] Fixes: " James Courtier-Dutton
2004-02-03 16:22       ` Jaroslav Kysela
2004-02-03 22:21         ` James Courtier-Dutton
2004-02-05 11:01           ` Jaroslav Kysela
2004-02-05 19:15             ` Glenn Maynard [this message]
2004-02-05 19:25               ` Takashi Iwai
2004-02-05 19:38               ` Jaroslav Kysela
2004-02-05 19:58                 ` Glenn Maynard
2004-02-05 20:44                 ` James Courtier-Dutton
2004-02-04 19:35     ` Takashi Iwai
2004-02-04 23:03       ` James Courtier-Dutton
2004-02-05 18:49         ` Takashi Iwai
2004-02-05 19:42         ` Takashi Iwai
2004-02-05 22:28           ` James Courtier-Dutton
2004-02-06 11:29             ` Takashi Iwai
2004-02-06 20:05               ` James Courtier-Dutton
2004-02-09 10:56                 ` Takashi Iwai

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=20040205191522.GE26089@zewt.org \
    --to=g_sf@zewt.org \
    --cc=alsa-devel@alsa-project.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