Best Practices For Rebuilding Audio Graph

What are the best practices for rebuilding the Audio Graph?

  1. How can a program assure that the Audio Graph is valid?

  2. What are the best methods to call? (such as, edit.restartPlayback())

  3. After what operations should the Audio Graph always be rebuilt?

Thank you!

  1. You can use TransportControl::isPlayContextActive() to determine if there is an audio graph built and attached to the audio device (for playback)

  2. You can call Edit::restartPlayback() but to be honest you shouldn’t really have to (see 3)

  3. All of the audio graph rebuilding for things that Tracktion Engine knows about is handled automatically internally. You shouldn’t have to call restart yourself at all if you’re using the stock Engine. The only time I can think that you’d need to call it manually was if you have some custom behaviour on top that indirectly affects the way the audio graph would be generated, but I’m struggling to think of a single concrete example…
    If you want a deeper look at how this is handled internally take a look at Edit::TreeWatcher in tracktion_Edit.cpp

I hope that helps.

1 Like

Very helpful, as always! Thank you!

I’ll study Edit::TreeWatcher to see how all the plumbing works.

If I may ask a follow-up question; Are there any practices specifically to avoid in terms of using the audio graph? …edge cases?

It’s a bit difficult to say as there’s literally thousands of things you could do…

Perhaps a better approach would be for you to let us know what you’re doing and we can give more specific advice?

I was really looking for general information—things to know and keep in mind when dealing with the audio graph.

The only specific problem I’m having at the moment is with recording one track while playing back from another. The audio on the second track appears to be phase canceled by the playback track.

So, I have two tracks. Track one is set to input one, and Track two is set to input two.

I arm Track one and record some audio.

Then, I disarm Track one, and arm Track two. And, I “rewind” the playhead back to the start of the Track one clip.

So, now I am hearing Track one as I record track two.

The Track two sound is audibly affected. It shows in the waveform thumbnail. And when the Track two clip is played back, it has been affected by the Track one clip.

This is reproducible in the Recording Demo.

What might cause this? And, how do you properly prepare the audio graph for recording new tracks as you playback existing ones?

That sounds odd. Can I ask a bit more about your setup? What is your input signal? I wouldn’t expect any phase cancellation, even on playback unless your signal was nearly identical during both recording passes…

Are you perhaps using some kind of loop-back on your audio device and the output from your first track is being mixed in to the input of your second track?

Are you calling TransportControl::stop before doing your rewind? That’s needed to “commit” the clips to the Edit.

I am testing on my development laptop, which is a Windows 10 computer. I simply record through the builtin microphone while coding. I can try it in my studio setup later.

Yes, I am calling TransportControl::stop. In fact, my Rewind button is disabled unless Stop is pressed first.

Please note, the issue is reproducible in the Recording Demo. And, I have tried a few more things. I have found that if I Mute the first track while recording the second track, the cancellation does not occur.

So, again, if I record Track one and Track two together, everything is fine. But, if I record only Track one, return the playhead to the beginning of the Track one clip, and now record Track two, while listening to Track one, the cancellation occurs. If Track One is Muted, it does not occur.

It will be a few hours until I can test on my studio equipment. But I will do that test so that hardware/driver idiosyncrasies can be ruled out.

And, in the meantime, perhaps someone can try the above procedure with the Recording Demo?

Sorry, I’m not seeing that here:


You can see from the two recorded clip (different takes) that there is no bleed or interference between them.

Perhaps a video of the problem would be easier to see?

Thank you for checking that. It would seem to indicate some strangeness in my development system laptop’s sound hardware (Realtek based).

Give me a few hours to conduct a test on my studio equipment, which is totally different hardware. I will report back on what I find.

Thank you again for your help and patience.

So, on my studio setup, everything works correctly. I tried several combinations, and all worked as expected. So, this definitely points to some odd behavior on my development system.

Perhaps the best we can learn from this is to beware what you are testing on (Acer laptop, Realtek sound). No matter how generic, it may still not work as expected!

Thank you for your patience!
.