a2dp sink and WiFi coexistence
Posted: Mon Jul 23, 2018 3:44 am
Hello,
I would like to use a esp32 to receive an audio stream using the a2dp sink profile on the Bluetooth radio and at the same time send a lower rate (~20kbit/s) data stream on the WiFi radio. My starting point was using the a2dp sink example with a periodic esp-Now transmission (20 bytes every 10ms). I tested each independently with good results. Audio quality was good and the esp-Now transmission latency was ~2ms. When tested together the esp-Now transmission was being blocked by a2dp. With an active a2dp stream the send call back latency when up to ~45ms even though the esp-Now receiver received the message within ~5ms of transmission (measured with logic analyzer). If I decrease the transmission rate to 50ms and the payload to ~5 bytes I could get reliable performance (data rate too low for my application). I also tried slower update rates with larger payloads but I could not get anywhere near 20kbit/s without blocking. At this time I learned that the radios are not independent. I played with the coexistence preferences to little benefit.
I suspected that due to esp-Now's insertion into lower levels of the WiFi stack the coexistence software may not be implemented for it yet. Does anyone know it this is true? Will it be implemented in the future?
So I moved to using sockets and TCP to transmit my WiFi data. This met with better results, however now the a2dp stream has audible discontinuities (from late or dropped data?). I attempted to alleviate this by changing coexistence priorities and the core the WiFi and Bluetooth run on, all to little benefit. Now that I have gained some familiarity with the esp-idf and understand that the radios are not independent, Am I expecting too much from one esp32 module? Should I add an independent radio for the ~20kbit/s stream. Any tips on coexistence between the radios? Do we expect improvements to software coexistence or is it already optimized? Does a a2dp stream keep the radio busy most of the time. The coexistence library is quite opaque to me. Is there anyway of timing the WiFi transmissions more intelligently with respect to Bluetooth transmissions? Sorry for dumping so many questions. Any input is much appreciated
Thank you,
Bryan
I am using esp-idf 3.2-dev
I would like to use a esp32 to receive an audio stream using the a2dp sink profile on the Bluetooth radio and at the same time send a lower rate (~20kbit/s) data stream on the WiFi radio. My starting point was using the a2dp sink example with a periodic esp-Now transmission (20 bytes every 10ms). I tested each independently with good results. Audio quality was good and the esp-Now transmission latency was ~2ms. When tested together the esp-Now transmission was being blocked by a2dp. With an active a2dp stream the send call back latency when up to ~45ms even though the esp-Now receiver received the message within ~5ms of transmission (measured with logic analyzer). If I decrease the transmission rate to 50ms and the payload to ~5 bytes I could get reliable performance (data rate too low for my application). I also tried slower update rates with larger payloads but I could not get anywhere near 20kbit/s without blocking. At this time I learned that the radios are not independent. I played with the coexistence preferences to little benefit.
I suspected that due to esp-Now's insertion into lower levels of the WiFi stack the coexistence software may not be implemented for it yet. Does anyone know it this is true? Will it be implemented in the future?
So I moved to using sockets and TCP to transmit my WiFi data. This met with better results, however now the a2dp stream has audible discontinuities (from late or dropped data?). I attempted to alleviate this by changing coexistence priorities and the core the WiFi and Bluetooth run on, all to little benefit. Now that I have gained some familiarity with the esp-idf and understand that the radios are not independent, Am I expecting too much from one esp32 module? Should I add an independent radio for the ~20kbit/s stream. Any tips on coexistence between the radios? Do we expect improvements to software coexistence or is it already optimized? Does a a2dp stream keep the radio busy most of the time. The coexistence library is quite opaque to me. Is there anyway of timing the WiFi transmissions more intelligently with respect to Bluetooth transmissions? Sorry for dumping so many questions. Any input is much appreciated
Thank you,
Bryan
I am using esp-idf 3.2-dev