Active Topics

 


Reply
Thread Tools
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#131
Originally Posted by maacruz View Post
In my case, with those patches enabled (and 512Hz) I do not observe such slowdown, it just takes about 2 seconds to preview.
Though I haven't imported the last kp50 patches yet, let's see what happens when I import them.
I see now, you misunderstand me . I was just asking what those two patches do, while I disabled all those from the list in my previous post. Those two will be the first to be enabled once stability is confirmed without the whole bunch.
 

The Following User Says Thank You to freemangordon For This Useful Post:
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#132
Originally Posted by freemangordon View Post
I see now, you misunderstand me . I was just asking what those two patches do, while I disabled all those from the list in my previous post. Those two will be the first to be enabled once stability is confirmed without the whole bunch.
I meant all 6 patches.
Just reviewed kp scm. Not counting the ck patches and a couple of other extra patches, my kernel has kp49 plus:
shutdown-reboot-patch.diff
option_disable_indicator_led.diff
the famous 6 patches (commit a50dfadacb9afa20d4c610da4a892b2d8b1916ee)
and your SR patches (commit df747c0a1f26594e9e60dd9619036b8995d4023f)

I don't see any patch in kp50-pre which could cause problems, though.
About those patches, 0001 and 0002 change spinlocks to mutexes, so may be they cause trouble (look at 0002 comments).
The other four seem really simple: one fixes a preemption bug, other a usb gadget driver bug, other a bluetooth bug, and the last one is mac80211 mesh related (which we will disable)

Good luck!
 

The Following 2 Users Say Thank You to maacruz For This Useful 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:
Posts: 2,153 | Thanked: 8,462 times | Joined on May 2010
#134
Originally Posted by maacruz View Post
1a) Reverse engineer pulseaudio Nokia filters for the different audio output profiles and calculate the coeficients for the IIR filters
Which pulseaudio filter? Do you know in which package is filter libraries? I'm asking this becuase some closed pulseaudio packages was opened on meego gitorious repositories.
 

The Following 2 Users Say Thank You to pali For This Useful Post:
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#135
Originally Posted by pali View Post
Which pulseaudio filter? Do you know in which package is filter libraries? I'm asking this becuase some closed pulseaudio packages was opened on meego gitorious repositories.
https://bugs.maemo.org/show_bug.cgi?id=6784#c30

I think it is actually easier to perform the classical (physical) reverse engineering and obtain the frequency-response graphs. How can pulseaudio output be redirected?
 

The Following 2 Users Say Thank You to maacruz For This Useful Post:
Posts: 2,153 | Thanked: 8,462 times | Joined on May 2010
#136
 

The Following 2 Users Say Thank You to pali For This Useful Post:
Posts: 3,074 | Thanked: 12,960 times | Joined on Mar 2010 @ Sofia,Bulgaria
#137
@maacruz - where is the high-pass filter applied - only for the speakers or for all of the audio outputs? Sorry for maybe the stupid question, I am too lazy to look at the schematics to check where the IC in question is attached.
 

The Following 3 Users Say Thank You to freemangordon For This Useful Post:
Mara's Avatar
Posts: 1,310 | Thanked: 820 times | Joined on Mar 2006 @ Irving, TX
#138
Originally Posted by maacruz View Post
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.

The chip actually has a proper hi-pass filter so no need to use the de-emph filter for this purpose (have a look at the data sheet referenced in the patch). Both hi-pass and de-emph are first order IIR filters.

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 Nyquist frequency (that is, 0.01*24000=240Hz) 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 240 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 filter with correct coefficients instead of the de-emph filter.

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.
If I'm understanding this right the (high pass) filter purpose is to reject low frequencies (bass) from reaching the speakers? I agree that the tiny speakers N900 has, there is no benefit to push them the bass frequencies. They are not able to reproduce them anyway. All you'd get is just distorted harmonics of the bass, which I find to be very annoying and ruin the listening experinece.

Personally I do not believe you can "blow up the speakers" with the little audio amp N900 has. However, the filter benefits should be reduced distorsion and also lower power consumption since the amp doesn't need drive the bass enegy to speaker.

Just to make sure the filter is not in the audio path to headphones? I do not want to filter the bass out from headphone port.
 

The Following 2 Users Say Thank You to Mara For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#139
Originally Posted by Mara View Post
Personally I do not believe you can "blow up the speakers" with the little audio amp N900 has.
AFAIK, there are many confirmed reports about doing so, while using mplayer (and derivatives) + experimenting with mixer. Of course, "blow up" doesn't mean explosion - it's just damaging the speaker membrane.

Originally Posted by Mara View Post
Just to make sure the filter is not in the audio path to headphones? I do not want to filter the bass out from headphone port.
+1. I think, that it is what freemangordon speaks about.

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following User Says Thank You to Estel For This Useful Post:
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#140
Originally Posted by freemangordon View Post
@maacruz - where is the high-pass filter applied - only for the speakers or for all of the audio outputs? Sorry for maybe the stupid question, I am too lazy to look at the schematics to check where the IC in question is attached.
The IC is the DAC/ADC, so the filters will affect all outputs when enabled, but the patch enables/disables the hi-pass filter in the same function where the speakers are enabled/disabled (rx51_spk_event())
 

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

Tags
development, kernel-power


 
Forum Jump


All times are GMT. The time now is 21:47.