Re: [chuck-users] Heavy distortion/clipping in Windows (Kassen)
Kas/others, It's even a little stranger than one might think. On Mac OSX, it's really hard to clip at all. For example, this code: SinOsc s => dac; 8.0 => s.gain; second => now; runs and sounds fine. You might need to turn your master system volume down so it doesn't blow out your headphones or speakers, but if you do that, you will hear a pretty pure sine wave. The proper gain for this should be 1.0 (the default), but it works ok up to pretty large numbers, but only on Macs. I haven't tried this in a VM Windoze on Mac, and I'm not sure how the audio is virtualized in this case. BUT This very same code would cause hideous distortion on a Windows/ Linux machine, because those audio subsystems have a hard limit on the amplitude that can be sent into the dacs. Mac seems to have figured out a how to deal with this in a very different (floating point) way. PRC
2. Re: Heavy distortion/clipping in Windows (Kassen)
Message: 2 Date: Thu, 19 Feb 2015 19:44:05 +0100 From: Kassen
To: ChucK Users Mailing List Subject: Re: [chuck-users] Heavy distortion/clipping in Windows Message-ID: Content-Type: text/plain; charset="utf-8" On 19 February 2015 at 18:59, Perry Cook
wrote: Ack! This is a common problem, and I thought I had caught all of the clipping/distortion cases on Windows/Linux with our last passes on checking the source code. I'll check it all again and put it in our Errata file for future ChucK/Mini releases, and future printings of the book.
Perry, now that you mention the OS's I'd like to share a thought. I wanted to postpone debating OS audio infrastructure because debates on OS features tends to lead to debates on OS preferences and the next step is likely to be total war and so I thought I'd try to figure out what was going on on my own. ;-)
Am I correct in understanding that you are saying the files could have been made on OSX with the system audio gain set to -say- 0.5? Then ChucK's output could reach peaks of -say-1.5 , it's get attunated and be at .75 when hitting the DAC; perfectly fine. In this case the audio reaching such amplitudes at ChucK's output might go unnoticed by the file's author. Under OS's with a audio infrastructure expressed in int's a output of 1.5 at the ChucK dac would clip at 1 at hitting the OS's audio rating and the final output (assuming identical system volume) would end up at a 0.5 amplitude while being heavily clipped. Is that correct?
Yours, Kas.
Perry,
This very same code would cause hideous distortion on a Windows/ Linux machine, because those audio subsystems have a hard limit on the amplitude that can be sent into the dacs. Mac seems to have figured out a how to deal with this in a very different (floating point) way.
Yes, I think we are on the same page, here. In general I think this is very nice and practical and it probably results in higher sound-quality when sending audio between processes. However, I also think it is the same thing Tomasz Kaye found; When something generating extreme amplitudes happens, like a unstable filter "exploding", while we are on sensitive headphones plugged into such a system, turning down the volume to a comfortable level won't help against that explosion. Our ears will get the blast at the full volume the hardware dac can muster. For that reason I think it may still be beneficial to employ a limiter. Just to state the obvious in case it helps save somebody's hearing; in cases like that a compressor set to some reasonable value like a 1:8 ratio won't help. The max of the floating point range is so big that turning it down to a 8th of the original volume will still be extremely loud. We talked about that before, but hearing damage isn't always curable, so I thought I'd talk about it again. Yours, Kas.
On Wed, Feb 25, 2015 at 11:18 AM, Kassen
[on windows] turning down the volume to a comfortable level won't help
against that explosion Are you saying there's no way to turn down the *output* of the DACs?
Hey, Robert!
On 26 February 2015 at 06:50, Robert Poor
On Wed, Feb 25, 2015 at 11:18 AM, Kassen
wrote: [on windows] turning down the volume to a comfortable level won't help
against that explosion
Are you saying there's no way to turn down the *output* of the DACs?
Let me first clarify; where you wrote "[on Windows]" I meant in systems using a floating point internal sound router. In our case that is really only OSX. Clearly you can turn the dac up or down using dac.gain( float). What I meant is that we have some sort of issue in our code that sends a signal with a huge amplitude, let's assume some signal with 10 digits worth of amplitude, it is hard to turn that down in a meaningful way. If we set the dac's gain to 0.1 then there will still be 9 digits worth of amplitude left; still orders of magnitude louder than what our hardware can deal with. Under normal conditions we would not make such a mistake, but runaway feedback, such as we might encounter in a unstable filter, will rapidly approach the max of what can be expressed in double-precission floats. There ways to deal with that. We could use a limiter or clipper. You can also use a external hardware gain and leave your system volume at 100%. I hope that clarifies how I believe it all works. If you are on Windows or Linux I don't believe this will matter to you, sorry if I was unclear there. Yours, Kas.
Just to reinforce Kas's point: Recently, I had an experience using headphones with ChucK on my mac where I had an improperly set filter value, and it blew up in my ears. Before trying the code, I had set the volume on my mac to the lowest setting, but as Kas and others have explained, when you multiply 0.01 by 10^30, you get 10^28 (figures approximate...), so it's basically giving you the loudest possible sound on your computer, even if you've set your volume as low as possible. My ears seem to be fine, but I was pretty rattled by the experience. Talking to a friend about it, he mentioned that he knew someone who really destroyed her hearing in one ear playing with filters in MAX.
From now on, I'm going to be using this code, and inserting one of these before my DAC whenever I use chuck:
class HardLimit extends Chugen {
2 => float limit;
fun float tick(float in) {
return Math.min(Math.max(in, -limit), limit);
}
fun float setLimit(float limit) {
limit => this.limit;
}
}
I think this is a serious issue for mac users and that it should be
addressed in the next build. My suggestion is to have a parameter of the
dac ugen called dac.limit, which is automatically set to 2 or 3 or so, and
which acts as a hard limit applied to the audio data going into the dac. A
user could set their own limit or set it to -1 or something to indicate no
limit. But I think the default should be something that will not destroy
anyone's hearing. :-)
Marc
On Thu, Feb 26, 2015 at 5:33 AM, Kassen
Hey, Robert!
On 26 February 2015 at 06:50, Robert Poor
wrote: On Wed, Feb 25, 2015 at 11:18 AM, Kassen
wrote: [on windows] turning down the volume to a comfortable level won't help
against that explosion
Are you saying there's no way to turn down the *output* of the DACs?
Let me first clarify; where you wrote "[on Windows]" I meant in systems using a floating point internal sound router. In our case that is really only OSX.
Clearly you can turn the dac up or down using dac.gain( float).
What I meant is that we have some sort of issue in our code that sends a signal with a huge amplitude, let's assume some signal with 10 digits worth of amplitude, it is hard to turn that down in a meaningful way. If we set the dac's gain to 0.1 then there will still be 9 digits worth of amplitude left; still orders of magnitude louder than what our hardware can deal with.
Under normal conditions we would not make such a mistake, but runaway feedback, such as we might encounter in a unstable filter, will rapidly approach the max of what can be expressed in double-precission floats.
There ways to deal with that. We could use a limiter or clipper. You can also use a external hardware gain and leave your system volume at 100%.
I hope that clarifies how I believe it all works. If you are on Windows or Linux I don't believe this will matter to you, sorry if I was unclear there.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- Marc Evans PhD Student in Music Composition at UCSB Stanford BA '10, Music; MA '11, Music, Science and Technology www.marcevansmusic.com "We are here on Earth to do good to others. What the others are here for, I don't know." --W. H. Auden
participants (4)
-
Kassen
-
Marc Evans
-
Perry Cook
-
Robert Poor