Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Serial Stream from ESP32 >> ESP32 #2011

Answered by pschatzmann
PacciK asked this question in Q&A
Discussion options

@pschatzmann is there a way to pipe a URLStream or an ICYStream's data as received, over to another microcontroller (this one with wifi off) over a suitably sized Serial data, for eventual consumption and I2S output in the second microcontroller , without having to resort to ADPCM comp/decompression like in the send-adpcm_framed-receive example ? What do you suggest as a pipeline? ThankYou.

You must be logged in to vote

I don't quite understand your question: The audio data transmitted via URLStream or ICYStream is usually mp3 or aac, so it is already complressed with a codec that is much better then ADPCM!

Just make sure that the baud rate is high enough if you want to live play...

Replies: 3 comments · 39 replies

Comment options

I don't quite understand your question: The audio data transmitted via URLStream or ICYStream is usually mp3 or aac, so it is already complressed with a codec that is much better then ADPCM!

Just make sure that the baud rate is high enough if you want to live play...

You must be logged in to vote
18 replies
@PacciK
Comment options

from previous tests, even sending out chunks of 4096 bytes at 2Mb/s worked well ( not sound wise - just the packets arrived intact is what I meant).
Please help me with the correct use of Your library, to do the sychronization it requires.
Following the examples/examples-communication/serial/send-adpcm_framed-receive/send-adpcm_framed-receive.ino , I cannot wrap my head around it.

@PacciK
Comment options

What I'd like is the send the chunks as fast as possible to the 2nd MCU, which will then process them at its own pace.

@pschatzmann
Comment options

This has nothing to do with my library: I already told you that you need to implement Serial data synchronization to prevent loosing data (eg. using the ctsPin and rtxPin).

Or you could implement a big buffer on the receiving side and implement your own synchronization protocol.

@pschatzmann
Comment options

Or you could write to a file to make sure that you don't loose any data assuming that you will never run out of disk space....

@PacciK
Comment options

@pschatzmann ThankYou for your patience and interaction.
Your extensive library is nothing short of fantastic, which reflects your abilities.

As a tinkerer / beginner, I think I'm going to give up.
....that cold Beer seemed so close.

Answer selected by pschatzmann
Comment options

@pschatzmann , if I use a circular buffer for the serial data instead of extra cables for CTS and RTX, perhaps it may work ?
What triggers or headers am I looking for in the incoming stream to know how to control the filling of the circular buffer ?
I want to limit my scope to Icecast/Mp3 streams, no AAC, at a max of 320Kbps.

You must be logged in to vote
21 replies
@pschatzmann
Comment options

Just added an untested example using xon-xoff over serial

@PacciK
Comment options

@pschatzmann That's super !!!! Going to test it soon.
Just having difficulties in compiling the sender code. VScode is complaining of :: pio/libdeps/esp32-s3-devkitc-1/audiokit/src/audio_driver/ac101/ac101.c:101: first defined here

Also, in the Sender code, why do you instatiate the "AudioBoardStream i2s(AudioKitEs8388V1); // final output of decoded stream" if the sender is not going to use I2S ?

Thanks !

@PacciK
Comment options

nevermind... its compiling now !!
Going to test soon.

@PacciK
Comment options

Bingo !!!!

@pschatzmann You are an absolute Legend !!!!

@PacciK
Comment options

Phil, I'm trying to extract ICY Metadata on the recevier ESP32, but I'm getting stuck.
After visiting the MetadataWiki, my logic tells me that i should add:

queue.setMetadataCallback(printMetaData);
queue.begin(50); // start when half full

but the types do not match, neither does "Serial1" instead of "queue".

is "queue" the right pipe to choose for this or does it require some more work on the communication class ?
Thanks !!

Comment options

not all streams are created equal. You can always write to or read from them but there is no obligation they have a setCallback method. Only MetaDataOutput streams promise to have the callback you want. Your queue or Serial1 have not.
I‘m sure the links about MultiOutput and its related example in the MetadataWiki will help doing the trick.
Would be more specific but I haven’t read that myself yet

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.