ios5beta3 -- only first call after startup has audio -- subsequent calls no audio

[GoogleCodeExporter]

a) Problems seems to be ios5 specific -- ios5beta3 on ipad2
b) If idoubs2.0 is launched, the first call produces audio but subsequent calls 
have no audio. If idoubs2.0 is killed and restarted then again the first call 
works.

Original issue reported on code.google.com by saket...@gmail.com on 18 Jul 2011 at 12:34

[GoogleCodeExporter]

This is an issue introduced in iOS5Beta because all is working for iOS 4.x and 
below.

After you hang up the call, try to wait until both the audio producer and 
consumer destructors get called. It will take something like 32 seconds (SIP 
transaction timeout) and try again to see if it works.

Original comment by boss...@yahoo.fr on 18 Jul 2011 at 4:16

• Changed state: Accepted

[GoogleCodeExporter]

No difference even if I wait for 64 seconds. Only first call has audio and all 
subsequent calls fail to contain audio

Original comment by saket...@gmail.com on 18 Jul 2011 at 5:59

[GoogleCodeExporter]

Problem seems to exist with iosbeta4 as well. Could it be that for subsequent 
calls beyond the first call some new re-initialization of audio needs to occur?

Original comment by saket...@gmail.com on 5 Aug 2011 at 2:03

[GoogleCodeExporter]

Are you doing your tests on the simulator or real device or both?

Original comment by boss...@yahoo.fr on 6 Aug 2011 at 2:25

• Changed state: Started

[GoogleCodeExporter]

Should be fixed in the latest Doubango revision (tested on the simulator only).
You must update both Doubango and iDoubs source code.

Original comment by boss...@yahoo.fr on 6 Aug 2011 at 2:55

[GoogleCodeExporter]

iDoubs revision 170+
Doubango revision 635+

Original comment by boss...@yahoo.fr on 6 Aug 2011 at 6:24

[GoogleCodeExporter]

This issue was found on real device. I just looked at rev. 634, the change 
seems only affect simulator. For real iPAD, the value for 
kDoubangoAudioUnitSubType is still kAudioUnitSubType_VoiceProcessingIO. Does 
this mean the changes for this issue are all on iDoubs?

Original comment by xiangch...@gmail.com on 8 Aug 2011 at 5:46

[GoogleCodeExporter]

@xiangch...@gmail.com
This is why we asked if you had the same problem on a real device (see comment 
4).
In comment 5, it's said that it's tested on the simulator only because we don't 
have a device with iOS5 and didn't know if it's worth to update our devices.
Now that you confirm that it also happen on a real device we'll check.

BTW, you should use rev. 635 (Fix crash issue on iOS) of Doubango instead of 
634.

Original comment by boss...@yahoo.fr on 8 Aug 2011 at 12:10

[GoogleCodeExporter]

Let me explain the issue.

The good news:
In Doubango r646-, when the user hang up the call we just uninitialize the 
audioUnit instance using "AudioUnitUninitialize". Looks like it's not enough 
and we must dispose the instance using "AudioComponentInstanceDispose".
I guess all VoIP application you have tested use this function in order to 
destroy the instance and this is why they are working on iOS 5 devices while 
iDoubs is not working.
The good news is that this issue is fixed in Doubango r647+. So, now you will 
have audio on the second call.

The bad news:
The bad news is that there is an issue in iOS 5 OS itself. To be short: The 
issue is that you cannot create more than one instance of audioUnit using Voice 
processing subtype.
I have added a ticket on the Apple's developer forum: 
https://devforums.apple.com/thread/118595
This is very annoying issue because it means that if you put the current call 
on hold and take (ore make)a second call without stopping the first call then, 
you will not have audio on the second call.
Please note that this issue only happens with 
"kAudioUnitSubType_VoiceProcessingIO" subtype. So, as a workaround for 
multiline calls you can use "kAudioUnitSubType_RemoteIO".
This issue is too evident and for sure it will be fixed by Apple before the 
final release.

Original comment by boss...@yahoo.fr on 19 Aug 2011 at 10:54

[GoogleCodeExporter]

I have worked out workaround for this that is to make the audio unit static. 
Attached you can find the file I modified for reference. 
I did not try more with multiple call scenario, but I think make the audio unit 
singleton with proper handover by each audio session should handle this. 

Original comment by erguan...@gmail.com on 20 Aug 2011 at 3:34

Attachments:

• tdav_audiounit.c
• tdav_consumer_audiounit.c
• tdav_producer_audiounit.c

[GoogleCodeExporter]

The problem with this workaround is that 
- when you have more than one session with different configuration (sample 
rate, ptime, channels, bits per sample, ...) it won't work
- if you stop one session then, all others will be stopped as you're sharing 
the instance. This could be fixed by modifying your code.

Original comment by boss...@yahoo.fr on 20 Aug 2011 at 8:00

[GoogleCodeExporter]

Can you share with use the apple bug number?
This bug is really impacts a lot on application.

Original comment by erguan...@gmail.com on 23 Aug 2011 at 7:55

[GoogleCodeExporter]

https://devforums.apple.com/thread/118595
iOS5 has a dedicated section.

Original comment by boss...@yahoo.fr on 23 Aug 2011 at 5:34

[GoogleCodeExporter]

New link: https://devforums.apple.com/thread/121519

Original comment by boss...@yahoo.fr on 5 Sep 2011 at 9:54

[GoogleCodeExporter]

had anybody use idoubs for ios 5

Original comment by vi...@whiteovaltechnologies.com on 17 Jan 2013 at 10:37

[GoogleCodeExporter]

idoubs last version work's perfect on IOS 5 this Issue need to close.

Original comment by vanea.voda@gmail.com on 6 Feb 2013 at 5:14