Two questions - one urgent, one background.
Two questions - one urgent, one background.
- Subject: Two questions - one urgent, one background.
- From: Ian Kemmish <email@hidden>
- Date: Sat, 6 Aug 2005 09:46:28 +0100
Both questions relate to a MusicDevice audio unit, i.e. a software
synthesiser.
1) First the background question, since I suspect it has a simple
answer: If you have a multi-timbral modular synth that allows the
user to publish named performance parameters from each voice she
creates, it is natural to want to have *different* lists of AU
parameters published for each group element.
There's no problem with this during performance, but the API calls
for letting the host software discover the complete list of AU
parameters appear only to support a single list of parameters across
all groups. For example, if parameter 65000 is called "pluck
position" on MIDI channel 1, it has to be called "pluck position" on
every MIDI channel.
Is this correct? Is it likely to change in the future? I can see
that allowing parameters to change their identity too much is likely
to confuse both hosts and users if they're not prepared for it, but
on the other hand, if they are prepared for it, it's irritating not
to be allowed to do it!
2) Now the urgent question. I recently added a vocoder module, so
now the audio unit has an input element as well as an output
element. Since I did this, my synth acquired a memory smashing bug.
This manifests itself if I call:
AUGraphInitialize (graph);
#if BUG
AUGraphUninitialize (graph);
AUGraphInitialize (graph);
#endif
AUGraphStart (graph);
but does not manifest if I don't have the middle two calls (I picked
this up thanks to AUValidate!)
The problem only appears if my AU's Render method calls PullInput()
to collect its input; if I merely comment out this call, everything
works OK. The addresses that malloc() reports when the problem is
present (usually relating to corrupted checksums in freed blocks),
seem to be always close to the addresses of either the
AudioBufferList returned by the input element's GetBufferList()
method or of the actual sample buffer it points to.
I don't understand this, because as far as I can see, AUInputElement
doesn't actually do anything when the AU is uninitialised, only when
it is closed. So it shouldn't even be able to have a dangling
pointer. But then my ability to read C++ isn't what it could be.
I've almost certainly just missed some input Cleanup action that I
need to take relating to the input element.
(In case it's relevant, the actual audio input my test code uses is
just the system default input, using the HAL output AU as described
in an Apple tech. note.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds
SG18 8HZ
email@hidden Tel: +44 1767 601361 Mob: +44 7952
854387
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
_______________________________________________
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