Re: Two questions - one urgent, one background.
Re: Two questions - one urgent, one background.
- Subject: Re: Two questions - one urgent, one background.
- From: William Stewart <email@hidden>
- Date: Mon, 8 Aug 2005 14:49:36 -0700
On 06/08/2005, at 1:46 AM, Ian Kemmish wrote:
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!
Firstly, there's a document in the SDK that you should read - in
Documentation/AudioUnits, there's something called Groups, Parts and
Multi-timbrality
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!)
In the auval readme, there's a description of how to use the memory
debugging tools - probably worth having a look at that. Also, you can
route audio input to an AU Instrument in the AU Lab application - you
could also try using your AU in this context as well.
Bill
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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