Re: [gst-devel] 0.8 in 2.6 ?

[Andy Wingo <wingo pobox com>]

On Tue, 07 Oct 2003, Leif Johnson wrote:

> On Mon, 06 Oct 2003, in7y118 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
                        Scheduling")
                           (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
> scheduling.

<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
   blocking.
       
   (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
restrictions". Thoughts?

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.

Regards,

wingo.