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

[alsa stream] Detect idle state based on dBFS threshold #846

Closed
cmelbye opened this issue Apr 1, 2021 · 11 comments
Closed

[alsa stream] Detect idle state based on dBFS threshold #846

cmelbye opened this issue Apr 1, 2021 · 11 comments
Labels
feature request next release fixed in develop branch and will be part of the next release

Comments

@cmelbye
Copy link

cmelbye commented Apr 1, 2021

Is your feature request related to a problem? Please describe.
I use an ADC (HifiBerry DAC+ ADC Pro) connected to a Turntable as input for the following ALSA stream:

source = alsa://?name=Turntable&device=sysdefault&send_silence=true&sampleformat=48000:32:2&idle_threshold=10

The problem I'm seeing is that Snapcast always reports its state as "playing", even if the Turntable is not playing anything. I assume this is because it constantly outputs some low-level noise.

I set send_silence and idle_threshold in an attempt to fix the issue, but it doesn't change anything. After looking at the source code, it seems like idle_threshold is expecting "true silence" from ALSA.

Describe the solution you'd like
It would be great if there were an alternate way to specify an idle threshold. I looked at the HifiBerry forums, and a thread seemed to suggest that using a dBFS threshold could work to detect "silent" noise.

I'm not experienced with this, so I could definitely be misunderstanding how this works. If it is possible, whether via that solution or something else, it would be a great improvement to get accurate state information from these types of ALSA sources.

For example, the snapclient web UI could accurately report whether or not the source is playing, or users could build automations that react to the stream moving from idle to playing.

@Thyself17
Copy link

I'd like to jump in and +1 this issue. I have the non-pro Hifiberry DAC+ADC hat on a raspberry pi 3. The alsa source always indicates that the stream is playing. Using some sort of noise detection would be great for these devices.

@badaix
Copy link
Owner

badaix commented Apr 28, 2021

@Thyself17 are you also talking about a line-in/mic-in analog stream?

@Thyself17
Copy link

@Thyself17 are you also talking about a line-in/mic-in analog stream?

Correct! Just as @cmelbye has setup with their also source, I am using the line-in input on the Hifiberry ADC as the source for my snapserver instance. Even when there is no media playing, the alsa source in the web UI always shows the alsa stream is playing- never idle. I have also tried unplugging line-in, but snapserver still does not detect silence, and therefore, never idles.

As the OP states, I imagine there is still some inaudible noise passing through the ADC signal converter, so it never is 100% silent. Thus the proposal for some dB or volume threshold for detecting silence

@badaix
Copy link
Owner

badaix commented May 5, 2021

Added with commit 216714b, you can find an automated build in actions.
It introduces a new parameter silence_threshold_percent for the alsa stream source. It's not in dBFS, but in percent of the maximum amplitude. So for a line-in something like 0.1 should work.

alsa

Captures audio from an alsa device

alsa://?name=<name>&device=<alsa device>[&send_silence=false][&idle_threshold=100][&silence_threshold_percent=0.0]

Available parameters

  • device: alsa device name or identifier, e.g. default or hw:0,0 or hw:0,0,0
  • idle_threshold: switch stream state from playing to idle after receiving idle_threshold milliseconds of silence
  • silence_threshold_percent: percent (float) of the max amplitude to be considered as silence
  • send_silence: forward silence to clients when stream state is idle

@cmelbye, @Thyself17 would be great if you could test the development snapshot

@badaix badaix added the next release fixed in develop branch and will be part of the next release label May 5, 2021
@Thyself17
Copy link

@badaix I'll have to test in the next couple weeks when I get home from travel. I'll be sure to follow up with results!

This is an amazing feature for my use case. Thank you!

@Mohawi
Copy link

Mohawi commented May 13, 2021

@cmelbye Thanks for the idea and @badaix Thanks for implementing it!
I have it running for a few hours now and it works just great! I have three analog devices connected to my pi and am now able to see where a signal comes from! For my connected vinyl player I put a silence_threshold_percent=0.2 to achieve a robust idle detection. With a value of 0.1 it oscillates a bit on status changes from playing to idle.

@badaix
Copy link
Owner

badaix commented May 15, 2021

@Mohawi thanks for the feedback

@badaix
Copy link
Owner

badaix commented May 15, 2021

Released in Snapcast v0.25.0

@badaix badaix closed this as completed May 15, 2021
@Thyself17
Copy link

Chiming in to say this feature has worked flawlessly and has been an amazing feature for my usecase. thanks!

@disi33
Copy link

disi33 commented Sep 10, 2021

OMG I have the exact same use case (HiFiBerry DAC+ ADC Pro - actually two of them, one for the turntable, another one for a long-distance Bluetooth receiver) and this has been bothering me for the longest time! Asked in the HiFiBerry forums for solutions etc.
I just had some time to kill and was gonna look at the code and see if there was a way I could contribute this feature, only to find that this has recently been added and it works flawlessly!

@bendschs
Copy link

ist there a way to get rid of the to low-level noise described in the first posts? it is quite annoying, especially when listening with headphones. in between tracks or when you pause sound to get a call or something, you allways have that noise in the background ...

cheers
bendsch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request next release fixed in develop branch and will be part of the next release
Projects
None yet
Development

No branches or pull requests

6 participants