Re: Audio applications running under Rosetta, endianess issues
Re: Audio applications running under Rosetta, endianess issues
- Subject: Re: Audio applications running under Rosetta, endianess issues
- From: Jeff Moore <email@hidden>
- Date: Tue, 21 Mar 2006 11:30:04 -0800
Mr. Duncan's answers are pretty much correct with a few clarifications.
On Mar 21, 2006, at 8:32 AM, David Duncan wrote:
On Mar 21, 2006, at 09:27 AM, Stéphane Letz wrote:
What happens for PPC audio applications running under Rosetta on a
Mac Intel?
Same thing that happens to everyone else.
Indeed. The world looks like a PPC world. As such the HAL will only
load PPC plug-ins.
In particular what happens to audio buffers going from/to the
intel coreaudio driver when accessed in the PPC code?
I don't know personally. But I would expect that Core Audio would
report the native sample order of the audio device as little endian
rather than the big endian, as this has always been a possibility
with Core Audio.
The physical format of the hardware will always be reported as it is
in the hardware. However, the "virtual" format (that is, the format
in your IOProc) for linear PCM data is still native-endian Float32.
This means that in Rosetta, apps will be providing big-endian Float32s.
Does Rosetta provide "transparent" access to float data (for
example) ?
In this particular case, I can't imagine it being a function of
Rosetta at all, after all, Core Audio has always dealt with endian
issues in the audio stream, so no reason for Rosetta to get
involved at all (not to mention we are talking about buffers of
data rather than function parameters, so this may be more tricky to
get right there -- see numerous examples in the porting guide of
data blobs that have fixed endian-ness)
It's transparent in that things continue to work like they always
have: IOProcs for mixable linear PCM data will be expected to provide
native-endian Float32s. The IOAudio-based driver knows the difference
between a Rosetta application and a native one and handles the endian
swapping of the data in the kernel.
We also have code that need to access a shared memory segment that
will be opened by an intel process and possibly read/written by a
PPC process. This does not work anymore... do we need to
explicitly use byte swapping functions to read/write the data in
shared memory?
I have not tried that, but I would expect that you would need to
know the byte order to do such writing properly.
Yes. You must define an access protocol for your shared memory so
that the data is coherent under this cicumstance. The system doesn't
do anything to help you here since only you know the structure of
your data and can do the right thing with respect to endian-ness.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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