1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
Scheduling:
- remove loop/get/chain from GstElement and add a "iterate" method.
The iterate method is called with the event (or events) that
triggered it, performs some action, and resets the events (file
descriptors becoming readable, semaphores, pads becoming readable
or writable, or a time occurs).
- Add GstLoopElement, GstChainElement, etc. for compatibility.
- Remove existing state handling and create 2 states, "playing" and
"stopped". "playing" means that the iterate() method of the
element may be called, that is, the element is allowed to move
buffers, negotiate, etc. "stopped" means that no gstreamer-ish
things happen to an element, only gobject-ish. A separate
reset() method will handle the difference between READY and NULL.
- Add a flag "ready" to GstElement that is under the control of the
element. If the element is ready to stream, it sets this flag,
and the entire pipeline starts streaming. (This is basically
the difference between PAUSED and PLAYING.) For example, osssink
won't set the ready flag until the device is opened and there is
a buffer available to write to the device.
- Scheduling of elements and movement of buffers will be timed by
clocks.
Example #1:
Pipeline: sinesrc ! osssink
- The application creates the pipeline and sets it to "playing".
- The clock is created and set to "paused".
- sinesrc.iterate() decides to watch for the event "src pad
negotiation" and sets the available caps on the pad.
- osssink.iterate() opens device, determines available caps, and
sets the available caps on the pad. Then it decides to wait for
"sink pad negotiation".
- The scheduler realizes that the two elements are waiting for
negotiation, so it negotiates the link.
- sinesrc.iterate() sets the "ready" flag (because it needs no more
preparation to stream) and decides to watch for the event "src
pad ready to accept buffer".
- osssink.iterate() decides to watch for the event "sink pad has
available buffer".
- The scheduler realizes that sinesrc.srcpad is now ready, so it
calls sinesrc.iterate()
- sinesrc.iterate() creates a buffer and pushes it, and decides to
wait for the same event.
- The scheduler realizes that osssink.sinkpad now has a buffer, so
it calls osssink.iterate().
- osssink.iterate() is now ready to stream, so it sets the "ready"
flag and waits for "time 0".
- 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 starts with the time 0. The scheduler realizes this,
and decides to schedule osssink.
- osssink.iterate() is called, and writes the buffer to the device.
This starts the clock counting. (Actually, the buffer could be
written by the clock code, since presumably the clock is related
to osssink.) iterate() then waits for "sink pad has available
buffer".
We're now basically in streaming mode. A streaming cycle:
- osssink.iterate() decides the audio output buffer is full enough,
so it waits for "time X", where X is the time when the output
buffer will be below some threshold.
- osssink.iterate() waits for "sink pad has available buffer"
- sinesrc.iterate() creates and pushes a buffer, then waits for
"src pad ready".
Further ideas:
- osssink can set a hard deadline time, which means that if it is
not scheduled before that time, you'll get a skip. Skipping
involves setting osssink to "not ready" and pauses the clock.
Then the scheduler needs to go through the same process as above
to start the clock.
- As a shortcut, osssink can say "I need a buffer on the sinkpad
at time X". This information can be passed upstream, and be used
in filters -- filter.sinkpad says "I need a buffer at time X-N",
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
Evil:
fakesrc ! tee ! fakesink tee0. ! never_accept_a_buffer_sink
sinesrc ! osssink videotestsrc ! ximagesink
fakesrc ! fakesink (pausing)
sinesrc ! identity ! osssink
|
