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: David Duncan <email@hidden>
- Date: Tue, 21 Mar 2006 11:32:18 -0500
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.
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.
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)
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.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
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