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@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Fear is finding a ".vbs" script in your Inbox - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
