Way to limit maximum output volume

#1

Hi,

I just recently started playing with supercollider and I’ve been following a bunch of tutorials.

Running the following code:

// WARNING: do not run this code with headphones on!!!
// read below
{ LPF.ar(WhiteNoise.ar(), MouseX.kr(10, 1000, 0).poll) }.scope;

I accidentally ended up feeding a negative value as the freq input of the low pass filter. This will cause an incredibly loud broken sound to come out of your output even with a single “tick” of volume on OSX. Way louder than I expected possible.

This is probably the consequence of a few bugs (e.g. MouseX returning values smaller than minval on multimonitor setups) but my question basically boils down to:

Is there a way to set a hard limit on the volume of the output of supercollider?
Some safety mechanism to protect my ears.

Any other noob safety tips, not to blow my ears off again are welcome.

2 Likes
#2

Alberto DeCampo wrote a SafetyNet Quark that could be just what you need:

Or there is StageLimiter from BatLib:

And about MouseX, we should definitely look into it if there’s a bug! I have no time right now, but generally what it takes is to find a minimal way to reproduce the bug, and then file an issue on supercollider’s github page

#3

Thank you for the link. SafetyNet seems to successfully limit the volume in the above case.

The Quark’s existence acknowledges that this is a problem and its help files even emphasize that this is problematic for newbies:

Does anyone know why is this plugin not installed by default?
I think this should definitely be fixed before the MouseX UGen.

#4

There’s an existing Github issue.

and apparently Linux and Windows have at least some level of protection by default unlike OSX.

#5

I’m sorry to say that I damaged my hearing permanently using SC due to an error.

Mac volume control doesn’t limit output volume in CoreAudio - I guess they are multiplying a floating point signal by a gain or some such…

too late for me but a more robust solution that is enabled by default would be good

maybe a lawsuit directed at Apple might help on that end

#6

@semiquaver Thanks for sharing.

Unless other software is affected it’s unlikely that you would have a good case. It would likely only backfire against “dangerous open-source” software.

Plus it would seem from the above linked issue that there is explicit code added to supercollider to make the other platforms safe. This would kind of put OSX into “the norm” and possibly put supercollider at fault, since it was clearly possible to prevent (other platforms were implemented). You just risk allowing Apple to make their platform even less “hackable”.

Let’s just fix SC and save some ears :wink:

#7

I think the problem is in in how mac implements the system volume

theright way to do master volume IMO is to convert from floating point to 24-bit int before scaling - so that 1 tick of volume can only hit the DAC with a max level of -40 or some such.

On Mac this is not what’s happening - even with only one segment of volume you can still hit the DAC with full 0db signal.

In a lot of analog signal chains the master volume controls the gain of an op-amp - so pratically limits the amount of volume you can get at the output - hit it too hard and you get input distortion.

By the time you figure out things aren’t working this way it may be too late.

In any case this is a needed feature for SC

#8

Wow, I was personally not at all aware that anyone was ever hurt by using sc. Sorry to hear that, and yes, I agree with doing something about it. I don’t understand all the details, and I’m not a mac user, but I kind of agree with Nathan’s idea to first do a hard clip in mac’s scsynth… Anyway I’ll bring this up tonight at the dev meeting.

Sorry, but I don’t get the same conclusion, I read it a few times but to me it looks like it is indeed an issue with coreaudio on osx, and not like sc protected only other platforms.

1 Like
#9

My super evident dummy-method is to clip and bring it down to amplitudes smaller than 1 before every output. The harmonics/saturation/distortion will indicate if something’s to much.

Something like this:
sig.tanh*0.7

#10

I brought this up during the last dev meeting, and working to fix this dangerous behavior on macosx will be a priority for version 3.12, or anyway right after 3.11.1 comes out (which is imminent, so this work can’t be included in it).

Thanks again for reporting it

#11

@elgiano
Thank you very much for taking care of this!

In case the next release would take long, maybe we could at least temporarily add some warning on the download page with the suggestion to download SafetyNext for OSX users? Ear damage is not exactly something that goes away with a new release.

#12

It definitely makes sense to me, let’s see what other people think.

Maybe something like this? Feel free to propose changes or another version altogether:

CAUTION: macOS system volume doesn’t effectively limit audio applications’ maximum volume. Extra care has to be put in working, especially with headphones, on this platform, because programs could produce unexpectedly loud sounds regardless of system volume settings. For an extra safety measure, it is recommended to use the SafetyNet quark.

#13

Only 3 issues (highlighted in bold above):

  1. point out the actual danger of ear damage otherwise people will skip it like “terms and conditions”
  2. “extra safety measure” would suggest that there are other safety mechanisms, and thus that it’s not that important to do this
  3. without instructions on how to install the quark (most beginners won’t even know what quarks are, let alone how to install one) they’ll simply skip it

Basically it boils down to making it clear that the default should be installing this quark and it’s not just some extra think few people might want to do.

#14

My thoughts for this were to:

  • install a hard Limiter at 1 / -1.0 on the server. Similar to how we implement Volume, but have it on by default
  • include instructions for how to turn it off
  • include UI in the IDE to toggle it.
2 Likes
#15

Or perhaps +/-2? Or, let’s be sure there’s no effect on dynamic range within full scale. I haven’t checked, just being a bit paranoid.

We’re trying to stop signal levels of hundreds of dB from going out. + a couple dB headroom won’t break that (+/-2 ~= 6 dB of course).

I do agree that it wouldn’t be much trouble to put a limiter in by default, and this is probably the best way.

hjh

1 Like
#16

Sorry if there hasn’t been the promptest reaction to this. I’ve now opened a Pull Request to add a warning:

I’m going to post to sc-dev too.
Anyone interested: please comment and/or propose different wordings.

1 Like
#17

As a Mac user I agree that it should be enable by default on MacOS.

My ears had blown up several times, luckily the damage was little.

#18

:’""( sorry about your hearing

#19

Is this already implemented in SuperCollider?

note about SafetyNet quark:

Safety.setLimit(0.1);

Seems to work here. If I set it to 0.8 or so, it’s still far too loud.

for Tidal Cycles a value of 0.05 seems to work even better.

(I’m not a audio expert (yet))

#20

There are some sticky problems here:

  • How to ensure that users don’t defeat the mechanism accidentally by moving nodes or groups.

  • Should the server recorder capture the volume-limited signal or the dry signal? IIRC the general consensus was to record the dry signal – which complicates the implementation (we can’t simply fold it into the Volume synth).

  • Also remaining questions about the impact on client languages other than sclang.

The server produces signals within a given numeric range.

The audio system converts this numeric range into a range of air pressure.

Often this conversion is very loud. It doesn’t surprise me at all that 0.8 would be loud.

There are two solutions: 1. Reduce the volume in the audio system. (The problem in this thread is, though, that lowering macOS system volume doesn’t prevent over-loud signals from reaching the hardware!). 2. Reduce the volume in the software (e.g. by setting a low limit). This will cost a few bits of numeric precision in the digital-to-analog conversion stage (assuming the audio driver expects integer samples – if it takes floating point samples, it’s not a problem at all), but that shouldn’t be noticeable for casual headphone use.

TL;DR Just set the limiter where it’s comfortable and don’t worry :grin:

hjh

1 Like