"TAG" member of MetaType enum conflicts with ESP_IDF_LOG TAG macro definition

[martinroger]

audio-tools version : 1.0.1+sha.28a8df1

Line 102 of MetaDataFilter.h declares the enum MetaType with TAG as its first enumerated value. This creates a conflict when using ESP's logger macros, as they require an overarching macro "TAG" to be defined in some cases, as a string. Obviously the enum declaration does not enjoy that ride...

Note : not using the ESP IDF logger (i.e. using the Arduino one) alleviates the problem.

[pschatzmann]

Please provide me a short example sketch so that I can reproduce your issue.
The following example compiles w/o problems for me with any core debug level:

#include "AudioTools.h"

MetaDataFilter filter;

void setup() {}
void loop() {}

Where does your #define TAG come from ? Usually applications define their specific defines like #define BT_APP_CORE_TAG "BT_APP_CORE"

Using such a unspecific #define is really a bad idea since defines are global!

[martinroger]

Hi @pschatzmann,
I made a small branch of my project for just that here , but yes you are right about this kind sweeping high level define.

I actually revisited my code deeply and managed to get rid of the need for this general "TAG", I guess this issue could turn more into an information or discussion for others.

One of the reasons for defining high level "TAG" raised from combining other libraries that did not have the necessary shielding (I was experimenting with redirecting ESP logs to an SD card instead of stdout). Some of the built-in libraries on slightly older versions of the Arduino core were calling for a general TAG... Using more recent ones expunges that problem.

Ultimately this should serve as an indication for others should they encounter this conflict?

[pschatzmann]

To output the log to a file, just replace the Serial with your file that has been opended for output:

 AudioToolsLogger.begin(Serial, AudioToolsLogLevel::Debug);

Don't forget to call flush in your sketch and close the file when you are done to save the content....

[martinroger]

Yes, though in my case I was also trying to make sure all (not just AudioLogger) logs were redirected away from the default Serial to an SD.
In my case UART0 is busy with emulating the Apple Accessory communication protocol (and I cannot reassign to different UART/pins) and I was trying to log on-board why I had disconnects on that front.

Ultimately I think it made things worse and I think I need to educate myself on Tasks, priorities and keeping interactions between the AVRC callbacks and the Serial writes on UART0 tidy :/