arduino-audio-tools
arduino-audio-tools copied to clipboard
stutter on ESP Now example with audio kit
I tried both esp now examples (normal and with SBC codec, but i receive a lot of stutter (probably some buffsize issues? What could possibly had gone wrong? I just edited the examples to use audio kit streams instead of i2s
its caused by the esp now sender, but I stillt dont know why
Is the log level in all sketches set to Warning? Maybe you can try to decrease the sample rate...
With the sine wave example it works fine, but when I switch it to the AudioKitStream it outputs a lot of garbage
Is this with the example with or w/o decoder ?
I am having the same issue , needing to send audio from audio kit input via esp now but sound stuttering using the codec encoder/ decoder think the problem is on the sender side , have tried lowering the sample rate but still an issue , works fine with the example
Streaming Audio is hard: If you use a process where you sample at the sender with constant speed, it might be that the receiver is running a bit faster than the sender: The clocks between the different microcontrollers are not synchonized: That could lead to stuttering! The sine example sends as fast as possible and gets stalled by playing the audio in the receiver. If you look what the web browsers do: they buffer a lot of audio before they start to play....
Thanks for the reply, I'm fairly new to audio tools. You have done great work with this library. It's made life a lot easier . I got it working with Bluetooth so I'll keep trying to fix the espnow issue, if anything it'll be a good learning experience. Thanks for you time .
Makes total sense what you said I'm streaming from a esp32 A1s (kit) to an esp32 with pmod I2s
Ok this is weird . So the buffer size is limited to 256 on the espnow . I thought what the hell and raised it to 1000. No more stuttering . EncodedAudioStream decoder(&kit, new SBCDecoder(1000)); did I miss something or has it changed . Or did I misunderstand the code
Check out the class documentation: you actually reduced the internal buffer from 8192 bytes to 1000. I guess you could even go further and decrease it down to the actual framesize length.
I am not sure why the proposed buffer size is so big. I guess this might be the maximum expected value. It should however not have any impact on the decoding performance since a frame is decoded whenever the framesize is reached.
I just added the actual framesize info to the info log...
Ah I understand now . Thanks for the info. This is awesome . Your a star . Thanks so much