badaix/snapcast

Using one snapserver as a tcp source for another running as a TCP client causes clicking noises

Opened this issue · 4 comments

Describe the bug
I've got three nodes around the house, and wanted to be able to serve audio from any of them, while clients are all connected to a single central node. What I did is have the central node add two TCP client streams pointing at the other two nodes, which are configured to serve PCM data. When a snapclient is connected to the central node and listens to one of these streams, it is audible but has a high frequency clicking noise on top. Is the PCM data served by snapserver true standard raw PCM?

Steps to Reproduce

  1. Set up one snapserver serving audio using PCM
  2. Set up another snapserver with a TCP client stream pointing at the first snap server
  3. Verify they are configured for the same sample rates etc
  4. Play audio on the first server, and start a snapclient on the second server
  5. Note that audio is discernable, but has a high frequency clicking noise, perhaps 10 clicks a second on top

Environment details

  • OS: NixOS 24.05 on Raspi
  • Snapcast version 0.29.0
  • Installed from nixpkgs

Attach logfile if applicable

Nothing notable in logs

For my very similar setup, I am using a different solution:
Piping the output from a snapclient connected to the 2nd snapserver into a pipe provided by the central snapserver.

snapserver.conf of the central snapserver:
source = pipe:///tmp/cd?name=CD&mode=create&dryout_ms=2000&sampleformat=44100:16:2&send_silence=false&idle_threshold=5000&silence_threshold_percent=1.0

Running on the same host as the central snapserver:
snapclient --logsink null -i 4 -h <ip_of_2nd_snapserver> --player file > /tmp/cd

Hope this helps!

Ah, I wasn't aware of the --logsink option, thank you! I assume you can run multiple snapclients simultaneously? Anyway I will try this out!.

-i <instance_id> is exactly what allows you to run multiple instances in parallel.

It's working great, thanks again!

I'm going to leave this open as the issue still persists with direct TCP connections, just to keep track.