about bap_broadcast_sink example

[heavyjo]

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? 

[Maria Gilje]

Hello,

I will start with a slight clarification on the sample: the bap_broadcast_sink sample (zephyr/samples/bluetooth/bap_broadcast_sink) is not the same as the nRF5340 Aduio: Broadcast sink application (nrf/applications/nrf5340_audio/broadcast_sink).

and this example used a 16bit resolution.
could i changed that bit resolution to 24bit? 

The answer to this question may differ depending on which sample you are using, so please clarify if you mean to use the nRF5340 Audio application or the Broadcast Audio Sink Zephyr sample.

• One BIG, one of the two BIS streams (selectable).

then i have a question, is it a hardware limitation? or just fw limitation?

I am fairly certain that this is an application limitation, so I will double check this and reply properly when you clarify which sample you are asking about.

Best regards,

Maria

[heavyjo]

The Galaxy S23 Ultra Auracast broadcast, based on data analysis, uses a 40ms Presentation Delay (PD), LC3 codec, and two streams. From the Codec_Specific_Configuration[0], we can determine that it operates at 48kHz with a 10ms frame duration, but the channel information is not explicitly stated. However, the channel information is present within the stream details.

Using this Auracast broadcast, I configured the SINK with the following settings:
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_CHAN_COUNT_SUPPORT(2),
60u, 120u, // (1) BT_AUDIO_CODEC_CAP_DURATION_10
CONFIG_MAX_CODEC_FRAMES_PER_SDU,
(BT_AUDIO_CONTEXT_TYPE_MEDIA | BT_AUDIO_CONTEXT_TYPE_CONVERSATIONAL));

With this configuration, I attempted to receive the SINK audio through the example code. However, the RIGHT channel is not received at all, while the LEFT channel stream is received to some extent.

It does not appear to be a decoding issue, as removing the decoding process still does not resolve the problem—the right channel is simply not received.

Below is the reception log:
Stream 0x20003868: received 134000 total ISO packets: Valid 0 | Error 134000 | Loss 0
Stream 0x20001470: received 140000 total ISO packets: Valid 70767 | Error 69233 | Loss 0

[heavyjo]

and i want to know that nrf5340_audio_dk could works on 96khz stereo environment

[heavyjo]

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]

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:

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).

2. The timestamp interval between packets received at once is approximately 1ms.

3. The iso_info(buf)->ts difference among the packets received together is about 10ms.

[Maria Gilje]

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)->ts difference among the packets received together is about 10ms.

Best regards,

Maria

[Maria Gilje]

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, all hdr->slen values are 0x4000.
This indicates that only invalid-flagged packets with data_len of 0 are being received.

Have you confirmed that the phone is transmitting valid packets?

heavyjo said:

Here are some notable findings:

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).

2. The timestamp interval between packets received at once is approximately 1ms.

3. The iso_info(buf)->ts difference 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