[gst-devel] 0.8 in 2.6 ?
wingo at pobox.com
Sun Oct 12 02:56:05 CEST 2003
On Tue, 07 Oct 2003, Leif Johnson wrote:
> On Mon, 06 Oct 2003, in7y118 at public.uni-hamburg.de wrote:
> > 2) What features do we need that need API/ABI changes and that should
> > go into 0.8?
> I'd like to see some SCHED_FIFO (lowlatency scheduling) action in
> GStreamer. Whether or not this could make it in by 0.8 is debatable.
Whether the support could make it there is hit-or-miss, yeah. But the
API could be added. Inspecting thread I see:
priority : The scheduling priority of the thread
Enum "GstThreadPriority" (default 1, "Normal
(0): Low Priority Scheduling
(1): Normal Scheduling
(2): High Priority Scheduling
(3): Urgent Scheduling
WTF is "urgent scheduling"? But although these map onto
GThreadPriority, they are actually a different enum. Odd.
I think this is the proper place to add realtime priorities
(SCHED_FIFO). At the least we can add (4) Realtime Scheduling. Maybe
even we can get this integrated into GLib. Leif, you up to it? ;)
> And it isn't necessary at the moment ; we can use GStreamer apps with
> JACK in non-realtime mode.
And if Jack has compiled-in capabilities support (this might be going
away, dunno), the libjack thread (that ends up iterating the GStreamer
pipeline) is given RT scheduling.
> But if we really want to support professional audio processing on
> Linux (yeah ! yeah !), we'll need to be able to do lowlatency
<echo>yeah! yeah!</echo> (refusing to punctuate a la francaise)
This is a larger issue than just realtime scheduling. Some scheduler
(maybe opt?) will need to be tweaked not to malloc *anything* while in
PLAYING, and all elements involved in a pipeline will need to do
anything non-rt safe. Perhaps elements can have flags to indicate if
they are RT-safe (like LADSPA)? I think this would also be nice,
GST_ELEMENT_HARD_RT_CAPABLE like LADSPA_PROPERTY_HARD_RT_CAPABLE:
/* Property LADSPA_PROPERTY_HARD_RT_CAPABLE indicates that the plugin
is capable of running not only in a conventional host but also in a
`hard real-time' environment. To qualify for this the plugin must
satisfy all of the following:
(1) The plugin must not use malloc(), free() or other heap memory
management within its run() or run_adding() functions. All new
memory used in run() must be managed via the stack. These
restrictions only apply to the run() function.
(2) The plugin will not attempt to make use of any library
functions with the exceptions of functions in the ANSI standard C
and C maths libraries, which the host is expected to provide.
(3) The plugin will not access files, devices, pipes, sockets, IPC
or any other mechanism that might result in process or thread
(4) The plugin will take an amount of time to execute a run() or
run_adding() call approximately of form (A+B*SampleCount) where A
and B depend on the machine and host in use. This amount of time
may not depend on input signals or plugin state. The host is left
the responsibility to perform timings to estimate upper bounds for
A and B. */
(1) and (3) apply directly. (4) just says that the loop or chain
function is O(N) where N is the number of samples. (2) can be relaxed to
say "The plugin will only use APIs known to comply with these realtime
Again, other than that, we just need to add a GstThreadPriority for
REALTIME, and possibly see about getting it into GLib. RT-safety is
difficult, but doesn't require too many A[PB]I changes.
More information about the gstreamer-devel