Live data from Hacker News

Show HN: Beatsync – perfect audio sync across multiple devices

github.com

131–135 of 135 posts

Re: Show HN: Beatsync – perfect audio sync across multiple devices

#131
post #127
post #19

Earlier quoted context omitted.

> This speaker is 300 feet away from its output through X meters of copper; figure out my additional latency offset for me. 0.3 microseconds. The period of a wave at 20kHz (very roughly the highest pitch we can hear) is 50 microseconds. So - more or less insignificant. Cable latency is basically never an issue for audio. Latency due to speed of sound in air is what you see techs at stadiums and performance halls tuni…

Oh, thanks for correcting me! Now that you mention it, I'm confused by a memory I have. Wired speakers seem to be less common these days but I remember being told about two decades ago that the "proper" way to install speakers was to run out equal lengths of speaker cable (basically just jacketed copper, afaik) to different speakers even if they weren't equidistant in a room. (This was advice for home installation, n…

Superstition for sure.

Re: Show HN: Beatsync – perfect audio sync across multiple devices

#133
post #97

Earlier quoted context omitted.

Snapcast has a webapp and a native android client. Although I'm not sure how well it handles many, many clients. In theory, if all on the same WiFi they should all play in sync like a silent disco (at least for those not using Bluetooth headphones where the playback latency is too high/not available).

Web radios handle many clients. The first problem could be if the Wi-Fi hot spot can handle that many clients. The second one is that web radios and their protocols usually don't care if two clients are not in sync. They are usually in different places, maybe different continents. I'm self hosting a web radio for my LAN at home. I set it up years ago, I'm not there so I can't check the details but I think it is: Icec…

They handle many clients but they absolutely do not play in sync. That's never a requirement for them and I'm not aware of any web radio protocol supporting that feature. Web radio is not the right solution for a silent disco type situation where you can at least guarantee everyone is relatively local.

Re: Show HN: Beatsync – perfect audio sync across multiple devices

#134
post #103

If you do RTP with pulseaudio you can know the latency of all devices and have it synced by design - no extra software needed, device agnostic. If it somehow runs linux it will "just work".

Works with pipewire too, although the user-facing docs are pretty sparse

Here are my server and client configs needed in case someone comes across this from google. It sets up sinks and sources, so you can just mute it, but it would just play automatic from logon:

Needed on Server and Clients is an override to a) fix my domain users having the same cookie if its stored in default location and b) make sure the server only starts when the network is REALLY up - the normal network online is a system service only and thus you cannot check for it in a users service. In my case the server runs under a domain users profile.

~/.config/systemd/user/pipewire-pulse.service.d/override.conf

  [Unit]
  After=user-network-wait.service avahi-daemon.service

  [Service]
  # this changes the location of the cookie because i use roaming homes for domain clients and each machine would have the same cookie
  ExecStartPre=/bin/bash -c 'systemctl --user set-environment PULSE_COOKIE=/run/user/$(id -u)/pulse/cookie'
~/.config/systemd/user/user-network-wait.service

  [Unit]
  Description=Wait for Network Connectivity

  [Service]
  Type=oneshot

  # This pings your LAN router and creates a network-online file in /run to pick up
  ExecStart=/bin/bash -c '[ -f /run/user/$(id -u)/network-online ] || (until ping -c1 10.126.0.1 >/dev/null 2>&1; do sleep 1; done; touch /run/user/$(id -u)/network-online)'
 
  [Install]
  WantedBy=default.target
Server Pulseaudio:

Not needed but very useful:

/etc/pipewire/pipewire-pulse.conf.d/50-networkparty.conf

  context.exec = [
      { path = "pactl" args = "load-module module-native-protocol-tcp auth-anonymous=yes listen=10.126.1.1 auth-ip-acl=127.0.0.1;10.126.0.0/16" }
  ]
# needed. Note how to to make sure s16le is used across all devices to keep conversion to a minimum and how to name the sink somewhat sane

/etc/pipewire/pipewire-pulse.conf.d/70-rtp-sender-sink.conf

  context.exec = [
    { path = "pactl"        args = "load-module module-null-sink sink_name=rtp_sender_sink format=s16le channels=2 rate=48000 sink_properties='device.description=\"RTP Sender Sink\"'" }
]

/etc/pipewire/pipewire-pulse.conf.d/71-rtp-sender-23912611.conf

  context.exec = [
    { path = "pactl" args = "load-module module-rtp-send source=rtp_sender_sink.monitor source_ip=10.126.1.1 destination_ip=239.126.1.1 port=5004 inhibit_auto_suspend=always" }
  ]
You can play to the sink f.e. in mpd with:

  audio_output {
    type "pulse"
    name "RTP Sender Sink Pulse"
    sink "rtp_sender_sink"
  }
Client Pulseaudio:

/etc/pipewire/pipewire-pulse.conf.d/71-rtp-receiver.conf

  context.exec = [
      { path = "pactl"        args = "load-module module-rtp-recv sink=combine_sink sap_address=239.126.1.1 latency_msec=64.3750" }
  ]
you can play with the latency_msec, journalctl will tell you the lowest fragment if you just put 0 or 1ms here. It needs to be a multiple of that minimum, just experiment. Im fine with this even though 12ms would also work in my lan, but its more stable across the wifi bridge.

The sap_address on the client may work to select the right multicast address even though its actually for the SAP announcements but don't count on that, i have not tested multiple streams so far and would not use "magic" solutions like SAP on the server (and they didn't work in my case and seem pipewire-only). Right now the client seems to pick the right stream - experiment ;)

The sink in my case is a module-combo, just check with pactl list sinks which sink you want the stream to play on. Note that this is not some application you can dynamically assign to other sinks!!

For LAN, if you run openwrt just enable igmp_snooping and multicast_querier on the softwarebridge (Luci --> Network --> Interfaces --> Tab Devices) and maybe Multi to Uni in your wifi advanced settings. I dont use this though as my wifi is another vlan or WDS-bridged so i stay out of these problems mostly.

There are more advanced settings possible with openwrt, including having working igmp_snooping on the hardware switch, if you are interested frequent my documentation (german) on Krei.se as i will write a guide for this sometime lol (or just ask me by DM). Its possible to run this ms-exact with clean network in any case, there is no need to install extra software or clog unused ports with multicast-traffic. If you are perfect about this the music will flow like water through your LAN only where its needed.

Re: Show HN: Beatsync – perfect audio sync across multiple devices

#135
post #26

Earlier quoted context omitted.

Sound travels at a speed of ~1 foot/millisecond

Wow it's insane how slow that is! But also, I don't really have an intuition for why the speed of travel is relevant here? It's funny that I have a natural intuition that sound is slow over long distances, yet 1 ft/s still feels astonishingly slow. And yet while I know light travels 1ft/ns, it's still astonishing that it takes 30ms to travel from London to Sydney at that speed.

sorry for late response

What I mean is that if you have multiple speakers around you, if any one is 1 foot closer or further than another, it'll be off by a millisecond already. Given that most people probably aren't going to have sub-foot positioning accuracy, sub-millisecond timing accuracy isn't critically important.

Post reply on HN