Suggestion: Ring buffer optional to save heap memory?

[Christian Schwinne]

Thanks for the amazing library @forkineye!
This is not an issue, but rather an enhancement suggestion.
I've got a quite complex sketch called WLED for controlling WS2812b LEDs.
For ESP8266 at least, memory is very limited and using over 4kB of heap just for the buffer was not acceptable in my use case. So I removed the ring buffer and instead added a callback to the ESPAsyncE131::parsePacket function that calls a method which directly writes the data to the LED output buffer. This reduces the memory usage of the library by 4466 bytes (buffers for 7 universes aka 1190 RGB LEDs).
It seems to work perfectly, at least for this use case.

Just wanted to let you know! If you are interested, here is my fork. (please note that I also removed the stats and error analysis code, as it was not relevant for my project)

Maybe the library could be enhanced by allocating 0 ring buffers, but instead have the user specify a callback.
The only real drawback I see with this is that all the processing has to be done in the callback, so doing anything time-intensive with the packet is of course not going to happen from system context. Are there other reasons for why you implemented the ring buffer?

Thanks once again for your hard work, this library is very useful!

[Shelby Merrick]

The biggest reason is as you stated, to get it into a buffer for external processing and out of the callback. Makes dealing with things like pixel grouping, zig-zag, gamma, color order, brightness, etc... all a little cleaner and things can get dicey with fresh pixel data coming in every 25ms. I initially added the ringbuffer back in the non-async version of this library to get around processing problems and input overflow, but never tried going back to writing directly to the output buffer once I did the async version. Plus, ring buffers just make good sense when dealing with communication processing pipelines.