Would it make sense to include the sample rate of the buffer in an AUInternalRenderBlock

Question

ForumsContributor OP

Created Feb ’22

Replies 1

Boosts 0

Views 1.4k

Participants 1

This just seems like a useful thing to have when rendering audio. For example, let's say you have an effect that pitches audio up/down. That typically requires that you know the sample rate of the incoming audio. The way I do this right now is just to save the sample rate after the AUAudioUnit's render resources have been allocated, but being provided this info on a per-render-callback basis seems more useful.

Another use case is for AUAudioUnit's on the input chain. Since the format for connections must match the hardware format, you can no longer explicitly set the format that you expect the audio to come in at. You can check the sample rate on the AVAudioEngine's input node or the sample rate on the AVAudioSession singleton, but when you are working with the audio from within the render callback, you don't want to be accessing those methods due to the possibility they are blocking calls. This is especially true when using the AVAudioSinkNode where you don't have the ability to set the sample rate before the underlying node's render resources are allocated.

Am I missing something here, or does this actually seem useful?

Boost

Answer 1

swillits OP

Jul ’22

Rereading your question a few times I thiiiink what you may be missing is that the audio unit works with the format and sample rates of its busses, which are known to it. So the audio unit never needs to know what the AVAudioEngine's input node's sample rate is, or have an external object set a custom property on the unit to hold "the format that you expect the audio to come in at". Instead, you just look at the relevant bus's format.

Like you said, you can simpy save the sample rate of your bus in the allocateRenderResources method, and the value does not change, so it does not need to be passed into the block. The block parameters are the minimum changing values needed to actually render the audio. While perhaps a trivial convenience saving you two lines of code, there are other values you also want to use in the block and need to save in the same way, so there's no reason the sample rate is special.

0