Sample rates

[steeley]

needs to support sample rates other than 44100

[admsyn]

Hi @steeley, thanks for the suggestion. Can you provide an example of how you think the API should look for this? Just a code snippet or something to show what you have in mind :)

[steeley]

Maybe:

ofxAudioUnit.setSampleRate(48000);

Based on:
kAudioUnitProperty_SampleRate

A read/write Float64 value valid on the audio unit input and output scopes.

The audio sample rate for a specified scope.

Available in OS X v10.0 and later.

Declared in AudioUnitProperties.h.

[admsyn]

Yeah at first glance that's what makes sense, but the problem really is that audio units have to work together to support non-default sample rates. So, you'd have to set the sample rate on all of your audio units individually, or drill down to the input / output busses explicitly (e.g. ofxAudioUnit.setOutputSampleRate(48000)).

For example, if you had a chain of audiounits A -> B-> C, and you wanted to set C's sample rate to 48000, you'd have to do it on B as well, which means you'd have to do it on A..

Maybe it'd make sense to be able to operate on the whole graph at once, via the output unit. So you set the output unit's sample rate, and it will traverse the graph "backwards" to set the sample rates on all of the units that are attached to it.

This might be overthinking it though :) I'll take a stab at adding just the simple version you proposed since it's fairly straightforward.

[steeley]

Good point - I guess the ideal way is to set it on the output as you say.
Thanks for taking a look.

[jasonlevine]

What if we have a static function* ofxAudioUnitSetSampleRate(int
sampleRate)* that iterates through the AUGraph and adjusts the sample rate
for each AU as well as setting a static variable sampleRate that tells
newly-created AUs what their sample rate should be?

On Thu, Dec 5, 2013 at 4:19 PM, steeley [email protected] wrote:

Good point - I guess the ideal way is to set it on the output as you say.
Thanks for taking a look.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-29939109
.

Jason Levine
new media performer + creative coder
http://jasonlevine.ca

[admsyn]

@jasonlevine that would be pretty convenient, but I'm against having magic statics like that can lead to some pretty weird and unintuitive behaviour in edge cases (like if you had > 1 graph in an app, for instance).

I think setting the output's sample rate, and having that traverse backwards over the connected units setting the sample rate as it goes makes sense. I'd think most people would be thinking something like "I want to render at 96000 Hz", in which case it'd be pretty intuitive to set it at the output. There should probably also be a special case for setting the sample rate of an input device as well.

.. Actually, in that case there'd probably need to be an internal AUConverter in the ofxAudioUnitInput that can handle the sample rate conversion in the very likely scenario that the input and output units in a graph aren't operating at the same sample rate.

So, basically, this is a bit more complex than just wrapping the kAudioUnitProperty_SampleRate property :) I'm game, though.

[jasonlevine]

So the problem is that someone might have two AUGraphs with different sampling rates?

[admsyn]

The problem is that having a global variable like that opens the door to unintuitive "magic" behaviour, and is just generally bad form if there are other options available.

It's also not as simple as just having a single static sampleRate variable. If it were done that way, every unit that gets created would have to register itself in some other global registry of audio units, so when the sampleRate static gets set, it can find references to all of the other live audio units in the app and set their sample rates accordingly.

With the "set it at the output" function, all of this isn't necessary since the output will have access to all of the units connected to it (recursively going backwards through the connected units).

Anyway, I'm not veto-ing the static global solution, but I'd really rather not start introducing global functionality if it can be avoided. It might turn out that there's some gotcha with "set it at the output", in which case I'll take a look at the magic global way. My gut instinct is that the global solution will have waaay more subtle gotchas, though :)

[steeley]

I guess the other thing to consider is that the sample rate could be set by default to whatever the AudioMIDI setup--> sound settings are.