Closed martinroger closed 1 month ago
I think the application works as designed: I am just passing all the events that are received to the callback and I guess that they have implemented it that way to make sure that no events gets lost.
Usually this is not a problem because the events are used to update the information locally.
If your application logic relies on some unique events, you will need to implement your own logic
Problem Description
When running any of the basic examples of the A2DP Sink that queries metada update notifications, I noticed that sometimes - and mostly when - doing a track change either directly on the TG or via the CT (a2dp_sink.next()), I would get double and even triple notifications with the new song metadata in a short timeframe, as if _av_newtrack() got called twice by two different places (I couldn't find evidence of that, even going to DEBUG level ESP messages).
The expected behaviour would be to get a single response metadata notification when changing tracks either via the CT, or directly on the TG (e.g. pressing the next button on the phone).
The current work-around is to implement some basic data-debouncing and compares, since these 2-3 responses are usually fired very rapidly together.
I noticed that sometimes between those duplicate metadata responses, the track duration attribute isn't updated on the first 1-2 responses but is updated on the third. This makes me think that this may be also possibly related to the type of TG device responding. Could this be just a quirk of how AVRCP is sometimes implemented in the wild and not an actual issue ?
Device Description
NodeMCU 32S, which is based on a WROOM-32. I also observed the same behaviour on a Sparkfun Thing Plus which I believe to run the WROOM-32E. It is connected to an external UDA1334A DAC, but it also shows the issue with the i2s pointing to the internal DAC.
Sketch
Other Steps to Reproduce
I tried :
Provide your Version of the EP32 Arduino Core (or the IDF Version)
IDF 6.7.0, Arduino Core 2.0.16, ESP32-A2DP 1.8.1+sha.b0ad45d
I have checked existing issues, discussions and online documentation