Hello everybody,
Huh, it's been a while... :-)
I'm interested in your suggestions/experience regarding multimedia tools for streaming audio and possibly also video via LAN (mostly WiFi), played back on multiple client machines, with little to no latency.
You know --- say I want to play some music on my laptop in the living room, and I want to hear the same thing play on another computer in the kitchen, and another one in the garage, etc... ;-)
Ideally, it should be low-latency, in the sense that playback should be synchronized across devices. Like, if two machines are playing in two rooms, and I'm in the hallway in between them, I shouldn't hear any offset between the two playbacks.
I'm looking for Linux-centric solutions in general, but mostly from Fedora or CentOS land. It should do audio, while video would probably depend on the WiFi speed, I guess.
So far, I've been thinking of a DIY combination of bash scripts and mplayer, but I guess it's easier to try out something that someone already made, before I end up mocking up the whole thing from scratch myself.
Looking for any pointers and suggestions (including keywords for google). ;-)
TIA, :-) Marko
On 12/17/18 4:27 PM, Marko Vojinovic wrote:
I'm interested in your suggestions/experience regarding multimedia tools for streaming audio and possibly also video via LAN (mostly WiFi), played back on multiple client machines, with little to no latency.
You know --- say I want to play some music on my laptop in the living room, and I want to hear the same thing play on another computer in the kitchen, and another one in the garage, etc... ;-)
Ideally, it should be low-latency, in the sense that playback should be synchronized across devices. Like, if two machines are playing in two rooms, and I'm in the hallway in between them, I shouldn't hear any offset between the two playbacks.
https://github.com/Logitech/slimserver (Logitech Media Server)
https://github.com/ralph-irving/squeezelite.git (client)
LMS has many plugins to serve local files or internet streams. There might be one to send local audio to it. The squeezelite client has really good synchronization. Aside from the builtin web interface, there is an open-source Android app (Squeezer) to control the server to choose the music for individual clients and to sync the clients.
On 12/17/18 4:27 PM, Marko Vojinovic wrote:
Hello everybody,
Huh, it's been a while... :-)
I'm interested in your suggestions/experience regarding multimedia tools for streaming audio and possibly also video via LAN (mostly WiFi), played back on multiple client machines, with little to no latency.
You know --- say I want to play some music on my laptop in the living room, and I want to hear the same thing play on another computer in the kitchen, and another one in the garage, etc... ;-)
Ideally, it should be low-latency, in the sense that playback should be synchronized across devices. Like, if two machines are playing in two rooms, and I'm in the hallway in between them, I shouldn't hear any offset between the two playbacks.
I'm looking for Linux-centric solutions in general, but mostly from Fedora or CentOS land. It should do audio, while video would probably depend on the WiFi speed, I guess.
So far, I've been thinking of a DIY combination of bash scripts and mplayer, but I guess it's easier to try out something that someone already made, before I end up mocking up the whole thing from scratch myself.
Looking for any pointers and suggestions (including keywords for google). ;-)
An issue I've dealt innumerable times in my ~20+ years in the streaming business.
Most streaming platforms now use quasi-HTTP connections to packetize the stream content (HLS, HDS, MPEG-Dash, et al.). As clients connect, they're given a "playlist" of these packets. Depending on the server and how it's set up, the server may have "n" "current" chunks, passes "n-1" chunks in a playlist, and expect the player to request another playlist when the last chunk starts playing. The gotcha here is that each client will get a slightly different playlist. Synchronization between multiple clients is almost impossible in this scenario if the current chunk list is more than one. One can try to mitigate it by making the current chunklist and the playlist exactly the same length, but that's not always possible.
Older technologies such as Icy (Shoutcast/Icecast) and RTSP (the old RealNetworks protocol) do support client synchronization (sorta), but due to the inherent latencies in decoding the data, absolute synchronization is also difficult (you'll hear the differences).
As long as the data is packetized, seamless synchronizing among multiple clients is almost impossible IMHO. There's almost always a lag of some sort. It's not like broadcast radio or TV. Even digitized TV signals will display differently on different TVs in the same room due to signal reflections, hardware differences in the decoders, software, etc.
If you're trying to emulate the experience you might have in wandering through a shopping mall, malls typically use fully analog systems with a distribution amplifier feeding a bus where individual loudspeaker amps pick the signal off the distribution amplifier for local playback. No packetization, no decoding, nada. The only synchronization issues there are the speed of the signal on the bus (thank you, Grace Hopper). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Very funny, Scotty. Now beam down my clothes." - ----------------------------------------------------------------------
On 12/17/18 5:13 PM, Rick Stevens wrote:
Most streaming platforms now use quasi-HTTP connections to packetize the stream content (HLS, HDS, MPEG-Dash, et al.). As clients connect, they're given a "playlist" of these packets. Depending on the server and how it's set up, the server may have "n" "current" chunks, passes "n-1" chunks in a playlist, and expect the player to request another playlist when the last chunk starts playing. The gotcha here is that each client will get a slightly different playlist. Synchronization between multiple clients is almost impossible in this scenario if the current chunk list is more than one. One can try to mitigate it by making the current chunklist and the playlist exactly the same length, but that's not always possible.
What is needed in this case is an external synchronization to tell the players where they should be in the stream. However, in almost all internet streaming applications synchronization is irrelevant.
Older technologies such as Icy (Shoutcast/Icecast) and RTSP (the old RealNetworks protocol) do support client synchronization (sorta), but due to the inherent latencies in decoding the data, absolute synchronization is also difficult (you'll hear the differences).
As long as the data is packetized, seamless synchronizing among multiple clients is almost impossible IMHO. There's almost always a lag of some sort. It's not like broadcast radio or TV. Even digitized TV signals will display differently on different TVs in the same room due to signal reflections, hardware differences in the decoders, software, etc.
LMS has very tight synchronization. I have a client playing on the stereo and one on my laptop. If I stand between the rooms, there is no perceptible difference in the timing. It uses its own protocol and I assume there is some timing information involved. Remember that the original question was for an internal LAN, not over the internet.
On 12/18/18 12:11 PM, Samuel Sieb wrote:
On 12/17/18 5:13 PM, Rick Stevens wrote:
Most streaming platforms now use quasi-HTTP connections to packetize the stream content (HLS, HDS, MPEG-Dash, et al.). As clients connect, they're given a "playlist" of these packets. Depending on the server and how it's set up, the server may have "n" "current" chunks, passes "n-1" chunks in a playlist, and expect the player to request another playlist when the last chunk starts playing. The gotcha here is that each client will get a slightly different playlist. Synchronization between multiple clients is almost impossible in this scenario if the current chunk list is more than one. One can try to mitigate it by making the current chunklist and the playlist exactly the same length, but that's not always possible.
What is needed in this case is an external synchronization to tell the players where they should be in the stream. However, in almost all internet streaming applications synchronization is irrelevant.
Older technologies such as Icy (Shoutcast/Icecast) and RTSP (the old RealNetworks protocol) do support client synchronization (sorta), but due to the inherent latencies in decoding the data, absolute synchronization is also difficult (you'll hear the differences).
As long as the data is packetized, seamless synchronizing among multiple clients is almost impossible IMHO. There's almost always a lag of some sort. It's not like broadcast radio or TV. Even digitized TV signals will display differently on different TVs in the same room due to signal reflections, hardware differences in the decoders, software, etc.
LMS has very tight synchronization. I have a client playing on the stereo and one on my laptop. If I stand between the rooms, there is no perceptible difference in the timing.
Are you speaking of Logitech Media Server?
It uses its own protocol and Iassume there is some timing information involved. Remember that the original question was for an internal LAN, not over the internet.
Yes, it uses its own protocol, which means the clients must grok it and that will restrict its use. In a LAN environment, where you have very tight control over which clients you use, yes, it may be a valid option.
Note that the "standard" packetizing protocols will exhibit these synchronization issues even on a LAN because you have no control over the clients' playlist request timings due to the inherent asynchronous, transaction-oriented nature of the connections. If you could control that, then things would be different and it would require some sort of out-of-band signalling. The downside to the older, connection-oriented protocols like RTSP is that any given server could easily be saturated with connections. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Blessed are the peacekeepers...for they shall be shot at - - from both sides. --A.M. Greeley - ----------------------------------------------------------------------
On 12/18/18 12:52 PM, Rick Stevens wrote:
On 12/18/18 12:11 PM, Samuel Sieb wrote:
LMS has very tight synchronization. I have a client playing on the stereo and one on my laptop. If I stand between the rooms, there is no perceptible difference in the timing.
Are you speaking of Logitech Media Server?
Yes.
It uses its own protocol and Iassume there is some timing information involved. Remember that the original question was for an internal LAN, not over the internet.
Yes, it uses its own protocol, which means the clients must grok it and that will restrict its use. In a LAN environment, where you have very tight control over which clients you use, yes, it may be a valid option.
That is what the OP was asking for.
Note that the "standard" packetizing protocols will exhibit these synchronization issues even on a LAN because you have no control over the clients' playlist request timings due to the inherent asynchronous, transaction-oriented nature of the connections. If you could control that, then things would be different and it would require some sort of out-of-band signalling. The downside to the older, connection-oriented protocols like RTSP is that any given server could easily be saturated with connections.
And that is why applications that require tight synchronization use special protocols. Considering the accuracy that NTP can achieve over the internet, it's certainly possible to do it over a LAN.
Allegedly, on or about 18 December 2018, Rick Stevens sent:
Note that the "standard" packetizing protocols will exhibit these synchronization issues even on a LAN because you have no control over the clients' playlist request timings due to the inherent asynchronous, transaction-oriented nature of the connections.
As soon as you use playlists, you're going to have synchronisation issues. Each player wouldn't begin loading from the playlist at the same time, as the first problem to deal with.
You'd need to be broadcasting a stream, and have players that that simply replay the current live stream, to get past that hurdle. As well as for being able to handle what one speaker system does when it recovers from a signal hiccup.
The second hurdle will be decoding delays. You'd want to be using the same playback hardware and software, on every player, to *try* make everything have the same inherent delay.
WiFi speakers have special protocols to manage this kind of thing.
On 12/18/18 6:04 PM, Tim via users wrote:
You'd need to be broadcasting a stream, and have players that that simply replay the current live stream, to get past that hurdle. As well as for being able to handle what one speaker system does when it recovers from a signal hiccup.
That's what Logitech Media Server does. It sends a stream and the clients know what point they are at in the stream. Adding a client to a synchronization group causes a brief interruption in the output of all clients.
The second hurdle will be decoding delays. You'd want to be using the same playback hardware and software, on every player, to *try* make everything have the same inherent delay.
That's not necessary. You feed data ahead of the playing point, so the audio is already decoded when it comes time to play it.
On Mon, 17 Dec 2018 16:50:33 -0800 Samuel Sieb samuel@sieb.net wrote:
On 12/17/18 4:27 PM, Marko Vojinovic wrote:
I'm interested in your suggestions/experience regarding multimedia tools for streaming audio and possibly also video via LAN (mostly WiFi), played back on multiple client machines, with little to no latency.
https://github.com/Logitech/slimserver (Logitech Media Server)
https://github.com/ralph-irving/squeezelite.git (client)
LMS has many plugins to serve local files or internet streams. There might be one to send local audio to it. The squeezelite client has really good synchronization. Aside from the builtin web interface, there is an open-source Android app (Squeezer) to control the server to choose the music for individual clients and to sync the clients.
Thanks for the suggestion, I'll try it out! The wiki pages are quite extensive, I'm reading through some of it right now...
Btw, I don't see LMS packaged for Fedora in the standard repositories (nor rpmfusion). I don't mind using the source (it's mostly Perl, anyway), but just to check --- is it packaged in any of the repos I'm unaware of?
Thanks, :-) Marko
On Tue, 18 Dec 2018 21:34:29 -0800 Samuel Sieb samuel@sieb.net wrote:
On 12/18/18 6:04 PM, Tim via users wrote:
You'd need to be broadcasting a stream, and have players that that simply replay the current live stream, to get past that hurdle. As well as for being able to handle what one speaker system does when it recovers from a signal hiccup.
That's what Logitech Media Server does. It sends a stream and the clients know what point they are at in the stream. Adding a client to a synchronization group causes a brief interruption in the output of all clients.
The second hurdle will be decoding delays. You'd want to be using the same playback hardware and software, on every player, to *try* make everything have the same inherent delay.
That's not necessary. You feed data ahead of the playing point, so the audio is already decoded when it comes time to play it.
Guys, I'm surprised that this thing is so complicated to design. If I were to do it, I'd just have the server add a timestamp tag to each packet, indicating that "this packet is to be played at 09:34:27 GMT", and send enough packets ahead of time to clients. Each client then collects enough packets, decodes the data, and plays it according to the timestamps. Given that, any synchronization issues between the system clocks of the clients should be handled by NTP, which already does an excellent job.
Am I missing some obvious problem with such a design?
The only downside I see is that one cannot use it to stream live data, i.e. someone speaking through a microphone, since any data that is to be played back needs to be buffered at the client side (I guess several seconds of audio). But live streaming is a different beast, here we are mostly talking about music playback (like, mp3 or internet radio or such), so there is no problem with data being buffered.
And I'm also surprised that LMS is the only choice here? Could it really be true that nobody else implemented anything like this, ever? Because to me it sounds like a quite common thing to ask for. When I posted the question, I was expecting to receive at least 4-5 different suggestions, and then people would start fighting over which one is the most convenient, etc... Instead, I receive only one suggestion (LMS), and a bunch of responses that what I'm asking for is more or less impossible to design, which is quite surprising.
Best, :-) Marko
On 12/19/18 7:37 PM, Marko Vojinovic wrote:
Btw, I don't see LMS packaged for Fedora in the standard repositories (nor rpmfusion). I don't mind using the source (it's mostly Perl, anyway), but just to check --- is it packaged in any of the repos I'm unaware of?
I didn't find it packaged anywhere, but it's easy to use. Just run the perl script from a clone of the git repo. The client is simple as well. Just clone it and compile.
On 12/19/18 7:59 PM, Marko Vojinovic wrote:
Guys, I'm surprised that this thing is so complicated to design. If I were to do it, I'd just have the server add a timestamp tag to each packet, indicating that "this packet is to be played at 09:34:27 GMT", and send enough packets ahead of time to clients. Each client then collects enough packets, decodes the data, and plays it according to the timestamps. Given that, any synchronization issues between the system clocks of the clients should be handled by NTP, which already does an excellent job.
Am I missing some obvious problem with such a design?
Most software is designed for people that don't have any idea what NTP is. :-)
And I'm also surprised that LMS is the only choice here? Could it really be true that nobody else implemented anything like this, ever? Because to me it sounds like a quite common thing to ask for. When I posted the question, I was expecting to receive at least 4-5 different suggestions, and then people would start fighting over which one is the most convenient, etc... Instead, I receive only one suggestion (LMS), and a bunch of responses that what I'm asking for is more or less impossible to design, which is quite surprising.
I looked for a long time before I found this. I was starting to work on my own solution. I think the consumer market prefers pre-built solutions like the Sonos speakers. Also, I wonder if most people are more interested in personal audio anyway. They want earbuds, not multi-room systems.
On 12/19/18 9:13 PM, Samuel Sieb wrote:
On 12/19/18 7:59 PM, Marko Vojinovic wrote:
Guys, I'm surprised that this thing is so complicated to design. If I were to do it, I'd just have the server add a timestamp tag to each packet, indicating that "this packet is to be played at 09:34:27 GMT", and send enough packets ahead of time to clients. Each client then collects enough packets, decodes the data, and plays it according to the timestamps. Given that, any synchronization issues between the system clocks of the clients should be handled by NTP, which already does an excellent job.
Am I missing some obvious problem with such a design?
Most software is designed for people that don't have any idea what NTP is. :-)
And I'm also surprised that LMS is the only choice here? Could it really be true that nobody else implemented anything like this, ever? Because to me it sounds like a quite common thing to ask for. When I posted the question, I was expecting to receive at least 4-5 different suggestions, and then people would start fighting over which one is the most convenient, etc... Instead, I receive only one suggestion (LMS), and a bunch of responses that what I'm asking for is more or less impossible to design, which is quite surprising.
I looked for a long time before I found this. I was starting to work on my own solution. I think the consumer market prefers pre-built solutions like the Sonos speakers. Also, I wonder if most people are more interested in personal audio anyway. They want earbuds, not multi-room systems.
I don't know why I didn't think of this before. D'oh!
For prerecorded (even live) audio content, Icecast (open-source) or Shoutcast (proprietary) worked very well for us. Unlike HDS, HLS, MPEG- Dash and the like, it is connection-oriented. This means that clients play whatever the server is ingesting at the moment and remain connected to the server for the duration of the session. Because of this, any given server can only handle so-many clients (primarily limited by server bandwidth). In my experience, Icecast (at least) itself is fairly lightweight.
Icecast provides a description subchannel so the client can display "what's playing now (artist, album, song)". I think it's the most common mechanism used for internet radio stations other than apps such as "I Heart Radio" here in the US and most audio playback clients I've used support it.
If you may potentially have large numbers of clients, Icecast (at least) provides a "fanout" mechanism, meaning that a stream comes into an "ingest" server. That ingest server only allows client connections from "edge" servers and the edge servers are what clients connect to. You can have as many edge servers as are needed (up to what the ingest server can support). You could have multiple layers of servers (ingest- level1distro-level2distro-edge) with the understanding that each layer between the ingest and edge will insert a delay, but all clients should see the same delay. It also provides for some authentication mechanisms.
We used Icecast in the "ingest-edge-client" mode very successfully in the past (two "classes" of content, so two ingest servers and seven edge servers per ingest server). We've had simultaneous connections of >120K clients spread across all the edge servers with a total bandwidth of about 4.2Gbps at full song (pun intended).
Icecast is available from the standard repos:
icecast.x86_64 2.4.4-1.fc29 updates icecast-doc.noarch 2.4.4-1.fc29 updates
The maintainer (last time I checked) was based in the UK, was a truly nice chap and quite responsive and helpful.
Website: http://icecast.org/ ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Fear is finding a ".vbs" script in your Inbox - ----------------------------------------------------------------------
-
Marko Vojinovic -
Rick Stevens -
Samuel Sieb -
Tim