Scheduling AEAudioFilePlayers for a simple DAW


First of all, a huge thank you to Michael for such an awesome framework, and the depth of knowledge I’ve found on these forums :)

I am interested if it is possible to sequence triggering AEAudioFilePlayers using AEBlockScheduler using TAAE1.x. I am trying to build a simple DAW where preloaded files (of different lengths) must play in time one after another.

I’m unclear if the AEAudioFilePlayer is designed for this purpose, where it can be queued up on the fly.

I am aware of the AEAudioFilePlayer::playAtTime() functionality, but I believe there are too many files to play at once without overloading the render callback.

Also, as the scheduler calls back in the audio thread, doesn’t this mean that any ObjC calls to the AEAudioFilePlayer are simply out of the question? So would I actually need to drop down into some custom C code here and stream the audio myself?

I have searched the forum and although this question has been touched upon, I cannot find a definitive answer. Perhaps TAAE2 makes this kind of thing easier?



  • Thanks, @aliMunchkin! You're too kind.

    I don't think AEBlockScheduler on its own is going to work for you, for the reason you've already picked up on: no ObjC on the render thread. You could use TAAE2 with some custom logic - for example, keep a table of play times vs audio players (managed by AEArray), and only start processing a player in the render loop once the play time has been met.

    However, regarding the number of tracks, you may be surprised how many you can cue using playAtTime. The time check is very fast, so you can probably have thousands of tracks cued up using that mechanism without getting much of a performance hit.

  • @Michael thank you very much for your response :)

    When I had originally tried playAtTime() I was seeing occasional errors as new files started playing:

    AEAudioUnitChannel.m:206: AudioUnitRender: -50

    This is why I thought perhaps the render callback was being overloaded, but as you say this is incorrect. A colleague narrowed the error down to this code in the AEAudioFilePlayer callback:

    // Start time is offset into this buffer - silence beginning of buffer for ( int i=0; i<audio->mNumberBuffers; i++) { memset(audio->mBuffers[i].mData, 0, silentFrames * THIS->_unitOutputDescription.mBytesPerFrame); }

    Eventually I found that changing from nonInterleaved16BitStereoAudioDescription to AEAudioStreamBasicDescriptionNonInterleavedFloatStereo alleviated the problem. I didn't spend any more time investigating, I thought it should work with either type but perhaps I was just doing something stupid.

    Anyway, seems to be working great now!

  • Oh, well done =) Not sure why that was happening for you, but glad it's working right with noninterleaved float. Noninterleaved int16's a bit of an unusual format in my experience and sometimes has limited support in the built-in audio units - could be some bug in the converter management.

Sign In or Register to comment.