SR10 Wired Audio Configurable Multiplexing (w/ Prioritization)
Different riding conditions and scenarios require flexibility in the configuration and behavior of the SR10.
I would like to build on concept that Mark Harrison's suggested in a forum thread on Audio Mixing. The concept that I would like to introduce is customizable / prioritization options for the SR10 to function as a Audio Mixer OR an Audio Mux. Specifically regarding how the SR10 mixes and switches the (3) wired audio inputs.
Via the SR10 Manager interface, I would like to have the ability to:
1) Turn the AUX Audio Mixing ON / OFF (If ON, all audio sources would be mixed together as they are today under the SR10 v1.2 firmware functionality)
2) If Audio Mixing is OFF the SR10 will function as a Audio Multiplexor with the ability to set the priority for each of the 3 SR10 wired audio inputs individually (i.e. the 2-way radio, AUX1 & AUX2). Conceptually, higher audio priority inputs override lower priority inputs if simultaneous audio input signals are detected. An optional "connection hold" value (e.g. hold the audio input source open for n seconds after no audio is detected) would also be desirable for fine tuning beyond default values.
EXAMPLE 1: Assume a 2-way radio is connected via the hi-rose connector, a GPS on AUX1, and a Radar Detector on AUX2.
USE-CASE#1- "I Like Talking to My Riding Buddies, but I don't Want to Get a Ticket". SETTINGS VIA SR10 Manager > Priority=1 AUX2 (Radar Detector). Priority=2 HI-ROSE (2-way radio audio). Priority=3 AUX1 (GPS). OUTCOME FOR THIS USE-CASE: GPS audio directions would be heard unless a incoming 2-way radio signal was detected (GPS audio would be switched off, 2-way radio audio on), the 2-way radio audio and GPS audio would be switched off if an audio signal was detected from the Radar Detector (which carries the highest priority).
**
EXAMPLE 2: Assume a 2-way radio is connected via the hi-rose connector, a GPS on AUX1, and a UHF radio scanner on AUX2.
USE-CASE#2- "A Very Large Ride Event with Multiple Ride Groups, and Support / Chase Vehicles with Radio Communication". SETTINGS VIA SR10 Manager > Priority=1 HI-ROSE (2-way radio audio). Priority=2 AUX1 (GPS). Priority=3 AUX2 (UHF Radio Scanner to monitor multiple Ride Group / Support Channels). OUTCOME FOR THIS USE-CASE: A broad range of UHF channels can be monitored ( listened to (weather, hazard, emergency, etc.), GPS audio directions would override the UHF monitored audio, unless a specific communication was received via the 2-way radio, which would then take priority over all other audio).
**
There are many other potential use-cases, scenarios, and specific applications where riders would benefit from having the increased control over the behavior of the SR10. Specifically in the multiplexing management and prioritization of wired audio inputs. I believe the proposed functionality to be a desirable capability across your entire SR10 customer base, providing the ultimate in product flexibility, and if implemented, would further sustain and extend SENA's market leading capability in the motorcycle communication integration space.
Can you provide this capability in the SR10 v1.3 release ?
-
Thank you for your suggestion. We will do the feasibility study for customizing mixing and priority setting on the SR10 Manager. We will keep you informed later.
0 -
@Daniel Brunt - I read the specs on the mixitproducts device you identified. It sounds like it offers a form of the audio mixing and multiplexing for mono GRMS audio that I proposed above.
Any progress / status on the implementation of the request capability?
COPY OF A POST I MADE ON ANOTHER THREAD:
However, the SR10 device that many of us have already invested in is a robust platform with an decent embedded micro-controller, DSP, and DAC capabilities. What is needed is a modification to the firmware / microcode for the (i.e. the software program) that instructs this sophisticated hardware package (the SR10) on how to behave / function / process and prioritize the multiple audio streams that it is already capable of handling.
Ergo, we don't need more 3rd party hardware to strap onto our handle bars and cobble together with a myriad of home brew cables and connectors; We (the customer base) need to influence the Software Engineers at SENA to get busy and write some code to meet the real world conditions we operate in.
0
Accedi per aggiungere un commento.
Commenti
2 commenti