here is 2 question for this example. (v2.9.0)
as i looking for this example, there are some limitations like belows.
One BIG, one of the two BIS streams (selectable).
then i have a question, is it a hardware limitation? or just fw limitation?
and this example used a 16bit resolution.
could i changed that bit resolution to 24bit?
When i changed the maximum SDU size on the SOURCE side to 100 bytes and set MIN and MAX values on the SINK side to 100 bytes, then it works.
Is this a limited value by any chance?
Apologies for the continued questions.
I am currently using the bap_broadcast_sink example to verify the reception of a 48kHz, stereo, 120-byte octets audio signal from a Galaxy device. However, I’m facing an issue where data for one of the stereo channels is not being received.
Is there any configuration or code modification that could help resolve this issue?
The environment is as follows:
Broadcaster: Galaxy S23 Ultra
BIG configuration: 48kHz stereo, 120-byte octets, not encrypted, 1 frame per SDU
static const struct bt_audio_codec_cap codec_cap = BT_AUDIO_CODEC_CAP_LC3(
BT_AUDIO_CODEC_CAP_FREQ_24KHZ | BT_AUDIO_CODEC_CAP_FREQ_48KHZ | BT_AUDIO_CODEC_CAP_FREQ_96KHZ,
BT_AUDIO_CODEC_CAP_DURATION_10 | BT_AUDIO_CODEC_CAP_DURATION_PREFER_10,
BT_AUDIO_CODEC_CAP_CHAN_COUNT_SUPPORT(2, 3), 100u, 120u,
CONFIG_MAX_CODEC_FRAMES_PER_SDU,
(BT_AUDIO_CONTEXT_TYPE_ANY));
When checking the ISO layer for the stereo channels,
I found that for one channel, all hdr->slen values are 0x4000.
This indicates that only invalid-flagged packets with data_len of 0 are being received.
Here are some notable findings:
The L/R packets arrive sequentially in a pattern of n packets for the L channel and k packets for the R channel (n, k > 2).
The timestamp interval between packets received at once is approximately 1ms.
The iso_info(buf)->ts difference among the packets received together is about 10ms.
Hello,
heavyjo said:Apologies for the continued questions.
That's alright. I also want to apologize for the delay, and thank you for your patience on getting your questions answered.
I'll do my best to address all of them before I leave work tomorrow.
heavyjo said:However, I’m facing an issue where data for one of the stereo channels is not being received.
heavyjo said:CONFIG_TARGET_BROADCAST_CHANNEL=3
My understanding is that the bap broadcast sink sample will only sync to one channel, which is configured by CONFIG_TARGET_BROADCAST_CHANNEL. I am fairly certain that when its value is 3, the target channel is the right channel.
heavyjo said:1. The L/R packets arrive sequentially in a pattern of n packets for the L channel and k packets for the R channel (n, k > 2).
This finding does challenged my understanding, though. I need to investigate this closely.
heavyjo said:and i want to know that nrf5340_audio_dk could works on 96khz stereo environment
LC3 does not support 96kHz sample rate. 96kHz is a supported feature in LC3 Plus, but LC3 Plus is not supported in nRF Connect SDK.
I will address the following tomorrow:
heavyjo said:On the nRF5340 Audio DK board, are there any additional settings that need to be configured in the bap_broadcast_sink example to support 48kHz stereo (for the previously mentioned Galaxy Auracast)? Or should I be looking into something other than configuration settings?
heavyjo said:When i changed the maximum SDU size on the SOURCE side to 100 bytes and set MIN and MAX values on the SINK side to 100 bytes, then it works.
Is this a limited value by any chance?
heavyjo said:2. The timestamp interval between packets received at once is approximately 1ms.
3. The
iso_info(buf)->tsdifference among the packets received together is about 10ms.
Best regards,
Maria
heavyjo said:On the nRF5340 Audio DK board, are there any additional settings that need to be configured in the bap_broadcast_sink example to support 48kHz stereo (for the previously mentioned Galaxy Auracast)? Or should I be looking into something other than configuration settings?
I can see that you have configured support for 48kHz sampling rate and multiple channels in your last reply:
heavyjo said:static const struct bt_audio_codec_cap codec_cap = BT_AUDIO_CODEC_CAP_LC3( BT_AUDIO_CODEC_CAP_FREQ_24KHZ | BT_AUDIO_CODEC_CAP_FREQ_48KHZ | BT_AUDIO_CODEC_CAP_FREQ_96KHZ, BT_AUDIO_CODEC_CAP_DURATION_10 | BT_AUDIO_CODEC_CAP_DURATION_PREFER_10, BT_AUDIO_CODEC_CAP_CHAN_COUNT_SUPPORT(2, 3), 100u, 120u, CONFIG_MAX_CODEC_FRAMES_PER_SDU, (BT_AUDIO_CONTEXT_TYPE_ANY));
Please note that the LC3 codec does not support 96kHz sampling rate (I also pointed this out in my previous reply).
Context type should be conversational or media because those are the audio types the LC3 codec are meant for.
Maria Gilje said:My understanding is that the bap broadcast sink sample will only sync to one channel, which is configured by CONFIG_TARGET_BROADCAST_CHANNEL. I am fairly certain that when its value is 3, the target channel is the right channel.
I looked deeper into this, and I realize that a sink can switch between channels when the the BISes are in the same BIG. Are you able to receive the data when only syncing to one stream/channel at a time?
heavyjo said:When i changed the maximum SDU size on the SOURCE side to 100 bytes and set MIN and MAX values on the SINK side to 100 bytes, then it works.
Is this a limited value by any chance?
In "Introducing Bluetooth LE Audio" by Nick Hunn (2nd edition), there is an example stream configuration for high reliability audio which is 100 octets (Table 5.6).
heavyjo said:When checking the ISO layer for the stereo channels,
I found that for one channel, allhdr->slenvalues are0x4000.
This indicates that only invalid-flagged packets withdata_lenof 0 are being received.
Have you confirmed that the phone is transmitting valid packets?
heavyjo said:Here are some notable findings:
The L/R packets arrive sequentially in a pattern of n packets for the L channel and k packets for the R channel (n, k > 2).
The timestamp interval between packets received at once is approximately 1ms.
The
iso_info(buf)->tsdifference among the packets received together is about 10ms.
I was not able to look closer into these findings today. I'll do so as soon as I can.
Best regards,
Maria