Enhancement: Play audio on web homepage

[gayde2]

Is your feature request related to a problem? Please describe. Not a problem, but this would be a cool feature for debugging and watching your own show.

Describe the solution you'd like Instead of just sending the sequence audio out over the headphone jack, have it also be able to play through the website. That way, if you navigate to it from a phone or other computer, you'll be able to hear what is playing. This would remove the need to have your own portable FM radio.

Describe alternatives you've considered I looked into PulseAudio streaming and VLC streaming, but that's very complicated and I wouldn't want to mess anything up with the way audio is routed currently.

Additional context A basic checkbox to enable audio streaming on the home status page next to the volume slider.

[ghormann]

There would be no way to have the music in sync with the lights.

[gayde2]

Why not? The music could just be offset to stream a bit earlier than the lights.

[cpinkham]

This idea comes up every couple years and unfortunately we keep shooting it down. Streaming audio over the internet will never be in sync with the display due to issues in different latency in the networks used to carry the data. Some users might be streaming over 2G cellular, some 3G, some LTE, some 5G, and some might be Comcast cable subscribers who are connected to the xfinity hotspot in the house across the street. The latency in each of these will be different. It also will be different for the user streaming the audio to the internet, some will be on DSL, some on a cellular hotspot, some on a cablemodem maxed at 5Megabits per second upstream and other on Gigabit Ethernet with no upstream bandwidth cap. No one delay setting will handle all of the unique situations. We already have enough issues with newer radios which can 'pause' the FM radio stream because they record the audio stream and play it back simultaneously. These radios often cause delayed audio which is not in sync with the lights and we have had reports from users with viewers who complained (or noticed) that the audio was not in sync on their radio. Some users have proposed having the viewers connect to the 'show' WiFi router to stream audio, but that will still have some of the same issues and would probably be better suited for a FPP plugin than a core feature of FPP itself.

Closing the ticket since this is something we have looked at several times before. Any further discussion or ideas are better suited for the forum or Facebook group.

[mwalden2004]

Going to bump this as I have an idea. You can compute ping from the server to the client (at least reasonably) by just sending a request that has a response with no logic, and preferably a small response size, and then calculating time from end to start. Then the client can send a request every few seconds to find the current playing time, and ping to re-seek the playing audio on the client. This should be easy, as the web client already shows what is playing, and the time it's at. So all it needs to do is pull down the already available audio file and play it and do it's best to just make sure it starts at the same time, and re-adjusts to put it back in sync if it gets unreasonably out of whack (which should not happen) This is really useful for testing the display without having to bring a radio out.

[meastman]

@mwalden2004 That's basically what I did when I started playing with the idea to implement a proof-of-concept.

I have a simple web server that:

• listens for FPP multisync packets
• streams a modified version of the multisync data using server-sent-events; it sends the logical start time of the audio (server time - current offset) so that latency of this stream doesn't really matter
• has an api that just returns the server time
• serves a simple web page
• serves audio files

The JS on the web page:

• uses the server's time api to estimate latency and compute client/server time deltas
• uses that information and the SSE stream to determine which song and offset the client should be playing
• uses the html audio element for playback
• syncs audio with the show using audio.currentTime for large adjustments or audio.playbackRate for small adjustments

The method it's using currently works great on Android Chrome and most desktop browsers, but the last I tried, iOS Safari didn't fully implement audio.playbackRate, making it nearly useless for most of my audience. I plan on spending some more time after light season to try to find a solution for iOS, and I'll update here if found.