Re: memory use / embedding concerns
Re: memory use / embedding concerns
- Subject: Re: memory use / embedding concerns
- From: James McCartney <email@hidden>
- Date: Mon, 14 Sep 2009 10:57:37 -0700
I would not recommend that you try to trace opaque structures.
Presumably you are the one installing collectable pointers into
CoreAudio objects. If so, and if the collector provides you some way
to register/unregister pointers owned by foreign data as roots of the
gc, then you can tell the gc what pointers are owned by CoreAudio for
the duration that they are owned.
(otherwise you could just use SuperCollider which has a real time GC,
instead of scheme :-)
On Sep 13, 2009, at 12:14 PM, John Clements wrote:
I'm trying to embed CoreAudio functionality in a system (mzscheme)
that uses precise garbage collection. In order to do this
successfully, I need to be able to identify the blocks of memory
allocated by the CoreAudio library, and walk them for pointers to
other pointers.
I'm not doing anything terribly fancy; the calls I'm making are
lifted directly from the PlaySoftMIDI example project. Creating and
connecting a few AUGraph nodes, fetching an AudioUnit pointer, and
sending it a sequence of MIDI commands.
Unfortunately, AUGraph's are really OpaqueAUGraph structs, for which
(as far as I can tell) I don't have header file definitions.
Naturally, there's an alternative approach; I could put the
CoreAudio in its own process, give it its own memory space, and
everything would be fine. This is yucky, though, because then
rather than using a nice FFI interface, I have to roll my own socket
connection etc.
_______________________________________________
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