DocScrutinizer05 changed the topic of #neo900 to: http://neo900.org | conversations are logged to http://infobot.rikers.org/%23neo900/ and http://irclog.whitequark.org/neo900 | 2013-11-04 - the day our fundraiser reached its goal | 2014-05-01 360 devices 75k€| 0712 183 ~30k | 0810 300 ~49k | 0914 346 ~56k
arcean has quit [Read error: Connection reset by peer]
nox- has quit [Quit: Leaving]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 255 seconds]
kolp has quit [Ping timeout: 240 seconds]
vakkov has joined #neo900
vakkov has quit [Ping timeout: 255 seconds]
unclouded has quit [Ping timeout: 272 seconds]
unclouded has joined #neo900
svree4 has quit [Ping timeout: 244 seconds]
svree4 has joined #neo900
silviof has quit [Ping timeout: 265 seconds]
silviof has joined #neo900
kolp has joined #neo900
arcean has joined #neo900
che1 has joined #neo900
<DocScrutinizer05> freemangordon: http://pastebin.com/HbCaWzfe #150 #151 looks pretty bad idea. A) it's a "static" sawtooth signal that's not checking any dynamic properties for all the AGC and mudrc. and worse B) it's exactly 100% phase inverted for left and right, iow has no mono component at all
<DocScrutinizer05> and wth is "for (i = 0;i < 1; i ++)" ?
<DocScrutinizer05> I strongly suggest to use a .wav as input
<DocScrutinizer05> create two .wav as output (for original and algo under test) and cmp
<DocScrutinizer05> don't forget that part of AEP/EAP(?) is AEC which also depends on mic input
<jonwil> aec is not part of aep or of -record
<jonwil> aec stuff all lives in -voice
<DocScrutinizer05> aah, ok
<jonwil> as for how to test it, maybe one way to go would be to modify the code for the record module such that you make it use the original version of one function instead of the clone (e.g. mudrc_process) then test that using whatever causes the record problems. Keep doing this function by function until you find the one that (when switched to use the stock version) makes the problem go away
<jonwil> And from that you know whats broken
<jonwil> and can dig deeper to find out why
<DocScrutinizer05> exactly
<jonwil> I use much the same trick before when cloning only parts of a binary (for a PC game mod I work on)
<jonwil> i.e. I can point it at the stock version of the code and at mine and see which function(s) are broken
<DocScrutinizer05> ideally make that a sequential test that does a switch netween original and new functionA every 500ms, for 10s, then jump to functionB and its new clone, and then functionC aso. Based on counting number of processes samples
<DocScrutinizer05> make sure both functions (original and clone) always get contiguous input signal and simply switch output you listen to
<DocScrutinizer05> btw what happens in C when in for(a; b; c); the a or c term throws error?
<DocScrutinizer05> I gather it just throws error like any other line of code?
<DocScrutinizer05> after all for (); is just one of C's "preprocessor macros", translating into a set of two arithmetic terms and one conditional jump
jonwil has quit [Quit: ChatZilla 0.9.91 [SeaMonkey 2.30/20141013232806]]
<DocScrutinizer05> https://gitorious.org/pulseaudio-nokia/pulseaudio-nokia/commit/b588351f28356b7856701d0bd368f514b2630bef wouldn't have happened in a true high level language with decent type checks
<DocScrutinizer05> but I guess even lint et all or a compiler warning flag would have done
<DocScrutinizer05> no, wouldn't, when all parameters are int32 ;-P
<DocScrutinizer05> int32, the C's "variant" type
<DocScrutinizer05> ;-P
<DocScrutinizer05> I wonder how many of the int32 are pointers/addr that fail with thundercrack on a 64bit system
<DocScrutinizer05> int32 *const *memoryBuffers
<DocScrutinizer05> ?
<DocScrutinizer05> ok, nope, this seems safe
<DocScrutinizer05> the nasty suckers are for sure more hidden
<DocScrutinizer05> downside of disassembly: types get lost
unclouded has quit [Ping timeout: 265 seconds]
Pali has quit [Ping timeout: 265 seconds]
Pali has joined #neo900
norly has joined #neo900
mvaenskae has joined #neo900
norly has quit [Quit: Leaving.]
norly has joined #neo900
<freemangordon> DocScrutinizer05: naah, we have the debug symbols
<freemangordon> so the types are correct
<DocScrutinizer05> aah
<freemangordon> however, errors like what I have patches is the price we pay for the freedom and the speed of C
<freemangordon> *patched
<DocScrutinizer05> hehe
<DocScrutinizer05> I might agree on "freedom"
<DocScrutinizer05> as far as "freedem == loose typechecking" goes
<freemangordon> well, I see "freedom" as "do whatever you want, on your own risk" :)
<freemangordon> and take the consequences :P
<DocScrutinizer05> a language that doesn't allow you to do/code whatever you want isn't a proper coding languge
<freemangordon> and honestly, I feel comfortable with that. though I prefer c++ for not time-critical tasks
<freemangordon> well all the languages allow that, the question is at what prce
<freemangordon> *price
<DocScrutinizer05> nevertheless e.g. in pascal I had to define a union (case in pascal) memory structure to cast from filehandle to pointer to opaque memory buffer
<freemangordon> exactly what I meant
<freemangordon> you are allowed, but it becomes a mess
<DocScrutinizer05> (to fix the problem with early pascal that every file handle needs to get defined in PRAOGRAM headline)
<DocScrutinizer05> arguable if that's a mess or rather focing you to do proper coding
<DocScrutinizer05> forcing
<MonkeyofDoom> Rust is... really nice, imo
<MonkeyofDoom> though not stable enough yet that one can just write code and be done with it, which is sad
<freemangordon> yep, I see your point, but C can do that either, It is up to the coder to do it properly
<DocScrutinizer05> explicit typecasts are mostly OKish when clearly defined what they do. *implicit* typecasts are the real mess
<MonkeyofDoom> but it's nice to have a proper typesystem and then be able to do all the type-ignoring byte-mashing in delimited blocks
<DocScrutinizer05> freemangordon: yep, exactly
<freemangordon> gcc warns you for such implicit casts
<DocScrutinizer05> should
<freemangordon> your fault if you don;t investigate what happens
<DocScrutinizer05> the problem is that many devels ignore all warnings
<DocScrutinizer05> yep :-D
<freemangordon> well, NMP :)
<DocScrutinizer05> :nod:
<freemangordon> I always try to have -Wall in gcc cmdline
<freemangordon> and -Werror
<freemangordon> anyway, lets see what else is broken
<DocScrutinizer05> yep, and the types used in that stuff are not invented by you
<freemangordon> (ir -record module)
<freemangordon> yeah
<DocScrutinizer05> anyway, dst[] is an array of s16le?
<DocScrutinizer05> even with 40kSamples/s rate you create a sawtooth of 40/65 Hz, in http://pastebin.com/HbCaWzfe line 150
<DocScrutinizer05> prolly white noise from /dev/urandom would be better suited to test audio disgital signal processing, than that ;-)
<DocScrutinizer05> but I suggest to read in a .wav file to buffer
<DocScrutinizer05> or even .au
<freemangordon> DocScrutinizer05: I get your point, but I don;t test if algos work correctly, but whether stock and replacement produce ond ant the same result given the smae input data
<freemangordon> so any data should do the job, IMO
<DocScrutinizer05> not really, when your input data is completely out of "range"
<freemangordon> still, output should match
<freemangordon> *outputs
<DocScrutinizer05> sure the test is stil "valid" but not testing much anymore
<freemangordon> sure
<DocScrutinizer05> you as well can use unitialized buffer
<freemangordon> yep
<DocScrutinizer05> couldn't be worse that a 0.6Hz sawtooth ;)
<freemangordon> but it is impossible to recreate the results ;)
<DocScrutinizer05> on the bright side, a read from some init .au file is probably just one line instead of 5. Well not really
<freemangordon> .au?
<DocScrutinizer05> .wav without header, basically
<freemangordon> oh
<DocScrutinizer05> the result of aplay foo.wav >xxx.au
<DocScrutinizer05> more or less
<freemangordon> hmm, will do that lately, makes sense
<freemangordon> or even now
<DocScrutinizer05> :-)
<DocScrutinizer05> always pleased to contribute a small idea
<freemangordon> :)
mvaenskae has quit [Ping timeout: 245 seconds]
<DocScrutinizer05> sox recital.au recital.wav
<DocScrutinizer05> translates an audio file in Sun AU format to a Microsoft WAV file, whilst
<DocScrutinizer05> sox recital.au -b 16 recital.wav channels 1 rate 16k fade 3 norm
<DocScrutinizer05> performs the same format translation, but also applies four effects (down-mix to one channel, sample rate change, fade-in, nomalize), and stores the result at a bit-depth of 16.
<freemangordon> DocScrutinizer05: do you have some .au file around? I can't find example over the inet
<DocScrutinizer05> create your own with sox ;-)
<freemangordon> nor I can fina a way to convert wav-> raw
<freemangordon> ok
<DocScrutinizer05> man soxformat
<DocScrutinizer05> yeah, .raw prolly fine as well
<bencoh> or just write a sine in a s16le array and dump that to a file :)
<bencoh> (10 lines loop :)
<freemangordon> bencoh: are you sure it is 16bit?
<freemangordon> and not32
<DocScrutinizer05> actually .au maybe *has* a header
<DocScrutinizer05> :-/
<bencoh> freemangordon: well, 32b then :)
<freemangordon> DocScrutinizer05: same quesion
<bencoh> doesnt change much
<freemangordon> yeah
<DocScrutinizer05> bencoh: no idea
<freemangordon> but again, sine has a narrow band freqs
<freemangordon> so a raw file will be better
<bencoh> but it's prolly 2x s16 (2chans, s16 each)
<DocScrutinizer05> prolly 32 even, internally. You gotta know your var types ;-)
<freemangordon> ok, going to try 32
<freemangordon> first
<DocScrutinizer05> pretty common to use int32 internally for all audio DSP
<freemangordon> :nod:
<DocScrutinizer05> int32 dst[2][SAMPLES];
varu|zZz has quit [Quit: poo]
<freemangordon> yep
<DocScrutinizer05> you want higher internal precision/range than what's your in/out data, or stuff like average calculations get really nasty
<DocScrutinizer05> r=(a+b+c)/3
<DocScrutinizer05> ;-P
<DocScrutinizer05> do that when a, b, c, and r are all same type
<DocScrutinizer05> with a range from minint to maxint
<freemangordon> hmm, I would have to deinterleave left/right cahannels
<bencoh> huhu
<freemangordon> channels*
<DocScrutinizer05> really?
<freemangordon> yep, as in raw file I have LR/LR/LR...
<freemangordon> and I need those separated when I call mudrc_process()
<DocScrutinizer05> what?
<DocScrutinizer05> raw file *is* interleaved
<DocScrutinizer05> nothing else makes sense
<DocScrutinizer05> oops, that's what you say
<freemangordon> yes, but I have to deinteleave in order to pass the data to mudcr_process
<freemangordon> :nod:
<DocScrutinizer05> #define SAMPLES 2 * 1024 * 1024
<DocScrutinizer05>
<DocScrutinizer05> int32 src[2][SAMPLES];
<DocScrutinizer05> ???
<freemangordon> 2 channels x SAMPLES sample
<freemangordon> s
<freemangordon> src[0] is left src[1] is right
<DocScrutinizer05> ooh, 2 Msamples
<DocScrutinizer05> yep
<freemangordon> any idea of a standart tool I can use to deinteleave that raw data?
<DocScrutinizer05> that's interleaved though, no?
<freemangordon> no
<freemangordon> "src[0] is left src[1] is right"
<DocScrutinizer05> that's what I get from not using strct proper types, like stereosample src[samples]
<DocScrutinizer05> dst[0][i] = dstn[0][i] = src[0][i] = srcn[0][i] = read("infile.raw)
<DocScrutinizer05> well, won't work this way, but you get what I mean
<freemangordon> yeah
<freemangordon> I didn;t want to do it in in runtime, but it seems it will be the easiest way
<DocScrutinizer05> it's init time
<freemangordon> yesh
<freemangordon> *yeah
<DocScrutinizer05> stereosample {monosample l; monosample r}
<DocScrutinizer05> s/stereosample/frame/
<DocScrutinizer05> iirc
<DocScrutinizer05> I guess I never seen a C code line as ugly as this: https://gitorious.org/alsa/alsa-utils/source/d63ab61022939d4f47bb41d91f926e2299b055d0:aplay/aplay.c#L650
<DocScrutinizer05> isn't there a holy rule to have labels left-adjusted?
<DocScrutinizer05> oh well, Jaroslav Kysela's coding style...
mvaenskae has joined #neo900
<bencoh> labels \o/
<DocScrutinizer05> labels are not dead, they just look funny
<DocScrutinizer05> and how would you use goto without them? ;-P
<bencoh> :))
<freemangordon> ok, calling stock and foss functions against 5.8 mb file produced by command "sox equinox-48KHz.wav --bits 32 --encoding signed-integer --endian little test.raw" gives no output difference
<bencoh> \o/ \o/
<freemangordon> hmm, how to tell aplay that input raw file has a sample size of 32bits?
<freemangordon> oh, saw it
<freemangordon> -f S32_LE
<DocScrutinizer05> .u32 ?
<DocScrutinizer05> aa k, that too
<DocScrutinizer05> .s32 even
<DocScrutinizer05> sox is *awesome*
<freemangordon> DocScrutinizer05: I guess http://pastebin.com/fymYxLX5 is enough to prove we have 100% equivalent mudrc_process function
<DocScrutinizer05> looks good
<freemangordon> now I only need to find what else is broken :)
<DocScrutinizer05> I love line 148 :-D
<Pali> ah alsa code is even worse as I thought...
<Pali> we need something new... ideally with same alsa api, just rewritten to be more readable
<DocScrutinizer05> though, are you sure you didn't forget to "normalize" by framesize and samplesize?
<DocScrutinizer05> Pali: you're free to rewrite aplay any time
<DocScrutinizer05> ooh " SAMPLES /= 2;" 155
<DocScrutinizer05> freemangordon: I still feel a tad confused by whether SA;PLES are bytes or number of total samples (l+r) or number of frames (lr tuples, aka (total_samples / 2) aka (bytes/4) )
<DocScrutinizer05> bytes/4 for 16bit sample size, /8 for 32
<DocScrutinizer05> ftell yields bytes_count I guess
<DocScrutinizer05> line 155 normalizes ot either 16bit sample size or for stereo file interleaved
gypsy has joined #neo900
<DocScrutinizer05> fread() reads one member of 4 bytes size
<DocScrutinizer05> ok, seems to fit for .raw of type S32
<DocScrutinizer05> err, does it
<DocScrutinizer05> ?
<DocScrutinizer05> you're reading filelen_in_bytes/2 samples of 4 bytes each, *two* time - once for left and ince for right
<DocScrutinizer05> SAMPLES = ftell(fp); SAMPLES /= 2; for (i = 0; i < SAMPLES; i++) { fread(&sample, 4, 1, fp); fread(&sample, 4, 1, fp); }
<DocScrutinizer05> seems to me you're trying to read 4 times as much bytes from file as there are
<DocScrutinizer05> freemangordon: ^^^
<DocScrutinizer05> I'm also still a bit puzzled about what and _how_ compare(&drcn, &drc); does
<DocScrutinizer05> I cannot find where it compares the complete buffer
<DocScrutinizer05> oops missed assert(!memcmp(dst, dstn, SAMPLES * 2)); #131
<DocScrutinizer05> maybe you want to write dst and dstn to two files after test run
<freemangordon> DocScrutinizer05: fread reads 4 bytes (a sample)
<freemangordon> so I read 2 sample per iteration
<freemangordon> *samples
<freemangordon> oh, wait
<freemangordon> samples count should be input file size / 8
<freemangordon> DocScrutinizer05: thanks for pointing that out
<DocScrutinizer05> yw
<Wizzup> freemangordon: well, 2 multiplied by sizeof sample :)
<freemangordon> yeah :)
<DocScrutinizer05> use more symbolic constants
<DocScrutinizer05> there should no hardcoded constants like "2" in assert(!memcmp(dst, dstn, SAMPLES * 2)) and SAMPLES /= 2;
<DocScrutinizer05> if you'd use CHANNELS here, you'd have noticed
<DocScrutinizer05> sizeof(stereosample)
<DocScrutinizer05> struct stereosample {monosample l; monosample r}
<DocScrutinizer05> BYTES_TOTAL = ftell(fp); MONOSAMPLES_TOTAL = BYTES_TOTAL / sizeof(MONOSAMPLE); STEREOSAMPLES_TOTAL = MONOSAMPLES_TOTAL / CHANNELS; for (i = 0; i < STEREOSAMPLES_TOTAL; i++) { fread(&sample, 4, 1, fp); fread(&sample, 4, 1, fp); }
<freemangordon> correct, I just don;t want to waste time on that
<DocScrutinizer05> oops
nox- has joined #neo900
<DocScrutinizer05> BYTES_TOTAL = ftell(fp); MONOSAMPLES_TOTAL = BYTES_TOTAL / sizeof(MONOSAMPLE); STEREOSAMPLES_TOTAL = MONOSAMPLES_TOTAL / CHANNELS; for (i = 0; i < STEREOSAMPLES_TOTAL; i++) { fread(&sample, sizeof(MONOSAMPLE), 1, fp); fread(&sample, sizeof(MONOSAMPLE), 1, fp); }
<DocScrutinizer05> it feels like "wasting time", but I came to appreciate it isn't, in the long run
<freemangordon> play with "aplay -c 2 -t raw -r 48000 -f S32_LE $FILE"
<freemangordon> sound perfectly fine to me
<freemangordon> testout is produced by replacement function, testaoutn by stock
<freemangordon> test is the input data
<DocScrutinizer05> I just got puzzled if 48k is actually correct ;-P
<freemangordon> i is
<freemangordon> *it is
Oxyd76 has quit [*.net *.split]
che1 has quit [Ping timeout: 245 seconds]
che1 has joined #neo900
_mAl0_c_ has joined #neo900
<freemangordon> hmm?
<DocScrutinizer05> hard to tell ... unless I maybe use headphones and mix test-l to left and testout-l to right chan
<freemangordon> what is what?
<DocScrutinizer05> it evidetnly does sth to signal, but what exactly
<freemangordon> lots of stuff
<freemangordon> :)
<DocScrutinizer05> yeah
<DocScrutinizer05> not sure if I would want that sort of stuff done for e.g. bootleg record of a concert ;-)
_mAl0_c_ has quit [Client Quit]
<freemangordon> DocScrutinizer05: keep in mind that parameters arew not fed, it uses defaults
<DocScrutinizer05> and *for sure* not for any analytical tool, even when it's just a dBa meter
<freemangordon> *are
<DocScrutinizer05> one man's earcandy is another man's noise
<DocScrutinizer05> ;-)
Oxyd76 has joined #neo900
<DocScrutinizer05> anyway great, seems to work, at very least sorts of
<freemangordon> yeah
<DocScrutinizer05> obviously even as good as original, right?
<freemangordon> a little bit slower(some 10%)
<DocScrutinizer05> meh
<freemangordon> but I'll fix that when it comes to it
<freemangordon> well, gcc 4.2.1
<DocScrutinizer05> we just would need dang nokia-voice now, the most important thing
<freemangordon> still doesn't work whe recording video
<DocScrutinizer05> :-/
<freemangordon> no, first we need -record working, then -music
<freemangordon> and the -voice :)
<DocScrutinizer05> kk
<freemangordon> *then
<freemangordon> ok, lets see what did jonwil with that PA stuff
svree4 has quit [Ping timeout: 240 seconds]
<freemangordon> I guess it gives mudrc-process only half of the samples :)
<DocScrutinizer05> hmm?
<freemangordon> recoreded video sounds like only parts of it are processed
<DocScrutinizer05> umm
<freemangordon> hmm, maybe you can help with your tool there
<DocScrutinizer05> so the rest unaltered?
<freemangordon> sounds like, do you want me to give it to you so you can feed the audio data to your analysis tool?
<DocScrutinizer05> sure, why not
<freemangordon> ok, just a second
<DocScrutinizer05> though I'm dang busy basically
<DocScrutinizer05> right atm
<DocScrutinizer05> just handwaving procratinating
<DocScrutinizer05> but toss it over, eventually I'll have a look at it dor sure
<DocScrutinizer05> jr@saturn:~/tmp> cmp testout.raw testoutn.raw; echo $?
<DocScrutinizer05> 0
<freemangordon> I already did that, with memcmp :P
<DocScrutinizer05> sure, just confirming
<DocScrutinizer05> would be silly if we found out they differ... in a 12 months
<freemangordon> :)
<freemangordon> yeah
<freemangordon> DocScrutinizer05: http://46.249.74.23/eap/20141102_008.mp4
<DocScrutinizer05> F U konqueror! I told U to NOT use kget anymore
<bencoh> (funny this browser is still around and alive :)
<DocScrutinizer05> that's actually one of the best things about it: virus hackers will think exactly same
<DocScrutinizer05> freemangordon: first cursory ear-torture makes me guess it's a non-linear filter parameter adjustment happening
<DocScrutinizer05> mudrc
<freemangordon> yep
<DocScrutinizer05> filtering out trebble for hush parts
<DocScrutinizer05> like one band not going active under a certain input level
svree4 has joined #neo900
<freemangordon> hmm, so you think there is something wrong with the parametars?
<freemangordon> *parameters
<DocScrutinizer05> or noise gate
<DocScrutinizer05> actave where it shouldn't
<DocScrutinizer05> pretty hard to tell from that test sound
<DocScrutinizer05> I'll give it closer analysis eventually
<freemangordon> ok
mvaenskae has quit [Quit: leaving]
mvaenskae has joined #neo900
<DocScrutinizer05> a min 5 min test of mixed stuff pure voice and some preferably non-too-electronic music would be appreciated
<DocScrutinizer05> first 5 min of a NCIS movie
<DocScrutinizer05> incl title "music"
<DocScrutinizer05> great test sound: http://www.youtube.com/watch?v=MFEIkjPEnh0
<freemangordon> ok, will do a video shortly
<DocScrutinizer05> completely useless testsound: http://www.youtube.com/watch?v=FsBls09adsY
<DocScrutinizer05> please use enough playback volume
<DocScrutinizer05> when doing that video
<DocScrutinizer05> ideally you do a "natural noise" for "calibration", like speaking a 2 words ar start
<DocScrutinizer05> and/or a whistle
<freemangordon> ok
xes has joined #neo900
xes has quit [Changing host]
xes has joined #neo900
<freemangordon> hmm, calling the original mudrc_process produces a video with correct audio
<DocScrutinizer05> hey, toldya
<DocScrutinizer05> sounds like a one-off or sth issue
norly has quit [Remote host closed the connection]
norly has joined #neo900
<DocScrutinizer05> btw where's mudrc_process() #174 _defined_?
<DocScrutinizer05> err ugh, are you sure the dlopen/dlsym does what we suspect it to do?
xes has quit [Remote host closed the connection]
<DocScrutinizer05> well, probably it should, but only when the according #include causes the foss.so to get loaded and linked first, aiui
<DocScrutinizer05> oh, dlsym() refers to "h"
<DocScrutinizer05> so for good measure I'd suggest to move lines 153 (void *h = dlopen(" ) to 156 (mudrc_process_f process =) after line171 (printf("foss\n");)
<DocScrutinizer05> will spoil your first _compare I guess
<DocScrutinizer05> so comment that out
<DocScrutinizer05> ... just to make sure what we actually see ;-D
<DocScrutinizer05> sorry, other way around
<DocScrutinizer05> dlopen() opens original nokia lib
<DocScrutinizer05> aiui
<DocScrutinizer05> so you should test that last, after using the foss.so already in tests
<DocScrutinizer05> IOW "mudrc_process(&drc, dst[0], dst[1], src[0], src[1], SAMPLES);" should get caled before "void *h = dlopen("/usr/lib/pulse-0.9.15/modules/module-nokia-record.so", RTLD_LAZY);" which needs to be done before mudrc_process_f process = (mudrc_process_f)dlsym(h,"mudrc_process"); process(&drcn, dstn[0], dstn[1], srcn[0], srcn[1], SAMPLES);
xes has joined #neo900
<DocScrutinizer05> again, just to be _sure_ what we see
<DocScrutinizer05> to rule out stuff works differently than we both think it should, with dlopen()
<DocScrutinizer05> aka LD_PRELOAD
<freemangordon> no, there is still some difference
arcean has quit [Read error: Connection reset by peer]
arcean has joined #neo900
<freemangordon> DocScrutinizer05: http://46.249.74.23/eap/20141102_013.mp4
<freemangordon> :)
<freemangordon> I guess this is perfect
jonwil has joined #neo900
<freemangordon> jonwil: hi!
<jonwil> hi
<freemangordon> :)
<DocScrutinizer05> your diff on crack, or what? ;-P
<jonwil> ok
<freemangordon> DocScrutinizer05: sorry, can't parse
<jonwil> so -record works 100% now?
<DocScrutinizer05> what's that patch foobar starting with 160 if (u->usedrc) {
<freemangordon> oh, for some reason when I paste in pidgin someone prepends what I want to paste with that shit
<DocScrutinizer05> nah, I faled to spot the differences. Seems to be indentation though
<freemangordon> yep, that is what the commit message says
<freemangordon> jonwil: yes
<jonwil> great, now on to -music
<jonwil> 2 functions to clone then testing :)
<freemangordon> yeah
<freemangordon> though... I wonder if it isn't better to make EAP as fast as stock first
<DocScrutinizer05> TABS in a c source? ohmy!
<freemangordon> well, jonwil use tabs, I use spaces. and as most of the code is with spaces I replaced the TABS :)(
<freemangordon> hmm, when it is compiled with gcc4.7.2, replacement takes exactly the same time (500ms) to process test.raw as stock
<freemangordon> so no need optimizations as of now, might convert some code to NEON some day
<freemangordon> jonwil: did you look at get_max_input_volume in harm -music module?
<jonwil> yes, I looked at the one in meego and harm and its too different
<jonwil> the stuff inside the #if 0 is the stuff from meego
<freemangordon> jonwil: could it be that gcc tried to optimize because of the recursion?
<jonwil> no idea, I suggest you just reverse engineer it
<jonwil> and ignore what meego/harm has
<freemangordon> h,, I'd rather use the stuff from harm and replace the missing pa_cvolume_merge
<freemangordon> s/h,,/hmm
<freemangordon> as it really looks like gcc optimized the first 4-5 recursion levels
Oksana has joined #neo900
<jonwil> Try seeing what the harm version looks like in IDA
<jonwil> There should be compiled binaries of the harm -music module in the harm SDK
<freemangordon> yep, I am looking at those
<freemangordon> what we have in fremantle looks like what is in harm, with the recursion unrolled
<jonwil> ok, go ahead and do whatever you think you think works
<freemangordon> heh
<freemangordon> ok :)
<freemangordon> jonwil: don;t you agree with what I said?
<jonwil> I haven't compared the functions so I cant comment
<freemangordon> ok
<Oksana> Good morning!
NIN101 has quit [Remote host closed the connection]
NIN101 has joined #neo900
<Oksana> Lightspreader-dots is a beauty. I hope Nokia hasn't patented anything about placement-size of dots? http://neo900.org/stuff/joerg/random-media/domesheet/lightspreader-dots1.JPG
<Oksana> Gap between upper and lower : is it something that N900 did not have, and Neo900 will have?
<Oksana> The one in which the stylus sensor is going to be placed? http://wstaw.org/m/2014/09/22/plasma-desktopbb1979.png
<bencoh> (is neo900.org behind a dsl ?)
<Oksana> Did you have a look at shape of domes? They are not round, no. Something like Snaptron's RK-series, I think. Though you have to do more research about shape, size and :o: in center of dome. http://maemo.cloud-7.de/Gallery-N900-exploded/platine_01.jpeg http://maemo.cloud-7.de/Gallery-N900-exploded/domesheet_bottom.jpg
<jonwil> So do we finally know all the information we need to have compatible domesheets made?
<Oksana> Snaptron asks for a PDF 'picture' of custom dome array to be made, I think.
<Oksana> DocScrutinizer05very nice company. I need to prepare a pdf (et al) drawing of domesheet for them to give quotation; my highres scans are not compatible with their process; I ponder to create a pcb pdf printout; from eagle
<Oksana> WikiwideFrom eagle... That would be nice for curious public :)
<Oksana> DocScrutinizer05http://maemo.cloud-7.de/Gallery-N900-exploded/domesheet_bottom.jpg is what they don't like
<Oksana> WikiwideThis jpg takes too long to load.
<Oksana> DocScrutinizer05ponders to use gimp to create svg or whatever outline "drawing" from http://maemo.cloud-7.de/Gallery-N900-exploded/domesheet_bottom.jpg and particularly http://maemo.cloud-7.de/Gallery-N900-exploded/platine_01.jpeg
<Oksana> DocScrutinizer05finally starts slaughtering a domesheet, to rip off all the gory last details of internal structure
<Oksana> bencohoO, a working domesheet ?
<Oksana> DocScrutinizer05W*T*F?! the white dots (lightspreader escape points) are on a separate foil glued to the "thick" lightspreader layer; the foil thickness is... incredibly thin; actually I cannot say if it's a foil, a printed varnish, or just parts of the lightspreader surface specially polished so it looks different; I cannot detect any thickness at all; thickness of the *complete* domesheet...
<Oksana> ...plastic (sans domes and protective pink/blue foil) is 0.37mm; the lightspread "thick" transparent foil seems 1/3 of that; the thin foil with dots on it - if it's really a foil - is <1/20 of the spreader foil thickness; gosh, where's my micrometer screw ruler? caliper fails for that stuff; http://neo900.org/stuff/joerg/random-media/domesheet/
<Oksana> drathirDocScrutinizer05: thanks i check that...
<Oksana> DocScrutinizer05((<bencoh> a working domesheet ?)) yes indeed
<Oksana> DocScrutinizer05F5 http://neo900.org/stuff/joerg/random-media/domesheet/ ETA 3:45
<bencoh> wtf ?
<Oksana> Sorry, just backlog about Snaptron. Or is there a way to give a link to specific lines in history?
<Oksana> Thanks a lot! What does <PROTECTED> mean in rikers-log, by the way? I wonder about this line: http://irclog.whitequark.org/neo900/2014-11-01#10693632
<Oksana> The o is called dimple, I think. Where can this be found, though? : :
<Oksana> No, o is 'reverse dimple'. What is double/triple dimple of Snaptron? What is : : of N900's domes? Size of dome should be 3.8x2.8x0.15 mm (source: http://www.electronicproducts.com/Nokia_N900_Mobile_Phone-whatsinside_text-90.aspx ) Number of domes: 3x13=39.
<kerio> what the fuck is going on
<Oksana> Sorry for 12 lines. I will use links to history in the future, instead of just pasting a copy of this history.
<Oksana> Do I understand it right? N900's domes were vented through polyester material of dome sheet array (in groups of 3)? http://maemo.cloud-7.de/Gallery-N900-exploded/domesheet_bottom.jpg http://www.snaptron.com/products/pcb-pads/plating-venting/
<DocScrutinizer51> yes, obviously.and ple*se try quoting a bit less
<Oksana> Yes, thank you :-) The second log-site has bookmarks for linking, and even search...
<freemangordon> jonwil: I *think* we have -music volume as well :)
<bencoh> woot
<bencoh> now to -voice ? :)
<freemangordon> not now, please :)
<bencoh> :-))
<bencoh> that's pretty awesome work btw
<mvaenskae> DocScrutinizer51: may i ask when confirmations on received donations will be sent out? :)
<mvaenskae> has been a while i feel :)
<freemangordon> jusa_: I am not sure we do the right thing here, could you please check
<freemangordon> s/here/there
<jonwil> so -music is complete now?
<freemangordon> looks like
<jonwil> but does it work? :)
<freemangordon> yes, I am listening to music right now
<freemangordon> :)
<jonwil> ok, great, so we have -music and -record done
<jonwil> I doubt -voice is going to be anywhere near this easy
<freemangordon> yeah
<freemangordon> BTW do you know how to tell (in Makefile.am) arbitrary files to be installed?
<jonwil> no idea
norly has quit [Quit: Leaving.]
<kolp> freemangordon: EXTRA_DIST =
<kolp> I think
<freemangordon> thanks, will try it
<kolp> oh, installed...
<kolp> that just includes in tarball, I think
<jonwil> I see now, that loop I see in get_max_input_volume is an inlined copy of pa_cvolume_merge
<freemangordon> ;)
<jonwil> you should compare the stock binary to our binary for that function and see if it looks like a match
<jonwil> not sure how useful it would be but it might be worth a look
<jonwil> :P
<freemangordon> I doubt it will look the same as pa_cvolume_merge does more things than what is done in fremantle
<freemangordon> asserts, etc
<jonwil> yeah true
<jonwil> fremantle has obviously been compiled with assets off
<jonwil> asserts
<freemangordon> or rather there were no asserts at all
<freemangordon> keep in mind I get the code from upsteram PA
<freemangordon> of pa_cvolume_merge that is
<jonwil> hmmm yeah good point
<bencoh> hmmm, EXTRA_DIST should just ship files when using make distcheck (or make dist)
<freemangordon> I found the way to install them
<bencoh> ^U kewl then :)
mvaenskae has quit [Quit: leaving]