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.
I think this paints a better picture of the situation than any one person can provide.
It's because the replies are interpreting the op's question differently from the intent.
When op asks: "why there isn't a standard protocol?" -- he's asking "why isn't there a SingleDominantThatWorksOnOnEveryDevice audio protocol that lets me connect devices seamlessly?"
The op's word of "standard" is just doing a lot of heavy lifting to convey a frustration with stuff not working intuitively.
The analogy is TCP/IP being a standard (SingleDominantThatWorksOnOnEveryDevice) network protocol that won over Apple AppleTalk, Novell SPX/IPX, and Microsoft LANMAN NETBIOS.
But many replies interpreted "standard" as "any available existing specification regardless of marketshare or device availability" -- so that's where you get various examples of audio protocols that are idiosyncratic to particular domains which are not analogous to the ubiquity and reliability of TCP/IP. E.g. the Dante audio protocol which doesn't seem relevant to op's use case.
And what's the scope of an "audio protocol"? Is it a "media query of music files" protocol like DLNA? Or is it a "virtual hardware audio device endpoint" like Bluetooth Audio?
Why isn't there a widely interoperable audio-over-the-network transmission protocol I can use, so that when I am playing sound (from a song, a video, or a game), I can hear it on an external speaker? [The scope is just a 'virtual hardware audio device endpoint' like bluetooth audio]
> ...(from) a video, or a game
So then you need low latency, like less than 10ms? So that lip-sync works, and the game is playable?
Do you need it distributed across different endpoints, also with low latency?
Does it need to run using unreliable WiFi connections, and not kill all audio just because one endpoint is under-performing?
These are all hard, hard enough that doing it well (and keeping it proprietary) makes companies like Sonos big.
OTOH, streaming mp3 from one endpoint to another is trivial.
I for one would accept latency and the audio going silent (or better, an audio indicator) if the connection isn't up-to-snuff but I don't know if other people would.
It manages it... sometimes.
I have an NVIDIA Shield I use for my video needs, and attempting to pair my Sony WH-1000XM4 headphones with it results in crappy latency and out-of-sync audio. These are both high end products from respected companies, and they work together with pretty shitty results.
Edit: I just tried this again after writing that and magically things work much better than they did before... but I stick by the general point.
In general, I'd describe the Bluetooth experience as mediocre at best.
The reason there isn't a standard (other than Sonos, or those discontinued Chromecast dongles) is that you need the following to work seamlessly:
- network attached DAC of some sort (in-speaker, or not; don't care)
- iOS app
- Android app
- the top 10 streaming services
- radio streaming directories, like TuneIn, or the open source ones.
- airplay
- Chromecast
- network / device auto discovery
- sound synchronization
- power management
- desktop apps
- NFS/cifs/etc bridge
- hdmi/fiber/??? bridge
- N.M surround sound (for N = 2, 3,5,7,9 and M=0,1,2)
- Some battery powered, waterproof speaker that works in direct sunlight on hot days
- Hardware distribution at places like IKEA, BestBuy, Amazon, etc.
- A healthy used hardware market
- 10+ year support lifetimes on the speakers + amps (note: discrete, cheap DAC dongles could disrupt sonos on this point)
And other things I forgot about.
I bought my first Sonos device last year, the Roam. Using it as a bluetooth speaker is fine and I love the sound and portability, but oh boy do I hate the experience of trying to use Sonos services over wifi.
Nine times out of ten, perhaps even more often, the iOS app says it can't connect and "let's fix it". If I go through the slow reconnection wizard it invariably ends up telling me to reboot my router(!?). I learned to either switch the Roam on/off a bunch of times, or kill and restart the app a bunch of times, before the app eventually decides yes, it can find the device ... only to then fail again when half hour later I want to add something else to the queue or switch station.
Try plugging into Ethernet, or placing it close to your router. If that fixes it, then you have a root cause.
Someone else has contacted me privately and recommended I switch off private MAC address on my phone. That seems to have improved things.
market leader? no idea. first-mover? wrong. Slim Devices were the first mover in this space with the Squeezebox (subsequently purchased by Logitech). Sonos came shortly afterwards.
I have multi-room streaming using “dumb” speakers, and copper wire (for audio and network). I control one content box and aim it at different speakers from my phone, tablet, laptop. Siri Shortcuts decouple me from waiting for an MBA to approve adding voice commands.
I know; brave flex sticking with simple wire versus going wireless.
There's not much in way of open source solutions to using it, and not many devices you would want to buy as a consumer that uses it, however.
But there are some? Can an arbitrary Linux box or Raspberry Pi be fitted with free software to receive AES67 over Ethernet from commercial solutions, or is there a catch?
So for AES67 receive, in principle no as PTP stack exists for RPI yet. You could cheat like the majority of manufacturers do and just play the audio as it arrives instead of using the timestamps. You'd also need a way of drifting the audio out clock to match the frequency of the PTP clock. If you didn't care about bitexact audio, you can resample, though ALSAs clock measurement kind of sucks.