search

admsyn / ofxAudioUnit

An openFrameworks addon which makes it easy to work with Audio Units on OSX and iOS
MIT License
120 stars 24 forks source link

ofxAudioUnitFilePlayer occasionally does not start #5

Closed admsyn closed 10 years ago

admsyn commented 11 years ago

On occaision, an ofxAudioUnitFilePlayer will refuse to start when play() or loop() is called. Several attempts may eventually wake it up, but this is not an acceptable workaround.

Calling play() / loop() by dispatch_async on the main queue doesn't seem to help, neither does a dispatch_after to give it some time to boot up.

antimodular commented 11 years ago

this seems to be mainly a problem when working with a large quantity of sound files.

calling ofSleepMillis(20) after each filePlayer.loop() call does not help either.

admsyn commented 10 years ago

Just stumbled accross a note in AudioUnitProperties.h that seems very relevant:

Priming You should set kAudioUnitProperty_ScheduledFilePrime after scheduling initial file regions to be played and before starting playback. This SetProperty call will begin reading the audio files and not return until the number of frames specified by the property value have been read.

Which is currently not a thing that ofxAudioUnit is doing. It sounds simple enough, a blocking call to AudioUnitSetProperty with the kAudioUnitProperty_ScheduledFilePrime property that returns whenever the file player is good-to-go. Would probably be good to expose this as a separate function void ofxAudioUnitFilePlayer::prime() that can be called after setting files (and that gets called by default by play() if it hasn't primed yet).

admsyn commented 10 years ago

Reopening, as this still seems to be an issue

jasonlevine commented 10 years ago

After a week of constant use, I can confirm that calling prime() followed by two play()s results in no dropped tracks.

admsyn commented 10 years ago

You're killing me here :D

Well, for now I'll assume that calling play() on it multiple times reduced the chances of it happening by a substantial amount, but it's still possibly a bug. I'd like to find something I'm doing conclusively wrong before saying this is fixed again

jasonlevine commented 10 years ago

Ha! I was hoping this strange behaviour might offer insight to the problem, and in no way insinuating that it was a fix!

admsyn commented 10 years ago

Ok, I think this is fixed now. Probably the combination of always calling prime() and the fact that I initially messed up the implementation of prime() when attempting to close this issue in the first place (see #12).