Filter screaming: danger to hearing
Hello all. I know that Kassen already posted to the list about (what seems like) a filter instability problem in certain situations. But after a conversation with him it seemed that I hadn't conveyed the full nature of the problem clearly, so in this post will try to do that. To recap, here's some code from Kijjaz that demonstrates the problem: PulseOsc osc => BPF filter => blackhole; 20000 => filter.freq; 0.5 => filter.Q; for(int i; i < 100; i++) { <<< "osc: ", osc.last(), " filter: ", filter.last() >>>; samp => now; } The value output by the filter keeps rising. I ran into this problem while i had a similar patch connected to dac instead of to a blackhole. I was wearing headphones, but i took the usual precaution of turning my macbook volume to the lowest level above 0 before running the patch. To my alarm, the resulting screaming sound came through my headphones at top volume anyway. It turns out that when set to any of the volume gradations above 0, the screaming happens at effectively full volume on my macbook. So the point of this extra post is to emphasise that (at least for mac users) the filter screaming issue is currently quite dangerous for hearing/speakers, even if you take (imo) normal sensible precautions before running a patch.
I'm aware that this is what happens what a filter is set at a negative value, and I guess from this example that the same thing happens at high filter values. (Maybe the value is looping?) I've never noticed this problem when the filter is keep > 0 and < 10000, so I think you can avoid it like that until a fix is given. But yes, the resulting sound is always at max volume. On Sat, Nov 28, 2009 at 11:09 AM, Tomasz Kaye's brain < tomasz.brain@gmail.com> wrote:
Hello all. I know that Kassen already posted to the list about (what seems like) a filter instability problem in certain situations. But after a conversation with him it seemed that I hadn't conveyed the full nature of the problem clearly, so in this post will try to do that.
To recap, here's some code from Kijjaz that demonstrates the problem:
PulseOsc osc => BPF filter => blackhole; 20000 => filter.freq; 0.5 => filter.Q; for(int i; i < 100; i++) { <<< "osc: ", osc.last(), " filter: ", filter.last() >>>; samp => now; }
The value output by the filter keeps rising.
I ran into this problem while i had a similar patch connected to dac instead of to a blackhole. I was wearing headphones, but i took the usual precaution of turning my macbook volume to the lowest level above 0 before running the patch. To my alarm, the resulting screaming sound came through my headphones at top volume anyway. It turns out that when set to any of the volume gradations above 0, the screaming happens at effectively full volume on my macbook.
So the point of this extra post is to emphasise that (at least for mac users) the filter screaming issue is currently quite dangerous for hearing/speakers, even if you take (imo) normal sensible precautions before running a patch. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- David M
David; I'm aware that this is what happens what a filter is set at a negative
value, and I guess from this example that the same thing happens at high filter values. (Maybe the value is looping?) I've never noticed this problem when the filter is keep > 0 and < 10000, so I think you can avoid it like that until a fix is given. But yes, the resulting sound is always at max volume.
I believe that at least LPF can become unstable at lower frequencies (I still need to confirm this). Most likely the stability of the filter at given frequencies will also depend on the sample-rate is I'd suggest supplying yours when giving this kind of example. In this case 44.1K v.s. 48K can make a big difference, I suspect IMHO it would be good for these filters (LPF, BPF, etc) to confirm that the coefficients resulting from the requested parameters actually result in a stable filter. As a side-note, I tend to monitor through a mixer with the soundcard at full volume and the hardware faders down to a reasonable level and only use headphones directly from my laptop when on the move. Even then I will rarely start code I'm not sure about with headphones on. Our ears may well need to service us for another half century or -hopefully- more. That's a long time for a precision instrument that can easily take the state of the art in technology to task in many regards. Perhaps it's not necessary to note this again but Tomasz's description of the blast he got scared me a bit. Kas.
I made a very crude test to see at roughly what kind of filter
settings the 'blowing up' was happening. It seems that keeping the
freq to below 10000 doesn't solve it unfortunately. With the following
code i'm varying the freq and Q of a BPF.
PulseOsc osc => BPF filter => blackhole;
100::samp => osc.period;
0 => int freqlowerbound;
10000 => int frequpperbound;
0 => int overrun;
0 => float qlowerbound;
1 => float qupperbound;
for(qlowerbound=>float k; k < qupperbound; k + 0.1 =>k) {
qlowerbound + k => filter.Q;
for(freqlowerbound=>int j; j < frequpperbound; j++){
freqlowerbound + j => filter.freq;
for(0=>int i; i < 100; i++) {
samp => now;
if(filter.last()>100){
<<< "Blowup happening: filter.freq: " + filter.freq() + "
filter.Q: " + filter.Q() >>>;
1 => overrun;
samp => now;
break;
}
}
if (overrun==1){
// skip to the next Q value if we got a blowup at the current freq
0 => overrun;
break;
}
}
}
Here's the output I get (intel macbook, 44.1khz)
"Blowup happening: filter.freq: 2218.0000 filter.Q: 0.1000" : (string)
"Blowup happening: filter.freq: 4429.0000 filter.Q: 0.2000" : (string)
"Blowup happening: filter.freq: 6641.0000 filter.Q: 0.3000" : (string)
"Blowup happening: filter.freq: 8853.0000 filter.Q: 0.4000" : (string)
2009/11/28 Kassen
David;
I'm aware that this is what happens what a filter is set at a negative value, and I guess from this example that the same thing happens at high filter values. (Maybe the value is looping?) I've never noticed this problem when the filter is keep > 0 and < 10000, so I think you can avoid it like that until a fix is given. But yes, the resulting sound is always at max volume.
I believe that at least LPF can become unstable at lower frequencies (I still need to confirm this). Most likely the stability of the filter at given frequencies will also depend on the sample-rate is I'd suggest supplying yours when giving this kind of example. In this case 44.1K v.s. 48K can make a big difference, I suspect
IMHO it would be good for these filters (LPF, BPF, etc) to confirm that the coefficients resulting from the requested parameters actually result in a stable filter.
As a side-note, I tend to monitor through a mixer with the soundcard at full volume and the hardware faders down to a reasonable level and only use headphones directly from my laptop when on the move. Even then I will rarely start code I'm not sure about with headphones on. Our ears may well need to service us for another half century or -hopefully- more. That's a long time for a precision instrument that can easily take the state of the art in technology to task in many regards.
Perhaps it's not necessary to note this again but Tomasz's description of the blast he got scared me a bit.
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Tom noted on Facebook that ChucK has now turned out to be capable of causing permanent bodily damage. It was only a matter of time, I suppose.... I'd like to point out that one of the things that's going on here is that apparently OSX is using floatingpoint without hard clipping all the way through the sound system. That's nice for sound quality but it does mean that fixing these filters will not protect your ears in all cases. Nothing prevents one from setting a 15 digit number as the gain for a UGen, which I would assume would have much the same effect. Please be careful; you only get a single pair of ears and while they can adjust to high volume (to some degree) this takes some time and very sudden, very loud, sounds can and will do permanent damage. I suppose this also means that parties interested in winning the "loudness war" should start releasing in one of the floatingpoint file formats on iTunes, if that's possible. "No warranties, no refunds, please mind your speakers and neighbours", should probably be amended to "No warranties, no refunds, please mind your speakers, ears and neighbours" now. Yours, Kas.
participants (3)
-
David M -
Kassen -
Tomasz Kaye's brain