Re: AUGraphInitialize in audio thread
Re: AUGraphInitialize in audio thread
- Subject: Re: AUGraphInitialize in audio thread
- From: "Angus F. Hewlett" <email@hidden>
- Date: Tue, 22 Apr 2003 21:08:58 +0100
Right, thanks for clearing that up... was a bit worried you were talking
about calling Render() directly from a lowlevel interrupt or driver code! :-O
At 06:52 PM 4/16/2003 -0700, Brian Willoughby wrote:
>
Hello,
>
>
Just to be clear, when I mentioned "breaking the paradigm" I wasn't talking
>
about literally breaking specific functionality. I was referring to
standard
>
coding practices for units similar to AudioUnits. It's a really good idea
to
>
not go outside the constraints of the AudioUnit API. This is a bit vague,
>
since I suppose it wasn't specifically written that you aren't supposed to
pop
>
up an alert panel inside your DSP code.
>
>
AudioUnits have a clear separation between the UI half and the DSP half.
>
Therefore, the DSP half should not do anything with UI, including alert
panels.
>
>
As far as what functionality besides UI might break, it really depends upon
>
what you're attempting, and what context your code is in. See the
CoreAudio
>
AudioUnits documentation for more information. I believe the
documentation is
>
being improved as these new issues come up.
>
>
Brian Willoughby
>
Sound Consulting
>
>
>
Begin forwarded message:
>
>
Date: Thu, 10 Apr 2003 12:31:58 +0100
>
From: "Angus F. Hewlett" <email@hidden>
>
Subject: Re: AUGraphInitialize in audio thread
>
>
At 02:30 PM 4/9/2003 -0700, Brian Willoughby wrote:
>
>
>Considering your needs - to alert the user about insufficient licensing -
>
>perhaps CoreAudio should allow for an exception to be raised, or add a
>
unique
>
>return code to indicate licensing restrictions. It would be up to the
>
host app
>
>to display the text of the exception, or to interpret the return code.
>
>
>
>It's a very common and powerful design principle to create code units which
>
>have no UI. This technique allows them to be used in many more ways than
>
>initially predicted. Breaking the paradigm by popping up alert panels is
>
>probably something that will restrict the flexibility of AudioUnits.
>
>
I must say, I have some reservations about this. Specifically, what other
>
classes of functionality besides UI might break or be unsafe in these other
>
uses? Or is it -only- UI that's affected?
>
>
Also, is this restricted to Initialize(), or does it apply to constructors
>
as well?
>
>
Finally, with regard to error messages, how about a Property for "last
>
error message". So, whenever the plug returns an error, it can set the
>
contents of a text buffer (or even a more detailed structure) internally,
>
which the host can receive via a GetProperty() call.
>
>
Regards,
>
Angus.
>
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd -
http://www.fxpansion.com
=======================================================
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.