CUSTOM SOUNDS should be skippable, and not every sound should go to the queue

[eried]

Problem: The voice/sound system is too rudimentary.

1. Sounds are never skipped: Welcome sound, and custom sounds should be skipped if another sound is triggered. Except if the sound is an alarm, or part of the alarm (like the time of that alarm).

2. Every sound goes to a queue: Only one item should be in the queue for custom sounds. Imagine you quickly move a switch with a sound assigned N times. What is the point of hearing all the N times VS only the last state of the switch, which is the valid one?

3. Custom sounds should not be triggered immediately: If you have a switch with 3 sounds and you switch from A to C. Why should you hear B and then C, not only C?

[somewhatlurker]

It's nice to have something I can test in emulator actually, unlike USBHID, so let's brainstorm here a bit.

The currently proposed solution seems to treat all custom alarms (everything configured in the voice config menu?) as equal and like they should be replaced when any other custom alarm triggers.
And due to the potential for this to unintentionally mask alerts from other switches, this is deemed unsatisfactory.

Proposed solutions to that new behaviour so far are either to assign audio to groups which can be skipped by other triggers in that group (one switch = one group, or perhaps leave it user-configurable), or to give alerts a priority setting where only equal or lower priority alerts will be replaced (so critical alerts such as one for an arm/disarm switch will always be played, but less important alerts will be skipped by other actions).

Is this summary correct?

　

I can see the appeal of both approaches -- a pilot with alerts setup on switches probably does want the changes to be acknowledged even after making other changes, but when there's constant alerts for several seconds after changing two or three switches a pilot may start to zone out and not notice something more important being played.
The concern over pilots zoning out could be potentially mitigated by offering ready-to-go voice packs at multiple speeds without code changes though.

[eried]

Yes that is a good summary. I do not actually agree on the importance of the alarms though, if I start hearing an alarm and switch flight mode from LEVEL -> HORI -> ACRO, I do not really expect to hear the whole alarm sounds sequences, then HORI, then ACRO like it is now. I would expect the alarm to be abrupted with only "ACRO" voice.

[somewhatlurker]

As for implementation, the easiest way I see is probably to work on the group-based approach and set the groups using the value of ptr from get_input_str. (this would group all alerts from the same input, but not allow for custom groups and certainly not allow other sources to skip an alert from a switch/knob)
Input change alerts seem to already be triggered from code in inputs.c, so the function is easily accessible.
(It seems kinda wrong to just compare char pointers to determine the switch, but INPUT_NumSwitchPos already does that so I suppose it's fine.)

This way moving a 3pos switch two clicks would generate one alert as expected, and moving another switch would not skip the alert for the first switch.

High priority sounds that shouldn't be skipped or low priority sounds to always skip could be assigned special groups with alternate behaviour.

　

An alternative would of course be for the model's voice config could have groups or priorities added and the UI updated to match, but I really haven't looked into what adding extra config options to ini files would require.

[somewhatlurker]

And I don't really know if I like the idea of interrupting alerts for unrelated things when inputs are received...
In my eyes, the purpose of enabling alerts for inputs is so you can always be sure of what your craft is doing, and the moment you start interrupting alerts you make it possible to inadvertently skip the playback of something that might be important.

Perhaps I'm thinking about this wrong though... If not just considering alerts from inputs, then it would be possible to make specific configurable switch inputs cancel telemetry/timer alerts.
Then any critical input that you want to be alerted about changes to will always announce the new final state, and if it's the appropriate response to acknowledge something from telemetry/timers then the current alert will stop.

[TheRealMoeder]

Before making any major voice changes (like #961), maybe we should merge my old code optimization changes in #665 first? I'd be glad if someone could take a quick look, it's been sitting there for quite a while.