| *** alvaro__ has quit IRC | 02:08 | |
| *** csaavedra has quit IRC | 02:44 | |
| *** lbt has quit IRC | 03:13 | |
| *** lbt has joined #maemo-devel | 03:13 | |
| *** lbt has quit IRC | 03:14 | |
| *** lbt has joined #maemo-devel | 03:14 | |
| *** GeneralAntilles has joined #maemo-devel | 03:16 | |
| *** DocScrutinizer has quit IRC | 03:36 | |
| *** DocScrutinizer has joined #maemo-devel | 03:37 | |
| *** madsy has joined #maemo-devel | 03:43 | |
| *** swc|666 is now known as Mr_Kingsford | 03:55 | |
| *** ptl has joined #maemo-devel | 04:11 | |
| *** Mr_Kingsford is now known as swc|666 | 04:51 | |
| *** MNZ has quit IRC | 05:40 | |
| *** eggonlea has joined #maemo-devel | 05:50 | |
| *** shinkamui has joined #maemo-devel | 06:17 | |
| *** kamui__ has quit IRC | 06:21 | |
| *** eggonlea has quit IRC | 07:14 | |
| *** DocScrutinizer has quit IRC | 07:30 | |
| *** DocScrutinizer has joined #maemo-devel | 07:30 | |
| *** DocScrutinizer has quit IRC | 07:34 | |
| *** DocScrutinizer has joined #maemo-devel | 07:34 | |
| *** swc|666 has quit IRC | 07:56 | |
| *** fragment has quit IRC | 08:46 | |
| *** achipa has joined #maemo-devel | 09:21 | |
| *** mirr0r has quit IRC | 09:44 | |
| *** tomast has quit IRC | 09:56 | |
| *** paul33 has quit IRC | 10:25 | |
| *** tomast has joined #maemo-devel | 10:34 | |
| *** amigadave has joined #maemo-devel | 10:47 | |
| *** JPohlmann has joined #maemo-devel | 10:51 | |
| *** dazo_afk is now known as dazo | 10:54 | |
| *** tomast has quit IRC | 11:19 | |
| *** madsy has quit IRC | 11:21 | |
| *** achipa has quit IRC | 12:17 | |
| *** csaavedra has joined #maemo-devel | 13:15 | |
| *** achipa has joined #maemo-devel | 13:24 | |
| *** Mister_X] has quit IRC | 13:32 | |
| *** Mister_X] has joined #maemo-devel | 13:32 | |
| *** ilius has joined #maemo-devel | 13:35 | |
| *** MNZ has joined #maemo-devel | 13:49 | |
| *** MNZ has quit IRC | 14:44 | |
| *** MNZ has joined #maemo-devel | 15:28 | |
| *** madsy has joined #maemo-devel | 15:50 | |
| *** ilius has quit IRC | 15:56 | |
| *** achipa has quit IRC | 17:03 | |
| MNZ | Anyone have any info on whether or not, and how, the camera uses the omap3's DSP ? Do we have the kernel code to manage this? | 17:32 |
|---|---|---|
| *** JPohlmann has quit IRC | 17:49 | |
| *** amigadave has quit IRC | 18:02 | |
| SpeedEvil | It's complex. | 18:04 |
| SpeedEvil | As I understand it. | 18:04 |
| SpeedEvil | The cameras are connected to the same port, with an external selectror switch. | 18:04 |
| SpeedEvil | This goes to a camera interface block that does the low-level shit. | 18:05 |
| SpeedEvil | You can then either directly read the image, or put it through a block that does stuff - for example jpeg compression, vignetting correction, noise removal. | 18:05 |
| SpeedEvil | This block is used inthe normal software. | 18:06 |
| SpeedEvil | It's configured by a binary blob | 18:06 |
| SpeedEvil | In principle you can write your own, but this isn't trivial | 18:06 |
| MNZ | ok, this blob is it the code loaded onto the DSP? | 18:07 |
| SpeedEvil | no | 18:07 |
| MNZ | are we using the DSP? | 18:07 |
| SpeedEvil | It's a seperate functional block with hardware encoding units. | 18:07 |
| MNZ | the jpeg encoding happens in the DSP.... or at least it's possible, and that's what everyone seems to think | 18:08 |
| MNZ | SpeedEvil, so you are telling me there's a separate hardware block for the jpeg stuff? | 18:09 |
| SpeedEvil | umm | 18:10 |
| *** nonick has joined #maemo-devel | 18:10 | |
| SpeedEvil | If you have spruf98d - it's page 1496 | 18:11 |
| SpeedEvil | Actually | 18:11 |
| SpeedEvil | I'm unsure that there is a jpeg codec on a quick skim | 18:11 |
| SpeedEvil | I know the camera interface can cope with JPEG cameras - I may have confused this | 18:11 |
| nonick | Hi, i want to upload to maemo, but i get " dpkg-shlibdeps: error: no dependency information found for /usr/lib/libevent-2.0.so.2" it builds a deb on my sb, but fails when upped to maemo. whats the problem ? | 18:12 |
| SpeedEvil | Ok - if the camera outputs JPEG - none of the above modules work | 18:12 |
| SpeedEvil | (the n900 camera does not) | 18:12 |
| SpeedEvil | So the DSP must be used | 18:12 |
| MNZ | SpeedEvil, I do have that datasheet | 18:13 |
| MNZ | and I did read a whole bunch of it | 18:13 |
| MNZ | and I came to that conclusion :/ and people all assume (or have read somewhere??) that the DSP does the jpeg stuff | 18:13 |
| MNZ | now the trouble is, are we using DSP for video/audio as well? For the life of me I can't figure it out | 18:14 |
| SpeedEvil | As I understand it, yes, there are some codecs that use the DSP | 18:14 |
| SpeedEvil | I would poke lcuk and pupnik. Pehaps they have some clue, or perhaps I'm confused | 18:15 |
| MNZ | Any idea which kernel module/code interfaces with the DSP ? | 18:15 |
| MNZ | lcuk, bacon | 18:15 |
| lcuk | RT: @PeterMeeGo Got an #N900? Let me know how you use multitasking. Do you keep the dashboard clean or messy? http://talk.maemo.org/showthread.php?t=61869 - https://twitter.com/PeterMeeGo/status/23243718531 | 18:15 |
| lcuk | I was brought here by the bacon | 18:16 |
| MNZ | lcuk, always works :D could you scroll up a bit and give us an opinion? | 18:16 |
| *** jacktheripper has joined #maemo-devel | 18:17 | |
| *** kamui__ has joined #maemo-devel | 18:17 | |
| lcuk | SpeedEvil, MNZ hmm | 18:18 |
| lcuk | i think for sure it should be asked more widely | 18:19 |
| SpeedEvil | lsmod|grep dsp | 18:19 |
| SpeedEvil | dspbridge 1284 0 | 18:19 |
| MNZ | SpeedEvil, good idea | 18:19 |
| *** shinkamui has quit IRC | 18:21 | |
| SpeedEvil | zaheerm woglinde stskeeps have mentioned dspbridge in my logs | 18:22 |
| ShadowJK | dspbridge is like this thing to interfac with the dsp | 18:30 |
| ShadowJK | to load code into it and to retrieve data | 18:30 |
| MNZ | SpeedEvil, yes, I have some background now | 18:30 |
| ShadowJK | But it's best at causing early hairloss | 18:30 |
| MNZ | s/SpeedEvil/ShadowJK/ | 18:30 |
| villager | SpeedEvil: the way I understand it, behind the v4l2 interface there's a binary blob that does all the image processing that converts the camera image into YUV... then there's a gstreamer plugin that can use the DSP to convert a YUV image into JPEG | 18:31 |
| MNZ | ShadowJK, I also have some background on the hairloss :/ | 18:31 |
| MNZ | villager, any idea what this gst plugin is called? | 18:31 |
| SpeedEvil | villager: That sounds plausible | 18:31 |
| MNZ | nvm, found it | 18:32 |
| villager | but I have no clue whether that binary blob will itself use the dsp | 18:35 |
| *** lmoura has quit IRC | 18:35 | |
| villager | but it's probably just using the camera hardware | 18:35 |
| *** lmoura has joined #maemo-devel | 18:36 | |
| SpeedEvil | the blob configures the camera interface. | 18:36 |
| SpeedEvil | It's seperate from the DSP code | 18:36 |
| SpeedEvil | As I understand it. | 18:36 |
| SpeedEvil | I found it a while back - but I forgot wherre it is. | 18:36 |
| *** _0x47 has joined #maemo-devel | 19:11 | |
| *** VDVsx has joined #maemo-devel | 19:40 | |
| *** pH5 has joined #maemo-devel | 19:51 | |
| *** JPohlmann has joined #maemo-devel | 20:08 | |
| *** VDVsx has quit IRC | 20:22 | |
| *** dazo is now known as dazo_afk | 20:24 | |
| *** VDVsx has joined #maemo-devel | 20:26 | |
| *** JPohlmann has quit IRC | 20:39 | |
| *** JPohlmann1 has joined #maemo-devel | 20:39 | |
| *** MohammadAG51 has joined #maemo-devel | 20:42 | |
| * MohammadAG51 slaps frals with http://pastebin.com/WZfD59Sq | 20:42 | |
| MohammadAG51 | frals, paste expires in 10 minutes | 20:43 |
| frals | checking :p | 20:44 |
| frals | MohammadAG51: can you even start that application? | 20:52 |
| frals | segfaults when i try to run it | 20:52 |
| MohammadAG51 | o_O | 20:53 |
| frals | guess it was because of gobject import | 20:53 |
| MohammadAG51 | weird, wfm | 20:53 |
| MohammadAG51 | QWidget::setLayout: Attempting to set QLayout "" on MainWindow "MainWindow", which already has a layout | 20:54 |
| MohammadAG51 | yep, wfm | 20:54 |
| frals | ~ $ ./test.py | 20:54 |
| frals | Importing PyQt4 modules | 20:54 |
| frals | Importing sys | 20:54 |
| frals | Importing os | 20:54 |
| frals | importing gobject | 20:54 |
| MohammadAG51 | Segmentation fault | 20:54 |
| frals | Importing dbus | 20:54 |
| frals | Segmentation fault (core dumped) | 20:54 |
| MohammadAG51 | clicked screenshot button | 20:54 |
| frals | well | 21:04 |
| frals | the fault is not in importing hildon | 21:04 |
| frals | its because of hildon.hildon_gtk_window_take_screenshot | 21:04 |
| frals | which i guess isnt really compatible with a qmainwindow :p | 21:04 |
| MohammadAG51 | sigh | 21:40 |
| *** VDVsx has quit IRC | 22:04 | |
| MNZ | DocScrutinizer, ping | 22:14 |
| DocScrutinizer | pong | 22:14 |
| DocScrutinizer | MNZ: wazzup? | 22:14 |
| MNZ | well for the shelving filters for bass/treble, I would need to do a bunch of floating point calculations | 22:14 |
| DocScrutinizer | :nod: | 22:14 |
| MNZ | and trig | 22:14 |
| MNZ | inside the kernel | 22:15 |
| DocScrutinizer | eew | 22:15 |
| MNZ | ideas :S ? | 22:15 |
| DocScrutinizer | nah, I'd precompute a 'rainbow table' for -12db@150Hz .. -9, -6. -3, 0, 3 etc | 22:16 |
| SpeedEvil | I'm unsure if the superposition of the outputs of set of FIR filters with given coefficients is the same as the output of a filter with a superposition of the set of their coefficients | 22:16 |
| MNZ | SpeedEvil, it's IIR not FIR btw | 22:16 |
| SpeedEvil | So you can simply add the coefficients precomputed. | 22:17 |
| SpeedEvil | Err - so it is, yeah | 22:17 |
| DocScrutinizer | SpeedEvil: now even you start talking inuktitut :-/ :-P | 22:17 |
| MNZ | SpeedEvil, I have reread that a couple times, still not sure what you mean | 22:18 |
| SpeedEvil | Umm. | 22:18 |
| SpeedEvil | Take 12 IIR filters. Now, load each one with coefficients to implement a bandpass. | 22:18 |
| DocScrutinizer | :nod: | 22:19 |
| SpeedEvil | So filter 4 is a bandpass from 350 to 470Hz. | 22:19 |
| SpeedEvil | And it has a relative output compared to the maximum of -20dB | 22:19 |
| SpeedEvil | If you sum the output of all of these filters, you clearly get an equaliser. | 22:19 |
| DocScrutinizer | yep | 22:19 |
| MNZ | SpeedEvil, which is the whole idea | 22:19 |
| SpeedEvil | Now, what happens if you divide all of the 12 filters coefficients each by 12. | 22:19 |
| SpeedEvil | And then add them into one filter | 22:20 |
| DocScrutinizer | won't fly | 22:20 |
| MNZ | AFAIK that wouldn't work | 22:20 |
| SpeedEvil | Do you get a IIR filter that implements an arbitrary filter. | 22:20 |
| MNZ | the coefficients are not linear in any way | 22:20 |
| MNZ | and they don't affect the filter in a specific way really | 22:20 |
| SpeedEvil | hmm | 22:20 |
| SpeedEvil | I should read up on this. | 22:21 |
| MNZ | also, you can't implement an arbitrary filter in IIR | 22:21 |
| MNZ | (AFAIK) | 22:21 |
| SpeedEvil | By coefficients above - I do not refer to the individual coefficients of any one filter - I mean teh whole set of 128 (or whatever) numbers that comprise the filter. | 22:22 |
| SpeedEvil | hmm. | 22:23 |
| MNZ | from what I gathered, there are specific types of filters that can be implemented with IIR filters. Shelving, EQ, Notch, high/lowpass, etc | 22:23 |
| SpeedEvil | I read the wikipedia page, and it has confused me. | 22:23 |
| MNZ | I generally avoid wikipedia for anything mathematics :D | 22:23 |
| DocScrutinizer | MNZ: (specific filter types) ack | 22:24 |
| SpeedEvil | I thought it was simply for each output sample, the input depends on the total value of previoussample[n]*coefficient[n] where n varies from 0 to filtersize. | 22:25 |
| DocScrutinizer | MNZ: aiui it's simulating a certain type of hardware that implements all those basic types of filters in one block, and you can tune the 'circuit' parameters | 22:26 |
| MNZ | for an IIR its output(n) = A1*input(n) + A2*input(n+1) +..... - B1*output(n-1) - B2*output(n-2) ...... | 22:26 |
| MNZ | DocScrutinizer, yes, that's what I understood as well | 22:27 |
| MNZ | where A1, A2, B1, B2, etc are coefficients | 22:28 |
| DocScrutinizer | much like the VCF you had in first moog synti | 22:28 |
| MNZ | http://www.student.oulu.fi/~oniemita/dsp/dspstuff.txt <--- this was very useful | 22:28 |
| MNZ | skip to the section titled "From poles and zeros to filter coefficients" | 22:29 |
| MNZ | now to computing that table. | 22:29 |
| MNZ | Though I wanted to at least have some sort of finer control over the filter :( I was thinking we could *at least* have a parametric equalizer | 22:30 |
| MNZ | so I could expose the center frequencies of the two shelving filters and their gain | 22:30 |
| *** Venemo has joined #maemo-devel | 22:33 | |
| SpeedEvil | Ah. | 22:35 |
| SpeedEvil | The superposition argument I made above clearly works for FIR | 22:35 |
| Venemo | SpeedEvil: what's up? | 22:35 |
| SpeedEvil | But not for IIR | 22:35 |
| SpeedEvil | hmm | 22:35 |
| SpeedEvil | Can you not use IIR in FIR mode by simply setting all of B coefficients to 0? | 22:36 |
| MNZ | SpeedEvil, AFAIK yes | 22:36 |
| SpeedEvil | Of course, you will gert poorer performance in terms of possible filter accuracy | 22:37 |
| MNZ | I have no idea what the consequences would be | 22:37 |
| MNZ | but I'd imagine you still could not really implement 'arbitrary' filters | 22:37 |
| MNZ | ie, you cannot really base an entire equalizer on just one F/IIR filter | 22:38 |
| SpeedEvil | If you can implement an arbitrary response to an impulse, then you can create arbitrary filters. | 22:38 |
| SpeedEvil | Simply as sound is simply a series of superimposed impulses | 22:38 |
| MNZ | actually, that equation I wrote for the IIR filter, I'm not entirely sure how it relates to the filter as it is in the audio codec | 22:42 |
| MNZ | see the datasheet, page 38 | 22:44 |
| DocScrutinizer | sorry for lengthy quote... | 22:44 |
| DocScrutinizer | A note about implementing the equalizer... If the equalizer is to be adjustable realtime, recalculating the whole equalizer filter formula with all the trigonometric functions may turn out too heavy. It may be better to precalculate coefficients for several overlapping filters, for example these for a three-channel equalizer: | 22:44 |
| DocScrutinizer | When calculating the coefficients for the whole equalizer, just pick the corresponding coefficients from these, scale according to the "equalizer sliders", and sum. | 22:44 |
| MNZ | DocScrutinizer, link? | 22:45 |
| DocScrutinizer | http://www.student.oulu.fi/~oniemita/dsp/dspstuff.txt Windowed FIR filter design | 22:46 |
| *** Venemo has left #maemo-devel | 22:46 | |
| DocScrutinizer | at the bottom. And yes, that's about FIR once again | 22:46 |
| MNZ | aha, well as speculated, it's probably possible to use the filter as a FIR | 22:47 |
| SpeedEvil | Ah - ok | 22:48 |
| SpeedEvil | The above argument is moot. | 22:48 |
| SpeedEvil | I was imagining something with significantly more than 5 coefficients. | 22:49 |
| SpeedEvil | Sorry | 22:49 |
| MNZ | I'm reading that section about equalizer in dspstuff.txt | 22:57 |
| MNZ | and I'm not sure any more if it's possible to create an equalizer out of just two filters | 22:58 |
| SpeedEvil | You won't be able to do much if any equalisation with 5 coefficients | 22:58 |
| MNZ | I'd imagined so yes | 22:58 |
| SpeedEvil | highpass/lowpass is pretty much the limit I imagine. | 22:58 |
| MNZ | not really, there's a way to approximate an EQ, but I'm not entirely sure it'd work | 22:59 |
| MNZ | we have 2 filters to use, so I can pick and match the filters and their shape to approximate the frequency response of a 'real' eq | 23:00 |
| MNZ | the more I think about it, the more it seems to be possible | 23:00 |
| MNZ | specially after mucking about with TI's coefficient calculator | 23:01 |
| DocScrutinizer | SpeedEvil: yes, indeed | 23:01 |
| MNZ | DocScrutinizer, did you check out the calculator? | 23:01 |
| MNZ | http://focus.ti.com/docs/toolsw/folders/print/coefficient-calc.html | 23:01 |
| *** JPohlmann1 has quit IRC | 23:01 | |
| DocScrutinizer | you got 2 parametric eq blocks, which each of them can do any of the basic filter types in any shape and flavour | 23:02 |
| *** JPohlmann has joined #maemo-devel | 23:02 | |
| DocScrutinizer | MNZ: nope, as I'm not windows affine | 23:02 |
| MNZ | it works perfectly on wine, if you have it | 23:02 |
| DocScrutinizer | not even that | 23:02 |
| MNZ | ooh common. It's a simple apt-get install wine | 23:03 |
| MNZ | (or yum install wine) | 23:03 |
| MNZ | (or whatever, you get what I mean) | 23:03 |
| MNZ | so anyway do you reckon an eq approximation is possible or not? | 23:04 |
| DocScrutinizer | nope, nothing of any practical purpose | 23:06 |
| SpeedEvil | Sorry - my earlier comments were predicated on it being a reasonably long filter - say >>32 coefficients | 23:06 |
| DocScrutinizer | as e.g if you want a notch/bandpass for voice freq, you can have the other filter to work on treble and bass simultaneously but only with same boost/attenuate for both | 23:07 |
| MNZ | DocScrutinizer, no, everything is independent for each filter | 23:08 |
| MNZ | bandwidth, gain, center frequency | 23:08 |
| DocScrutinizer | MNZ: you don't get my point. You only have two filters, and it's really hard and usually implies restrictions you don't want, to model anything beyond a simple butterworth/bessel or whatever | 23:09 |
| DocScrutinizer | so with the given hardware you only have 2 parametric filters, and you can basically add two simple curves together | 23:10 |
| *** JPohlmann has quit IRC | 23:11 | |
| DocScrutinizer | each of those curves usually has one max/min only | 23:12 |
| MNZ | each of the curves has a 'center frequency', a bandwidth, and a gain | 23:12 |
| DocScrutinizer | sure you can model a filter that has notches at 1k 2k 4k 8k, but you can't control each notch individually | 23:13 |
| DocScrutinizer | (freq, bw, gain) that's exactly what a parametric eq block does, yes | 23:14 |
| DocScrutinizer | and it's probably best to expose exactly those via kernel API | 23:15 |
| MNZ | DocScrutinizer, actually, yes. It'd be best to expose it as a parametric EQ. | 23:16 |
| DocScrutinizer | if you don't want to do the actual coefficient numbercrunching in userland, and only expose the plain coefficients | 23:16 |
| MNZ | I'm still convinced it would be possible to approximate, say, a 6 band EQ | 23:17 |
| DocScrutinizer | (which I'd think is the cleaner way) | 23:17 |
| MNZ | so we'd completely depend on a userland app to do the calculations, yeah | 23:18 |
| DocScrutinizer | MNZ: real professional equalizers in studios never are multiband graphic, they are always 2- or 3-block parametric | 23:18 |
| MNZ | yeah, but users want a graphic equalizer! | 23:19 |
| DocScrutinizer | so leave it to userland to cope with this insane conversion duty | 23:19 |
| MNZ | I just have a bad feeling it will never be done :D | 23:20 |
| MNZ | ok, I'll just expose the coefficients. Easier for me too :P | 23:21 |
| DocScrutinizer | just build a userland reference app implementing two parametric blocks offering filter-type-switching (HP, LP, BP, NOTCH) and f0, gain, Q for each | 23:21 |
| MNZ | Now will you guys take a look at the de-emphasis block? | 23:22 |
| DocScrutinizer | it's fine for the hifi purists, and anybody inclined can offer an app to have a set of (possibly hundereds) of precalculated EQ settings | 23:22 |
| DocScrutinizer | (userland reference app) sounds like ALSA mixer controls to me | 23:28 |
| *** MNZ has quit IRC | 23:28 | |
| DocScrutinizer | the number crunching to calculate the coefficients from (type,f0,Q,gain) settings in ALSA mixer, well it seems an ALSA plugin is the perfect place to do this. Have to think a bit longer about it... | 23:32 |
| DocScrutinizer | but now for some RL, sorry | 23:32 |
| *** MNZ has joined #maemo-devel | 23:41 | |
| * MNZ scratches head | 23:42 | |
| MNZ | turns out I was D/Ced since about 20 minutes. Did I miss anything? | 23:42 |
| MNZ | nvm, found the logs. Will look into the alsa plugin thing | 23:45 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!