Error messages as wavs

ProffieOS
, ,
1

It’s been a while since error wavs were introduced, but I am only getting around to testing it now.

I found one minor issue, one major issue (freezing) and an overall suggestion for how things should work.
@profezzorn, I have a working local copy running that could be used to submit a PR.

Previous to OS8, error messages like “Error in font directory” would play directly along with a boot or font.wav. This was a bit hard to hear, and combined with the limitation of clean diction with the Talkie “Speak and spell” voice synthesis, it was so often misheard that we needed to have a “What’s it saying?” page added to the documentation on https://pod.hubbe.net/.
Now with OS8, we have the option to use wav files instead of the Talkie voice. This is awesome!
Now of course, if the error is “SD card not found”, there is no wav available, so that one is Talkie or beeps no matter what, but that one is pretty rare anyway.

Ok, so with the current implementation of wavs, a “ducking” feature was also introduced where the boot/font.wav file is still played simultaneously with the error message (either Talkie or the wav) but the boot/font volume is lowered a bit so that the error could be heard a little better.
For those not familiar with “ducking”, it’s an audio term for when the volume of one thing is lowered so it “ducks under” another thing playing. Think of a voiceover at the end of a show. The closing theme music plays, then lowers so the announcer can say something, then it gets loud again when the voiceover is done. This is also known as “bedding”.
This ducking feature is DodgeSound() in ProffieOS, and it’s the thing I personally would like to see change (my “overall suggestion for how things should work” mentioned above.)

First lets talk about tests I did on the way things currently are.

These are the things I used for testing (all linked below):

  • testfont2b with “booting up” boot.wav and the “iiiit’s the test font!” font.wav.
  • A V2 voicepack.
  • A commonBU (backup) tertiary folder in the font search path. This is how I do fallback sounds for fonts that don’t have stuff like stab or slash etc… It was also where I tested that error wavs can exist and pre-empt the default ‘errors’ folder on the root of the SD card (it works fine). I plan on possibly adding error wavs for the Voicepacks, but it’s a lot of work so we’ll see about that. Moving on…
  • I duplicated the default_proffieboard_config.h file and replaced all the presets with 5 presets; 4 with unique errors and a 5th with two errors. Those are listed here:
// // ERROR WAV TESTS

// Preset 0 - Font Directory Not found
{ "sdrfgzdf;ProffieOS_V2_Voicepack_The_Ronin/common;commonBU", "", // nonsense font name for testing
//{ "testfont2b;ProffieOS_V2_Voicepack_The_Ronin/common;commonBU", "", // Temp alternate GOOD font for testing without freezing
StylePtr<Layers<Red>>(),
StylePtr<Layers<Red>>(),
"NAME-Font Directory Not found"},

// Preset 1 - Error in Font Directory
{ "testfonteifd;ProffieOS_V2_Voicepack_The_Ronin/common;commonBU", "", // clsh files mis-sequenced for testing
StylePtr<Layers<Blue>>(),
StylePtr<Layers<Blue>>(),
"NAME-Error in Font Directory"},

// Preset 2 - Voicepack Not found
{ "testfont2b;commonBU", "", // voicepack required because MENU_SPEC_TEMPLATE is defined
StylePtr<Layers<Green>>(),
StylePtr<Layers<Green>>(),
"NAME-Voicepack Not found"},

// Preset 3 - Error in Voicepack version
{ "testfont2b;ProffieOS_V2_Voicepack_Thrawn/common;commonBU", "", // voicepack.ini intentionally named incorrectly for testing
StylePtr<Layers<Yellow>>(),
StylePtr<Layers<Yellow>>(),
"NAME-Error in Voicepack version"},

// Preset 4 - Error in Font Directory AND Voicepack Not found
{ "testfonteifd;commonBU", "", // clsh files mis-sequenced for testing and voicepack required because MENU_SPEC_TEMPLATE is defined
StylePtr<Layers<Green>>(),
StylePtr<Layers<Green>>(),
"NAME-EIFD and VPNF"}

Note that the first preset 0 has an alternate “good” font used - more on that later.

Let’s start with when there are no wav files available, and Talkie does its thing as normal.
Here is what those presets sound like (I recorded my saber).
This is booting to the first preset which has a misspelled font folder in the preset, then cycling through the rest.

Now for testing when error wavs are available.
For those who don’t know, the following error message wavs can be used:
e_blade.wav - “Error in blade array”
e_fnt_nf.wav - “Font directory not found.”
e_in_fnt.wav - “Error in font directory”
e_vp_nf.wav - “Voicepack not found”
e_vp_ver.wav - “Error in voicepack version”
These can be put in any font, any common folder, or in an ‘errors’ folder on the root of the SD card. This is the fallback location if none are found in the preset’s Font Search Path. This works like having another ;common appended to the FSP, but can be omitted as it defaults to that regardless.

I included a set of these in the link below, they’re just me speaking the errors. (Possibly character versions to come later and added to existing voicepacks)

First, the critical error that’s freezing the board.
Note that this is booting to a preset that has an error (Font Directory Not Found).
It seems if the preset that boots has an error, and error wavs exist, it uses both Talkie AND the error wav, and something collides and boom - freeze. Nothing at all shown in serial monitor, and no response from board.
It crashes because in PlayErrorMessage() it starts a sound, but checks its length before it’s loaded, thinks no sound is playing, then starts a bunch of other sounds too, and the audio system gets overloaded/confused and locks up.
This example is that happening:

So I corrected the first preset so it would boot normally. This worked fine, then cycling through the rest worked.
This is what that sounds like:

Certainly way better than Talkie. But note that when there were multiple errors for preset 5, both the font.wav and one of the errors was ducked, so there are 3 simultaneous wavs playing all at once … kinda not great.

So, what if we didn’t overlap all these messages and boot/font sounds?
Well, I made some edits to ProffieOS and this is what I propose.
Let’s start with when there are no wav files available, and Talkie does its thing as normal.

And this is using wavs (boot to a preset with an error works)

No overlap, no confusion.

Now I know this is one of those “utility” things that not everybody cares that much about, but I feel like errors are important, and “what’s it saying” is one of the most popular questions asked. I think this would be the way to go.

Thoughts?

Link to the test stuff and error wavs:

3 Likes
2

I ABSOLUTELY love it. as one of the peeps that’s always troubleshooting my cores and breaking them this would help greatly rather then having to repeat it to figure out what is the saber complaining about.

The ducking is an improvement but the last test might also fix the freeing issue, right?

3

Yes. An update would fix the freezing issue.

4

Great find. This was an interesting read, and an interesting morning digging into it, since I haven’t been using error wavs myself. You’ve done far more work on the voicepack side than I have, so take this as one user’s perspective rather than a recommendation.

My own preference is that I’ll likely stay on Talkie. Part of what makes an error useful to me is that it doesn’t sound like anything else on the saber, so I know something is wrong before I’ve worked out what it said. But the “what’s it saying” problem is clearly real for a lot of people, and clearer words are worth something. Two thoughts on how they work:

  1. Consistency. With the wavs living in the font search path, the error voice changes depending on which preset you were on, and falls back to something else if the font name is wrong, which is one of the cases you’d most want to hear clearly. Requiring them in the errors folder you mentioned would keep one voice across the whole saber (short of the “SD card not found” as you already said), since that folder sits outside the font search path and everything inside the path can vary by preset.

  2. A define. Either way it comes down to letting the user turn this on deliberately. Creating an errors folder is one way to say yes, a define in the config is another, and there’s no reason it couldn’t be both. If the wavs have to live in the errors folder, that folder is the opt in on its own. If the location stays flexible, the define is what makes it a choice.

Either way, the freeze fix is worth having on its own. Just my two cents.

2 Likes
5

Playing multiple error messages at the same time is clearly not a good thing. When using talkie, this isn’t a problem, as it has a builtin queue. We may need a sound queue for wav errors as well.

Obviously the freeze should be fixed too. Should be easy to fix if we can replicate it in a debugger.

2 Likes
6

Sound queueing them works.
PR submitted.