Low latency audio across network

[fgoldstein]

I'm interested in doing something that seems like it should be simple with the Pi and an audio card like the Cirrus, but don't know exactly which software, if any, can do the job.

The idea is to take line-level sound input at one location (audio from a radio receiver) and output it at another location across a network. There is no storage or playback involved, and no hi-fi. I've seen various articles on how to do this with ffmpeg and acodec, among other things, but they all seem to have too much latency. I need to hold the latency in the Pis to under 20 milliseconds or so, and also gets rid of jitter in the output. That timing includes output buffering (the end to end network jitter will be less than that) and input serialization.

One really clever-looking approach just piped the audio through ssh, but ssh uses TCP, which is based on retransmission. I need an approach that uses either rtp or just plain udp with application buffering. A 64k PCM stream is 40 payload byes in 5 ms., which is acceptable efficiency.

Or is the hardware incapable of this? The Barix Annuncicom does the job in dedicated hardware, but its hardware apparently has a 2048-byte playback buffer, which adds too much latency unless the audio coding rate is set very high, and I really only need telephone-line (64 kbps PCM) quality, though a slightly better PCM would be nice too. Plus a Pi would be cheaper (we could use a bunch of these) and kinda fun... Thanks.

[r3d4]

Pi and an audio card like the Cirrus, but don't know exactly which software, if any, can do the job.

Hear is a list wiki.linuxaudio.org/apps/categories/network_audio , hopefully that should make it simpler to research somthing that can do the job !.

[fgoldstein]

Please, I know how to Google stuff! I just thought somebody here might know from experience a) which programs can pass audio without much latency, and b) how to use it with a simple pipe or other network connection. I am guessing that it can be done with the right one-line shell command, but piping what to what with what parameters is not obvious. Most of the audio discussions are about music, and a second or two makes no difference, and most of the programs are aimed at that market. But a codec piped using rtp/rstp theoretically doesn't have need kind of delay. Many audio programs seem to have their own bufferbloat.

[r3d4]

Please, I know how to Google stuff!

*dubious*

I just thought somebody here might know from experience a) which programs can pass audio without much latency, and b) how to use it with a simple pipe or other network connection.

Perhaps what might lack in experience can be made up for in methodical tenacity.

piping what to what with what parameters is not obvious

Did you all ready try?
0) ffmpeg / ffplay
0.1) avconv / avplay

[fruitoftheloom]

http://www.ti5.tu-harburg.de/staff/meie ... bedded.pdf

They used a Raspberry Pi 1 which has the ARMv6 BCM2835 SoC

[fgoldstein]

Thank you fotl. That was an interesting paper! He was right on point, going for low-latency audio, and maybe if I find jamberry around I'll try it. Other than that, I see his approach but hope there's something easier to do than write that much code.

[stderr]

Thank you fotl. That was an interesting paper! He was right on point, going for low-latency audio,

What is the reason for the low latency? I can see it for someone playing a musical instrument with other musical instruments that all have to be in sync. I can less see it for serving up media on a network. Even for media that is going onto a network to be played out by various devices in sync, since I think it would be better to delay things and sync to this delay.

[fgoldstein]

Many things need low latency. Phone calls, for instance. But the VERY strict requirement in this case is public safety. First responders, especially fire fighters, carry walkie-talkies. These communicate via repeaters. The repeater transmitter is generally at a high place, maybe 30-70 watts output on UHF frequencies. The walkie-talkie puts out maybe a watt or three. When a fire fighter goes into a burning building, he needs to be able to reach the repeater 100% of the time! So they way that's done is to have more receivers than transmitters.

The repeater has a group of receivers, designed to have good reception all over the municipality, connected back to a comparator. When the receiver is squelched, it transmits a constant tone. The comparator listens for a break in the squelch tone, keys the transmitter, and connects that receiver to the transmitter. But the user may be in a car, or moving around, so which receiver gets the best signal may change rapidly. Thus a comparator listens to all receivers at once. And of the unsquelched ones, it picks the one with the least energy in the 2000-3000 Hz range, since that noise rises as the signal gets weaker (at least on an FM system; I'm not sure about P25). So all of the receivers have to be synchronized to within very low milliseconds of one another for the handoff to be seamless.

The comparator tolerates a differential delay of up to 30 milliseconds and equalizes in that range. Right now a lot of the receivers are connected over telephone lines, either analog or T1 digital. But the telephone company is no longer maintaining them, and is taking them out, because this is the US and as part of our great national deterioration into third world status, our phone companies no longer want to be phone companies (they'd rather sell iPhones for kids to sext on). So the police, fire, and emergency medical departments have to go elsewhere. We're helping put in microwave systems and local fiber networks for that purpose. These are all digital, Ethernet/IP, so the voice has to be packetized with low end to end latency and jitter, to be compatible with the comparators and not mess up the repeaters.

For the analog lines, the best thing I've found so far is a Barix Annuncicom, but it adds about 50 ms. of latency. Or the rare RAD IPmux with analog (E&M) ports, but they're expensive and fidgety. So the idea of a Pi came up. My guess is that a Pi + Cirrus is not all that different internally from a Barix, but it might not have the excessive hardware playback buffer (min. 2048 bytes) of the Barix. And that's the lower-latency Barix, compared to their other models.

[woehrl]

I'ld try gstreamer!

http://stackoverflow.com/questions/2715 ... -gstreamer
http://labs.isee.biz/index.php/Example_ ... _Streaming

Good luck.

[RpiName]

I'm interested in doing something that seems like it should be simple with the Pi and an audio card like the Cirrus, but don't know exactly which software, if any, can do the job.

The idea is to take line-level sound input at one location (audio from a radio receiver) and output it at another location across a network. There is no storage or playback involved, and no hi-fi. I've seen various articles on how to do this with ffmpeg and acodec, among other things, but they all seem to have too much latency. I need to hold the latency in the Pis to under 20 milliseconds or so, and also gets rid of jitter in the output. That timing includes output buffering (the end to end network jitter will be less than that) and input serialization.

Try UV4L. It implements standard WebRTC which allows you to stream real time audio from any (defaulted) sound card installed on the rpi2 to any WebRTC-compliant peer (like browsers, smartphones, tablet, etc..) over the network. The delay is just few ms (I think no more than ~40ms). No configuration is required and works out-of-the-box . Being the protocol standard you can choose the codec with few lines of Javascript (via GetUserMedia and or other API's) - I think by default Opus is tried first. Just install the packages and that's it.

UV4L:
http://www.linux-projects.org/modules/s ... e&artid=14

(By default two-way audio & video is enabled, but you can configure the Streaming Server to disable video at all and audio in one direction)

Manuals:
http://www.linux-projects.org/modules/s ... e&artid=17

[fgoldstein]

Thanks for the pointer to UV4L. I'm looking into it. WebRTC does use RTP, not TCP, so it should be workable.