Layering audio annunciators

At first, proritizing, with a minumum time for each 'sound', would seem best.

One thing I've noticed is, there is a BIG difference between 'random' 'announcements' vs being 'prepared' for an announcement. For instance, a 'good' PBX operator will 'ask' for attention before giving the pertinent data. Even here at work, our front desk will do some thing like "Scott Johnson, you have a sales call on line 4 --- Scott Johnson, line 4" . If she just blurted out "Scott Johnson, line 4" it is much less likely people have had time to focus their attention on the announcment. If you are someplece that has door prizes, anMC should get everyone's attention before reading the number - and it should be repeated a coupla times.So, one thing might be to have an 'attention getting' sound that would then be followed by the 'data' carrying sound. In movies, I've heard ships that have a 'blast' of sound before a verbal announcement. If there is a life threatening or very great property damage emergency - there should be NO DOUBT that people need to begin exiting or otherwise give full attention to any announcements.

I bet security/alarm system companies have given this some thought. There may even be a standard suite of sounds for certain things.

If I were doing something like this for my airplane, I'd want a priority interrupt on flight safety issues, i.e. low oil pressure is a lot more important than 50 feet above assigned altitude, and then the lesser alarms queued and presented in order of importance.

I'm pretty sure this is the way Airbus does it.

I'm pretty sure any mission-critical system better have court-defensible use cases and reams of data to show conformance to the use cases.

-- Les Cargill

It all depends on what you think "mission critical" means. I've been following the Airbus AF447 accident for 2 years now and have learned quite a bit about their design philosophies. Most were adapted with little or no prior use and some appear to show a high degree of "ad-hockery".

In the case of my airplane, being certified as a light sport and not conforming to a standard airworthiness certificate, I don't think there was a great deal of "conformance to the use" practiced.

I'll just leave it at that.

That's somehow not surprising. We mortals who depend on things like Frontline get the "pitot tube icing" story.

"Use *cases*" SFAIK, that's still the gold standard for critical software design. No, there's nothing about that in DO-178B.

X planes, they figure you can go to blazes in your own way... :)

-- Les Cargill

I am reading the situation quite differently.

According to the recordings recovered from the black boxes from the bottom of the sea, it is quite clear that the flight crew lost situation awareness (e.g. doing nose up when the plane was stalling).

The real question is, why did the flight crew loose situation awareness ? Was it due to bad man/machine interface or bad training ?

No doubt the plane would have landed safely if the pitot tubes had not iced up. The real question is why, with the data that *was* available, 3 qualified crewmembers could not determine that they were in a deep stall.

In any case, I didn't mean to hijack Don's thread and I suppose we should start another one if we want to talk about AF447 and Airbus.

No argument from me on that point. Personally, I think the answer is both. From what I've read, developed stalls are not practiced even in a sim. Couple that with the stall warning going away when the airspeed fell through 60 knots and then came back on as the airspeed increased through 60 knots and you can see that the m/m interface could have been better.

I'm not sure if you're being sarcastic or not. Could you clarify?

But, in the case of multiple overlapping/concurrent events, do you queue those that are preempted? Or, pretend they are playing "behind" the more important notification?

Yes. OTOH, that makes the "notification" longer (in time). It can then be regarded as more of a distraction and/or competing with other potential notifications.

I think you can use sound *qualities* to encode information and exploit that to keep these things terse. E.g., if the front desk *only* uses the PA system to tell folks to pick up the phone (i.e., you don't have to deal with a wide variety of messages like "Scott Johnson, please come to the front office", "Scott Johnson, you left the lights on in your car", "Scott Johnson, your wife is here to pick you up for your doctor's appointment", etc.), then you could assign a particular

*type*/character of sound to each person. E.g., Scott is a wolf-whistle, Bob is a buzzer, Tony is a chime, etc. [no, I am not advocating this in the workplace, just using that as an example]

This keeps the sounds short yet easily recognizable by the people *attuned* to their particular sounds.

Also, I think we (humans) have some small capacity to drag *short* audio sequences out of our memory as long as they have some "color" to them. E.g., "Scott Johnson, pick up on line 4" is long enough that *Bob* is not likely to remember *who* was paged (he'll know it wasn't *him*) -- though he might remember "line 4". I'm claiming that he'd probably be able to tell you if it was a wolf-whistle or a chime -- even though it *wasn't* the buzzer that signals *him*

But, I suspect these things aren't really "events" as much as "conditions"? I.e., "the captain has turned off the seatbelt sign" denotes an instant in time. OTOH, "low oil pressure" is probably a (persistent?) condition.

Or, said another way, if you *missed* the low oil pressure "notification", you'd need a reminder because it (probably) still exists.

Said yet another way, a buzzer sounding (continuously while oil pressure is low) is more in line with that than a single "chime".

This goes to the fact that (I think) people have very short audio memories. And, if lots of "events" are thrown at them, it is easy for one or more to be ignored, overlooked, etc. So, a "condition" merits a more static indication than the transient ones I'm describing here (I haven't yet figured out how to deal with those :-/ )

The analogy I am using (in my own evaluation of how to do it) is that of your PC desktop. E.g., "new (USB) hardware detected" is an event. If you miss it because you were distracted by something else, you can later deliberately go looking for the status of that hardware. Likewise "you have mail".

OTOH, if the printer goes offline (out of paper), that's a

*condition* that persists until acknowledged/remedied. (sorry, it's not a good example compared to "low oil pressure").

Also, the sorts of notices you are probably thinking of wrt flying are probably all in the "important" class. I.e., do you have a "crusing altitude attained" notification? Or, other non-critical/information-only things?

By contrast, think of a PC/computer user who might be notified when his print job is complete, when another user has logged in, when a network connection is dropped, etc.

Isn't the paradigm you're looking for that each system has its own physical noise maker? E.g. The oven goes ding at the same time as the washing machine buzzes; I hear them both and arrive at my own priority scheme to service them. Embed this and you have a audio system that can mix an arbitrary number (N) of distinct sounds into a composite to drive your one speaker. It's only when you have more than N simultaneous noises that you need to start queuing or interrupting them. Or, maybe I'm misunderstanding the question :-) Bob

In a "real world" environment, you have lots of extra cues that aren't (necessarily) present in an artifically created one.

E.g., you have situational awareness that "primes" your mind for these particular (oven, washing machine) notifications.

[imagine how you would react if you heard the washing machine buzz when you didn't KNOW there were clothes being washed]

You also have directional cues (what if the washing machine's "buzz" originated at the place where you know the *oven* to exist?).

You (we) can handle multiple sound sources pretty well when they are long "streams" (cf., cocktail party effect) but short "notifications" are harder to identify esp when competing against similar notifications.

"N" is a fluid constraint that varies situationally as well as "personally". E.g., if you are cognitively engaged in a particular task, a "brief" (terse?) audio notification can be highly disruptive. Your attention may resist the distraction. If there are many of these, even more so.

You (I) want a filter that knows how to let the right information through. And, the ability to parameterize it as your notion of "right" varies dynamically.

E.g., a "good secretary" manages the "interruptions" that, unchecked, would overwhelm his/her boss. He/she doesn't apply rigid rules but, instead, balances situational requirements.

So, if the CEO has "dropped in" for a little chat, the Financial Director might be turned away from the boss's door (who otherwise might have unfettered access). OTOH, if its a slow day and the mail clerk wants a chat, that might be *allowed*.

One obvious criterion for such a filter is juggling some number of concurrent alarms to keep N "reasonable" -- instead of just throwing it all in the user's lap and hoping he/she can sort it out.

[e.g., I've already decided that there needs to be a way of looking back at the most recent "events" to see if you've missed any. Of course, doing this while *other* events can continue to be generated is a whole 'nother problem!]

I had a recent experience with this kind of annuciator. I happened to have been in Washington D.C. during the earthquake recently, and many buildings seemed to have false fire alarms as a result of that. I went into the lobby in one building to fetch my car from the parking garage and there was a loud klaxon-like alarm, an occasional siren and a canned voice message which I couldn't hear through all the cacophony. The security guards were calmly chatting to each other and waved to me, so I figured it was a false alarm. I got onto the elevator and when the door closed, it muffled the klaxon in the lobby and I could finally hear the voice message which was saying, "This building is experiencing a fire emergency. Do NOT use the elevators." Oops!

Another thing to avoid is an error I made on a first version of a design some time ago. The audio output was various kinds of different sounds based on particular conditions of the device. In my case I decided for simplicity to just have a single queue and just queue up the various short, canned output sounds. There was an error in the code in the first version in which the sound queue output processing was suspended but not resumed. The result of that bug was that only when the user pressed a button (and the queue processing was resumed as a side effect) they got maybe a serialized beeps and boops of the last hour's worth of unprocessed sound outputs! Not very helpful and extremely annoying. If I recall correctly, I reimplemented using a priority queue with expiration and never needed expiration once the bug was fixed.

Ed

[ You should have inherently *known* that to be the case! :>

(don't step into a box that relies on external forces to let you out!)]

Yes, this is clearly masking in the extreme. A result of each annunciator being designed with the "I'm most important" attitude and no mechanism to tolerate coexistence with others.

This is why I had suggested (as one possible strategy) simply inhibiting an "overridden" annunciator so that the more important one was audible (if annunciators are independently chosen/designed, then you never know which is going to have the greater masking effect when perceived concurrently with each of the others)

Yes. And, even in the absence of a bug, this ends up tying up the audio channel for increasingly longer periods of time. E.g., each annunciator/notification takes *some* amount of REAL time. Arranging them serially increases the chance that some *other* notification will be "blocked" (and thus enqueued -- further lengthening the queue!) while they are playing.

E.g., in a degenerate case, you could imagine one notification being enqueued while the process that signalled it is waiting for an acknowledgement (unaware that the notification has yet to be "played"). Eventually, lacking that acknowledgement, it issues yet another of those notifications (which is appended to the queue...). Etc.

Even more pathological behaviors can result! Consider: first a "priority based" scheme in which a particular notification is issued at, e.g., priority 3. For whatever reason, it is queued and the notifying process starts waiting for that acknowledgement. Eventually, it gets impatient and reissues a more "significant" notification. I.e., "Hey! You have failed to acknowledge my warning that the aircraft was getting ready to stall (perhaps because the 'left-engine-on-fire alarm' has preempted that notification) so now I am going to SCREAM (using a more noticeable notification at a higher priority): aircraft is in a stall!!!"

The notification handler sees this higher (highest?) priority annunciator queued and moves it to the head of the queue. As a result, you get the *second* warning FOLLOWED by the *first* warning! Without being a pilot (Jim??), I can still imagine that this would just add to your sensory overload in a critical situation: "Huh? I'm taking corrective action (based on that SCREAM). So why is it now telling me I'm (still?) in a stall??"

[of course, you can work around this by creating notification "channels" such that any more important notification in *that* channel discards all others, etc.]

To avoid the serialization, I had suggested the "already in progress" strategy. I.e., the more important notification deliberately masks ("mutes") the other notifications BUT THEY CONTINUE "playing". So, their temporal needs are met in the same way regardless of whether they are masked or not.

A possible refinement would be to digitally mix them such that more important messages were louder and less important ones quieter but not necessarily fully muted.

Ed

Yes.

But, without knowing (or constraining) the characteristics of each "sound" (notification), this can get tricky. E.g., a sound mapped to one particular notification could be "louder" than one mapped to a different (lower priority) one.

And, you are still faced with the potential for the number of such sounds to be unknown -- yet now you are incurring a processing cost for each additional sound. (i.e., one of the advantages of masking is it keeps your costs closer to constant since "one" -- or N -- sound is played at a time)

Another solution might be to *fix* the sounds used for notifications and just allow their mapping to be changed (then the sounds can be chosen to be audibly unique).

Yes, but unless they're constrained to begin with, this would be the case whether or not they were played simultaneously or sequentially.

Depending on the processor and sound hardware, the processing could be very nearly free. If both sounds are serialized in memory somewhere and the output is via a simple DAC, then for each time slot, "mixing" is simply a matter of prescaling each sample, adding them, and sending the result to the DAC.

If you don't allow all possible simultaneous (or overlapping) sounds to play without delay, the problem is then essentially identical to an RTOS task scheduling problem, and so techniques for that should work just as well for this purpose.

Ed

One notification might be a tone, another "spoken word". The energy in each is different. And, perceived/tolerated differently.

E.g., something "spoken loudly" might be harder to understand than something spoken at a lower volume level. OTOH, a soft tone might be too easily ignored vs. a louder tone.

Sure. But you still have to decide what to attenuate and how much to attenuate it, etc. It's not just "pick *this* one instead of

*that* one"

An RTOS is an amusing parallel. Esp if you consider HRT systems. I.e., if a low priority task (notification) is preempted by a higher priority task (notification) AND the deadline for the low priority task expires before it can be resumed, you *cancel* the lower priority task (after the deadline, it has no *value* to its completion)

This is akin to the "already in progress" approach.