Rework audio handling

[dl1jbe]

These commit gives recording and playing of voice keyer messages and contest soundlogs a thorough overhaul.

The code relies on the tools from the SoX package with some sane default settings but allow user configuration of all play and record commands (See also the discussion in PR #276)

The default directory for recorded soundlogs was changed to ./soundlogs and are therefor contest specific now. These setting can also be overwritten by a configuration keyword (see man page for details).

Please update the script soundlog in /usr/bin before testing.

As I will be away the next days please merge the PR in if there are no problems.

[zcsahok]

I see at least one issue: contest recording can be started multiple times. The user has no feedback whether it is already active. Ideally options 1 and 2 would be mutually exclusive. Similarly on exit the recording continues, that could be viewed both as a feature or a bug. Here it would make sense to ask for confirmation to continue with the recording, e.g. in case user wants to make a quick parameter change and get back to TLF.

[zcsahok]

Added some minor cosmetic fixes.

[dl1jbe]

I see at least one issue: contest recording can be started multiple times. The user has no feedback whether it is already active. Ideally options 1 and 2 would be mutually exclusive. Similarly on exit the recording continues, that could be viewed both as a feature or a bug. Here it would make sense to ask for confirmation to continue with the recording, e.g. in case user wants to make a quick parameter change and get back to TLF.

Thanks. That sounds like a valid enhancement. The following commits fixes both problems.

[zcsahok]

Thanks for the updates! Just added minor cosmetic fixes.

On playback using the default command I get this warning:

It's the same from command line:

$ time play -q 172036.au
play WARN alsa: can't encode 0-bit Unknown or not applicable

real	0m51.251s

I does play it back, just the warning is annoying. In my case a trailing -t alsa option fixes it, but maybe this is not a universal solution. Info: https://groups.google.com/g/linux.debian.bugs.dist/c/jCqdwFWPUKk

Another point: it would be nice to use the same terms (Enable/Disable vs. Start/Stop) on the :sound screen and at exit.

[dl1jbe]

Hmm, that does not look nice. Here it works without problems. The provided discussion is quite old, just wondering that the problem is not fixed yet in SoX.
We could redirect all output to /dev/null , but it seems not right to me. Maybe we find another solution.

Wrt start/stop I agree. Will fix it.

[zcsahok]

I have this SoX version (Debian 11)

$ play --version
play:      SoX v14.4.2

[dl1jbe]

Same version here but with patchset from May 2021. v14.4.2 is otherwise quite old - 2015.

Anyway the code should work with the tools provided by the actual standard distributions.

[dl1jbe]

Can you please test if the warning from play goes only to stderr (play -q xyz 2> /dev/null)?

[zcsahok]

There is no warning with stderr redirect. (2>/dev/null)

[dl1jbe]

Thanks for the quick test and sorry for the late reply. Last days I did not feel well.

I think best is to redirect that error message by adding the '2>/dev/null' but only for the default soundlog play command. If the user decides t use another program for play back there will be nost likely no error. See coming patch.

[zcsahok]

OK with me.

[zcsahok]

(stopping with Ctrl-C is somewhat slow, but that's the same from command line. most likely it buffers a large amount of sound data that needs to be drained first.)

[dl1jbe]

Yes draining the buffers takes some time. Other than for voice key messages the delay seems acceptable here. So no need to hard kill the program and let it finish graceful.

Again, Thanks for the feedback. Will merge it in tomorrow.