From alsa-devel-owner@alsa.jcu.cz  Thu Aug 27 20:04:34 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 UAA13928
	for <alsa-devel@alsa.jcu.cz>; Thu, 27 Aug 1998 20:04:31 +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 UAA08577;
	Thu, 27 Aug 1998 20:04:29 +0200 (MET DST)
Received: from localhost (pin@localhost)
	by morisot.math.chalmers.se (8.8.5/8.8.5) with SMTP id UAA04445;
	Thu, 27 Aug 1998 20:04:29 +0200 (MET DST)
Date: Thu, 27 Aug 1998 20:04:29 +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.980827192211.867A-100000@entry.jcu.cz>
Message-ID: <Pine.GSO.3.95.980827195352.1683G-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:

> 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.

But that feature is not needed _so_ badly...

> This will be fixed in next release of driver.

Good!

> > Is such behaviour OK and what is the right way to flush the input buffer?
> > 
> > "close(); open()" does the trick but it is not the appropriate method,
> > or is it?
> 
> What about RESET ioctl when MIC isn't used? Recording will be stoped and
> no overruns will be occured.

Yes, if you know beforehand (as in my case) that you will _not_ need the
data.

Otherwise repeated non-blocking read() seems to be the right (and 
portable) approach. And it will hopefully work with the next driver
release.

> 						Jaroslav

Thank you for the reply!

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


