Re: A Rosetta wrapper AU
Re: A Rosetta wrapper AU
- Subject: Re: A Rosetta wrapper AU
- From: Mark Pauley <email@hidden>
- Date: Thu, 14 Dec 2006 16:07:48 -0800
You might want to consider:
a) Creating an AU output device that can be written to from a Rosetta
process and read from a Native process
b) Creating an AU wrapper that fork-exec's a rosetta stub-host if one
is not alive
c) Sending a message to the rosetta stub-host that tells it to load a
given ppc AU
d) In the Rosetta stub-host, connect the plugin to the input side of
the AU output device
e) From your native wrapper, read from the output side of the Rosetta
AU output device
basically, you use an AU device to slingshot around Rosetta, while
still leveraging CoreAudio to keep the timing for you.
Would that work? I know I'm missing some necessary details.
_Mark
On Dec 14, 2006, at 11:31 AM, Andrew Barnert wrote:
Thanks.
Part of the reason I'm going with an incredibly slow API for the
first draft is to figure out exactly what I need to do about the
latency issue.
I think (but I'm just learning AU, so I could be wrong...) that I
can just do everything directly, and bump up
kAudioUnitProperty_Latency appropriately, and the host has to take
care of dealing with that extra latency. (Less-sophisticated hosts
may not use this info, but I'm assuming GB, Logic, etc. do.)
The only issue is this:
> If the sample latency for your audio unit varies, use this
property to report the
> maximum latency. Alternatively, you can update the
kAudioUnitProperty_Latency
> property value when latency changes, and issue a property change
notification using
> the Audio Unit Event API.
So I have to know the maximum latency--and this is almost certainly
based on the maximum command size, which is based almost entirely on
the maximum buffer list size, which I can't know a priori (can I?).
Maybe I can just keep track of the slowest command I've seen so far
(or since the last Reset?) and update through notifications,
something like this pseudocode (aka Python):
# Called by each command before it does the marshaling
def PreMarshal(self, ci, scope):
self.start = clock()
# Called by each command just before returning
def PostDemarshal(self, ci, scope):
latency = clock() - self.start
if latency - self.wrappedlatency > self.maxlatency:
self.maxlatency = latency - self.wrappedlatency
self.NotifyPropertyChange(ci, scope, kAudioUnitProperty_Latency,
[self.maxlatency + self.wrappedlatency])
def GetProperty(self, ci, scope, element, property, *data):
self.PreMarshal(ci, scope)
# do all the real work
self.PostDemarshal(ci, scope)
if element == kAudioUnitProperty_Latency:
if result != noErr:
result = noErr
data[0] = 0
self.wrappedlatency = data[0]
data[0] += self.maxlatency
return result
def HandleNotifyPropertyChange(self, ci, scope, element, property,
*data):
# Do all the demarshaling
if element == kAudioUnitProperty_Latency:
self.wrappedlatency = data[0]
data[0] += self.maxlatency
SendNotifyPropertyChange(self, ci, scope, element, property, *data)
Are there different latencies for different scopes, or can I just
keep a single value around?
On 13 Dec 2006, at 01:09, Angus F. Hewlett wrote:
Sounds workable... the one issue you will run in to is that
interprocess communication always has a latency penalty, so you'll
need to do some extra buffering to account for that so as not to be
waiting for the Rosetta process to do its thing during the Intel
process' audio thread.
Best regards,
Angus.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden