* pcm_drain() behavior (Re: snd_pcm_close hangs) [not found] ` <Pine.LNX.4.21.0206181957020.820-100000@summer.quitte> @ 2002-06-24 13:39 ` Takashi Iwai 2002-06-24 14:14 ` Paul Davis 2002-06-26 15:55 ` Jaroslav Kysela 0 siblings, 2 replies; 5+ messages in thread From: Takashi Iwai @ 2002-06-24 13:39 UTC (permalink / raw) To: alsa-devel; +Cc: Tim Goetze 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)? Takashi ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pcm_drain() behavior (Re: snd_pcm_close hangs) 2002-06-24 13:39 ` pcm_drain() behavior (Re: snd_pcm_close hangs) Takashi Iwai @ 2002-06-24 14:14 ` Paul Davis 2002-06-26 15:55 ` Jaroslav Kysela 1 sibling, 0 replies; 5+ messages in thread From: Paul Davis @ 2002-06-24 14:14 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Tim Goetze >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. i agree with the proposal. ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pcm_drain() behavior (Re: snd_pcm_close hangs) 2002-06-24 13:39 ` pcm_drain() behavior (Re: snd_pcm_close hangs) Takashi Iwai 2002-06-24 14:14 ` Paul Davis @ 2002-06-26 15:55 ` Jaroslav Kysela 2002-06-26 17:11 ` Takashi Iwai 1 sibling, 1 reply; 5+ messages in thread From: Jaroslav Kysela @ 2002-06-26 15:55 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel@lists.sourceforge.net, Tim Goetze 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. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pcm_drain() behavior (Re: snd_pcm_close hangs) 2002-06-26 15:55 ` Jaroslav Kysela @ 2002-06-26 17:11 ` Takashi Iwai 2002-06-26 17:23 ` Jaroslav Kysela 0 siblings, 1 reply; 5+ messages in thread From: Takashi Iwai @ 2002-06-26 17:11 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: alsa-devel@lists.sourceforge.net, Tim Goetze 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. Takashi ------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: pcm_drain() behavior (Re: snd_pcm_close hangs) 2002-06-26 17:11 ` Takashi Iwai @ 2002-06-26 17:23 ` Jaroslav Kysela 0 siblings, 0 replies; 5+ messages in thread From: Jaroslav Kysela @ 2002-06-26 17:23 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel@lists.sourceforge.net, Tim Goetze 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 <perex@suse.cz> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-06-26 17:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <s5h7kkwh5o2.wl@alsa2.suse.de>
[not found] ` <Pine.LNX.4.21.0206181957020.820-100000@summer.quitte>
2002-06-24 13:39 ` pcm_drain() behavior (Re: snd_pcm_close hangs) Takashi Iwai
2002-06-24 14:14 ` Paul Davis
2002-06-26 15:55 ` Jaroslav Kysela
2002-06-26 17:11 ` Takashi Iwai
2002-06-26 17:23 ` Jaroslav Kysela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.