from Hacker News

Ask HN: Why isn't there a standard network audio protocol?

by armagon on 4/14/22, 2:30 PM with 149 comments

Having been frustrated again in using bluetooth from a computer to a smart speaker -- ugh! I swear connections only work half the time, and it isn't due to RF interference -- I'm wondering why there isn't a standard protocol for transmitting audio over the network. I think it would be so much easier to use.

[I'm talking about having my devices at home talk to each other. They are already on the same network.]

Edit/Addendum: Are there any streaming audio protocols that work from Mac/Windows/iOS to Amazon Echo Dots? I'm looking for a drop-in replacement for bluetooth audio streaming, where I can play sounds on my computer (ex. a youtube video) and hear it on a louder speaker.

  • by exabrial on 4/14/22, 7:54 PM

    There is several standards in the professional space, Dante being the biggest for "audio over ethernet". It's packet switched, so buffering is required.

    AES50 works over cat5 cables, but doesn't use ethernet; it uses a synchronous clock to transmit PCM audio. A lot of the Midas/X32 product lineup uses this to great effect.

    Dante allows normal IP equipment to function as audio distribution devices, but has noticeable latency for close-quarters stuff (sound travels ~ .9ms / foot +-10%).

    AES50 has extraordinarily low latency, pretty much as good as analog, but only allows point-to-point links.

    On the consumer side, RAOP existed for awhile before silicon valley elitism infected Apple: https://en.wikipedia.org/wiki/Remote_Audio_Output_Protocol

    EDIT ====

    I had in my head the RAOP was an open standard, it's not.

  • by PragmaticPulp on 4/14/22, 3:44 PM

    > I'm wondering why there isn't a standard protocol for transmitting audio over the network.

    Bluetooth isn't the same as your WiFi network. Most of the comments here are talking about IP-based protocols that aren't relevant for Bluetooth anyway.

    Bluetooth is probably the best example of a widely adopted protocol for connecting to devices and sending audio streams. The protocol isn't exactly the problem. It's the buggy implementations of Bluetooth stacks and Bluetooth software in embedded devices.

    Getting it right is actually extremely difficult because Bluetooth grew in complexity to be everything to everyone. It isn't only an audio sending protocol. Almost nobody owns the entire Bluetooth stack, so it's a mix of pieces from different companies and vendors.

    Apple's implementation isn't perfect, but from experience I can tell you it's 10X better than the nightmare that is Android Bluetooth. It's getting better, but for years you had to collect a lot of different Android phones so you could make your software work around all of the different quirks in each vendor's different Bluetooth stacks.

  • by geekuillaume on 4/14/22, 3:30 PM

    There are some projects like Snapcast[1] or SoundSync[2] (disclaimer: I'm the creator of Soundsync) to let multiple devices communicate together on the same network. The transmission-side isn't that complex: you choose an audio codec, transmit chunks of data and add a synchronization layer (to keep multiple outputs in sync and to correctly delay video playback to match the soundtrack). The bigger problem is building an ecosystem big enough to make it attractive. Bluetooth sucks but is everywhere.

    [1] https://github.com/badaix/snapcast [2] https://github.com/geekuillaume/soundsync

  • by jhugo on 4/14/22, 8:32 PM

    There is a standard protocol for audio (and other realtime media) over an IP network: RTP.

    But your problem doesn't have anything to do with a lack of standards; Amazon has no incentive to just let you send RTP to the Echo Dot on a port — nobody is asking for that, and they would have no control over the "experience".

  • by throwaway67743 on 4/14/22, 4:18 PM

    Probably get flamed for this, but pulseaudio is good enough for IP networks and handles delay calculation pretty well, when used via multicast it's reasonable but a lack of ecosystem means non-linux support is poor and control is basically non existent, but I did operate pulseaudio as my home audio for TV/PlayStation/phone audio for a time, with some extras like casting receivers etc it's almost useful, but not convenient (there is a gap here someone could fill)

  • by octoberfranklin on 4/14/22, 4:18 PM

    There sort of is, RTP/RTSP, and in fact it's been around since the earliest pre-web days of the Internet.

    The problem is that it's a protocol with a ton of warts -- having two connections, one UDP and one TCP, has been a massive headache for decades now. But it's not awful enough to get ripped up and redone.

    The Asterisk VOIP platform had a really awesome protocol called IAX that was basically RTP with the two streams merged into a single UDP connection (and a bare-bones TCP-like reliability layer for the control frames inside of UDP). IAX was never meant for anything other than VOIP, but I wish it had been turned into a wholesale replacement for RTP. If that had happened, it would have been wonderful.

  • by atoav on 4/14/22, 8:01 PM

    I was thinking about something like Dante, AES50, AES67, AVB, Ultranet, Ravenna or any other of those professional Audio over Ethernet standards out there.

    Those are working and used in live venues and studios, the hardware used for those might however be out of scope in terms of price for the typical user and it certainly won't work with your smart speaker.

    Does that smart speaker have line in (3.5 mm TRS)? If so you could just send your audio analog over the ethernet cable and build an ethernet to TRS adapter on the other end : ) For longer distances balanced line drivers might be needed, tho.

    But shielded Ethernet cables work surprisingly well for analog audio purposes, especially if you send balanced signals through them. If you transformer-balance them you even get galvanic isolation for free.

  • by b20000 on 4/14/22, 3:14 PM

    there is already ABV and DANTE in the pro audio world. you are not aware of it because you probably are not in the recording/audio/music business.

    bluetooth sucks because it was invented by a bunch of guys in suits and consumer electronics companies rather than people who understand latency, performance etc. i designed my own protocol in the 2.4ghz band and wrote firmware and middleware for it and it deals with all the weaknesses of BT.

    BT should have been designed by those who design the products and applications and deal first hand with end users.

  • by monocasa on 4/14/22, 9:16 PM

    > The good thing about standards is that there are so many to choose from.

    ― Andrew S. Tanenbaum

    But really, RTP is the closest thing. Outside of the consumer space nearly everything is RTP + some out of band signalling protocol. It's low latency, designed to be multicast, has RFCs for evey codec under the sun, etc.

  • by winkeltripel on 4/14/22, 7:20 PM

    There is. You build a network of analog cables. Use a sound board to 'switch' the channels. This leads to headphones on 3.5mm jacks, and one or more zones of stereos connected by RCA. This 'network' is as solid in 2022 as it was in 1975.

  • by sigstoat on 4/14/22, 3:56 PM

    clearly (given all the other responses), there are a bunch of different conflicting requirements which lead to different protocols.

    as for your bluetooth issues, PC bluetooth is a mess.

    some of bluetooth's messiness comes from having the higher level elements of the stack designed 20+ years ago to operate on microcontrollers of that era. they've got N different audio profiles because the hardware it was expected to operate on originally would've been hard pressed to handle a single audio profile that could negotiate the gamut of use cases.

  • by currency on 4/14/22, 7:00 PM

    Specifically for computers to smart speakers, I use AirPlay 1, but this works better from Windows with a 3rd-party app than from iOS or MacOS—the 3rd party app is perfectly happy to play to as many endpoints as I like, while Apple will only transmit to one endpoint at a time if it's an AirPlay 1 device.

    From my Windows 10 PC, TuneBlade AirPlay streaming provides a great experience:

    I can play stream anything that is playing on the PC to any AirPlay device on my LAN, and all the playback devices will be in perfect audio sync.

    AirPlay 1 devices on my network include an AppleTV, Apple HomePod Minis, Nexum Airplay receivers attached to powered speakers, and DAPs with Airplay reception.

    There is a significant buffer delay—about 2 seconds—that messes with video streaming. TuneBlade has the ability to stream video to VLC with synced audio, but doesn't support other video streaming endpoints. There is a bufferless mode with no delay, but it doesn't work well on my network.

  • by akvadrako on 4/14/22, 3:48 PM

    There is Airplay 1, which is the only widely supported protocol I'm aware of. See for example https://github.com/mikebrady/shairport-sync.

    There is also DLNA, which is actually a standard. I think it's rarely supported for push audio streaming since the protocol is poorly specified.

  • by qbasic_forever on 4/14/22, 6:51 PM

    Some people might say DLNA, but trust me you want absolutely nothing to do with that disaster of a protocol and tech. I have tried off and on for _15 years_ to use different DLNA tech and every single time it ends in total disappointment and failure.

  • by duped on 4/14/22, 3:05 PM

    There is, it's called AES67. It just isn't used much in consumer products. The acronym to google is AoIP ("audio over IP")

  • by craggyjaggy on 4/14/22, 3:01 PM

    If you want to turn your home into a TV/Radio station, have a look at Audio Video Bridging[1]. It requires special hardware, but once you're set up devices can reserve bandwidth for their streams which will be prioritized by switches over other Ethernet traffic thus ensuring 100% reliability and sub-2ms latency accross 7 hops.

    [1] https://en.m.wikipedia.org/wiki/Audio_Video_Bridging

  • by LargoLasskhyfv on 4/14/22, 2:56 PM

  • by TOGoS on 4/15/22, 5:41 AM

    I keep wanting JACK / netJACK[1] to be this. I've only actually gotten it to work once, though, and it required several hours of fiddling with configuration files and restarting daemons. Usually I run into a problem like...not being able to get certain applications on Windows to route audio through JACK at all.

    So, maybe the answer to your question is that there are too many standards for sending audio over the network, which means none of them get enough polish to really become the standard, with support on multiple platforms, requisite drivers actually working, etc.

    And this is why I string old-fashioned audio cables around my house.

    [1] https://jackaudio.org/faq/netjack.html

  • by nixpulvis on 4/14/22, 7:09 PM

    Another question. Why aren't my bluetooth headphones better at buffering larger amounts of data. I should be able to load a complete song without skipping with interference.

  • by stuntkite on 4/16/22, 10:53 PM

    This is a great question that I've been playing with since getting some JBL PA speakers and seeing the ethernet jacks and looking at what it supported. It's SO difficult to get something working without buying really locked down and expensive gear that is for much larger applications. Also pretty cumbersome to enable on my Ubiquiti router but I'm getting there!

    I ended up settling on using CobraNET by buying some fairly affordable GPIO rack units from reverb from a defunct church made by AudioScience. As doesn't really want to sell to me directly but they sell to a lot of churches and they scale up and down a lot so nice gear is really affordable.

    I wouldn't call it easy to use, but compatible, affordable, and pretty cool. I've been working on a 4.2 mini "ambisonic" setup... It's a long term goal like an old guys basement train set. Heh.

    http://www.audioscience.com/internet/products/cobranet/cobra...

    I hope this helps and thanks for bringing this up to HN. I look forward to reading all the replies.

  • by lowbloodsugar on 4/15/22, 3:45 AM

    A Hifi Berry [1] plus a speaker. The Hifi Berry is a Raspberry Pi hat. There are hats for digital output, analog output, and one with amplified analog output that can drive a 4ohm speaker quite respectably.

    I have some old Cambridge Soundworks speakers outside that I drove from a HifiBerry Amp2 hat for a while. Not quite enough power for outside so I switched to a Hifiberry DAC Pro and a pretty capable amp off eBay. The sub to go with them uses a HifiBerry DAC too.

    My main listening speakers are active digital speakers, with SPDIF inputs, and Hifi Berry Digi+.

    The HifiBerry has a RPi build you can just stick on a card, though I now use dietpi as it survives power loss better. Once that's done you can connect over wifi or wired, using Airplay, Roon, bunch of other things I forget. Basically you can run any music server on it, because linux. With Airplay or Roon (and probably others) you can make all the speakers in the house play the same music, which is awesome for parties.

    There's a bunch of manufacturers that make wifi/wired active speakers. Bluesound. KEF make some nice ones for $2000. Not portable, mind you.

    [1] https://www.hifiberry.com

  • by m0shen on 4/14/22, 8:35 PM

    I haven't seen VBAN mentioned yet:

    https://vb-audio.com/Services/support.htm#VBAN

    https://vb-audio.com/Voicemeeter/vban.htm

    It's a free, open protocol that runs on UDP, transmits PCM audio and MIDI

  • by rglullis on 4/14/22, 3:00 PM

    RTSP/RTMP are not to your liking?

  • by bentcorner on 4/14/22, 3:35 PM

    To pile on further, you may have better success getting a small device (like a pi) and connect the audio out to your speaker.

  • by incomingpain on 4/14/22, 4:17 PM

    I too found bluetooth to be unreliable.

    For that reason, I have extensively worked with pulseaudio over network. There is no UI that works for this. NTP for some reason is important which seems like bad design to me. zeroconf doesn't work at all.

    Once you get it working... dont dare change anything. It will break in inexplicable ways that drive you up a wall.

  • by mnkmnk on 4/14/22, 7:54 PM

    Making a Bluetooth alternative, I think apple is the only company that can pull it off. But they will absolutely do it such that only their headphones will work with Apple devices. And then they will license other manufacturers to be able to use their tech to connect to apple devices.

    Otherwise, I see a huge opportunity for a consortium to develop a new hardware and software stack for high quality low latency audio and being them as a package to their products. I would love a completely wireless Dolby Atmos like setup with no central receiver, your mobile device itself being the av receiver. New speakers from any manufacturer and form factor could be added wherever you want as you buy them. Calibration according to your speaker placement would be wireless and automatic.

  • by hsbauauvhabzb on 4/14/22, 8:47 PM

    I’ll link to https://news.ycombinator.com/item?id=29514876 here, it may have valuable insight.

    I can use my hdmi ARC soundbar from my computer. We live in a backwards world.

  • by macinjosh on 4/14/22, 4:28 PM

    What about HDRadio? A home scale FM broadcast could accomplish this efficiently and cheaply. Each speaker would just need an FM receiver.

    I guess the downside is that your neighbors could listen to whatever you're listening to but who listens to terrestrial radio in their home that is received OTA anymore?

    https://en.wikipedia.org/wiki/HD_Radio

    https://www.amazon.com/Home-FM-Transmitter-Whole-House/dp/B0...

  • by cratermoon on 4/14/22, 4:21 PM

    The answer is DRM. In fact, almost any audio/video standard attempts have to address the elephants in the room: Disney, Warner Media, Universal Music Group, etc, and they all require DRM.

  • by iancmceachern on 4/14/22, 4:04 PM

  • by Melatonic on 4/14/22, 8:41 PM

    If you don't like audio over ethernet do not even think about doing high quality video :-D

    Hate to say it but you are probably better off getting something other than Echo Dots for music. Too bad Google discontinued the Chromecast Audio - I love mine. The biggest plus for me is that once you have a compatible app (such as Spotify) streaming is done entirely on the chromecast audio from your internet itself instead of continuing to use your phones battery and wifi.

  • by remram on 4/14/22, 8:55 PM

    I've run into this. I would like to use my Android phone as speaker and microphone for my laptop, so I can walk around without leaving my call. For some reason this is impossible, Bluetooth supports it of course, and so does Pulse Audio on my laptop, but an Android phone will only act as the host not the speaker/mic.

    I found SnapCast which lets me send audio from laptop to phone (with huge latency) but not the other way (phone mic to laptop).

  • by aj7 on 4/14/22, 4:10 PM

    And while we’re on the subject, why is cell phone audio so horrible? It is worse than that delivered by the cast metal telephones with rotating dials of my youth.

  • by AussieWog93 on 4/15/22, 7:08 AM

    There is at least an attempt at WiFi audio I've seen in the wild, at IKEA of all places: https://www.ikea.com/au/en/cat/wi-fi-speakers-46194/

    No idea of the broader ramifications of this, but any move away from the shitshow that is Bluetooth can only be a good thing.

  • by rapjr9 on 4/15/22, 4:26 PM

    If you are just looking to move audio from one computer to another you can do it with netcat, no protocol needed:

    https://www.audio-digital.net/a-pages/audio-over-netcat.html

    I've tried this and it works.

  • by malthaus on 4/15/22, 6:44 AM

    As someone who produces music with synthesizers - there's also no (well working & established) standard for running/managing multiple audio sources over usb.

    There are some valiant efforts (e.g. Overbridge by Elektron), but even those took a lot of effort, are proprietary and buggy.

  • by unixhero on 4/14/22, 10:10 PM

  • by nikonyrh on 4/18/22, 8:15 PM

    Bluetooth has been in development for over 20 years now, I'd assume they have solved all the problems by now. Meanwhile the consumer WIFI is faster than ethernet copper.

  • by xyzzy21 on 4/14/22, 10:39 PM

    Firewire was supposed to be an AV standard that allowed connecting anything to anything and completely eliminate the RCA cables etc.

    And then the RIAA and MPAA discovered the plan and killed it good.

  • by heavyset_go on 4/14/22, 10:37 PM

    The PulseAudio protocol supports network audio.

  • by open-paren on 4/14/22, 3:17 PM

    In this thread:

    https://xkcd.com/927/

  • by nomoreusernames on 4/14/22, 6:59 PM

    audio signal is enough. jackd is nice as an option.

  • by _trampeltier on 4/14/22, 4:31 PM

    You can't even send anything from Apple to non Apple by Bluetooth. Why do you expect audio would work.

  • by stuaxo on 4/15/22, 12:03 AM

    ROC looks pretty good.

  • by MrMan on 4/15/22, 10:39 AM

    Dante? AVB? over tcp

  • by fxtentacle on 4/14/22, 4:01 PM

    There is, Dante.

  • by jszymborski on 4/14/22, 3:26 PM

    It's a bit funny that there are already a bunch of comments that are stating "There already is, it's called 'X'", each with a different value for X.

    I think this paints a better picture of the situation than any one person can provide.