4 ms·

The question is: why? Why distribute the music that way, why not just attach it to a radio directly, or some RPi that will pull the stream, or just have it prer

by pfoof 4y ago

The question is: why? Why distribute the music that way, why not just attach it to a radio directly, or some RPi that will pull the stream, or just have it prerecorded. Despite its simplicity, seems to be overengineered.

moffkalast 4y ago
Science isn't about why, it's about why not!
anyfoo 4y ago
> Why distribute the music that way Because distributing music over multicast works very well, and it's rather simple in nature: You get audio frames as UDP packets, you play them. Because it's multicast, they reach where they should. > why not just attach it to a radio directly Because you lose control of what's being played, and there are probably not many "elevator music" radio stations. > or some RPi that will pull the stream Because then every location that plays the music has to pull an individual stream, quickly saturating the bandwidth for no reason, instead of just subscribing to the multicast stream. I also would not say "some RPi" is less engineering, and less maintenance, than the current solution that likely uses an off the shelf multicast audio system. > or just have it prerecorded Because you lose control of what's being played without a significant replacement step, when you could just play a multicast stream instead. > Despite its simplicity, seems to be overengineered. I'm honestly not convinced I read a less "overengineered" solution so far...
- hot_gril 4y ago
  > I'm honestly not convinced I read a less "overengineered" solution so far... Prerecorded music on an MP3 player sounds like the one simpler solution, though it wouldn't put the elevators in sync with each other or let you control it remotely.
  - anyfoo 4y ago
    Yes, but if you want to do even as much as not play the music in the middle of the night, now your MP3 player needs a clock. That clock may drift, or it may drop out completely when the power goes out, unless you synchronize that clock over the network. But if you have network on your MP3 player, you may as well let it subscribe to the multicast stream instead of reading the stream from internal storage. If you do not have network, and you want to change the schedule of when your music plays, have fun to send out some maintenance crew to every single one of those devices. And don't forget any...
    - hot_gril 4y ago
      Yeah, this is if you just want your playlist on loop 24/7, which seems reasonable in many scenarios.
      - burntwater 4y ago
        In the U.S. at least, most jurisdictions will require the music to be shut off in an emergency -- namely, if the fire alarm goes off. Audio sources commonly are required to have a relay/GPIO input that triggers the shutoff, a network command is not good enough (network switches typically not being life safety rated). In this hotel scenario, you have one audio source that can be located in a location that can be conveniently tied into the fire alarm relay panel. Stop the audio there and you've stopped it everywhere.
        hot_gril 4y ago
        That makes sense, never mind the MP3 player solution then.
- ibz 4y ago
  >> why not just attach it to a radio directly > Because you lose control of what's being played, and there are probably not many "elevator music" radio stations. Radio is still by far the simplest and most fail-safe solution. But not playing an existing radio station. Rather buying a radio transmitter, like the ones used in churches - strong enough to emit FM throughout the hotel, and yet not requiring a radio license. Then the speakers would just be plain speakers with a FM receiver attached - no more wifi/wired infrastructure involved, routers, ability of the speakers to connect to the wifi, ...
  - anyfoo 4y ago
    I think this might have been a popular solution once, but my guess is that it came with its own set of problems. Hotels often being pretty big (bigger than most churches, which also tend to be relatively open structures), usage of the license free bands from other devices, audible interference (which you don't care about in ham radio or portables as long as you can still understand what's being said, but for music in a hotel even low interference is bad as soon as it's audible)... though admittedly, I have no experience with radio transmitters for that particular use case.
kalmi10 4y ago
This sounds like an easy way to keep the players in sync. That is important if you have multiple players nearby each other on the same corridor.
jcrawfordor 4y ago
This is pretty much the simplest feasible way to do distributed audio over IP, and it's commonly implemented by commercial distributed audio amplifiers. The advantage of IP distributed audio is that it functions over the existing IP network, so it avoids the need to wire a high-voltage audio system (which will still require multiple amplifiers in large buildings) or dedicated signal-level wiring to distributed amplifiers. It also tends to be more reliable as the IP network is more robust to issues like crosstalk and poor connections that can turn into frustrating troubleshooting on analog systems. "Some RPi that pulls the stream" is exactly what this system is except it uses multicast for significantly reduced bandwidth usage and the receivers are presumably commercially-supported distributed audio equipment. No hotel wants to be doing patch management for embedded Linux devices.
- kccqzy 4y ago
  I don't think multicast significantly reduces bandwidth usage. Traffic needs to go everywhere anyways. It will probably reduce CPU usage since switches (even dumb ones) can just broadcast the packet at line speed, since it's all in the hardware. There's no need for whatever server is distributing the stream to maintain multiple sockets and copy buffers multiple times.
  - anyfoo 4y ago
    With unicast, the node originating the stream would have n times the traffic, where n is the number of devices pulling the stream. Further from the originating node in the network topology, each edge would transport as many times the traffic as there are listeners whose traffic travels along that edge. That seems very significant. With broadcast, all the nodes and edges transport the stream only once, but you can only distribute the stream in the same (L3) network, and within that network you transport the stream even through L2 nodes and edges (i.e. network switches, cables, Wi-Fi channels) where there are no listeners at all. You could in theory repeat those broadcast packets into other networks, but you need to set that up more explicitly, and then every node and edge in that network gets the traffic, too. With multicast, devices and effectively segments can subscribe to the stream, and all nodes and edges transport the stream at most once, and they can do so across network boundaries while retaining the same property, and using a standardized mechanism that is designed to make the traffic only go where it needs to go as much as the topology allows.
snickerbockers 4y ago
those suggestions all seem way more over-engineered than just using multicast packets
berjin 4y ago
It probably functions as a fire alarm and PA so having the ability to control the content is important. The hotel already has radio - Wifi.

by pfoof 4y ago

moffkalast 4y ago

Science isn't about why, it's about why not!

anyfoo 4y ago

> Why distribute the music that way Because distributing music over multicast works very well, and it's rather simple in nature: You get audio frames as UDP packets, you play them. Because it's multicast, they reach where they should. > why not just attach it to a radio directly Because you lose control of what's being played, and there are probably not many "elevator music" radio stations. > or some RPi that will pull the stream Because then every location that plays the music has to pull an individual stream, quickly saturating the bandwidth for no reason, instead of just subscribing to the multicast stream. I also would not say "some RPi" is less engineering, and less maintenance, than the current solution that likely uses an off the shelf multicast audio system. > or just have it prerecorded Because you lose control of what's being played without a significant replacement step, when you could just play a multicast stream instead. > Despite its simplicity, seems to be overengineered. I'm honestly not convinced I read a less "overengineered" solution so far...

hot_gril 4y ago
> I'm honestly not convinced I read a less "overengineered" solution so far... Prerecorded music on an MP3 player sounds like the one simpler solution, though it wouldn't put the elevators in sync with each other or let you control it remotely.
- anyfoo 4y ago
  Yes, but if you want to do even as much as not play the music in the middle of the night, now your MP3 player needs a clock. That clock may drift, or it may drop out completely when the power goes out, unless you synchronize that clock over the network. But if you have network on your MP3 player, you may as well let it subscribe to the multicast stream instead of reading the stream from internal storage. If you do not have network, and you want to change the schedule of when your music plays, have fun to send out some maintenance crew to every single one of those devices. And don't forget any...
  - hot_gril 4y ago
    Yeah, this is if you just want your playlist on loop 24/7, which seems reasonable in many scenarios.
    - burntwater 4y ago
      In the U.S. at least, most jurisdictions will require the music to be shut off in an emergency -- namely, if the fire alarm goes off. Audio sources commonly are required to have a relay/GPIO input that triggers the shutoff, a network command is not good enough (network switches typically not being life safety rated). In this hotel scenario, you have one audio source that can be located in a location that can be conveniently tied into the fire alarm relay panel. Stop the audio there and you've stopped it everywhere.
      - hot_gril 4y ago
        That makes sense, never mind the MP3 player solution then.
ibz 4y ago
>> why not just attach it to a radio directly > Because you lose control of what's being played, and there are probably not many "elevator music" radio stations. Radio is still by far the simplest and most fail-safe solution. But not playing an existing radio station. Rather buying a radio transmitter, like the ones used in churches - strong enough to emit FM throughout the hotel, and yet not requiring a radio license. Then the speakers would just be plain speakers with a FM receiver attached - no more wifi/wired infrastructure involved, routers, ability of the speakers to connect to the wifi, ...
- anyfoo 4y ago
  I think this might have been a popular solution once, but my guess is that it came with its own set of problems. Hotels often being pretty big (bigger than most churches, which also tend to be relatively open structures), usage of the license free bands from other devices, audible interference (which you don't care about in ham radio or portables as long as you can still understand what's being said, but for music in a hotel even low interference is bad as soon as it's audible)... though admittedly, I have no experience with radio transmitters for that particular use case.

kalmi10 4y ago

This sounds like an easy way to keep the players in sync. That is important if you have multiple players nearby each other on the same corridor.

jcrawfordor 4y ago

This is pretty much the simplest feasible way to do distributed audio over IP, and it's commonly implemented by commercial distributed audio amplifiers. The advantage of IP distributed audio is that it functions over the existing IP network, so it avoids the need to wire a high-voltage audio system (which will still require multiple amplifiers in large buildings) or dedicated signal-level wiring to distributed amplifiers. It also tends to be more reliable as the IP network is more robust to issues like crosstalk and poor connections that can turn into frustrating troubleshooting on analog systems. "Some RPi that pulls the stream" is exactly what this system is except it uses multicast for significantly reduced bandwidth usage and the receivers are presumably commercially-supported distributed audio equipment. No hotel wants to be doing patch management for embedded Linux devices.

kccqzy 4y ago
I don't think multicast significantly reduces bandwidth usage. Traffic needs to go everywhere anyways. It will probably reduce CPU usage since switches (even dumb ones) can just broadcast the packet at line speed, since it's all in the hardware. There's no need for whatever server is distributing the stream to maintain multiple sockets and copy buffers multiple times.
- anyfoo 4y ago
  With unicast, the node originating the stream would have n times the traffic, where n is the number of devices pulling the stream. Further from the originating node in the network topology, each edge would transport as many times the traffic as there are listeners whose traffic travels along that edge. That seems very significant. With broadcast, all the nodes and edges transport the stream only once, but you can only distribute the stream in the same (L3) network, and within that network you transport the stream even through L2 nodes and edges (i.e. network switches, cables, Wi-Fi channels) where there are no listeners at all. You could in theory repeat those broadcast packets into other networks, but you need to set that up more explicitly, and then every node and edge in that network gets the traffic, too. With multicast, devices and effectively segments can subscribe to the stream, and all nodes and edges transport the stream at most once, and they can do so across network boundaries while retaining the same property, and using a standardized mechanism that is designed to make the traffic only go where it needs to go as much as the topology allows.

snickerbockers 4y ago

those suggestions all seem way more over-engineered than just using multicast packets

berjin 4y ago

It probably functions as a fire alarm and PA so having the ability to control the content is important. The hotel already has radio - Wifi.