Re: DefaultOutputDevice timestamps
Re: DefaultOutputDevice timestamps
- Subject: Re: DefaultOutputDevice timestamps
- From: Jeff Moore <email@hidden>
- Date: Wed, 24 Oct 2001 12:14:37 -0700
Preface: My experience with ObjC is very limited. I've read through the
language docs once and gone through a few of the tutorials. Take this with a
grain of salt and consult your local ObjC guru for real information.
on 10/24/01 2:44 AM, email@hidden <email@hidden> wrote:
>
You helped to find where the problem is - my appIOProc is *not* a simple c
>
function, it is a c function that calls an obj-c class' method.
Ostensibly, this should be fine.
As I understand it, method dispatching in ObjC is done through a central
dispatching routine that does a look up by name for the method. I think it
then marshals the arguments through the stack (maybe in registers, I don't
recall) to call your method. It is more or less a call into the runtime
engine to outside code that has compiler support.
>
The parts of which I have less
>
understanding (calling a OBj-c method from a C function is code adjusted
>
from suggestions given to me by others on the list) is that perhaps the
>
defptr I use isn't handled correctly or perhaps I need to do something
>
else to call the audioCallback method
I'm not sure about this one. Since ObjC object references are pointers, I
would think that you should be able to pass that in directly using casting
as appropriate. I think you said you tried this without success.
My bet here is that your problem is tied up in the method dispatch. Somehow,
the arguments are being marshaled incorrectly. The result is that you are
getting a bogus pointer in your routine.
One thing you can try is to make sure that your IOProc's declaration and
definition are outside of any ObjC @implementation or @interface statements.
This may make a difference in how the compiler treats the code (I don't know
for certain).
Another possibility is that somehow your code has the AudioTimeStamp struct
laid out in memory differently than the HAL implementation code does. This
could come up from some kind of header ordering conflicts that are
redefining the basic types in <CoreAudio/CoreAudioTypes.h> or there is some
alignment pragma in effect unintentially.
--
Jeff Moore
Core Audio
Apple