Rework sound recorder and playback.

[N0NB]

I have been poking at things this week in anticipation of the Kansas QSO Party this coming weekend. As I do operate SSB in this event, I use the voice keyer with good results. One thing I'd not tried for some time was the contest recorder and find that the soundlog file has an invalid option, -w for the rec utility now found in the SoX package. Perhaps this was a holdover from the OSS days which is possibly where rec was also found. I fixed that by replacing that option with -c 1 which forces single channel recording, which may not be optimal for transceivers capable of two channel output such as my K3 with the sub-receiver installed. By default rec will record in two channel mode. The files are thus about twice as large, but with a fader each channel could be listened to independently later on.

I also found a bug in the SOUnd menu code for option 3 in audio.c where the opendir() function was given the string "$HOME/tlf/soundlogs/" which, after some investigation cannot work as opendir does not work in the shell environment as the system() function does. So, I have fixed that by querying the value of HOME from the environment and then concatenating that with the rest of the string to pass to opendir().

Finally, in that same code where play is called, it is passed the -d /dev/dsp option by default. This fails on my system (Debian 11) where PulseAudio on ALSA is used but no /dev/dsp exists. I've not tackled that one yet but will tonight (of course I can comment out those lines for my local copy, but a more general solution is needed). I know there are already an abundance of config file keywords, but perhaps some more are warranted to get user control of the sound utilities in use--OSS, ALSA, PulseAudio, PipeWire, etc. I am still thinking of that one.

I am also considering eliminating the sound scripts--soundlog and play_vk--by calling the relevant sound utilities directly as this is already done in dorecord(). One advantage would be to allow using the ESC key to pkill the called utility just like ESC kills CW keying in the call and exchange input functions.

I likely won't get this together well enough for a pull request until next week. I'm writing this up as a reminder to myself and to let others know what I'm up to. I may also ask some questions via the mailing list.

[N0NB]

Hopefully this will not be closed just yet!

[dl1jbe]

Thanks Nate for bringing SSB back into attention. You are right, the relevant pieces needs a thorough overhaul. As OSS is dead now, the whole sound handling in tlf needs to be ported to alsa, pulseaudio or others. Feel free to just go on on that.

[N0NB]

The easiest route is to recommend the SoX package for the sound stuff and let the user decide how to direct the audio. I use the pavucontrol GUI app to set where sound streams go with PulseAudio. Its nice thing is that it remembers those settings between sessions.

I don't want to think about trying to advise users who don't have PA installed. There is the new Pipe Wire that may replace PA in the future...

I say we rely on the SoX versions of play and rec.

That said, I think the BSD variants depend on OSS, but does anyone use Tlf on BSD?

[N0NB]

As another thought or two.

Where to place sound files. I know the config command set is large, but really, this should be user defined. As well, the play and rec commands likewise which are then called directly rather than from scripts (perhaps that doesn't work). However, then there lays the possibility that a user will specify audacity!

[dl1jbe]

The easiest route is to recommend the SoX package for the sound stuff and let the user decide how to direct the audio.

I don't want to think about trying to advise users who don't have PA installed. There is the new Pipe Wire that may replace PA in the future...

We may cross these bridge when we are there ....

I say we rely on the SoX versions of play and rec.

I support that. We should make sure that these commands always work.

But it would be good if we allow the user to choose its own programs by a config keyword. Airween did something similar with the QTCREC_RECORD command. We need at least 4 such commands:

• Recording microphone input to voice keyer files
• Sending those files to the rig
• Recording rig output for sound logging and
• playing back the soundlog to speaker or headphone

I would say we should support calling the programs directly (with parameters) but also shell scripts which may provide additional flexibility.

[N0NB]

The question I have with calling shell scripts is can stoptx() work as well with them as with calling the utility directly?

The advantage of staying with shell scripts is nothing much really needs to change. I will say that right now things are inconsistent in this area. Recording voice messages calls rec directly. Playing voice messages calls the play_vk shell script. The contest recorder calls the soundlog script while its playback calls play directly, as I recall.

Regardless, I would rather have a recommended dependency on a package like SoX for its utilities rather than attempting to interface directly with OSS, ALSA, PA, PW, etc. Down that path lies madness!

Advantage of extending the configuration options a bit more are that the user can call whatever suits them. If play from OSS or SoX works, fine, if aplay from ALSA is needed, fine. Maybe audacity is their preferred choice (that is what I used years back to record my voice files, long before using Tlf). As an aside, now that I recorded the party last weekend, I may go through and see if I can snip out some better voice keyer messages. Hmmm

[dl1jbe]

The question I have with calling shell scripts is can stoptx() work as well with them as with calling the utility directly?

That should be answered with PR #276 I made two days ago. I think you should have gotten an info about it as I asked for test and review?

It works fine here on my side now.

The mix of calling scripts and/or programs may come from the different people who were working on tlf in different times, but I agree the current situation can use improvement.

I am fine with recommending SoX as standard tool, but I would like to allow the experienced user to have more complex solutions.

[dl1jbe]

Completed with PR #318 just merged in.
Thanks again to all for discussion and help.