Re: [PATCH] Kernel crash

[Takashi Iwai <tiwai@suse.de>]

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