building a 3rd party library

[nvannote]

Not carefully enough...mea culpa. I went ahead and copied the library under your project structure (I'm running on Windows and links/shortcuts don't always do what I want them to). It now builds and runs. Very nice work on your part.

No worries, first cup of coffee; I forgot the insert a smile. It was only intended as a soft jab.

1. at startup, I'm getting this error:

W (302) spi_flash: Detected size(8192k) larger than the size in the binary image header(4096k). Using the size in the binary image header.

Do you get this as well?

Open up menuconfig; Navigate to "Serial flasher config" and change "Flash size" to what would be appropriate for your module. The module I was working with at the time probably had a 4MB flash, so it went to GitHub as such.

2. I do my code browsing and editing in an IDE (one that currently can't cross-compile for the ESP32, but it's still a great tool). The IDE isn't finding any of the ESP_LOGX macros in your main. More accurately, it's not finding CONFIG_LOG_DEFAULT_LEVEL. The program builds and runs using the idf.py tool, so this is nothing more than an inconvenience, but my incipient curiosity has me wondering why. I compared your sdkconfig file with one from another project (that does find that macro), and didn't see any differences that looked relevant. Did you have to do anything to get the linker to "find" this?

That's a new one on me. No, I haven't seen that before. Other than the command line, I am typically using Eclipse CDT as an IDE for the ESP series. Eclipse CDT is far from perfect in any sense, but it gets the job done and the Espressif plugin gives it a "fair" amount of ESP32/IDF awareness. Out of curiosity, what IDE are you using?


Best Regards

[mzimmers]

I'm currently using the ESP32-WROVER-E. I increased the flash size to 8MB and that eliminated the error.

The IDE I'm using is Qt Creator. It's a wonderful code browser and editor, even if you can't use it to build. I'll look into this error tomorrow.

So, I guess the next logical step would be to add a socket and have this library attempt to interpret an audio stream?

Thanks again...

[nvannote]

So, I guess the next logical step would be to add a socket and have this library attempt to interpret an audio stream?

Baby steps. Yes, the next thought is to implement a "basic" test using network connectivity.

I will throw the warning down up front. This very well could be for nothing.

This library is a bit of a beast and we are dealing with a platform of very limited resources. I don't know what kind of demands this thing is going to impose in a real world scenario. I have not seen the terms "embedded" in any documentation (or the Cisco issue tracker) whatsoever. There are a zillion allocation statements in the code base, and while any one particular use case will probably only hit a fraction of those, they are still a problem.

The question "Can you?" has been partially answered. Sure, perhaps. The question of "Can you what?" and "Should you?" are an unknown. I personally feel that this is going to be a VERY high bar for an ESP32.

Best Regards

[nvannote]

Baby steps. Yes, the next thought is to implement a "basic" test using network connectivity.

OK. Maybe not so many baby steps.

I spent some time with it; I have RTP working; P2P and Multicast between macOS, Linux and ESP32/FreeRTOS. Basic session authentication seems to work. Next is to start activating security services.

I can't share this just yet. After finishing the required application and sockets "glue" code; I rushed and dragged in an internal component to get everything else up quickly.

Regards