From alsa-devel-owner@alsa.jcu.cz  Thu Aug 27 20:48:06 1998
Received: from monet.math.chalmers.se (monet.math.chalmers.se [129.16.167.74])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id UAA16774
	for <alsa-devel@alsa.jcu.cz>; Thu, 27 Aug 1998 20:48:03 +0200
Received: from morisot.math.chalmers.se (morisot.math.chalmers.se [129.16.167.91])
	by monet.math.chalmers.se (8.8.5/8.8.5) with ESMTP id UAA11938;
	Thu, 27 Aug 1998 20:48:02 +0200 (MET DST)
Received: from localhost (pin@localhost)
	by morisot.math.chalmers.se (8.8.5/8.8.5) with SMTP id UAA04988;
	Thu, 27 Aug 1998 20:48:01 +0200 (MET DST)
Date: Thu, 27 Aug 1998 20:48:01 +0200 (MET DST)
From: Ivan Popov <pin@math.chalmers.se>
To: Jaroslav Kysela <perex@jcu.cz>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: 0.2.0-pre5 - strange behaviour?
In-Reply-To: <Pine.LNX.3.96.980827201042.867D-100000@entry.jcu.cz>
Message-ID: <Pine.GSO.3.95.980827203005.1683L-100000@morisot.math.chalmers.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Thu, 27 Aug 1998, Jaroslav Kysela wrote:

> > Another possibility would be to use circle buffering (with last <buffer

> It's true, but if recording willn't be stopped, application should get
> wrong actual record pointers. If application read only few data (not

> Both implementations have advantages and disadvantages.
> In perfect world overrun should never occur.
> 
> 						Jaroslav

In a nearly perfect world overrun is a natural thing :)
Every application may read sound data as slow or as seldom as it needs.
And it may want to get buffered sound - not ideally, i.e. with limited
buffering.

I agree, that is hard to implement in the "right" way and it may cost too
much resources (buffer space and/or efficiency) but I don't see why it
wouldn't be possible.

The model I am thinking of is a moving window of fixed size, recording
pointer being always at the beginning (the window moves at fixed
speed - sampling rate) and reading pointer follows read
operations. Every read() moves the reading pointer ahead. With fast
read()-ing it stops at the recording pointer, giving small portions at a
time to each read(), with slow reading it stops at the end of
the window, missing the oldest samples. It needs probably double buffering
and is hence inefficient. But it is logical.

Good luck

and thanks for the good work! ALSA works very nice.

--
Ivan Popov <pin@math.chalmers.se>
Systemman, Driftavdelningen, Matematiska institutionen, Chalmers TH


