- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
With bsa stack, the discovery results doesn't show if the BT headset supports 16Khz sampling rate(HFP version >= 1.6 uses wide band audio) or 8Khz sampling rate .
I have two headsets,one with HFP version 1.5 (Plantronics discovery 975) and HFP v1.6 (Plantronics Explorer E50).
Based on above models ,Plantronics E50 should be able to support 16Khz audio,but i could hear audio as choppy if the app_ag_register is not set with with BTA_AG_FEAT_CODEC (i.e 0x00000200 /* Codec Negotiation */). And in this case i could hear 8Khz audio clearly. It looks like the stack is enabling wide band audio based on BTA_AG_FEAT_CODEC macro.
Is there any settings in bsa_server.txt which makes the code negotiation happen automatically ?Or do i need to get that info from scan results and set any params?
In the BT discovery results i dont see any info wrt HFP version or sampling rate supported by BT headset. Below is a sample discovery result for Plantronis E50.Any pointers would be appreciated.
Discovery result
Name:PLT_E50
ClassOfDevice:24:04:04 => Audio/Video
Services:0x00000000 ()
Rssi:-42
DeviceType:Unknown InquiryType:Unknown AddressType:Public
Extended Information:
FullName: PLT_E50
Complete Service [UUID16]:
0x1108 [Headset]
0x111E [Handsfree]
0x110B [Audio Sink]
0x110E [A/V Remote Control]
0x1101 [Serial Port]
Discovery complete
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can get the headset HFP version supported during codec negotiation in function bta_ag_create_sco using the flag p_scb->peer_version.If the peer_version is HFP ver >= 1.6, then the codec used is mSBC else its CVSD. Audio layer would send the appropriate audio format based on this flag .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello:
Would you please check if you have enabled the macro in the bsa_server.txt ?
BTM_WBS_INCLUDED = TRUE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Zhengbao_Zhang for the response.
Yes i have enabled the flag BTM_WBS_INCLUDED. And my SCO route is over PCM.
# Voice over HCI
BTM_SCO_HCI_INCLUDED = FALSE
BTM_WBS_INCLUDED = TRUE
-Vinod
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello:
So What is the performance for BTA_AG_FEAT_CODEC enabled?
Are earphones that support 8k sample rate getting chopped when doing SCO communication?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If i include the macro BSA_AG_FEAT_CODEC in APP_AG_FEATURES(Called in app_ag_register) then i could hear 16Khz audio clearly but 8Khz is little robotic. And if i dont have the macro BSA_AG_FEAT_CODEC then 8Khz is clear but 16Khz audio becomes robotic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With BSA_AG_FEAT_CODEC set to true and if 8Khz headset is connected ,then the audio(8Khz audio played) is clear and if i use 16Khz headset then the audio (16Khz audio played)is clear but 8Khz audio is choppy.
Some headsets supports both 16 and 8Khz . Iam trying to run aplay with both 16Khz and 8Khz audio sample and if the headset supports HFP >=1.6 then it would support wide band audio.so if i play 8Khz audio it should work clearly in 16Khz supported headset right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello:
For SCO role we should choose one CODEC info like 16k or 8k in the stage of the link creation according to the negotiation from the two sides, if two sides agree to use 16Khz rate, we should use 16khz always, do not use an 8Khz source to play, it will not change the sample rate automatically.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Zhengbao_Zhang .
Since i use i.MX processor, between i.MX and radio chip the audio format should be constant i.e either set to 8Khz or 16Khz .So the flag BSA_AG_FEAT_CODEC would determine the audio format between iMX and Radio chip i.e if enabled the audio format is 16KHz else 8Khz.
Between Radio and the headset the audio format is completely different. if for ex we set 8Khz as the audio format between i.MX and Radio chip and if the headset is of 16Khz then the radio chip up-samples it to 16Khz for format between radio and headset.Up-sampling must be automatic.
So i need to know if the headset supports 16Khz(wide band audio) or 8Khz.I dont get this info from discovery results. Based on this info i need to set the default audio format.Not sure if the headset sampling rate details would be available once we do Audio Gateway connect as i dont see any structure which gets this info.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hello:
I think we need to enable all the debug logs of DG from bsa_server or APP_DG, then try to find the sample rate info from the logs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another suggestion: app_dg has open source code like app_ag_register , you can find the code flow different between 16k and 8k earphones, then you can write a flag to a system node where other applications can visit. Then you can choose 8k or 16k sources automatically according to the flags.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can get the headset HFP version supported during codec negotiation in function bta_ag_create_sco using the flag p_scb->peer_version.If the peer_version is HFP ver >= 1.6, then the codec used is mSBC else its CVSD. Audio layer would send the appropriate audio format based on this flag .