Setting rate on AudioUnit subtype kAudioUnitSubType_NewTimePitch
Setting rate on AudioUnit subtype kAudioUnitSubType_NewTimePitch
- Subject: Setting rate on AudioUnit subtype kAudioUnitSubType_NewTimePitch
- From: Vincent CARLIER <email@hidden>
- Date: Wed, 5 Jul 2017 08:43:05 +0200
I'm using `AUGraph` with different audio units in it, one of them is of
type `kAudioUnitType_FormatConverter`, and subtype
`kAudioUnitSubType_NewTimePitch`.
I'm trying to change the `kNewTimePitchParam_Rate` parameter on it.
It does work in some way, but when I reset the parameter to the value 1.0
(no change rate) I still get pitch variation in audio. I'm trying to
understand how to do that properly.
I'm doing this live in my application, directly calling the
`AudioUnitSetParameter()` function :
- (void)setTempo:(float)value {
OSStatus err = noErr;
err = AudioUnitSetParameter(tempoUnit, kNewTimePitchParam_Rate,
kAudioUnitScope_Global, 0, (Float32)value, 0);
if (err != noErr) {
NSLog(@"Could not set tempo unit rate: %d", (int)err);
}
}
Is it the correct way to do it ?
It's an iOS application, are there better ways to achieve this ?
Related question: [here](
https://stackoverflow.com/questions/44744683/setting-rate-on-audiounit-subtype-kaudiounitsubtype-newtimepitch
)
**EDIT**
After digging around and logging, here is what I found :
First here's the complete graph structure :
AudioUnitGraph 0xDF5046:
Member Nodes:
node 1: 'auou' 'rioc' 'appl', instance 0x170837a80 O I
node 2: 'aufc' 'nutp' 'appl', instance 0x170634f20 O I
node 3: 'aufc' 'nutp' 'appl', instance 0x170a23140 O I
node 4: 'aufc' 'nutp' 'appl', instance 0x17083b700 O I
node 5: 'aumx' 'mcmx' 'appl', instance 0x17063bc80 O I
node 6: 'aumx' 'mcmx' 'appl', instance 0x174626da0 O I
node 7: 'aumx' 'mcmx' 'appl', instance 0x17063bd60 O I
Connections:
node 6 bus 0 => node 4 bus 0 [ 2 ch, 44100 Hz, 'lpcm'
(0x00000029) 32-bit little-endian float, deinterleaved]
node 5 bus 0 => node 3 bus 0 [ 2 ch, 44100 Hz, 'lpcm'
(0x00000029) 32-bit little-endian float, deinterleaved]
node 4 bus 0 => node 7 bus 0 [ 2 ch, 44100 Hz, 'lpcm'
(0x00000029) 32-bit little-endian float, deinterleaved]
node 3 bus 0 => node 7 bus 1 [ 2 ch, 44100 Hz, 'lpcm'
(0x00000029) 32-bit little-endian float, deinterleaved]
node 7 bus 0 => node 2 bus 0 [ 2 ch, 44100 Hz, 'lpcm'
(0x00000029) 32-bit little-endian float, deinterleaved]
node 2 bus 0 => node 1 bus 0 [ 2 ch, 44100 Hz, 'lpcm'
(0x00000029) 32-bit little-endian float, deinterleaved]
Input Callbacks:
{0x100a31764, 0x1706df330} => node 5 bus 0 [2 ch, 44100 Hz]
{0x100a31764, 0x1706df250} => node 5 bus 1 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dccb0} => node 5 bus 2 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dda40} => node 5 bus 3 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dcc40} => node 5 bus 4 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dca80} => node 5 bus 5 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dcaf0} => node 5 bus 6 [2 ch, 44100 Hz]
{0x100a31764, 0x1706df2c0} => node 5 bus 7 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dce00} => node 5 bus 8 [2 ch, 44100 Hz]
{0x100a31764, 0x1706ddb90} => node 5 bus 9 [2 ch, 44100 Hz]
{0x100a31764, 0x1706dddc0} => node 5 bus 10 [2 ch, 44100 Hz]
{0x100a31764, 0x1708c0c40} => node 6 bus 0 [2 ch, 44100 Hz]
{0x100a31764, 0x1706df410} => node 6 bus 1 [2 ch, 44100 Hz]
{0x100a31764, 0x1706ddab0} => node 6 bus 2 [2 ch, 44100 Hz]
CurrentState:
mLastUpdateError=0, eventsToProcess=F, isInitialized=T, isRunning=T (1)
At the far left of the graph, there are to multi channel mixers, each
followed by an audio unit new time pitch (pitch modulation), then a mixer
that receive audio data from the two, and finally the tempo audio unit.
I configure each mixer at the left with render callbacks.
At first I thought that each callback would be called one after the other,
requesting X frames of audio data for a same audio timestamp, but it
happens that after changing the rate of the tempo unit, frames aren't
requested in order anymore.
It doesn't happen with default rate of 1.0.
Here's the output logging with default rate of 1.0 :
0 -> 1024 / 7785692434.000000 (0)
1 -> 1024 / 7785692434.000000 (0)
11 -> 1024 / 7785692434.000000 (0)
2 -> 1024 / 7785692434.000000 (0)
3 -> 1024 / 7785692434.000000 (0)
4 -> 1024 / 7785692434.000000 (0)
5 -> 1024 / 7785692434.000000 (0)
6 -> 1024 / 7785692434.000000 (0)
7 -> 1024 / 7785692434.000000 (0)
8 -> 1024 / 7785692434.000000 (0)
9 -> 1024 / 7785692434.000000 (0)
10 -> 1024 / 7785692434.000000 (0)
12 -> 1024 / 7785692434.000000 (0)
13 -> 1024 / 7785692434.000000 (0)
------------ advance to 1024 --------------
0 -> 1024 / 7785693458.000000 (0)
1 -> 1024 / 7785693458.000000 (0)
11 -> 1024 / 7785693458.000000 (0)
2 -> 1024 / 7785693458.000000 (0)
3 -> 1024 / 7785693458.000000 (0)
4 -> 1024 / 7785693458.000000 (0)
5 -> 1024 / 7785693458.000000 (0)
6 -> 1024 / 7785693458.000000 (0)
7 -> 1024 / 7785693458.000000 (0)
8 -> 1024 / 7785693458.000000 (0)
9 -> 1024 / 7785693458.000000 (0)
10 -> 1024 / 7785693458.000000 (0)
12 -> 1024 / 7785693458.000000 (0)
13 -> 1024 / 7785693458.000000 (0)
So everything is perfectly fine here, callback number 0, 1 and 11 are put
on one mixer, the rest on the other mixer (the large float on the right is
the callback audio timestamp sample time).
Now when I change to a higher rate :
0 -> 1156 / 7785775378.000000 (0)
1 -> 1156 / 7785775378.000000 (0)
11 -> 1156 / 7785775378.000000 (0)
------------ advance to 84100 --------------
0 -> 380 / 7785776534.000000 (0)
1 -> 380 / 7785776534.000000 (0)
11 -> 380 / 7785776534.000000 (0)
------------ advance to 84480 --------------
2 -> 1156 / 7785775378.000000 (0)
3 -> 1156 / 7785775378.000000 (0)
4 -> 1156 / 7785775378.000000 (0)
5 -> 1156 / 7785775378.000000 (0)
6 -> 1156 / 7785775378.000000 (0)
7 -> 1156 / 7785775378.000000 (0)
8 -> 1156 / 7785775378.000000 (0)
9 -> 1156 / 7785775378.000000 (0)
10 -> 1156 / 7785775378.000000 (0)
12 -> 1156 / 7785775378.000000 (0)
13 -> 1156 / 7785775378.000000 (0)
------------ advance to 85636 --------------
2 -> 380 / 7785776534.000000 (0)
3 -> 380 / 7785776534.000000 (0)
4 -> 380 / 7785776534.000000 (0)
5 -> 380 / 7785776534.000000 (0)
6 -> 380 / 7785776534.000000 (0)
7 -> 380 / 7785776534.000000 (0)
8 -> 380 / 7785776534.000000 (0)
9 -> 380 / 7785776534.000000 (0)
10 -> 380 / 7785776534.000000 (0)
12 -> 380 / 7785776534.000000 (0)
13 -> 380 / 7785776534.000000 (0)
Audio data is requested in a different order, twice for the first 3
callbacks, then for the rest.
Can anyone confirm what I observe is expected ?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden