• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AU Properties and Initialization
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU Properties and Initialization


  • Subject: Re: AU Properties and Initialization
  • From: Bill Stewart <email@hidden>
  • Date: Sat, 29 Mar 2003 14:16:24 -0800

This is a little more complex and I don't think its a good idea.

For ex, setting a stream format...

Say you don't allow setting the format if you're initialized
Currently you then return - nope - can't set format and you get a format err.

Now - we'd have to manage extra logic to say:
Is that a nope because you are initialized
or
Is that a nope because you don't like the format

Thats a pain to do for the AudioUnit itself - though I guess we could add additional logic somewhere (can you do this if you are initialized?)

Seems unnecessary though...

All the host has to do is:
Set the property -> error
Uninitialize the Unit
Set the property -> error - oh - so now it knows its actually a bad value

That doesn't seem onerous to me as typically there are for most properties ways you can ascertain valid property values, so, most of the time you should be uninitializing the unit anyway and you are probably not in a great shape by the time you've failed the second time anyway and will have some work to do to recover

Bill

On Saturday, March 29, 2003, at 01:25 PM, Marc Poirier wrote:

Bill,

Thanks, this clarification is very much appreciated! There's just one
little thing that I see left hanging:

It seems a simpler semantic to us (and this was our initial design
goal) to firmly separate the establishment of state from the process of
rendering., thus, returning an error is I believe entirely acceptable
and appropriate. This might be different for different AU's and a host
application should be prepared to deal with this.

This sounds fine, but unfortunately there currently isn't a clear way to
say to the host, "Hey, you can't do that because I'm already initialized.
You need to unitialize me if you want to do that." There is a
kAudioUnitErr_Uninitialized error, but no cannot-do-that-when-initialized
counterpart. So anyway, I would propose adding an error code called
something like kAudioUnitErr_Initialized, because otherwise there won't be
a way to clearly tell the host that unitialization is required.


Marc
_______________________________________________
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.


-- 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
________________________________________________________________________ __
_______________________________________________
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.
  • Follow-Ups:
    • Re: AU Properties and Initialization
      • From: Marc Poirier <email@hidden>
References: 
 >AU Properties and Initialization (From: Bill Stewart <email@hidden>)

  • Prev by Date: Re: multi-channel AUs
  • Next by Date: Re: OT: OS X documentation
  • Previous by thread: Re: AU Properties and Initialization
  • Next by thread: Re: AU Properties and Initialization
  • Index(es):
    • Date
    • Thread