View Single Post
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#133
Originally Posted by freemangordon View Post
Well, I think I am in position

@Pali, why is that filter needed in Maemo5 kernel, what problem/bug it fixes, or what functionality it adds? Who sent you the patch? Is it upstream patch?

TBH I think you should remove that from kernel-power at least until there is some information WTF is this animal(the filter) doing and who will support it (fix bugs) at least while KP is in devel.

Or even better - remove it constantly.

P.S.
And maybe you should re-consider your policy to accept patches from developers who cannot be contacted/don't want to help if some problem arise, thus leaving only me and you to fix bugs introduced by some random guy.
Originally Posted by vi_ View Post
Well after reading the patch it does look like it could be interesting. I think it implements an IIR filter at the hardware level that is controllable through software. This is an unused hardware feature of the 320aic3x chip. This IIR filter affects the sound coming from the speakers. The part about only supporting 48kHz sample rate also gives me the willies, what are the implications of this?

I think the main beef was that while it was submitted by luke-jr, he has literally no idea what it is or does beyond 'stop n900 speakers from blowing up' (no offense luke-jr, I read your script for getting the nokia binaries for n900 in your gentoo install, it was boss). This in turn aroused suspicion for obvious reasons. It was however written by some other bro in September 2010 who does understand what it is he was creating. I think the original author is still on maemo IRC, he had something to do with chinook version of xchat I think.
Regarding this patch which causes so much paranoia around here I have been studying it today and it is a really nice feature to add, although it actually is not completely correct.

Actually, as you can see in the attached graphic (ellip), the filter coefficients used are wrong, since the intended cutoff frequency is 0.01 of the sampling frequency (that is, 0.01*48000=480Hz) while the real cutoff frequency is half of the intended (that's because he calculated the coefs using an elliptic filter simulation, good for higher order, instead of just Butterworth).

Actually, as it has already been said, speakers protection is implemented in pulseaudio. This is bad for two and a half reasons:
1) pulseaudio eats a lot of cpu
1.5) I hate pulseaudio.
2) mplayer and friends can bypass pulseaudio (actually I bypass pulseaudio in mplayer) and damage the speakers accidentally.
This driver allows to implement all audio filtering in hardware, so 0 cpu usage.

With a little work we can:
1a) Reverse engineer pulseaudio Nokia filters for the different audio output profiles and calculate the coeficients for the IIR filters
1b) Enable a hi-pass filter to protect the speakers, no matter pulseaudio. The cutoff frequency proposed in the patch is around 480 Hz, but if we perform step 1a we can learn what cutoff frequency is Nokia using.
2) Disable filtering in pulseaudio lowering cpu usage by 66% and use some script to load them when the audio profile changes.

To do step 1a, only one question is needed: How to redirect PA output to a file instead of the pcm device? Then feed PA with pure sinusoids in thirds of octave frequencies and calculate the gain, then some algebra for the coefficients.

I'll start by enabling the hi-pass (de-emph) filter with correct coefficients.

EDIT: I forgot to mention, the right coefficients are 31770, -31770, 30771 instead of 32276, -32276, 31785. Calculated using "iir(1, 'hp', 'butt', [0.01 0], [0 0])" in scilab.
EDIT2: I misread the data sheet. The hi-pass filter is only in the input path, the output path has only the de-emph filter (plus the 4º order IIR filter) with no additional hi-pass filter
Attached Images
  

Last edited by maacruz; 2012-02-05 at 19:47.
 

The Following 15 Users Say Thank You to maacruz For This Useful Post: