Packaging sanity checks

[sodface]

I'm trying to maintain the signal-estimator package for Alpine Linux, currently in the testing repo. I haven't actually used it for what I had originally planned but I'd already had the package accepted, so I've been updating it as required.

Do you have any suggestions for minimal testing I should do after updating the package? Right now I'm just making sure the cli command and gui start. I run through the various modes in the gui with the default sound devices but I'm not really sure what's expected.

See attached for example. To me, this display seems a lot noisier than it was when I first packaged this a few versions ago.

[gavv]

Hi!

First of all, thanks for your packaging work!

I think the most important and at the same time straightforward test is to run:

./bin/x86_64-linux-gnu/signal-estimator -i <device> -o <device> -m latency_corr

and to check that the latency is correctly measured:

...
latency:  sw+hw  30.579ms  hw  22.579ms  hw_avg5  21.410ms
latency:  sw+hw  30.749ms  hw  22.749ms  hw_avg5  21.745ms
...

You can then remember the latency of your hardware and check that it's the same each release :)

latency_corr is quite robust, and usually works without additional configuration.

The second mode, latency_step, which you're using on your screenshot (it's also used in noop mode), is much more fragile. You should ensure that the volume is not too low and not too high and may need to adjust threshold for your specific conditions. You can play with these parameters:

 Step-based latency estimation options:
      --step-period arg         Step period, seconds (default: 1.000000)
      --step-length arg         Step length, seconds (default: 0.100000)
      --step-detection-window arg
                                Step detection running maximum window, in
                                samples (default: 96)
      --step-detection-threshold arg
                                Step detection threshold, from 0 to 1
                                (default: 0.400000)

and also with volume via --volume option and/or alsamixer.

I think on your screenshot, volume of output or input ALSA device is too high. We don't control it programmatically yet, but we have a task: #10.

BTW, if you connect output to input via jack cable, it will be much easier to make latency_step working with minimal configuration, because there will be almost no noise.

Regarding GUI. It does not display measurement results yet, so there is not much to test. However we have #44, which I think we'll be included in next release. It will provide the same data in GUI that we have in CLI.

[sodface]

Thank you!

[gavv]

Closing, feel free to reopen if needed

[gavv]

Note: #44 was merged into master, so since next release it would be possible to do meaningful tests for GUI too.

[gavv]

A few other sanity checks that I do from time to time:

• ensure that latency_corr and latency_step produce the same result on cable (the very first example in readme)

• ensure that hw_latency is not affected by changing --out-latency, --out-periods, --in-latency, --in-periods

• ensure that hw_latency is not affected by --chans and --rate