On Thu, 5 Feb 2004, Glenn Maynard wrote:
> 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.
It's guaranteed to 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.
Send us bug-reports if you have problems. We have not a magic ball.
> (I don't quite understand why start_threashold == buffer_size doessn't
> mean "start when the buffer is full", though.)
Because we have the avail_min threshold which says that we don't want to
write new data when buffer can accept less samples than this threshold. So
if start_threshold is greather than '(buffer_size / avail_min) *
avail_min' expression, then stream won't be automatically started, because
we cannot fill data in read/write operations to satisfy the requirement
that start_threshold == buffer_size.
Isn't this clear and right?
Of course, the "endless loop" is questionable in this case when the stream
is not running and we should probably return from the write function.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
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
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
