Re: Speaktime wavplay problem Debian Buster on PiRLP

 

I should have mentioned... This script uses $CUSTOM/wavplay_nice so there is no need to worry about $SCRIPT/wavplay being over written.

I also noticed that Rob had tried my script too but didn't say what the problem was/is using it.


>< Dave Parks ><
WB8ODF@...
http://wb8odf.com



On Friday, November 22, 2019, 11:40:35 PM EST, Dave Parks - WB8ODF via Groups.Io <wb8odf@...> wrote:


WOW Nick,

That was a whole lot of stuff I can't wrap my head around.

There is NO REASON to use sox in any of the IRLP scripts, I never understood why Dave C used it.... EVER

I'm sure Dave C is going to fix his script for Rob (he's good that way)... HOWEVER, I'll suggest we use my script (when I say *MY* script I mean the one I have for download on my server), I didn't write it, but I did edit it to work with Debian without the use of sox. It has worked for me since the very first version of Debian used by IRLP.

I'll step back here and let Dave C chime in with his fix for the sox problems since it actually was one of his "FEATURES" if/when purchasing one of the IRLP nodes.

We can go from there.... :)


>< Dave Parks ><
WB8ODF@...
http://wb8odf.com



On Friday, November 22, 2019, 11:21:20 PM EST, Nosey Nick VA3NNW <irlp@...> wrote:


Dave Parks - WB8ODF via Groups.Io wrote:
I know Dave C's feeling on this, through the years programmers of "Linux" and it's programs seem to change their flags with no rhyme or reason.

Whereas all the programmers of, say, "Microsoft Windows" and all it's 3rd-party programs, they have NEVER changed a thing? Yuh, sure   :-D

I *THINK* the problem here is that scripts/wavplay has at least 2 or 3 modes of operation:

Mode 1: USE_APLAY=YES ? Convert any FILE.ul to FILE.wav and aplay all the WAVs

Mode 1b: USE_APLAY=YES, and they are already all FILE.wav, and there's NO FILE.ul, no conversion required, simply aplay all the (existing) WAVs.

Mode 2: Otherwise if there IS NO FILE.ul, convert each FILE.wav to a temporary FILE.ul, join all the .ul files together into one big ul file, convert that back to a .wav, and $PLAY that.

You follow? Good so far EXCEPT neither of the conversions work with recent versions of "sox" (which is totally sox's fault, regardless of whether you choose to run sox on Linux, Windows, Mac, NetBSD or Commodore 64). This removes the usefulness of mode 1 and mode 2. The only mode that can still work is 1b, when USE_APLAY=YES, and when they are ALREADY FILE.wav. Luckily USE_APLAY=YES by default these days, and ALMOST every part of IRLP uses WAVs not .ul any longer, so you're ALMOST always using 1b and everything just works.

... except saytime uses audio/custom/*.ul which have not been converted to WAVs yet, so that takes mode 1b off the table too.

Possible solution A:

edit scripts/wavplay and fix the "sox" commands that are used for the conversions.

Assuming "sox --version" is quite new (mine is 14.4.2), everywhere it says "sox BLAH.ul -s -u BLAH.wav" (it MUST be a ul to a wav, and it must have the -s -u) ... change it to "sox BLAH.ul -e un BLAH.wav" (basically ONLY replace "-s -u" with "-e un" and leave the rest of the lines intact). There are at least 2 places to make this edit.

*AND* make sure your fixed scripts/wavplay doesn't get "fixed" back again every night when your machine updates itself, because you're not supposed to touch scripts/stuff, only custom/stuff. This is left as an exercise for the reader, your two hints are to read the "rsync" manpage, and to (ab)use this:

scripts/update:    UPDATEFILELIST="`cat ${CUSTOM}/update-file-list`"

*AND* make sure you DO eventually "fix" it to a new updated scripts/wavplay sometime if/after this problem is fixed, if ever. This is also left as an exercise for the reader, because really I'm not happy with any of "possible solution A" because of these last 2 points. I think I'd prefer you go for something like...

Possible solution B:

Make sure you have the aplay command. Try just typing "aplay" and see if you get a big help text (good) not "command not found" (bad).

Make sure you export USE_APLAY=YES in custom/environment

Convert all remaining FILE.ul to FILE.wav, as that appears to be the current IRLP standard anyway.

A script to TEST this conversion would be:

find audio -name '*.ul' | sed -E 's/(.*)\.ul/sox "&" -e un "\1.wav" \&\& mv "&" "&-OLD"/'

Be *EXTREMELY* careful with quotes, punctuation, spacing, and word-wrap when copying the above command. Cut+paste would be MUCH safer.

The above should output a list of conversion commands but NOT run them. If they look safe and you're happy to run them, you could copy+paste them into the same terminal, or alternatively:

find audio -name '*.ul' | sed -E 's/(.*)\.ul/sox "&" -e un "\1.wav" \&\& mv "&" "&-OLD"/' | sh

... which is exactly the same except with | sh on the end. You can almost certainly up-cursor, | (that's a pipe, probably shift-\, not a1, i, I, l, nor L), sh, return.

HOWEVER, that's not the whole story either, because some/many old versions of "saytime" are ignoring the very nice scripts/wavplay, INSISTING on the .ul files being present, and ignoring USE_APLAY=YES and writing direct to /dev/audio which you can't safely do any more unless you're running a dangerously old Linux.

So ALSO edit your "saytime". First, make a backup copy of this file in case you make things worse, then replace:

say () {
        file=$SDIR/$1.ul
        if [ ! -f $file ] ; then
                echo "`basename $0`: cannot find $file"
                exit 1
        fi
        SAYFILES="$SAYFILES $file"
}

... with just:

say () {
        SAYFILES="$SAYFILES custom/$1"
}

... and at the end, if it says:

cat $SAYFILES > /dev/audio

replace the line completely with:

$SCRIPT/wavplay  $SAYFILES

I *THINK* saytime will then work. I make no promises. I'll admit I've done NEITHER of the above Solution A/B, I've gone for Possible Solution C:

Rewrite saytime completely. Have it use a nice new clean set of synthesized WAVs, use IRLP-standard wavplay properly (and hence support USE_APLAY), support UTC or local time or both, add an optional voice ID/call, hey why not optionally read a short local weather forecast too?   :-D

... however I'm unfortunately not yet able to share my scripts for Solution C. Partly because the "local" weather is only local to Canada at the moment.   :-/

I might be talked into releasing a straight simple replacement for saytime if Solution B doesn't work for you.

Nick VA3NNW

-- 
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer;    sig@...
Numeric stability is probably not all that important when you're guessing.


Join IRLP@irlp.groups.io to automatically receive all group messages.