1.5.3 regression? when changing sample rate

The following is a contrived example based on a bug I started to see after upgrading from 1.5.2

- (void)viewDidLoad {
  [super viewDidLoad];
  // Do any additional setup after loading the view, typically from a nib.

  AudioStreamBasicDescription asbd = AEAudioStreamBasicDescriptionNonInterleavedFloatStereo;

  _audioController = [[AEAudioController alloc] initWithAudioDescription:asbd inputEnabled:YES];

  AEPlaythroughChannel *playthroughChannel = [[AEPlaythroughChannel alloc] init];
  [_audioController addInputReceiver:playthroughChannel];
  [_audioController addChannels:@[playthroughChannel]];

  NSError *error = nil;

  [_audioController start:&error];
}

- (void)setSampleRate:(float)sampleRate
{
  AudioStreamBasicDescription asbd = _audioController.audioDescription;
  asbd.mSampleRate = sampleRate;

  NSError *error = nil;
  [_audioController setAudioDescription:asbd error:&error];
}

- (IBAction)FourOneTouch:(id)sender {
  [self setSampleRate:44100];
}

- (IBAction)EightTouch:(id)sender {
  [self setSampleRate:48000];
}

Link FourOneTouch and EightTouch to two buttons.

On a 6S Plus with no headphones plugged in, alternately tap the buttons and after a few taps, I experience the crash as per the attached stack at the highlighted line.

Comments

  • Great catch, Ed, and thanks for the great error report. You're absolutely right, missed this one =(

    Fixed, and I think it's important enough to make it a new update, so I did that: version 1.5.4.

  • Cheers Michael, that's fixed it :)

  • edited November 2015

    Ergh, actually it's fixed the original issue, but now I'm seeing a different issue! In fact, two issues.

    In testing I noticed that every so often there would be a thirty second delay when switching sample rate. It would be accompanied in the log by this (see the 30s between 19:11:40 and 19:12:10):

    2015-11-29 19:11:40.497 SRTest[524:144719] TAAE: Stopping Engine 2015-11-29 19:12:10.507 SRTest[524:144719] 19:12:10.506 WARNING: [0x19f837000] 1251: AURemoteIO::Stop: error 0x10004003 calling TerminateOwnIOThread 2015-11-29 19:12:10.508 SRTest[524:145245] TAAE: Warning: render took too long (30.011108s, 1125416.57% of budget). Expect glitches. 2015-11-29 19:12:10.508 SRTest[524:145245] 19:12:10.508 ERROR: [AURemoteIO::IOThread] >aurioc> 1503: [email protected]: IOThread exiting with error 0x10004002 2015-11-29 19:12:10.879 SRTest[524:144719] TAAE: Audio session initialized (input available, audio route 'iPhone Microphone and Speaker') HW samplerate: 48000 2015-11-29 19:12:10.891 SRTest[524:144719] TAAE: Input status updated (1 channel, non-interleaved, with converter)

    The delay is always very close to 30 seconds.

    The issue doesn't happen every time, sometimes I can go for 20-30 seconds pressing FourOneTouch and then EightTouch alternately and then it will suddenly happen.

    I tried to see what I could do to exacerbate the problem. I didn't find a way to make it any more repeatable. However, whilst investigating I found the second issue. I added a further 99 channels to the existing playthroughChannel to take it to the AEAudioController limit of 100 channels.

    <

    pre lang="objc">
    for (int i=0; i<99; i++) {
    AEBlockChannel *channel = [AEBlockChannel channelWithBlock:^(const AudioTimeStamp *time, UInt32 frames, AudioBufferList *audio) {}];

    [_audioController addChannels:@[channel]];
    }

    In-so-doing, each time the audio engine switches sample rate, I get a raft of:

    2015-11-29 19:11:06.191 SRTest[524:144719] AEAudioController.m:3602: AudioUnitSetParameter(kMultiChannelMixerParam_Pan): -10867

    Switching back to 1.5.2, I still get the kMultiChannelMixerParam_Pan errors, but I couldn't re-create the 30s pause in the fairly long time a spent happily pressing one button and then the other and back and again...

    I can also say that removing the AEPlaythroughChannel and just having the AEBlockChannel(s) makes no difference. You can still intermittently experience the 30s delay in 1.5.4.

    Googling 'TerminateOwnIOThread', it seems other have encountered this, too, although without satisfactory resolution IMO.

    If you pause the app whilst it's in it's 30 second wait, you'll see that it is sat on the line:

    AECheckOSStatus(AUGraphStop(_audioGraph), "AUGraphStop");

    If I think of any other way to narrow down the bug, I'll add further comments.

  • Ouch! You're right, I can reproduce that too. I did a binary search through the commits, and it's this commit. No idea why, but I'll add a workaround by maintaining AEAudioController's own copy of the kAudioUnitProperty_IsInterAppConnected state.

  • I'd like to say that's fixed it, but I'll give it a bit more testing first :) Thanks for the speedy response, though.

Sign In or Register to comment.