From alsa-devel-owner@alsa.jcu.cz  Thu Aug 27 20:18:47 1998
Received: from entry.jcu.cz (perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.8.8/8.8.8) with SMTP id UAA14836;
	Thu, 27 Aug 1998 20:18:39 +0200
Date: Thu, 27 Aug 1998 20:18:39 +0200 (MET DST)
From: Jaroslav Kysela <perex@jcu.cz>
To: Ivan Popov <pin@math.chalmers.se>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: 0.2.0-pre5 - strange behaviour?
In-Reply-To: <Pine.GSO.3.95.980827195352.1683G-100000@morisot.math.chalmers.se>
Message-ID: <Pine.LNX.3.96.980827201042.867D-100000@entry.jcu.cz>
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, Ivan Popov wrote:

> On Thu, 27 Aug 1998, Jaroslav Kysela wrote:
> 
> > have overrun bug. Recording should be probably stoped when overrun (not
> > enough space in buffer to receive next data) than continue. In current
> > code is problem with updating read pointers after overrun.
> 
> Another possibility would be to use circle buffering (with last <buffer
> length> of recorded data available). It might be useful for e.g. checking
> signal level that happened to be right _before_ the moment when we resume
> read()-ing. Simple recording stop would not do it.

It's true, but if recording willn't be stopped, application should get
wrong actual record pointers. If application read only few data (not
complete fragment) and overrun occurs, then simply change internal
pointers to ring buffer (which is already used for PCM operations)
should produce bad record pointers which application shouldn't handle
correctly (note that OSS API doesn't have any overrun counter in API, so
applications doesn't know that overrun was occured).

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

						Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


