Hi everyone. I am going to develop a project based on ESP32 for recording my electric guitar. The general idea is following: to connect a guitar to an external ADC, to connect an ADC to an ESP32 module and to send a digitalized signal to a phone or PC via wireless protocol. An ESP32 does support bluetooth and wi-fi and both of them are suitable for wireless connection but I stuck because of some nuances. Bluetooth classic provides a bandwith that equals to 0.7-2.1 Mbps that is enough for guitar signal but I can't find accurate information related with latencies. Also, wi-fi supports much higher bandwith but I still can't realize latency issues. So my question is following: what latencies does an ESP32 module have for BT and Wi-fi audio transmission and are these latencies suitable for guitar recording?
Thanks
ESP32 wireless capabilities for guitar recording
Re: ESP32 wireless capabilities for guitar recording
Hi,
Why worry about latency?
Open a connection based socket (if Wifi then say TCP) & stream. Now you only need to worry about average throughput - assuming you have some seconds of buffering ESP side.
Live stream probably won't work well unless you buffer client side and client plays x seconds after i.e. has x seconds within which to recover from the hover being switched on or junior starting a download etc. That said my Bluetooth headset seems to manage.
You say 'record' so it really does not matter when you 'record' that data & so the focus is how much buffering you can do ESP side.
Bag yourself a module with some PSRAM & 'fill your boots'.
@320Kbps I would have thought you could get close to 10 seconds buffer with a basic ESP32 & some headache extra code to use spare IRAM etc. Maybe 6 seconds using spare DATA ram & simple code. The problem then becomes outage frequency/duration vrs your capacity to catch up. You should setup a simple loop test case & check your bandwidth etc. BTW: I don't think you have a problem, you have OOM better theoretical throughput but tests work well!
Once watched a project bleed major $ not hearing that with TCP you cannot expect 1 seconds worth of ADC samples every second (& certainly not with UDP). But a client can chunk 1 seconds worth of data perfectly well if the client works in the past.
Work in the past!
Why worry about latency?
Open a connection based socket (if Wifi then say TCP) & stream. Now you only need to worry about average throughput - assuming you have some seconds of buffering ESP side.
Live stream probably won't work well unless you buffer client side and client plays x seconds after i.e. has x seconds within which to recover from the hover being switched on or junior starting a download etc. That said my Bluetooth headset seems to manage.
You say 'record' so it really does not matter when you 'record' that data & so the focus is how much buffering you can do ESP side.
Bag yourself a module with some PSRAM & 'fill your boots'.
@320Kbps I would have thought you could get close to 10 seconds buffer with a basic ESP32 & some headache extra code to use spare IRAM etc. Maybe 6 seconds using spare DATA ram & simple code. The problem then becomes outage frequency/duration vrs your capacity to catch up. You should setup a simple loop test case & check your bandwidth etc. BTW: I don't think you have a problem, you have OOM better theoretical throughput but tests work well!
Once watched a project bleed major $ not hearing that with TCP you cannot expect 1 seconds worth of ADC samples every second (& certainly not with UDP). But a client can chunk 1 seconds worth of data perfectly well if the client works in the past.
Work in the past!
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: ESP_Sprite, ltsm0265 and 96 guests