Re: Brutefir for Touch or VB-player
Toby Dickenson
> With BrutefirDRC I still had dropouts and "clicking" sound both from Touch
> and HRT. Yesterday I was looking at this for the n'th time and noticed
> that 'filter_length:' in the brutefir config from Klaus is set to
> '1024,64;'. I remember Anders Torger discussing partitioned convolution of
> the filter and checked his web site. Yes!
> '1024,64;' gives very low latency, but is very demanding. By changing this
> to 16 partitions of 4096, cpu usage drops from around 20-25% to around 6%
> while playing a 96kHz track. The clicking is also gone (using Touch, not
> checked HRT on USB port yet). Setting 'float_bits: 32' reduced CPU usage
> further to around 2%.
Hi all. Olav, I hope you dont mind me quoting your email on the new list.
Ive been investigating the effect of filter_length and float_bits on performance.
Attached is a python script which tries all combinations. Numbers are elapsed
time in seconds:
32 64
65536,1 5.175813 10.400801
32768,2 4.745253 9.042772
16384,4 4.359495 8.657616
8192,8 3.751281 9.483818
4096,16 3.584298 11.990837
2048,32 4.530481 18.957166
1024,64 5.677914 28.637125
512,128 8.505780 50.300683
Firstly, using 64 bit is obviously a large performance hit, and I'm sure the
difference is inaudible. I wont argue with anyone that wants to use 64 bits,
but I will change the BrutefirDRC sample filter files to use 32 bits.
Secondly, Olav's suggested 4096,16 is optimal of my machine (core2 duo E7200).
Up to now I had been using 16384,4 which is 22% slower. The default in the
sample files are 1024,64 which is 58% slower.
I would appreciate seeing results from other machines. You need an "input.wav"
file in the same directory. Make sure it is not so long that disk IO affects the
timings; I used a 4 minute album track. You might also need to change the name
of baseline_filter at the top of the script, to refer to your normal brutefir
filter configuration file.
--
Toby Dickenson
Mervin Beng
3.0GHz Xeon E3110
32 64
65536,1 0.542575 0.924676
32768,2 0.492040 0.883122
16384,4 0.557041 0.824138
8192,8 0.607919 0.778408
4096,16 0.717056 0.841170
2048,32 1.008719 1.142344
1024,64 1.557232 1.723474
512,128 2.727756 2.910152
Note that 64-bit penalty is minimal. This is on ubuntu 10.10, with a
liquorix 2.6.37 kernel.
These are results for a Dell Studio 15 laptop:
32 64
65536,1 0.833888 1.388530
32768,2 0.771170 1.182697
16384,4 0.779312 1.132377
8192,8 0.856401 1.258330
4096,16 0.990466 1.690990
2048,32 1.434005 2.462831
1024,64 2.330343 4.342738
512,128 4.134711 7.838100
Also '64-bit' but not as 64-bit as a Xeon??
Thanks for this suggestion. With 8192,8 brutefir is now using only 2%
cpu per channel for a 24/96 audio file.
Mervin
> 1KViewDownload
Klaas Reineke
to have nearly no latency. With Tobys wrapper there is really no good
reason to have such aggressive settings anymore. I started the plugin
and had no wrapper script so the latency was a problem for all
material that needed gapless playback. See this
http://www.ludd.luth.se/~torger/brutefir.html#lowdelay for more
information about the filter length.
Regards Klaas
Olav Sunde
32 64
65536,1 9.854410 16.287175
32768,2 9.355497 14.624213
16384,4 9.151262 12.997282
8192,8 9.951993 13.907033
4096,16 11.647632 17.511732
2048,32 15.506425 25.944718
1024,64 23.597594 43.018412
512,128 40.378681 76.803511
For me 16384,4 is even a little faster than 4096,16. Nice script Toby!
I have noticed that 88.2 and 96 kHz files sound louder than 48 and
44.1 with brutefirdrc. There is no difference between 16 and 24bit.
To test I created a few 10 sec pink noise tracks of various sample
rates, both flac and wav, normalized to 0dBfs. I also converted a real
music track from 24/96 to 16/44.1 and observed the same. I did not
measure the level difference, but I'd guess 8dB corresponding to the
difference between 16 and 24bit.
Any one experience this? I am using analog out from my Touch at the
moment. Maybe this is a Touch issue.. I'll try the same with out
brutefir one of the first days.
Olav
Mervin Beng
Yes I have noticed it. I have not measured, but use a preamp with
digital readout roughly corresponding to 1dB, and I was wondering why
the 44.1kHz tracks needed so much more gain (actually less
attenuation, as it's a 0dB gain buffer). I have not measured the
difference yet, but your suggestion that it's 8dB is consistent with
how many steps louder I need to set 44.1 audio. All my fiac files are
24-bit, and I've verified that the conversion to 24-bit has not
attenuated them.
Finding the source of the issue and "re-gaining" that lost 8dB or so
would be excellent.
I cannot recall if this phenomenon is heard without brutefir, apart
from the attenuation set in the filter config file. It's worth
checking too, to establish if it's a squeezebox-related issue.
I use a dac for output, so the issue appears to exist on digital out
also.
Regards,
Mervin