From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] Kernel crash Date: Wed, 22 Sep 2004 12:08:10 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20040911210212.317d930b.pochini@shiny.it> <20040913220729.466531ce.pochini@shiny.it> <20040915195008.33713acb.pochini@shiny.it> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Jaroslav Kysela Cc: Giuliano Pochini , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Wed, 22 Sep 2004 10:08:14 +0200 (CEST), Jaroslav wrote: > > On Fri, 17 Sep 2004, Takashi Iwai wrote: > > > At Fri, 17 Sep 2004 12:22:07 +0200, > > I wrote: > > > > > > > The linking makes sense for hardware that support that. Otherwise, we can > > > > start streams in most close time, but draining and dropping doesn't make > > > > much sense, because different clocking sources for different cards will > > > > produce jitter, thus there is no real sync and application must care. > > > > > > Agreed. I've assumed that drain/drop are supposed to be synchronous, > > > but they should not. > > > > I just noticed that pcm_multi.c _assumes_ indeed that linked > > draining/dropping works as synchronized. So, the current semantics is > > correct. > > Yes, sorry - my fault. I had vacation and I read e-mails only quickly. I hope you enjoyed vacation ;) > > If snd_pcm_drain() affects only the given stream, then it's difficult > > to get sync among all streams, because basically draining consists of > > two phases: > > > > - trigger DRAIN state to all streams > > - wait until all streams get drained > > > > We cannot do the procedure above in the serialized manner. > > Application might care independently for all streams. But on other side, > it's too late to change midlevel behaviour, so we should only correct the > problems. As written above, for draining, we'll need two actions: changing the streams to DRAINING state and then syncing. If we call snd_pcm_drain() for each stream in the serial manner, the situation like below can happen: - snd_pcm_drain(pcm1) - stream 1 goes to DRAIN - wait until synced - meanwhile, stream 2 got out of data. all linked streams are changed to XRUN. - returns -EFIFO. So, if we implement seprate draining, two functions should be provided, such as snd_pcm_drain_trigger() snd_pcm_drain_sync() and the multiple streams can be handled like for_each_stream { snd_pcm_drain_trigger(pcm); } for_each_stream { snd_pcm_drain_sync(pcm); } > > Also, another question is how to handle XRUN state. > > When one of the linked streams gets XRUN, should all streams be > > stopped and marked as XRUN? I think yes. > > Probably yes. In all cases, the application (or pcm_multi plugin) must > take care about correcting jitter, otherwise the streams will go out of > sync after awhile - resulting in xrun. In the case of multi pcm, we can do nothing against clock difference because all data is sent synchronously to several streams. Hence, when one of streams gets XRUN, the whole pcm should be handled as XRUN. OTOH, when you link streams but feed/read data separately for each stream, the clock difference doesn't matter. Each stream may have even different periods, buffer sizes, whatever. So, in the first case, handling xrun/drain/drop in sync of all linked streams makes sense. But what about the second case...? Well, the link can be removed dynamically. So, in theory, we can propose like the following: - Start, drain, drop and xrun of linked streams are operated to all streams by a single call. Especially, drain assures that the all streams get sync'ed. - When one wants to operate drain and drop separately, explicitly unlink streams after the sync'ed start. Or, we can create new PCM functions or flags for single-stream operations, but I don't think it's needed. Takashi ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php