i dont care much about thorkz or anything he has said. he is only serving as an embarrassment to anybody who really wants to objectively discuss these things. i'll try to give him answers (i've been about 9/10 points sure he's a troll since pages 3-4) since no matter if the questions are serious or not, so far they have been valid questions most of the time.
that said, it'll still require 10/10 troll points for me to judge the guy. he hasnt been obvious about it yet if he _is_ trolling. he might be genuine, i dont really care either way. i'd just rather not take the chance at misjudging anybody when it's not necessary.
Integer is King? - final thoughts about the EQ challenge
-
- KVRist
- 86 posts since 14 Jan, 2007 from around
What do you mean you dont care about me???? I thought we were friends? 
But for a last question:
That creeping..... (in time domain?).... would that lead to somthing like sidebands like a FM would produce? That could explain why I cant really get rid off that stuff even with an analog EQ in the monitor path.
Also it could be the reason for the effects not beeing hidden in some noisefloor but more like all over the place.
thorK
But for a last question:
That creeping..... (in time domain?).... would that lead to somthing like sidebands like a FM would produce? That could explain why I cant really get rid off that stuff even with an analog EQ in the monitor path.
Also it could be the reason for the effects not beeing hidden in some noisefloor but more like all over the place.
thorK
-
- KVRian
- 770 posts since 2 Apr, 2003
Actually this "error creeping" theory seems flawed to me.
If I understand correctly aciddose is saying that since small values can dissappear completely when added to large values, the error would tend to creep in one direction.
But we're dealing with audio, which on average will spend as much time positive as negative. so the error caused by such a "dissappearing" value will be negative as often as it is positive, and on average be zero, therefore no creep.
Also, the worst case error with floats is going to be equal to the error you would get with ints the size of the mantissa, best case will be considerably better than that, so a 32 bit float will be as accurate or better than a 24 bit integer.
If I understand correctly aciddose is saying that since small values can dissappear completely when added to large values, the error would tend to creep in one direction.
But we're dealing with audio, which on average will spend as much time positive as negative. so the error caused by such a "dissappearing" value will be negative as often as it is positive, and on average be zero, therefore no creep.
Also, the worst case error with floats is going to be equal to the error you would get with ints the size of the mantissa, best case will be considerably better than that, so a 32 bit float will be as accurate or better than a 24 bit integer.
-
- KVRAF
- 12615 posts since 7 Dec, 2004
well in most cases it wont take effect. i tried to explain that this "creeping" effect was something i've observed specifically in very high and very low frequency filters, and it's dependent upon the specific filter as well. the filter in xhip is one example that i'm drawing from. this is my best explanation for why the filter explodes at very high or very low frequencies or feedback levels rather than just having more or less error as you'd expect. if i'm using the int version, i can use down to 9 bits and it continues to function just fine without exploding. adding more bits improves the clarity and i suspect that this will trail off around 48 bits. you can definitely hear the difference between 24-25 and 31-32.
with the float version, subtracting bits (i have actually not tried this with a 24 bit float or something) seems to make it destabilize earlier on, while adding bits just makes it slightly more stable. it seems like going from a single to a double only moves the point where it explodes out linearly and so to get it to be 100% stable would require an infinite float precision, i guess.
the reason i think it creeps to invalid ranges and explodes is that at very high frequency settings the very small errors become much more important. if you want to see what i mean, try running xhip at 48khz and look at the output of the filter at very high (>18k) frequencies. i'm only using 2x oversampling (just throwing out a sample, no filter involved) and the frequency can actually be brought up to exactly nyquist. the only reason it is currently limited to just below is that i've put in the top end value by hand rather than calculating it.
rate / 9.0
i need a number just very slightly smaller than 9, or smaller than 4.5 since we're talking about nyquist. i've thought in the past that limiting the frequency to just below nyquist is in a way good, since at or very close to nyquist the beat frequency will be very low or zero meaning that you'd get weird results in terms of the amplitude of the oscillation. it would be interesting to know exactly what number i'm looking for though. a number like 8.995 just baffles me.. i dont know how to get that from pi or e or anything else. although - it may be related to the phase error caused by the 1/2 sample delay in the feedback.. i've no idea.
http://xhip.cjb.net/temp/public/xhip.ou ... er.48k.wav (for rate / 9.0)
with the float version, subtracting bits (i have actually not tried this with a 24 bit float or something) seems to make it destabilize earlier on, while adding bits just makes it slightly more stable. it seems like going from a single to a double only moves the point where it explodes out linearly and so to get it to be 100% stable would require an infinite float precision, i guess.
the reason i think it creeps to invalid ranges and explodes is that at very high frequency settings the very small errors become much more important. if you want to see what i mean, try running xhip at 48khz and look at the output of the filter at very high (>18k) frequencies. i'm only using 2x oversampling (just throwing out a sample, no filter involved) and the frequency can actually be brought up to exactly nyquist. the only reason it is currently limited to just below is that i've put in the top end value by hand rather than calculating it.
rate / 9.0
i need a number just very slightly smaller than 9, or smaller than 4.5 since we're talking about nyquist. i've thought in the past that limiting the frequency to just below nyquist is in a way good, since at or very close to nyquist the beat frequency will be very low or zero meaning that you'd get weird results in terms of the amplitude of the oscillation. it would be interesting to know exactly what number i'm looking for though. a number like 8.995 just baffles me.. i dont know how to get that from pi or e or anything else. although - it may be related to the phase error caused by the 1/2 sample delay in the feedback.. i've no idea.
http://xhip.cjb.net/temp/public/xhip.ou ... er.48k.wav (for rate / 9.0)
-
- KVRian
- 770 posts since 2 Apr, 2003
Sorry, maybe I'm being thick, but I'm a bit confused by what you're saying here. Are you rounding off the mantissa to various numbers of bits of accuracy?aciddose wrote:with the float version, subtracting bits (i have actually not tried this with a 24 bit float or something)
-
- KVRAF
- 12615 posts since 7 Dec, 2004
"Are you rounding off the mantissa to various numbers of bits of accuracy?"
no i'm just comparing between long double, double and float. i mentioned i havent tried shaving away mantissa bits, i meant that when i said "24 bit floats or something".
it would be interesting though to start with long doubles and then zero bits directly and track the results.
no i'm just comparing between long double, double and float. i mentioned i havent tried shaving away mantissa bits, i meant that when i said "24 bit floats or something".
it would be interesting though to start with long doubles and then zero bits directly and track the results.
-
- KVRian
- 770 posts since 2 Apr, 2003
ok thanks, now I understand what you meant.aciddose wrote:"Are you rounding off the mantissa to various numbers of bits of accuracy?"
no i'm just comparing between long double, double and float. i mentioned i havent tried shaving away mantissa bits, i meant that when i said "24 bit floats or something".
it would be interesting though to start with long doubles and then zero bits directly and track the results.
-
- KVRist
- 86 posts since 14 Jan, 2007 from around
Sorry that its me again. But now really for the last time (I think)
Another look at mixing in float.
If I add two different sine waves in float I get a "pulsing" quantisation error, am I right here?
Can I look at this as an amplitude modulated noise?
If so, does A-modulated noise build up sidebands like amp-modulated sounds do?
thorK
Another look at mixing in float.
If I add two different sine waves in float I get a "pulsing" quantisation error, am I right here?
Can I look at this as an amplitude modulated noise?
If so, does A-modulated noise build up sidebands like amp-modulated sounds do?
thorK
-
- KVRAF
- 3080 posts since 17 Apr, 2005 from S.E. TN
I do IIR filters in ASM, and unless I run out of registers, I try to keep everything in the FPU stack at 80 bits. If I run out of registers and have to access memory, it is in doubles.
Perhaps the biggest achilles heel-- I save final results back to float buffers on each processing pass.
Forinstance, if applying a fourth-order Linkwitz-Riley filter to a float buffer (two second-order filters in series), I call the first filter asm tight loop, which calcs at double float resolution, but the final results are rounded to 32 bit float back into the buffer.
Then I call the second filter asm tight loop, which calculates in double resolution on the 'rounded results' from the first filter, and saves its rounded result back to 32 bit float.
So if there really is something tiny but significant getting lost, it is most likely lost in the rounding back to 32 bit float on each individual DSP pass on the buffer?
If there is something significant that could get rounded away after multiple passes on the 32 bit float buffer, perhaps it could be avoided by always operating on double buffers? That way you only get ONE round-to-32-bit-float at the exit of the plugin?
I guess in a host that does mixing, the host could use double buffers for streaming to plugins and mixing. But maybe that wouldn't be worth it, if each plugin at minimum must round to 32 bit float at least once when it exits and returns the buffer?
Four plugins in series on a track insert-- The host would have to round its double buffer to float and send it to the plugin, then the plugin calculates and rounds to float. Four rounding steps in a row. With all that rounding going on, maybe it would gain nothing if a host used double mixing buffers?
Do any of ya'll routinely promote float input buffers to double before you process the buffers? If so, do you notice improvements?
Perhaps the biggest achilles heel-- I save final results back to float buffers on each processing pass.
Forinstance, if applying a fourth-order Linkwitz-Riley filter to a float buffer (two second-order filters in series), I call the first filter asm tight loop, which calcs at double float resolution, but the final results are rounded to 32 bit float back into the buffer.
Then I call the second filter asm tight loop, which calculates in double resolution on the 'rounded results' from the first filter, and saves its rounded result back to 32 bit float.
So if there really is something tiny but significant getting lost, it is most likely lost in the rounding back to 32 bit float on each individual DSP pass on the buffer?
If there is something significant that could get rounded away after multiple passes on the 32 bit float buffer, perhaps it could be avoided by always operating on double buffers? That way you only get ONE round-to-32-bit-float at the exit of the plugin?
I guess in a host that does mixing, the host could use double buffers for streaming to plugins and mixing. But maybe that wouldn't be worth it, if each plugin at minimum must round to 32 bit float at least once when it exits and returns the buffer?
Four plugins in series on a track insert-- The host would have to round its double buffer to float and send it to the plugin, then the plugin calculates and rounds to float. Four rounding steps in a row. With all that rounding going on, maybe it would gain nothing if a host used double mixing buffers?
Do any of ya'll routinely promote float input buffers to double before you process the buffers? If so, do you notice improvements?
-
- Skunk Mod
- 21249 posts since 10 Jun, 2004 from Pony Pasture
I may not be convinced of the original claim but I'm for sure learning a few tricks that could spell improvements for my own DSP coding in an entirely different domain (2- and 3-D stuff). For which: thanks.
-
- KVRAF
- 12615 posts since 7 Dec, 2004
i dont think anybody is convinced of the original claim, in fact many of us are nearly convinced (and some entirely!) that it was intentional flame bait 
jcjr, there are definitely improvements keeping everything in the highest precision possible. my problem has been that even with very high precisions in float, it seems like there is some float-specific (when i say float here i dont mean single, i mean floating point) error which causes my filter to destabilize.
for other areas keeping the high precision should definitely make some noticeable improvements, it's just always a trade-off between the cache filling up and audio quality. if you're running a single filter like in an effect plugin there is no sense in using anything less than 80 bit values, since in that case there _should_ be such a small number of variables involved that it doesnt add up to any level which could cause cache issues. although, individual cache lines are 32 bytes, so using anything bit enough to fill that up could cause some issues i'm unaware of if accessing multiple cache lines at once is slower internally than single lines.
thorkz; yes it would be am-modulated quantization noise. the sideband amplitude is always going to be less than or equal to unity (1.0) though, so the effect will be that you'll get closer to white noise instead of the usual quantization noise which has peaks and valleys in it - i think.
jcjr, there are definitely improvements keeping everything in the highest precision possible. my problem has been that even with very high precisions in float, it seems like there is some float-specific (when i say float here i dont mean single, i mean floating point) error which causes my filter to destabilize.
for other areas keeping the high precision should definitely make some noticeable improvements, it's just always a trade-off between the cache filling up and audio quality. if you're running a single filter like in an effect plugin there is no sense in using anything less than 80 bit values, since in that case there _should_ be such a small number of variables involved that it doesnt add up to any level which could cause cache issues. although, individual cache lines are 32 bytes, so using anything bit enough to fill that up could cause some issues i'm unaware of if accessing multiple cache lines at once is slower internally than single lines.
thorkz; yes it would be am-modulated quantization noise. the sideband amplitude is always going to be less than or equal to unity (1.0) though, so the effect will be that you'll get closer to white noise instead of the usual quantization noise which has peaks and valleys in it - i think.
Last edited by aciddose on Wed Jun 13, 2007 3:01 pm, edited 1 time in total.
-
- KVRAF
- 2665 posts since 11 Jun, 2007
But we had fun, didn't we?aciddose wrote:i ... think ... that it was intentional flame bait
BTW, when will Xhip be final, sound like a Virus, run on ProTools, and when will it stop crashing when moving the unison sliders while playing?
Shogger
-
- KVRAF
- 12615 posts since 7 Dec, 2004
i'm going to write a test for the float-multimode-explosion thing and give out the source.
- i want to make sure i'm not insane and this isnt my imagination, in other words validate that this really happens
- i'm pretty sure i dont need to do any of the stuff which makes the xhip filter special in order to show the difference between float and int versions
hopefully i'll be back soon with the source code and results so everybody can see this effect actually happening. hopefully i will _not_ be back saying "hrm, this only occurs with the parts of the code that i dont want to release".. that saddly is a possibility though. not only because i do not want to release those parts, but because i do not want to go through implementing them in float _again_ since it's a pain in the arse.
- i want to make sure i'm not insane and this isnt my imagination, in other words validate that this really happens
- i'm pretty sure i dont need to do any of the stuff which makes the xhip filter special in order to show the difference between float and int versions
hopefully i'll be back soon with the source code and results so everybody can see this effect actually happening. hopefully i will _not_ be back saying "hrm, this only occurs with the parts of the code that i dont want to release".. that saddly is a possibility though. not only because i do not want to release those parts, but because i do not want to go through implementing them in float _again_ since it's a pain in the arse.