Repeated audio route change causes left and right headphones to get out of sync

[rweichler]

If you repeatedly take your headphones in and out really fast, the sound that is playing either becomes out of sync in the left and right headphones (usually), or the sound becomes extremely choppy (sometimes).

I noticed that you do a lot of stuff when the audio route changes so I commented that part out and it ended up fixing both symptoms of the issue for me. I'm going to investigate further.

What fixes it:

• Commenting out [sm checkSessionProperties]

What doesn't fix it:

• Dispatching [sm checkSessionProperties] to another queue (WEIRD!)
• Commenting out all of the NSLogs
• Commenting out the CheckErrors
• Commenting out [self checkAudioSource] in checkSessionProperties

SO I think the problem is all of the calls to AudioSessionGetProperty when the audioRoute changes. What I think you should ACTUALLY do is have custom getters for numInputChannels, numOutputChannels, etc. And when the audio route changes, set all of them to -1. When the getter is called, and if they are set to -1, THEN it calls AudioSessionGetProperty.

edit: Nevermind, I tried implementing the above and it didn't fix the problem. I'm stumped.

[alexbw]

This is a really great bug find, thanks! The checkSessionProperties is necessary for apps that really need to know what the sample rate is, or more importantly, what the number of channels currently is.

A couple other things you might try — 

• You can completely pause playback when the audio route changes. When headphones are being unplugged or plugged, an extra 500ms of silence won't be a big deal.
• What queues have you dispatched checkSessionProperties to? Both main thread and background thread? If you haven't tried both, it's possible one might work. OSX threading and audio rarely walk peacefully together...

[rweichler]

I tried the main thread and a custom thread I created via dispatch_queue_create. Neither worked. :/

[alexbw]

Bummer. I might then try wrapping the call with [pause] and [play], or temporarily turning off the OutputBlock.

[rweichler]

I figured out the problem. It's an extension of #58, the samplingrate/numchannels was out of sync between the AudioManager and AudioFileReader. Putting this code in AudioFileReader.mm fixed it:

-(UInt32)numChannels
{
    return Novocaine.audioManager.numOutputChannels;
}

-(float)samplingRate
{
    return Novocaine.audioManager.samplingRate;
}

obviously this is a horrible solution, but yeah :P

EDIT

Oh man, I just realized I inadvertently fixed #58 in the code I'm using, and instead of it crashing this issue occurs. I'll upload what I have right now in a gist, just a sec.

[rweichler]

https://gist.github.com/rweichler/8341169

[alexbw]

Can you make this into a pull request?

On Thu, Jan 9, 2014 at 3:16 PM, Reed Weichler notifications@github.comwrote:

https://gist.github.com/rweichler/8341169

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

[rweichler]

I don't think it would be a good idea, the code is kind of shitty TBH, and I added some specific functionality for the application I'm using that would be confusing for other people.

[rweichler]

I think what I did to fix it was just running the seeking/loading/buffering the audio in another thread.

[alexbw]

Okee doke. Well, if you ever come up with an in-line solution where the
AudioFileReader manages threads, that'd be a pretty sick addition.

On Thu, Jan 9, 2014 at 3:19 PM, Reed Weichler notifications@github.comwrote:

I think what I did to fix it was just running the
seeking/loading/buffering the audio in another thread.

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

[rweichler]

Will do :D

[rweichler]

This is still a bug, lol

[samiarshad]

Has anyone solved the issue??

[rweichler]

nope.