RE: Garageband 3/audio units odd behaviour
RE: Garageband 3/audio units odd behaviour
- Subject: RE: Garageband 3/audio units odd behaviour
- From: "Muon Software Ltd - Dave" <email@hidden>
- Date: Tue, 6 Feb 2007 15:18:31 -0000
- Importance: Normal
Stefan,
Understood, but that design makes an assumption that the host knows better
than the AU when audio might need to be rendered.
I have one AU for one client that has a comprehensive file browser with
built-in previewing - the previewing feature doesn't work when the audio
thread isn't running as the AU has nowhere to render to. Another AU for a
different client has a built-in sample keymapping editor that has zone, note
and sample preview features, none of which work when the audio thread isn't
running. There must be a lot of other AU's that have previewing features
too, not just ours.
Another question would be why is GB3 so different in terms of the way its
threading works to a reference host like AU Lab or Logic. It'd be nice, from
a testing point of view if the behaviour was at least similar in critical
areas like threading :-)
Kind regards
Dave
> -----Original Message-----
> From: Stefan Gretscher [mailto:email@hidden]
> Sent: 06 February 2007 15:06
> To: Muon Software Ltd - Dave
> Cc: email@hidden
> Subject: Re: Garageband 3/audio units odd behaviour
>
>
> Hi Dave,
>
> unlike in VST world, AU hosts are not required to process all
> AUs all
> the time.
> Instead, AUs are based on a pull-output model, and that implies that
> if the
> audio data produced by a given AU is not needed at a certain
> point in
> time
> (for example while the engine is not running or if a track is
> muted),
> the host
> can skip rendering that AU (i.e. not pull its output) in order to
> save CPU.
>
> Best,
> Stefan
>
> Am 06.02.2007 um 15:40 schrieb Muon Software Ltd - Dave:
> > I'm testing a PPC audio unit we're developing for a client in as
> > many hosts
> > as possible and have come across something odd specifically in
> > Garageband 3.
> >
> > The AU in question is built from the same code as the VST and
> > Standalone
> > versions of our product and assumes that there is a separate audio
> > and GUI
> > thread in all hosts. Because of this assumption, in some
> cases when
> > the user
> > alters certain settings in the GUI we simply make a note of that
> > request and
> > leave it down to the next render cycle when it would be
> thread-safe
> > to act
> > upon that request.
> >
> > What seems to be happening in GB3 (but not in any other AU host
> > tested) is
> > that the audio rendering thread doesn't seem to start when the
> > application
> > is first loaded, which seems to break our plugin in some new and
> > interesting
> > ways.
> >
> > So far the only work arounds that I've found to get the the audio
> > thread to
> > start running are:-
> >
> > 1. run the transport or...
> > 2. open the musical typing keyboard or piano keyboard window and
> > play a note
> > or...
> > 3. Show editor and click in the vertical piano keyboard on
> the left
> > side
> >
> > Is this normal behaviour? Any suggestions?
> >
> > Regards
> > Dave Waugh
> > Muon Software Ltd
> > www.muon-software.com
> >
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Coreaudio-api mailing list (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> > 40apple.com
> >
> > This email sent to email@hidden
>
>
>
> ------------------------------------
> Stefan Gretscher
> plug-in development & 3rd party developer support
>
> phone: (+49)-4101-495-586 (Central European Time)
> AU developer support: email@hidden
> TDM developer support: email@hidden
>
> Apple Computer GmbH
> Geschäftsführung: Freddie Geier, Georges Guyon de Chemilly
> Sitz der Gesellschaft: München
> Amtsgericht München, HRB 66158
>
>
>
>
_______________________________________________
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