Hi
Does anyone know of a way to send one channel of audio over the network, with low enough bitrate to support a wifi network? I would like to send audio from a desktop to a tablet/mobile device.
And it would need to be non proprietary, and possible to implement in a juce app.
Does anyone have experience with something like this?
You would need to write up some kind of client/server interaction. JUCE provides several classes to achieve this:
I believe the JUCE demo provides examples of each.
I think binary websockets might be the way to do this without having to open ports etc
Thank you both for responding.
I’m relatively aware of the basics here, but is it really that trivial?
Simply pushing sample buffers through a socket. Is there no need to do data compression, or add error checking etc?
I guess a relatively large buffer would be needed to account for lost packages and connection issues. And you would need to resample at both ends.
And converting to 16 bit samples + dither seems like a good idea to save bandwidth.
But there is no “turn-key” solution out there then as far as you know.
Guess I have to get my hands dirty and make some tests 
Is there no need to do data compression, or add error checking etc?
Error checking - that’s a given.
Data compression? Well, probably! In fact, it’s very likely that you will need to, but it’s entirely dependant on your needs! Looking at your first message:
send one channel of audio over the network, with low enough bitrate to support a wifi network?
How performant should this be - in what kind of context? Real-time? Offline - so uploading to a server and waiting for something back, like in a P2P-style setting?
The concepts we have provided cover both cases at rudimentary levels, but it’s up to you to create and configure systems as per your needs.
Hi Nik, how did you go with this?
Hi. it’s been a while, and I don’t recall why I investigated this. I do remember that I have had audio over wifi working. It was for a “intercom-like” application.
Looking at old code; I see that I used the Opus codec: https://opus-codec.org/
I then used a Listener and Sender class that has a
processBlock(juce::AudioBuffer &buffer)
That gets called by the audio thread.
The audio is then put in a FIFO, and then there is another thread that encodes the data, puts it in a custom struct/packet (to give it an id and a sequence number) and sends it via UDP to the network.
The Listener then gets the UDP-data, checks the id and sequence, decodes the data, puts it in a FIFO, and it then gets picked up by the audio thread in a process block call.
Did that make sense? not sure if it is the most elegant solution, but it worked.
You also have to take into account, different SR on listener and sender, dropped packets and so on.
It has been a while for me, but if I remember correctly UDP makes next to no guarantees (but is faster than TCP).
For that reason I would spec a limiter/compressor on the receiver end so you can prevent (very) loud noises and pops due to corrupted data.
That is correct, UDP makes no guarantees, but if it is close to realtime audio it does not matter if the packet comes in “some time later” like with TCP, it can be discarded, and a newer gets used in stead.
What I did was add a running “sequence number” to the packet, so that the listener knows that a packet is missing. if you are missing packets or the packet does not contain valid data, you can make a short fade to 0, no need to output noise.
1 Like