Hi,
Imagine some number of -- potentially concurrent -- audio annunciators. They are characterized as being of short, fixed duration (O(seconds)) but may be complex in nature (e.g., a police siren is considerably more complex than a Windows "ding").
Given that these can originate at unrelated (?) times, what sort of infrastructure seems suited to preserving the most information (since annunciators can be thought of as conveying specific information)?
[I'll use event interchangeably with annunciator below]E.g., several naive schemes suggest themselves:
- ignore other annunciators while "playing" the current one
- interrupt any current annunciator to play next event
Along with simple enhancements:
- play next event AFTER current is completed
- resume interrupted event after current completes
And, even more subtle enhancements:
- resume interrupted "already in progress" after current completes
- assign priorities to events and revisit question (think about it)
But, I think these are too simplistic to handle an unconstrained set of "annunciators".
E.g., if you interrupt a current event after 1ms, the interrupted event is unrecognizable. Especially if you use the "already in progress" strategy -- the interrupted event may *expire* before the interruptING event completes. I.e., it seems like there should be a hold-off applied to new "audio activity" to ensure the existing activity is recognizable. But, that delay might vary depending on the annunciator's actual temporal characteristics. (i.e., perhaps you have to specify a miminum for each particular annunciator?)
It also seems that you would want to put some deadspace between annunciators. So they isolate themselves from their temporal neighbors as separate "events". Sort of like putting a mask around text to ensure it stands out amid the background it might be layered upon.
The issue of sequential vs. "already in progress" can have a dramatic impact on what gets *heard* (imagine two successive events each overriding the very first annunciator such that even a lengthy annunciator isn't long enough to span the time of these two). OTOH, if you enqueue them, you run the potential of scheduling more events than you have real-time to "play" them!
I can't see how to parameterize such a system to ensure all the information is presented -- without requiring explicit acknowledgement of each by the user, etc.
--don