Hacker News Reader

Comment by geekuillaume | Hacker News Reader

Not my project but I've been using it for a year on 3 Raspberry Pi and it has been rock solid. I highly recommend it. The synchronization is perfect and it only adds a small delay (500ms max) to the music. I've configured Librespot to use this as a Spotify Play speaker and control it from the desktop or mobile Spotify app.

View on HN

Do you have the PIs hooked to amps? If so what are you doing for volume control?

Worth pointing out that the raspberry audio out has quite a bad rep quality wise:

http://raspberrypimaker.com/cheap-quality-audio-raspberry-pi...

Pimoroni has a line of £20 hats that help solve that: https://shop.pimoroni.com/collections/pirate-audio

I bought a couple, they're really good, my only dislike is that the screen software is written as a Mopidy plugin, but I'd prefer a remote mopidy instance and the pis and hats are just clients with controls.

Did you find a solution to the remote mopidy instance yet? I'd like to do the same thing.

I ended up using a (cheap) USB DAC to get around the RPi’s onboard audio. It’s a bit cheaper than a HAT, but can be hit or miss for compatibility.

For snapclient, I used a USB DAC at first, but turning it off and then on meant that snapclient lost its connection. I could not resolve that so I purchased a DAC HAT instead.

I assume this is only for the analog output, right?

Obviously if you're just using a cheap or old amp it won't have HDMI, but if you're amping with an A/V receiver you can just use the HDMI out and get perfectly good quality.

It was really bad when launched, but to call it really bad now (or in 2018) is not fair. A lot of poeple waste their money on these hats when they don't need to.

Has the hardware improved or just software? I have a DAC-Hat and it definitely picks up some sort of digital noise from the pi. I can literally hear SSH when large amounts of text are being dumped across the wire.

The Pi 1 B+ was improved with a dedicated power supply and I think that might have been it on the hardware side. The big improvement came with the software, details of which are linked elsewhere in this thread.

Pi native audio has gotten a bit better. https://www.raspberrypi.org/forums/viewtopic.php?t=195178

500ms sounds like quite a lot. What causes the latency and are there any improvements that can be done to improve it?

My use case for whole home audio is to play audio of a sports game that’s playing on TV in the living room.

500ms of latency is far too much. Even Sonos suffers from this with port/connect

Isn’t this a case where you delay the video on the TV side to match the latency of the audio? I assume your TV has an option for audio delay.

The problem that I’d see is that you probably don’t have this setup all the time, so switching your TV back and forth for an audio delay would be annoying. That and 500 ms might be more of a delay than your TV can handle.

Audio source is my receiver which does not offer this functionality. You’re right, config management will be painful.

Receiver runs Linux and I did get a shell on it, but to be honest this is something I would rather just pay for. I don’t want to risk bricking it.

I'm curious which receiver(s) run Linux

Emotiva XMC-1

The majority of receivers above a certain point have streaming radio, "cast", and/or "smart TV" features. Just like so much of the rest of the appliance world, most of those are powered by some random ARM or MIPS SoC running some flavor of Linux.

A modern networked AV receiver is sort of analogous to a managed switch, there's a fairly generic CPU running a general purpose OS presenting the user-facing interfaces, managing configuration, and handling some housekeeping tasks, then there's specialized hardware that actually deals with the signals and does the real heavy lifting after being set up by the general purpose processor..

ISTM they could just have a different mode for the system that lowers latency and increases droppage. For a sportscast the occasional pop or crackle wouldn't hurt anything.

If you're a fan of overly-complicated setups and looking for low latency, I had some success using JACK on a rpi. Be prepared for some tinkering, though.

As others have pointed out, 500ms is huge for some applications. But when the use case is selecting a song from a playlist, starting to hear the track 1 second later is totally fine. It's often preferable to a stream with <30ms latency that drops a buffer every once in a while.

I'd guess the latency comes from generous buffer sizes that keep playback rock solid even though this does TCP, potentially over somewhat flaky WiFi. Keeping separate speakers synched within 1ms is pretty good — you'll cause a greater variation than that just by moving your head to look at the phone with the playlist :)

Plus, that one second delay is present even if you use native solutions, like spotify play through amazon echo (very small delay, not that annoying) or sonos app (way more noticeable of a delay, closer to 1-2 seconds).

AirPlay uses a fixed latency of 2 seconds, so 500ms is not bad. Either way it's not a technical accomplishment/failure, the longer the latency the longer you can put up with your WiFi breaking without having your audio blip.

500ms should be enough that you can roam between multiple APs without the audio stream being interrupted. If you're on hard-wired ethernet you should just be able to modify the snapcast source code to reduce it to whatever you want (10ms should be fine).

Tbh, I feel like this was a genius move by Apple. AirPlay’s 2 second delay gives plenty of time for all devices to sync up and they simply build it in to the AV playback so that videos are perfectly synced to audio as well.

However, without that source-side adjustment: 500ms is a lot. Especially for video.

Yes, snapcast is really designed for audio streaming. For video it's not going to work (but surely for video cases you want something to stream both audio and video?).

I couldn't get Librespot to work, will have to give it another go. What I ended up doing was running the Spotify desktop app, sinking it to the snapcast pipe via pulseaudio.

I don't think librespot is maintained anymore. If you try again, maybe give spotifyd a shot. It works well for me in a basic setup (not using Snapcast)

edit: forgot link https://github.com/Spotifyd/spotifyd

It is maintained at https://github.com/librespot-org/librespot

I don't know why the original author never merged the PRs pointing to the new repo.

Reply on news.ycombinator.com