Any idea on running a (very) small silent disco system?
For the last few summers I've tried (and failed) to get a silent disco system working for a small group of friends. The requirements are
- Anyone should be able to join (locally) with a phone and a pair of bluetooth headphones. With the absence of headphone jacks I've found most people rely on bluetooth headphones.
- Low enough latency.
- Decent enough audio fidelity.
- No weird monetized apps you have to sign in to.
In a post covid age where we all had low latency video calls, it seems crazy there isn't an obvious way to have <10 people connected to one 128kbps audio stream. Here are the shortcomings
-
Most silent disco systems (for events) use FM to broadcast to FM receivers. Broadcasting without a license is technically illegal, but easy enough to do. The lack of wired headphones means most phones no longer support receiving FM frequencies, as they used the headphone wire as an antenna. It's not ideal checking up on everyone's phone models to see whether or not they support FM ahead of time.
-
Throughout covid we used Discord to listen to music together many miles apart. The trouble is bluetooth does not have enough bandwidth for speakers and a microphone. So - those with wired headphones it worked perfectly, but with bluetooth headphones the audio drops to landline phone quality, far below what's listenable. Discord supports 'Stage' calls where some participants are talking and others are only listening. Unfortunately this doesn't disable the microphone for the audience, and so the audio is still poor.
-
Lastly is streaming. This solves everything above but the latency is too high. Using software called 'Stream What You Hear' allowed us to create a webpage with a stream running, but each person could be many seconds ahead or behind depending on when they loaded the stream. Attempts to sync everyone up would fail if someone accidentally locked their phone.
I'm wondering if the solution is going to have to be a bit more technically minded, which I'm open to investigating, but wondered if anyone here had any ideas to bounce.
Thanks in advance!
EDIT: I tried SnapCast as recommendation by @arch and it seems to do exactly what I was setting out to achieve, and FOSS software too! Thanks to everyone for their suggestions and help, I'm really excited to trial it.
There's a software named Snapcast that I use to stream the same music to different rooms & speakers my house. It has a native Android app and also runs a basic webserver that people can browse to listen to the stream. It tries to synchronize the audio, and synchronization is able to be customized by each client. Bluetooth adds a variable latency that is going to be difficult if not impossible to overcome, though. Like 100-200 ms difference, not on the order of seconds. I'm not sure how much this will matter to you. You might need a Linux based system to run the server, though.
It can be opened up and run over the web, too.
I think 100-300ms could be totally workable. I could definitely run a server via a Linux based system.
My worry is accessing the stream via the browser. My understanding is it opens a seekable player that, depending when the browser opens the link, changes at what timestamp the player starts (causes the multiple seconds of delay mentioned in my third example)
Could I ask what means you had other devices connect to the stream?
I think this is one you should look further into. You might have to install an app instead of using a web browser, but it seems designed well for your use case, considering most people use it to sync speakers across multiple rooms in their house.
I have not had the experience of the web browser for Snapcast opening a pausable stream in the browser. I highly doubt it's seekable even if it does this, because it's streaming a FIFO socket.
You wouldn’t necessarily know it from how many janky implementations are out there, but browsers have some surprisingly robust support for interacting with the local media buffer, even if it’s constructed from an ephemeral stream. Looks like the web client does at least theoretically allow it, but if you’re not seeing it in the primary UI I think OP should be in the clear!
To be honest even if they are seeing it in the UI I think your suggestion here is by far the right choice. With only ~10 people, you just say “hey, don’t hit the seek button”, and if someone does accidentally go out of sync they can just refresh the page.
[Edit] @TooFewColours For complete clarity, even if it is seekable in the UI I wouldn’t expect a delay anything close to a second with this option. If you were seeing that on a previous attempt depending on when each person loaded the stream it was probably an issue with DASH/HLS segment size, 4 - 6 seconds variability would be about average if CMAF (the tech that lets those segments get split into much smaller chunks) isn’t configured. As I understand it Snapcast will be using TCP directly rather than HTTP, so it should have much better sync than even CMAF.
I managed to install Snapcast earlier today and just working through it (a little more technical than I usually dabble in, but seems manageable). Looks like a promising solution, so fingers crossed - I'll report back if it works!
Nice one! Fingers crossed it does the job.
It works! Thanks @arch for the recommendation. It took a bit of shifting things around as I'm on Fedora with Pipewire, but turns out it was very straightforward.
Snapweb perfectly syncs audio over WiFi, so there's no woes regarding seekable players. There are still the whims of bluetooth latency as expected - I tested a few devices around my home and some were off quite badly, but others were pretty much aligned.
I had the idea that I could set up multiple sources +/- a few 100ms so people could roughly line themselves up if necessary, but it seems like there is one global buffer value, and it would otherwise need to be tweaked through snapclient, which I don't believe Snapweb supports the configuration of from what I can tell.
If anyone has any final ideas on that, let me know. Given that's the nature of Bluetooth I think this solution is as ideal as I could have hoped for - I'll just have to trial it next week when everyone's together.
Thanks a bunch!
I've had the same issue with Bluetooth headphones on Windows but there are ways to fix this. In the settings you can switch to a non-microphone version of the device and it'll stream audio without any microphone input, which fixes the low-quality output issue.
If you have a separate microphone, you could turn off the headphone microphone through the settings. Might be a solution?
Do you think something like this would be possible on Android+iPhone? Since that's what the headphones/microphones will be connecting to. I remember hitting a bit of a dead end looking into this at the time.
Worth noting that it sounds like your discord issue wasn’t an overall bandwidth limitation but a bluetooth profile problem. Short version is that when the mic is enabled, the whole device will often use the HSP or HFP profile - which were specced 20+ years ago for phone calls, so your landline comparison is pretty much spot on. If you force it over to A2DP (may happen automatically when you disable the mic, may need to be changed in the Bluetooth settings specifically, unfortunately isn’t always clear or easy to do depending on device and OS), you’ll get the modern connection standard designed for listening to music with decent quality.
So everyone has their phone there which means they have a mini computer. Their headphones connect to their phone.
How about running a wireless AP or have someone run a hotspot and then run up a Teams call? Everyone connects with headphones on mute or simply run a Teams webinar with no video?
Any radio broadcasting software, even something like old icecast would work. Then it's browser or rtsp stream.
If you like any ideas like this I'll do a quick search and build out the full solution for you.
Thanks for the reply!
My gut says that connecting via Teams will have a similar issue to discord regarding the bandwidth of bluetooth, even muted or without video, but definitely worth a try - the software might work differently.
Given our lack of success with streams in the past, does the broadcasting software you mentioned have a means to ensure those receiving the stream are synced up? The latency doesn't have to be perfect (especially after a couple drinks), but anything 1000ms or up is probably going to be noticeable.
It's actually not illegal to broadcast FM (or AM) radio! It's only illegal if your transmitter is working over a given power level. Consult your local
librarybroadcasting authority for details; although I know that radio rules are pretty similar across the world, there are always differences and broadcasting in those bands may actually be illegal.I think one of the key ingredients with most silent discos is that they have the headsets that change colors to match what it's tuned into. It prevents the dance floor from being overwhelmed by people yelling out "WHAT CHANNEL ARE YOU ON?" With that in mind, you might want to buy the dedicated headsets.
In any case, I think plain old radio is the ultimate answer. You need to have the clients all synchronized to the same beat, and to my knowledge there is no application that will sync the time with any kind of precision. Unfortunately this means that it's going to be a relatively expensive solution. Dedicated silent disco headsets seem to go between $10-30 each when bought in quantities of 100 on Alibaba. You could go cheaper by getting standard FM reciever headphones but those are so niche these days they're not particularly cheap and have their own problems. Luckily it sounds like you are not dealing with a huge group, so the total wouldn't be too high.
I wonder if a self hosted Shoutcast/Icecast server would do what you want. I think you can specify passwords so it doesn't broadcast to the world. I remember making one back when I was in college radio; they're fairly simple to get up and running.
https://help.geckohost.nz/article/complete-login-guide-shoutcast-icecast/
I believe this runs into the issues I highlighted in the third attempt, but I could be mistaken. Watching this video at 5:33 he loads into the broadcast in much the same way we connected to the stream, the trouble was each device would connect to the stream at a different point, and be various seconds behind or ahead.
It seems like a good broadcasting solution where latency of a few seconds doesn't matter, but unfortunately makes or breaks a silent disco.
Let me know if you think I'm wrong! Or if there's a client (available on iOs and Android) that can somehow ensure it's connecting to the stream with minimum latency.
This is an interesting problem! This is probably not very helpful to you, but I found this page describing some pretty old software that did this, including alternatives (at the time), technical challenges, and some details on the eventual implementation. It might be helpful if you wanted to write your own software to do the same, but I'm guessing that's out of scope. :)
edit:
This blog post from the comment section of the link I posted above may have a solution that would actually work in modern day, so it may be worth looking into as well...
Wow 2002! And you're right, these are a few hairs more technical than I think I'd be able to wrap my head around, and seem more focused on eliminating as much latency as humanly possible (because speakers playing out of sync is jarring, but matters less when each person is listening through person headphones)
I did find this talk from a while back, which is a system to start a disco anywhere without internet connection. Again, we have the luxury of an internet connection in a house, so it feels like extra layers of complexity.
Could you describe what a disco is in this context? I’m imagining people silently rocking out in bell bottoms and airpods at their desks, but I don’t think that’s what you’re aiming for …
Re. Bluetooth, although it’s not a useful distinction in this case, the issue isn’t bandwidth. It’s that the protocol for transmitting and receiving audio (HFP) is much, much older than the standard for just receiving audio (a2dp or one of the aptX flavours). There’s no technical or physical reason that it’s this bad, manufacturers just can’t agree on what to do. This article seems like it goes over the problem, but I admittedly only skimmed it … hopefully it’s a better summary than my blurb.
Your description is pretty much on point minus the bell bottoms. Essentially everyone is listening to the same song at the same time through a personal set of headphones. In this case bluetooth headphones connected to phones.
I don't exactly understand the bluetooth limitation, I must have read somewhere the issue was bandwidth, apologies if that isn't entirely accurate. In any case, I believe phones enter a sort of 'call mode' which limits the device, and I've yet to find some software/an app that allows you to choose whether or not to enter this mode when in a call (because most people aren't using it for silent discos).
The base limitation with bluetooth is that there are 2 separate bluetooth profiles, A2DP (Advanced Audio Distribution Profile) and HSP/HFP(Headset and Hands-Free Profiles). A2DP is that profile that actually sounds like good audio, but as soon as a microphone is requested, it switches to a HSP/HFP profile, which has a significantly lower bitrate (16 kHz) and sample size (8 kHz) compared to the A2DP profile which supports up to ~320 kHz sample rate in the High Quality SBC codec.
I've done a bunch of stuff in the real-time audio and video space and this is a fun question! I think there's two overall problems you're working with:
From what I can tell, there isn't really any open source or otherwise turnkey solution for this. Web based technologies for streaming low-latency audio is generally found in WebRTC. This is the technology that Discord and Teams (probably) uses for shared voice chats. The most accessible way to do this is probably to set up a WebRTC broadcast where you broadcast audio to participants.
This may not be as simple as it sounds. Lets say you're broadcasting to 10 people. The broadcaster needs to have enough low-latency outbound bandwidth to be able to send audio data to 10 people. Each user you broadcast to requires more bandwidth on the broadcaster. This experiment lets you play around with something similar. Building something like this for just a handful of people on the Web (<= 10 participants) is probably fairly simple. Higher listener counts usually involve infrastructure like SFUs (Selective Forwarding Units) and caching layers which help manage the amount of bandwidth necessary.
I'm active in a niche community of anime DJing and we mostly use OBS to broadcast to Twitch. We then hand the Twitch link to other people and everyone just listens to Twitch streams. Twitch handles the necessary machinery to host audio segments on a CDN and decrease the amount of bandwidth required for the broadcaster. While there is definitely more latency on this than a "true" WebRTC (or better yet a RTP/RTSP/RTMP connection), most of the listeners will have a stable amount of latency through Twitch and will receive the same experience. As long as the broadcaster also listens in on Twitch, they can understand the experience that the listeners have.
You might be able to just buy a sack of old, cheap mp3 players that could do FM radio. They probably come with wired headphones. It would be very
low qualityretro!Ha this did occur to me too! Trouble is I would have to lug around a sack of headphones and receivers when travelling from A-to-B, bringing more or less depending on how many people show up. We live in a society where everyone carries very powerful computers in their pockets - we should be able to use them!
Fair enough. I wish manufacturers had just left us the headphone jack instead of saving pennies per device to force us into using Bluetooth devices.
https://www.ampme.com/about?locale=en_US
Looks like this would work for exactly what you need!
Alternative, https://soundseeder.com/ but that seems to be Android only.
Would https://sync-tube.de/ work? I like it because it's a free service, no need to log in, just start up a "room", paste youtube links into the playlist, and share the room URL with friends so they can watch in sync with you. UX works fine on mobile.
My friends and I use it to do "karaoke parties" on video calls. It's not 100% latency-free since we're all in different places around the world... but if you and your friends are all just in one place, with everyone's phones connected to the same wifi, it could work better maybe? Then everyone can just use their own earphones with their own phones.
Edit: Ok I tried it just now with my phone and tablet connected to the same wifi. It's not lag-free but I think it's ok enough for silent disco use!
Could you set up a local server with software like wowza, stream you mix into the server and setup a small locally hosted webpage with a media player playing the stream?
( streamed videos to hundreds of people using a set up based on this back in the mid 00's, should work for a small audio session)
Echoing a few other comments, I've not had luck with a media player on a webpage as a way to access the stream - the media player will start at a different timestamp depending on when it connects. Works fine for internet radio or broadcasting a video, but being a few seconds out makes or breaks a silent disco.
To go down the streaming route I'd need a way for both Android and Apple to load the stream at approximately the same point as everyone else who has loaded the stream.