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

(audio feature) detect frozen / stuck input signal #62

Open
softhack007 opened this issue Aug 7, 2023 · 2 comments
Open

(audio feature) detect frozen / stuck input signal #62

softhack007 opened this issue Aug 7, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@softhack007
Copy link
Collaborator

softhack007 commented Aug 7, 2023

development note for a future feature

Is your feature request related to a problem? Please describe.

To help diagnose wrong configuration, it would be useful to make a difference between "silence" (some signal but below thresholds) and "frozen" signal (constantly at the same value for long time).

Describe the solution you'd like

Implementation should be straight forward, with some potential for optimizations as we only need to consider "sample batches" that are all at the same value.

  • static unsigned long timeOfLastChange=0; that stores the millis() from the last changing sample batch (special case "0" = never changed since startup)
  • static float previous_sample =0; for comparing with new samples. If all samples in the batch == previous_sample, we are stuck at a value. If at least one is different, update timeOfLastChange to indicate "not stuck". And update previous_sample to a randomly picked sample, like the 16th in a batch (does not matter which one we use).
    • edit: previous_sample is not strictly needed. Just take the first one from a batch of 512, and compare if all other 511 are the same value. If yes--> potentially frozen.
  • check timeOfLastChange when showing info page. If silence and timeOfLastChange - now() > 5 seconds --> show "frozen".

Additional context

I2S is basically single-direction from programming perspective, so you set pins, then start reading values. There is no feedback available about bad configuration, for example missing/broken MCLK signal.

Thanks @netmindz and a few other discord users who suggested a detection scheme for "frozen" signals.

At the moment it feels like there are too many failure possibilities that all just result in the info page saying silence. For example, you can set the wrong pin for master clock and just get Silence, when surely without clock we are getting no meaningful data at all, so reading the same sample value all the time?

@softhack007 softhack007 added the enhancement New feature or request label Aug 7, 2023
@softhack007 softhack007 self-assigned this Aug 7, 2023
@dosipod
Copy link

dosipod commented Aug 8, 2023

Great idea and for sure will eliminate some of the guess work . I do hope you could also consider analog as that would be helpful for line-in as some are still on the DIY listed in the wiki ( works really well when it does )

@netmindz
Copy link
Collaborator

netmindz commented Aug 8, 2023

It would not be possible to do this for analog @dosipod as the value read this way will never be exactly 0 or freeze if a connection comes loose.

The idea here was to help uses get better feedback when trying to wire up I2S devices, but using the wrong pins etc. Better to indicate some form of error rather than just say "silence"

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

No branches or pull requests

3 participants