Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Snapserver pipe source not switching to idle #1123

Open
isolatedvirus opened this issue Apr 12, 2023 · 3 comments
Open

Snapserver pipe source not switching to idle #1123

isolatedvirus opened this issue Apr 12, 2023 · 3 comments

Comments

@isolatedvirus
Copy link

Snapserver configured to accept fifo output from snapclient will not change the source to idle when nothing is playing. This results in silence being played, and will also block audio from lower priority sources when configured in a meta source. Current workaround is to list the source as lower priority in the meta source config to avoid blocking audio, but this does not address the constant output of silence.

Setup
Central snapcast server is being used to stream audio to various phones, raspi devices, laptops, etc. This server is not physically located where i want to capture audio.
The audio flow is: alsa capture device --> snapserver --> snapclient (output to named pipe /tmp/vinyl) --> snapserver (read from named pipe /tmp/vinyl) --> snapclients

I've included a diagram to hopefully make this more clear:

Steps to Reproduce
1.Configure downstream snapcast server to send audio
2.Configure upstream snapcast client to pipe audio to fifo file using "--player file:/tmp/filename"
3.Configure snapcast server on upstream client to utilize the same fifo pipe.
4.Configure meta source on upstream server and set higher priority for the new fifo pipe
5.Play audio to lower priority source. This source will be blocked as the higher priority "snapclient fifo source" will begin blocking. This source will not be marked idle regardless of any dryout_ms setting.

Environment details

  • OS: Raspbian / Fedora
  • Snapcast version 0.27.0
  • Self compiled

Debug log output
Logs from Fedora snapclient

2023-04-12 18-42-57.351 [Debug] (Stream) Failed to get chunk, returning silence
2023-04-12 18-42-58.001 [Info] (Stream) No chunks available
2023-04-12 18-42-58.401 [Debug] (Stream) Failed to get chunk, returning silence
2023-04-12 18-42-59.001 [Info] (Stream) No chunks available
2023-04-12 18-42-59.451 [Debug] (Stream) Failed to get chunk, returning silence
2023-04-12 18-43-00.001 [Info] (Stream) No chunks available
2023-04-12 18-43-00.501 [Debug] (Stream) Failed to get chunk, returning silence
2023-04-12 18-43-01.001 [Info] (Stream) No chunks available

Logs from Fedora snapserver

2023-04-12 18-42-57.168 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 0, refers: 0
2023-04-12 18-42-57.168 [Debug] (Server) onMessageReceived: Time, size: 8, id: 0, refers: 0, sent: 1681339377,162046, recv: 338311,674028
2023-04-12 18-42-57.716 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 2745, refers: 0
2023-04-12 18-42-57.716 [Debug] (Server) onMessageReceived: Time, size: 8, id: 2745, refers: 0, sent: 334073,144231, recv: 338312,222243
2023-04-12 18-42-58.168 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 0, refers: 0
2023-04-12 18-42-58.168 [Debug] (Server) onMessageReceived: Time, size: 8, id: 0, refers: 0, sent: 1681339378,162102, recv: 338312,674180
2023-04-12 18-42-58.716 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 2746, refers: 0
2023-04-12 18-42-58.717 [Debug] (Server) onMessageReceived: Time, size: 8, id: 2746, refers: 0, sent: 334074,145025, recv: 338313,222892
2023-04-12 18-42-59.168 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 0, refers: 0
2023-04-12 18-42-59.168 [Debug] (Server) onMessageReceived: Time, size: 8, id: 0, refers: 0, sent: 1681339379,162320, recv: 338313,674332
2023-04-12 18-42-59.717 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 2747, refers: 0
2023-04-12 18-42-59.717 [Debug] (Server) onMessageReceived: Time, size: 8, id: 2747, refers: 0, sent: 334075,145543, recv: 338314,223560
2023-04-12 18-43-00.187 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 0, refers: 0
2023-04-12 18-43-00.187 [Debug] (Server) onMessageReceived: Time, size: 8, id: 0, refers: 0, sent: 1681339380,181895, recv: 338314,693795
2023-04-12 18-43-00.718 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 2748, refers: 0
2023-04-12 18-43-00.718 [Debug] (Server) onMessageReceived: Time, size: 8, id: 2748, refers: 0, sent: 334076,146332, recv: 338315,224249
2023-04-12 18-43-01.188 [Debug] (StreamSessionTCP) getNextMessage: Time, size: 8, id: 0, refers: 0

@giantorth
Copy link

I am encountering the same issue with squeezelite clients connected via stdout or fifo to snapcast 0.27. I've verified that the squeezelite client sends no data when idle but snapserver will not actually mark the source as such.

@patrex0304
Copy link

I have a same problem. I have a pulse audio source that is written into a pipe. Snapserver reads that pipe. I have a metastream that changes between that pipe and other inputs. The pipe has the highest priority. After a certain runtime the snapserver does not change the the source of the metastream anymore. It just keeps switched on the pipe even if nothing writes to the pipe.

@badaix
Copy link
Owner

badaix commented May 8, 2024

When using alsa capturing, you will always have some noise floor, you can configure a threshold for this with the silence_threshold_percent parameter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants