Hello Ming,
thank you for your reply.
This gives us some clues. I replaced coreaudio_dev.c with iphone_dev.c from the Siphon project to see if it had the same issue. It had some other issues, but bluetooth is actually working fine! (there is no bluetooth-support in iphone_dev.c, all bluetooth-handling is performed directly from the app). I'm looking further into this (we'd prefer to use a patched coreaudio_dev.c), but tell us if you've got some more ideas.
Best regards,
Magnus.
On 20. okt. 2010, at 16.58, Ming wrote:
> Hi Magnus and Even,
>
> The coreaudio_dev was implemented and tested with the old SDK and iOS
> which seems to behave a bit differently now. According to the old
> documentation and sample code, CMIIW, when there is an audio route
> change, we need to dispose and recreate the audio unit since the
> device's sample rate may change. However, it seems no longer necessary
> so you're spot on with your patch on propListener as mentioned in (2).
>
> Unfortunately, I cannot offer much help for (3) since I can't
> reproduce it here. I am not sure what may cause the sudden audio
> category change, perhaps a stack trace may tell you what triggered it?
> If you can have access to devices with iOS < 4, then you may want to
> test it there, just to make sure that it is not iOS4 BG feature
> specific problem. Just my two cents.
>
> Best regards,
> Ming
>
> On Wed, Oct 20, 2010 at 9:17 PM, Even Andr? Fiskvik <eaf at oyatel.com> wrote:
>> Could someone (Benny, Samuel?) please confirm wether they have gotten
>> Bluetooth to actually work fine using the coreaudio_dev.c on iPhone?
>> We'd hate spending hours of "fixing" the coreaudio_dev.c if it's something
>> that isn't broken, but rather an error in how it is used.
>> Best regards,
>> Even Andr?
>> On 19. okt. 2010, at 16.40, Magnus Gal?en wrote:
>>
>> I'm trying to implement support for bluetooth on IPhone. Although pjmedia
>> has support for bluetooth, it seems to me it may not have been tested? After
>> a lot of testing I've found out the following:
>> 1. Initializing bluetooth via pjsip
>> To initialize bluetooth, I run the following code while in call
>> (AudioCategory is AVAudioSessionCategoryPlayAndRecord):
>> [snippet#1]
>> pjmedia_aud_dev_route route = PJMEDIA_AUD_DEV_ROUTE_BLUETOOTH;
>> pjsua_snd_set_setting(PJMEDIA_AUD_DEV_CAP_INPUT_ROUTE, &route, PJ_TRUE);
>> This triggers the function ca_stream_set_cap in 'coreaudio_dev.c'
>> [snippet#2]
>> ostatus = AudioSessionSetProperty (
>> kAudioSessionProperty_OverrideCategoryEnableBluetoothInput,
>> sizeof(btooth), &btooth);
>> Where 'btooth' equals 1. The request fails. 'ostatus'
>> returns kAudioSessionUnsupportedPropertyError ("The audio session property
>> is not supported.").
>>
>> 2. Initializing bluetooth from outside pjsip
>> To test further, I removed snippet#2 (AudioSessionSetProperty) from
>> 'coreaudio_dev.c' (so it only sets 'strm->param.input_route' and
>> returns PJ_SUCCESS). Then I included the same code in the app after calling
>> snippet#1, so bluetooth-support was turned on in the application, and not in
>> pjsip. Now the call to AudioSessionSetProperty succeeds, but another error
>> occurs.
>> kAudioSessionProperty_AudioRouteChange is triggered which calls propListener
>> (in coreaudio_dev.c). propListener stops the stream and creates and sets up
>> a new audio unit. This includes resetting the AudioCategory to PlayAndRecord
>> which also resets the audio route from HeadsetBT to ReceiverAndMicrophone
>> (turns off bluetooth!).
>> The user experiences this as follows: The bluetooth headphone device beeps
>> to indicate it is turned on, followed by 1-2 seconds of sound, then it is
>> turned off. To go around this issue, I simply added "return;" in
>> propListener before the call to 'ca_stream_stop', to prevent it from
>> resetting the stream.
>>
>> 3. Initializing bluetooth outside pjsip with modified propListener
>> This works in 50% of the cases. When successful, AudioSessionSetProperty
>> returns kAudioSessionNoError, and kAudioSessionProperty_AudioRoute is
>> correctly set to 'HeadsetBT'. Audio is working fine both ways.
>> However, it fails seemingly randomly. Sometimes five times in a row, and
>> sometimes it works five times in a row, with no obvious pattern. What
>> happens is AudioCategory is set to <null>, which again triggers
>> kAudioSessionProperty_AudioRouteChange with routeChangeReason
>> CategoryChange. After the callback has returned, the AudioCategory has
>> suddenly changed to AVAudioSessionCategorySoloAmbient.
>> Resetting or changing category before it changes to
>> AVAudioSessionCategorySoloAmbient does not work. No audio is working. There
>> are no clues on the Apple Developer forum to similar errors. Reinitializing
>> the AudioSession does not work. Changing category or enabling bluetooth
>> after this moment returns success in code, but no audio is playing on any
>> device. However, hanging up the call and starting a new call, seems to reset
>> the audio-device, and audio is working again.
>> I'm pulling my hair out on this. Has anyone got a clue to *anything* of what
>> is going on? All help is appreciated.
>>
>> Thanks,
>> Magnus Gal?en.
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
