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>
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>
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
<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>
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]
<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>
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