On Wed, 26 Jun 2002, Takashi Iwai wrote:
> At Wed, 26 Jun 2002 17:55:49 +0200 (CEST),
> Jaroslav wrote:
> >
> > On Mon, 24 Jun 2002, Takashi Iwai wrote:
> >
> > > At Tue, 18 Jun 2002 20:23:50 +0200 (CEST),
> > > Tim Goetze wrote:
> > > >
> > > > Takashi Iwai wrote:
> > > >
> > > > >well, draing samples at close corresponds to flushing the buffered
> > > > >data to disk at fclose. then it sounds normal, doesn't it?
> > > >
> > > > i'm still not convinced -- if the stream is running when you close it,
> > > > you're right, obviously.
> > > >
> > > > but when it's not running, starting and stopping it usually produces a
> > > > click that will ruin the audible effect of the few msec worth of sound
> > > > 'drained' (that nobody cares about anyway since the stream is about to
> > > > be closed).
> > > >
> > > > right?
> > >
> > > this is a question of behavior.
> > > i don't think it's absolutely "wrong" that the driver processes the
> > > rest of samples at stop status if drain() is called.
> > >
> > > but.. from my feeling, i agree with you. it doesn't matter if the
> > > samples are simply dropped at close() when its stream was already
> > > stopped. so i myself would like to change this behavior.
> > > the fix must be quite easy.
> > >
> > > however, we need a consensus about this.
> > >
> > > any comments (or objections)?
> >
> > We can see both behaviour for the device access. The current
> > implementation was taken from OSS. Actually, I don't mind to change it,
> > because programmers should call drop() or drain() before close depending
> > on their choice. It's also true, when the process is canceled for some
> > signal, it would be better to drop the contents of ring buffer by default.
> > It means that even the stream is running, it should be stoped and droped
> > in native API.
>
> yep.
> dropping in all cases will be the easiest solution.
> we can even reduce the strange conditionals in close().
>
> drain() can be called at the close() of oss emulation layer
> if it's really necessary.
It is, but the OSS emulation code already uses a different flush method,
so we don't need to touch this code.
Jaroslav
-----
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project http://www.alsa-project.org
SuSE Linux http://www.suse.com
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
