Re: Is ReWire necessary under OS X?
Re: Is ReWire necessary under OS X?
- Subject: Re: Is ReWire necessary under OS X?
- From: Philippe Wicker <email@hidden>
- Date: Fri, 31 Jan 2003 19:05:01 +0100
On Friday, January 31, 2003, at 05:33 PM, Urs Heckmann wrote:
Am Donnerstag, 30.01.03, um 16:45 Uhr (Europe/Berlin) schrieb Malcolm
Haylock:
Hi everyone,
When I first heard about plans for OS X Audio services I assumed that
it would provide interapplication streaming of audio that would
replace ReWire. It seems now that ReWire is getting alot of attention
(eg ProTools implementation). Was I overestimating the power of OS X
audio?
Malcolm Haylock
Yeah, me too.
However, sending MIDI across application borders is not a problem
(Virtual inputs).
For Audio you can do two things:
1. Write a virtual Input/Output device (Virtual Soundcard)
2. Use Mach kernel messaging, pipes or such to provide a stream from
one app/AU to another app/AU
What I thought of first was creating AUs on the fly (see that thread
some weeks ago) from memory which then could be seen from within other
apps, but that doesn't work because it is a deprecated stuff in the
ComponenManager API which weirdly still sits in the documentation.
Anyway, I can't imagine what effort has to be done to compensate for
latencies then...
Cheers,
;) Urs
We could imagine an AudioServer, some sort of MIDIServer for the audio
with concepts of virtual audio sources and destinations, AudioReadProc,
etc... One problem is that the throughput - the bandwidth - necessary
for multiple connections at say 96KHz/32bits is much more than the
bandwidth consumed by the MIDIServer. Moving blocks of data between
different apps needs to cross the address boundaries of processes
involved (process context switches) while moving data between AU only
need thread context switches (less CPU prone than process switch). The
UA model is a pull model, which may be less adapted to interprocess
communication than a push model (BTW, your 1st solution would be based
on a push model). To guarantee a glitch free flow of data, block size
would probably need to be significantly bigger than the 64 or 128
samples frames we are dealing with when AU are concerned. This will
imply delay/latency that would have to be compensate by anticipating
the time of the send regarding the time stamp of the data. This is
anyway feasible, that's what rewire does. I would have been very
interested in reading rewire specifications but they are - alas - not
opened to individual people.
Cheers.
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.