Subject: Re: [linux-audio-dev] UST
From: Paul Davis (pbd_AT_op.net)
Date: Wed Jul 24 2002 - 03:51:14 EEST
>> i read this a year or two ago. it was a major impetus in the design of JACK,
>> because i believe that almost all of it is based on a complete misconception
>> of how to do this stuff, and some of it is just plain wrong. Its worth
>> noting that SGI's "DM" API has never really taken off, and there are lots of
>> reasons why, some technical, some
>> political.
>
>I was under the impression that SGI had a pretty good grasp on how to do RT
>systems... (http://www.sgi.com/software/react/)
their stuff has never been widely (if at all) used for low latency
real time processing of audio. its not because their OS can't do it
(it can) and thats all the REACT stuff sets out to prove. their FRS
scheduler in particular is very cool and probably very very useful for
some applications.
no, despite a fine fairly-firm-RT OS, it doesn't get used this way
because (1) their hardware costs too much (2) their API for audio
doesn't encourage it in any way (3) their API for digital media in
general is confused and confusing. i or someone else posted a link
here a few months ago from someone who worked in the DM group at SGI
which described the problems that have beset their Video API. a
similar set of problems exists for the Audio side of DM, IMHO.
SGI's definition of "realtime" is great when discussing their OS, but
it more or less fades into the background when using the DM API and
UST.
>> SGI tried to solve the problem of the Unix read/write API mismatch with
>> realtime streaming media by adding timestamps to data. CoreAudio solves it
>> by getting rid of read/write, and acknowledging the inherent time-basis of
>> the whole thing, but for some reason keeps timestamps around without using
>> them in many cases. JACK follows CoreAudio's
>> lead, but gets rid of the timestamps.
>
>Timestamps are needed in hard-realtime and parallel-computing systems,
timestamps are not needed to deal with streaming media when it is
handled without pre-queueing. Pre-queuing destroys latency, and so is
best left to a higher level API and/or the application itself. SGI's
own FRS scheduler is proof of that, and is an interesting vindication
of JACK in some respects in that its essentially the scheduling part
of JACK executed in kernel space.
--p
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 03:57:35 EEST