Subject: Re: [linux-audio-dev] UST
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Jul 24 2002 - 13:13:36 EEST
> their stuff has never been widely (if at all) used for low latency
> real time processing of audio.
[...]
> ...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 agree that the DM audio API does not seem suitable for RT audio. It
is more oriented towards video and it suitable for RT video i think,
because with video the frame size is kown.
> 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.
This article described the problems of the old video API and concluded
that a different approach was needed. The approach described was dmSDK,
at least that is the way I read it.
> 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.
CoreAudio MIDI uses timestamps also. You\'ll need some relation between audio
time and the time for MIDI timestamps to be able to use these 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.
There is always some pre-queueing unless you handle audio per frame.
And how to handle MIDI? Have the application schedule itself? I think a
common timebase for timestamping/scheduling (in the API) would be better.
> Pre-queuing destroys latency, and so is
> best left to a higher level API and/or the application itself.
If you only pre-queue one buffer you basically have ASIO...
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Wed Jul 24 2002 - 13:12:36 EEST