BuddyCasino wrote:Ah, you mean bluetooth. Didn't test that a lot, ESP-IDF does most of the work anyway so I'm not sure I can fix that. The "xBtuQueue Failed" is triggered in btu_task.c, which is Broadcom code. Its possible that we don't consume the PCM buffer fast enough, but I have no idea really.
Hi,
i tried to fix this problem, where audio stop working after a while, or is continuously interrupted while playing, with BT Audio.
I finally found a workarround by adding a delay in the bt task in esp-idf. It's not the most beautiful patch i have ever written, but it does the job, at least in my tests.
Code: Select all
diff --git a/components/bt/bluedroid/btc/profile/std/a2dp/btc_media_task.c b/components/bt/bluedroid/btc/profile/std/a2dp/btc_media_task.c
index 8610ef8..d8dd600 100644
--- a/components/bt/bluedroid/btc/profile/std/a2dp/btc_media_task.c
+++ b/components/bt/bluedroid/btc/profile/std/a2dp/btc_media_task.c
@@ -264,6 +264,7 @@ static void btc_media_task_handler(void *arg)
btc_media_ctrl_handler(e);
osi_free(e);
}
+ vTaskDelay(1);
}
}
It's like if bluetooth task handling a2dp profile was always reading the receiving queue and no other tasks were scheduled. Note that it works well with the a2dp example of esp-idf sdk, and it's the implementation of ad2p in esp32 webradio which is not working
Maybe the task feeding audio in esp webradio has the same proprity and is never schedule. IIRC correctly the BT audio task has a priority 3.
It may help others people.
Regards,
Nicolas