From 872c394a3972d7aa3889282f69142ae648f154c1 Mon Sep 17 00:00:00 2001 From: David Schleef Date: Mon, 9 Aug 2004 23:36:07 +0000 Subject: [PATCH] more notes Original commit message from CVS: more notes --- docs/random/ds/0.9-planning | 47 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/docs/random/ds/0.9-planning b/docs/random/ds/0.9-planning index 668fb46..d2606bd 100644 --- a/docs/random/ds/0.9-planning +++ b/docs/random/ds/0.9-planning @@ -30,7 +30,7 @@ Scheduling: -Example: +Example #1: Pipeline: sinesrc ! osssink @@ -106,6 +106,51 @@ Example: where N is the latency of the filter. +Example #2: + + Pipeline: osssrc ! osssink + + - The application creates the pipeline and sets it to "playing". + + - The clock is created and set to "paused". + + - negotiation happens roughly as in example #1, although osssrc + additionally opens and prepares the device. + + - osssrc.iterate() sets the "ready" flag (because it needs no more + preparation to stream) and waits for "time 0", since it presumably + can't wait for the file descriptor (audio input hasn't been + enabled on the device yet.) + + - osssink.iterate() decides to watch for the event "sink pad has + available buffer". + + - The scheduler realizes the deadlock and (somehow) tells osssink + that it can't pre-roll. (This needs more work) In other words, + osssink can't be the clock master, but only a clock slave. + + - osssink.iterates() agrees to start at time SOME_LATENCY, sets the + "ready" flag, and waits for a buffer on its sink pad. + + - The pipeline is now completely ready, so the clock may be + started. A signal is fired to let the application know this + (and possibly change the default behavior). + + - The clock starting causes two things to happen: osssrc starts + the recording of data, and osssink starts the outputting of data. + The data being output is a chunk of silence equal to SOME_LATENCY. + + - osssrc.iterate() is called for "time 0", does nothing, and waits + on the file descriptor (via the scheduler, of course). All waiting + on file descriptors should have an associated timeout. + + - osssrc.iterate() is called when the file descriptor is ready, + reads a chunk of data, and pushes the buffer. It then waits for + its file descriptor to be ready. + + - osssink.iterate() is called + + -- 2.7.4