WinXP directly driving two 4-way active speakers

[tester]

I agree strongly with stw - generally audio should be switched off by default when opening a schematic.

[steph_tsf]

Okay, I now grasp what you mean.

I agree that in case there is a microphone connected at the ASIO-in, and in case such microphone gets enabled with a fairly high sensitivity (mic switch on, high preamp gain), then such signal will get processed by the .fsm, and show on ASIO-out. This is audio feedback, Larsen phenomenon, potentially leading to damage to the ears, amplifiers, and speakers. Something to avoid, I agree.

Now, tell me. If the user has mikes hooked on ASIO-in, don't you think that he did this on purpose ? And if the user has speakers hooked on ASIO-out, don't you think that he also did this on purpose ? Thus, with a computer setup like this, the user safely and quietly builds a kind of Audio bomb, waiting for a trigger to explode. The bomb may not explode because the user is relying on two separated software never working together, a first software using the mike while muting the speakers, and a second software muting the mike while using the speakers. So, finally, what is the trigger ? I guess you will reply : "your .fsm, dear friend". I confess I must agree on this. You are right.

At this stage, I would appreciate that you agree that it is the user's fault or ignorance, causing him to build a kind of Audio bomb ready to trigger. Right ?

Now, let's see how we could detect such situation upon loading a .fsm (or running an .exe) for telling the user there is an Audio bomb waiting to explode in his computer, that he needs to deal with, otherwise the .fsm (or .exe) will keep waiting for preventing any discomfort or damage.

I have the impression that something like this could become a great standard addition to many Flowstone schematics.

Do you have something in stock, that we could integrate in the .fsm ?

Upon loading the .fsm (audio enabled) or launching the .exe (audio enabled), there would be a 1000 ms test period where the .fsm behaves like an audio generator outputting a -30 dB pink noise on all ASIO-out channels (such level should not be harmful), combined to an averaged two-channel (ASIO-out as reference, ASIO-in as measured) 256-samples FFT analyzer. After 1000 ms, such analyzer knows the ASIO-out to ASIO-in isolation for all frequency bands. The .fsm would display the worst case value (decibels), or display a graphic curve in "expert mode", along with a short message explaining the purpose of such testing sequence. There would be a button for starting a new measurement sequence (presumably, after the user disables his mikes). The full .fsm logic would only engage, if the ASIO-out to ASIO-in isolation is better than 40 dB for all frequencies. In "expert mode", next to the graphic curve displaying the isolation in function of the frequency, there may be a supplementary button allowing the user to force entering the full .fsm logic, after pressing "I understand and take full responsibility" on a disclaimer.

Your opinion ?

[tester]

@steph_tsf - did I mentioned, that some time ago, your wonderful but audio-enabled schematic - almost blew my head out?

[steph_tsf]

@steph_tsf - did I mentioned, that some time ago, your wonderful but audio-enabled schematic - almost blew my head out?

I think I remember. There was a pink noise generator, outputting audio close to fullscale. Was it the dual-channel FFT analyzer? Or Speaker Lab, perhaps, automatically generating FIR-filter coefficients?

[stw]

Your opinion ?

My opinion...
what you call a users mistake actually is a developers mistake, no matter on what purpose or intention something is released. You as the creator of the schematic should always consider that your developing environment mustn't have similar specs as a users one!
Just an example (my example). I have ASIO4ALL driver as one of the ASIO options. If for any reasons other ASIO drivers are unavailable, or maybe your ASIO setting accidentally hits my ASIO4ALL driver, suddenly my Direct Ins and Outs are unintended in the signal path if you enable it by default. If a sudden feedback occurs i'm busted because there's no chance for an immediate access to the controller! This is a really unwanted experience at 4 o' clock in the morning, believe me!
As you may notice i never intentially created any kind of audio timebomb because the setting your .fsm creates never appears under normal circumstances. Every application which creates any similar signal flow at least has some kind of ducking or automute behaviour. Direct access for attenuation is the least to provide.
So even if you don't want to hear it, never release anything which directly feeds an input to an output without direct and obvious user access to kill or attenuate the signal path. Better by default disable these chains and let the user do the activate and deactivate part.

Anyway that's all kindergarten talk because you're experienced enough to know that by yourself, and every attempt to blame others for own failures doesn't increase ones reputation.

The better way would have been to simply just disable the f***in audio drivers - reup you work and all other talks would have been obsolete!

Just to clarify... i'm not talking about any future releases or maybe upcoming the special technical background meeting unharmful environments, i'm talking about that .fsm upload at this place.
My warning will remain because your edits IMHO are the wrong way to handle that issue...

[nix]

Hey Steph,
IMO- it would be better as stw recommends,
turn the dialogues off.
The thing is, we all have different audio setups-
and your default setting will not be correct for us anyway.
Feedback loop potential must always be minimized.
Thanks for the example and in-depth discourse.

[steph_tsf]

The thing is, we all have different audio setups - and your default setting will not be correct for us anyway.

Wow ! Does it mean that if the user has another ASIO-capable card installed than mine, that the demo .fsm could be useless or harmful for him ? I'm curious to see how the Audio Menu appears on different machines, once you enable Audio (new .fsm uploaded in post #5 above).

[nix]

dialogs.png (16.8 KiB) Viewed 32476 times

Here are the dialogs on my internet machine.
My other system has 3 ASIO soundcards installed,
so the selection would be randomly one of those.
Cheers
Yes, leaving audio on can cause problems for sure.
It will just turn on a random configuration.

[stw]

Wow ! Does it mean that if the user has another ASIO-capable card installed than mine, that the demo .fsm could be useless or harmful for him ?

10 people 10 answers. In my case yes and yes.
But thanks for updating your work. Much safer and maybe the way to go for future releases from you.

BTW: I guess most users are not familiar with the technical term "Larsen Effect". Why not call it what it is - audio feedback - and everyone understands what you're talkin about?

[steph_tsf]

I guess most users are not familiar with the technical term "Larsen Effect". Why not call it what it is - audio feedback - and everyone understands what you're talkin about?

Really ? IMO, all Flowstone users should know what's a Larsen. How to get to that ? There could be a question to be answered by the user for the audio getting enabled. "Please tell me what's a Larsen". In case the user does't provide a decent answer, the .fsm could run a short tutorial explaining what's a Larsen. In case the user can't provide a decent answser after watching the tutorial, the .fsm would display the following text : "Bad answer, try again".