Esp-idf: [TW#18633] a2dp_sink: Lots of dropped packages "BT: Pkt dropped"

[JLIspace]

Hello,

I'm currently trying to make a simple bluetooth sink setup. I'm using the a2dp_sink example with an added serial connection to a Arduino Nano. The nano processes all inputs and sends serial commands which then should trigger forward/backfard/play/pause. (The serial connection is based on the examples/peripherals/uart_async_rxtxtasks example) As I was not able to find a way without emulating a press and lift of a button I just did both after each other, like this:
//skip to the next track esp_avrc_ct_send_passthrough_cmd(0, ESP_AVRC_PT_CMD_FORWARD, ESP_AVRC_PT_CMD_STATE_PRESSED); esp_avrc_ct_send_passthrough_cmd(1, ESP_AVRC_PT_CMD_FORWARD, ESP_AVRC_PT_CMD_STATE_RELEASED);

This works pretty well. The reaction time is very low and the log looks something like this:
E (18339283) BT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA E (18339283) BT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA I (18339313) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 0 I (18339313) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 1

The only problem which I've encountered is that when I flood the ESP with the "skip-track-command" (which happens very easily as I'm using a rotary encoder as an input) it more and more outputs this error:
E (18377093) BT: Pkt dropped
These dropped packages are very noticeable and it even goes so far that it degrades sound quality over time, making it sound very "robotic" after just a few minutes.

I don't really know how to troubleshoot this as it's not really leading to any serious error.

(btw. the ESP is connected to an PCM5102A DAC for sound output)
I would be very grateful if someone could help me with this. :)

[pufstudio]

In your case I would queue received events from encoder/arduino and wait for a successful confirmation from the avrcp target after each sent command:

I (18339313) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 0 I (18339313) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 1

Then if there are still commands on the queue you repeat the process.
Also make sure you are not doing any serial logging per received sample as that can also cause packets to be dropped.

[Weijian-Espressif]

@blueMoodBHD Please help to view this issue.

[JLIspace]

@pufstudio Thanks for the idea. I had the updated program running for a few hours today, simulating button presses and flooding.
As it turns out, it's not dropping nearly as many packages now than without queuing. I guess the rest is actually caused by interference of other bluetooth/wifi devices? (It's dropping an average of 2~3 packages per song while my phone is sitting right next to the ESP)
Also I'm not logging anything per sample, but instead I'm using the ESP_LOG() functions for keeping track of what the ESP is doing atm. Do you think that this could be a problem?
I already tried moving everything but the bluetooth task to the other cpu core just to be sure that nothing is interfering with it.

I (39763) BT-CMD-QUEUE: Add AVRCP-CMD to Queue: (key_code: 0x4c # key_state: 0x0)->[0] I (39763) BT-CMD-QUEUE: Add AVRCP-CMD to Queue: (key_code: 0x4c # key_state: 0x1)->[1] E (39763) BT-CONTROL: Last Track. I (39773) BT-CMD-QUEUE: Sending AVRCP-CMD from Queue: (key_code: 0x4c # key_state: 0x0)<-[0] E (39773) BT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA I (39783) BT-CMD-QUEUE: Awaiting AVRCP-device rsp (processing_now = 1) I (39783) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 0 I (39813) BT-CMD-QUEUE: Sending AVRCP-CMD from Queue: (key_code: 0x4c # key_state: 0xx1)<-[1] E (39813) BT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA I (39823) BT-CMD-QUEUE: Awaiting AVRCP-device rsp (processing_now = 1) I (39823) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 1 I (339833) BT-CMD-QUEUE: Add AVRCP-CMD to Queue: (key_code: 0x4c # key_state: 0x0)->[2] I (39843) BT-CMD-QUEUE: Add AVRCP-CMD to Queue: (key_code: 0x4c # key_state: 0x1)->[3] E (39853) BT-CONTROL: Last Track. I (39863) BT-CMD-QUEUE: Sending AVRCP-CMD from Queue: (key_code: 0x4c # key_state: 0x0)<-[2] E (39863) BT: btc_avrc_ct_send_passthrough_cmd: ssuccesfully sent passthrough command to BTA I (39873) BT-CMD-QUEUE: Add AVRCP-CMD to Queue: (key_code: 0x4c # key_state: 0x0)->[4] I (39883) BT-CMD-QUEUE: Add AVRCP-CMD to Queue: (key_code: 0x4c # key_state: 0x1)->[5] E (39893) BT-CONTROL: Last Track. I (39873) BT-CMD-QUEUE: Awaiting AVRCP-device rsp (processing_now = 1) I (39893) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 0 I (39913) BT-CMD-QUEUE: Sending AVRCP-CMD from Queue: (key_code: 0x4c # key_state: 0x1)<-[3] E (39913) BT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA I (39923) BT-CMD-QUEUE: Awaiting AVRCP-device rsp (processing_now = 1) I (39923) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 1 I (39953) BT-CMD-QUEUE: Sending AVRCP-CMD from Queue: (key_code: 0x4c # key_state: 0x0)<-[4] E (39953) BT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA I (39963) BT-CMD-QUEUE: Awaiting AVRCP-device rsp (processing_now = 1) I (39973) BT_AV: AVRC passthrough rsp: key_code 0x4c, key_state 0 I (39983) BT-CMD-QUEUE: Sending AVRCP-CMD from Queue: (key_code: 0x4c # key_state: 0x1)<-[5] E (39983) BBT: btc_avrc_ct_send_passthrough_cmd: succesfully sent passthrough command to BTA I (39993) BT-CMD-QUEUE: Awaiting AVRCP-device rsp (processing_now = 1)

I guess that always sending both (press/lift) at once with the "priorities" 0 and 1 is not the way to go as the response actually takes a bit of time. My solution sends each avrcp-command individually with the same "priority" 0. If someone is facing the same problem I'd gladly offer my help :)
I know, that this might not be the best way, but it seems to work fine.

Thanks again for your answer 👍

[pufstudio]

Try increasing dma_buf_count in i2s setup routine.

[ESP32DE]

@JLIspace

first check the connection itself
then increasing the dma_buf_count in i2s setup routine
example:

.dma_buf_count = 128,                      // 32,        // 6,
.dma_buf_len = 64,                         // 60,              

@Weijian-Espressif
hope this helps.

best wishes
rudi ;-)

[JLIspace]

I previously tested it with higher values like 8/12 (6 was preset) without noticeable changes. That's why I haven't thought about this again.
But as you both suggested increasing this value further, I tried it today.

And it actually stopped (woohoo 😀) dropping packages (at least for the last ~50mins) with:
.dma_buf_count = 128, //6 .dma_buf_len = 64, //60
I searched a way to calculate these values based on my sample-/bitrate online, but it looks like everyone is just sugessting choosing a "high value" so I'm currently using 128 for both of them.
(Oh, and btw. it'll still drop packages when not using the queuing method. So that seems to be of importance, too.)

Thanks again for your efforts! I'm really really happy that it's working flawlessly now =)

[blueMoodBHD]

@JLIspace Is there any other problem now? if not ,can we close this issues?