--- Log for 07.05.112 Server: wolfe.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 day and 19 hours ago 00.01.09 Quit Rower85 (Quit: Hmmm...) 00.02.10 # saratoga: it must handle any arbitrary amount though it can output none if it doesn't yet have enough data 00.02.21 # thanks 00.10.35 # resample_data.frequency isn't used by asm (mistakenly implied that it is), it's ok to just increase last_sample if a longer history is required 00.14.56 # whatcha working on=? 00.17.33 # saratoga's cubic splinging the resampler 00.17.53 # derp splinging, splining 00.18.34 # what kind of cubic spline? hermite? 00.18.39 # yes 00.18.48 # yeah, should be ok 00.20.48 # Commit 6fd4780 in rockbox by 03Michael Sevakis: Correct comments in lin_resample re: what is actually used by asm. 00.22.15 *** Saving seen data "./dancer.seen" 00.23.57 # preglow: http://src.gnu-darwin.org/ports/multimedia/helixplayer/work/hxplay-1.0.7/audio/resampler/hermite.c 00.26.31 # 6fd4780 build result: All green 00.26.41 # http://musicdsp.org/showone.php?id=93 00.26.55 # some of those forms are also worth checking out, especially for fixed point 00.26.58 Part domonoky 00.27.10 # the last one especially 00.27.36 # i think thats the form i'm using 00.27.38 # actually think i've got code for that lying some place 00.27.53 # 3 muls and some shifts in place of divides 00.28.05 # yeah, http://www.pvv.org/~thomj/rockbox/flanger.c 00.28.29 # huh maybe it isn't 00.34.54 # heh, this hermite code counts samples by rounding the phase, while the rockbox code truncates it 00.34.54 Quit maffe (Quit: IRC ist obsolet!) 00.35.14 # probably going to be a hilarious off by 1 error in there somewhere 00.35.26 # you tend to hear those really easily 00.36.35 # yeah 00.36.43 # just trying to get it to run without a segfault now 00.36.50 # sine + pitchscreen works nicely 00.36.50 # been too long since i looked at c 00.36.50 # funman: pong :) 00.36.57 # wait till tuesday night... tommorrow night 00.37.03 # but yeah, rounding doesn't sound right in that case 00.37.03 # i keep trying to do matlab assignments :) 00.37.17 # *shiver* 00.37.53 # u no lik matlab? 00.37.54 # lists without commas gets addictive 00.37.55 Quit c3sso (Ping timeout: 250 seconds) 00.38.05 # matlab is an abomination 00.38.21 # i should like matlab 00.38.25 # but i just can't 00.42.04 # /* Wrap phase accumulator back to start of next frame. */ data->phase = phase - (pos << 16); 00.42.13 # what is this for? 00.45.18 Join kevku [0] (x@Gizka-1-pt.tunnel.tserv24.sto1.ipv6.he.net) 00.50.39 # sec 00.52.25 # it just preserves the fractional part of the phase accumulator 00.52.31 # not quite 00.52.52 # depends 00.53.08 # depends on the delta 00.53.12 # it could be more than a fraction 00.53.17 # but not by much :> 00.54.08 # if you're past the end of a frame, it positions where it thinks it will be within the next buffer, and it keeps doing that until it's within some buffer, which could in theory be several skips 00.54.52 # yeah, that's more accurate 00.55.23 # if you processed a linear block of samples, that line wouldn't be necessary, it's basically just compensating for the block based processing 00.55.43 # ugh 00.55.45 # sweet god, i can't believe we're still using this piece of shit resampler :> 00.55.59 # it's fast? 00.56.02 # sort of? 00.56.21 # so what i have no is a resampler that has an unsigned int fractional part that wraps around as it accumulates 00.56.22 # well, as fast as you can get and still call it resampling with a close semblance of a straight face 00.56.34 # lol 00.56.35 # and a signed int integer part that is incremented when the fractional part wraps around 00.56.53 # * jhMikeS admits his face was a bit crooked, maybe not quite enough :) 00.57.05 # should i just subtract the number of output samples from the interger part and hope for the best? 00.57.28 # hope and pray 00.57.41 Quit ender` (Quit: The sardines were packed as tight as the coach section of a 747.) 00.57.52 # no way to just combine int+frac ? 00.58.22 # i could, but i'm not sure that makes sense 00.58.31 # it'd be less accurate, and i need the fractional part anyway 00.58.34 # so it saves shifts 00.59.08 # the asm stuff decomposes it once per call and recombines it 00.59.27 # you think its worth the accuracy hit? 00.59.30 # i agree its an easier solution 00.59.54 # is it subject to amplify the inaccuracy in some way? 01.00.36 # do we have any guarantees on block size? 01.00.38 # the target sampling rate will be off by 1 sample every second or so 01.00.54 # preglow: nope, I made it all so it's completely arbitrary 01.00.56 # i guess thats a pretty minor pitch error 01.01.09 # I don't think that hardware is that accurate 01.01.21 # yeah i suppose not 01.01.27 # alright, time to rewrite this mess again 01.01.30 # the pitch error doesn't matter, what matters is if the resampler produces more/less samples than it should 01.01.36 # or goes through its input slower/faster 01.01.48 # but i guess that doesn't matter if the input isn't live 01.02.13 # I've tested the same sincewav file player against play and it beats every few seconds, varying with device 01.02.22 # s/since/sine 01.02.31 # the real sample rate is usually pretty far off in most dap hardware anyway 01.03.26 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 01.04.09 # I think the AMS players were the worst ones 01.04.12 # yeah people have done measurements of some of our players 01.04.16 # no the AMS ones are fixed now 01.04.54 # by a few HZ at most? 01.05.10 # ROCKBOX PITCH FIX: The good folks who maintain Rockbox apparently knew about the above error, and interestingly, fixed it in their firmware. Here's the same Clip+ playing the same file but running Rockbox and the error is now near zero (0.04%): 01.05.47 # still 17 samples per second, so i guess whatever 01.05.49 # i've seen things be off by hundreds of hz 01.05.58 # imperceptible even then 01.05.59 # 18Hz is pretty nasty. the gigabeats and coldfires are better 01.07.26 # the sandisk firmware is off by a lot more 01.07.31 # of course I think they're optimized for 48 01.07.37 # +K 01.07.40 Quit factor (Read error: Connection reset by peer) 01.07.46 # most things are optimized for either of 48 or 44.1 01.08.14 # the beast has a nice pll on the codec so it's always pretty damn good :) 01.08.14 # i think the problem was that they used one PLL for the pclk and the DAC, which meant that they couldn't hit all sampling rates exactly 01.08.27 # which was dumb since the ams chips have two plls 01.08.55 # some of the enabled samplerates in the AMS are so far off you can hear it with direct comparison 01.09.10 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 01.10.10 # frac = f >> 1; 01.10.16 # so if f is 0.32 unsigned 01.10.49 # and our phase is s15.16 01.11.22 # or, optimistically, the frac is 0.16 unsigned :) 01.11.32 # i guess I want to do (0x0000FFFF&phase) << 15? 01.13.00 # I guess, but in assembly I'll try to pull funny tricks like is already done 01.13.17 # *if I do that bit 01.14.12 Quit kadoban_ (Ping timeout: 272 seconds) 01.18.22 # I guess asm isn't required to keep its data the same precise format as the C code 01.30.43 # heh, so right now i just get static 01.32.30 # ah now it works 01.32.37 # apparently the original code assumed 16 bit input 01.32.50 Join Thra11_ [0] (~thrall@31.185.180.140) 01.32.53 # all great things start with static, even the universe :) 01.33.45 # ha 01.33.52 # actually theres some static sound still, so something is wrong 01.34.17 # i wonder if i'm just clipping 01.36.16 # jhMikeS: how are the input samples to the resampler scaled? 01.36.20 Quit Thra11 (Ping timeout: 276 seconds) 01.37.00 # saratoga: they won't be if the codec outputs > 16 bits 01.37.37 # i have a volume dependent crackle which i'm assuming is overflow, but i'm not srue why 01.40.17 # maybe it's just not audible until the signal is loud enough? 01.41.09 Join Keripo [0] (~Keripo@165.123.49.209) 01.41.54 # i assume i've made a mistake somewhere in the scaling 01.45.18 # its not clipping, its the way the history samples are being computed 01.45.29 # its volume dependent since you only notice when they're wrong if they're also loud :) 01.45.52 # jhMikeS: did you write the logic for the linear resampler, or at least understand it? 02.00.00 # how it is now in many ways, yes, so that it would transition up/down cleanly and handle 0 consumed/produced properly. I didn't do the original, which was rather buggy. 02.01.10 # i need to work on something, else so i'm going to push it to gerrit for now 02.01.17 # feel like skimming it to see if i've made some dumb mistake? 02.01.26 # sure 02.01.47 # is this planned to replace the linear one? 02.02.22 # for now it replaces it, i don't know that we have to do that though 02.02.32 # and crap pushed to gerrit with the meier patch applied 02.02.45 # that is something the commit -v could have mentioned ... 02.02.51 # of course, codecs that really need speed could just handle it themselves 02.03.08 # http://gerrit.rockbox.org/r/#/c/231/ 02.11.26 Quit prof_wolfff (Ping timeout: 276 seconds) 02.13.55 Quit bitcraft (Remote host closed the connection) 02.16.05 Join bitcraft_ [0] (~bitcraft@173-20-20-92.client.mchsi.com) 02.22.19 *** Saving seen data "./dancer.seen" 02.23.07 # I can see that if count < 3 then it'll be looking ahead into nowhere 02.23.39 # or did I misread, hmm 02.24.40 Quit pamaury (Read error: Connection reset by peer) 02.31.56 # hmmm... last_samples aren't being read at the begginning using channel info 02.40.58 Quit bitcraft_ (Remote host closed the connection) 03.03.22 Quit KiwiCam (Quit: Leaving) 03.08.31 # jhMikeS: thanks, that seems to fix it 03.10.15 # pushed the fixed version to gerrit 03.10.19 # will play around with this more in the morning 03.20.34 # well just quickly trying a 96k sampling rate file with two strong ultrasound tones, both Hermite and linear are horrible, but hermite sounds a lot less bad 03.23.51 Quit saratoga (Quit: Page closed) 03.51.56 Join bitcraft [0] (~bitcraft@50.44.14.169) 04.13.33 Quit perrikwp (Read error: Connection reset by peer) 04.17.51 Quit bitcraft (Remote host closed the connection) 04.22.20 *** Saving seen data "./dancer.seen" 04.32.31 Join FrenchVerbs [0] (~chatzilla@c-71-193-88-22.hsd1.mn.comcast.net) 04.33.08 # Hey guys, I am on a somewhat old build of rockbox and when I plug in my ipod classic, it refuses to show up as a disk drive. How can I go about fixing this? 04.34.24 # Also congrats on a decade! 04.35.07 Quit TheSphinX_ (Ping timeout: 244 seconds) 04.37.08 # It does show up in device manager though. 04.37.35 # Anyone there? 04.39.01 # yes, just noone has seen what you said who has an answer for you 04.39.19 # (yet) 04.40.05 Join TheSphinX^ [0] (~briehl@p5B323F30.dip.t-dialin.net) 04.41.47 # Wait, it just showed up. I'm going to take this oppurtunity to update my version of rockbox. 04.43.08 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 04.43.15 Quit [7] (Disconnected by services) 04.44.08 # Commit 675f171 in rockbox by 03Rafaël Carré: skin_parser: simplify skin_buffer_alloc 04.46.57 # Where can I see a changelog for the nightly builds btw? 04.49.16 # www.rockbox.org 04.49.40 # there are no nightly builds though, builds are made each time the source is changed 04.52.32 # http://download.rockbox.org/daily/ipodclassic/ 04.52.47 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 04.52.48 # isn't that a nightly (daily) build, funman? 04.53.05 # hmm yes 04.53.15 # i thought we only copied some current builds 04.53.30 # What do you mean? 04.53.45 # see "code changes" on the web site 04.54.04 # Okay, thanks 04.55.28 Quit pixelma (Disconnected by services) 04.55.28 Quit amiconn (Disconnected by services) 04.55.30 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.55.30 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.55.32 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.55.35 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.59.45 Quit FrenchVerbs (Quit: ChatZilla 0.9.88.2 [Firefox 15.0a1/20120506030520]) 05.01.09 # Commit aaf9a1b in rockbox by 03Rafaël Carré: get_image_filename() return value is never used 05.14.13 # Commit 65bb8e4 in rockbox by 03Rafaël Carré: Remove extraneous parens 05.17.07 Quit [Saint] (Read error: Connection reset by peer) 05.19.07 Quit factor (Read error: Connection reset by peer) 05.26.33 Quit enthdegree (Ping timeout: 260 seconds) 05.29.25 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 05.29.49 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 05.32.28 Join enthdegree [0] (~enthdegre@wikimedia/enthdegree) 05.35.03 Join bitcraft [0] (~bitcraft@50.44.14.169) 05.35.46 Quit bitcraft (Remote host closed the connection) 05.38.59 Join bitcraft [0] (~bitcraft@50.44.14.169) 05.43.24 # Commit 06c8ab8 in rockbox by 03Rafaël Carré: Don't use function in a function 05.43.24 # Commit 5aadf87 in rockbox by 03Rafaël Carré: asap codec: remove invalid memset 05.43.25 # Commit dfeab52 in rockbox by 03Rafaël Carré: remove extraneous parens 05.43.26 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 05.45.11 Quit bitcraft (Remote host closed the connection) 05.48.43 # Commit 2eccc02 in rockbox by 03Rafaël Carré: sansa AMS: i2s_reset() is never used 05.51.08 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 05.53.58 # * [Saint] wonders if funman has any insight into the recent(-ish) skin engine weirdness. 05.57.08 Quit [Saint] (Quit: Quit) 05.57.29 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 05.57.44 # http://people.videolan.org/~funman/rockbox/ (clip zip) 05.57.56 # [Saint]: no i am still waiting for jd help 05.58.16 # i dont really understand hwo buflib/skin buffer work 05.58.55 # <[Saint]> funman: right, I was just curious. The skin engine was a minefield even before burflib ;) 05.59.23 # <[Saint]> I have a feeling, and have had for a while, that bufflib is rather broken. 06.00.11 # the bug i pointed out is clearly specific to skin and not caused by buflib 06.02.48 # Commit cf09020 in rockbox by 03Rafaël Carré: Sansa AMS: more compat irq names 06.09.34 # AlexP: ping 06.09.40 # AlexP: http://build.rockbox.org/shownewlog.cgi?rev=cf09020;type=sansac200v2boot 06.09.43 Quit enthdegree (Quit: HydraIRC -> http://www.hydrairc.com <- Organize your IRC) 06.12.15 # AlexP: seems to be python3 06.14.10 # * [Saint] recalls that coming up some time ago. 06.16.17 # <[Saint]> Its barring for distros that aren't symlinking so python "just works" when python2 is expected, iirc. 06.16.26 # <[Saint]> *barfing 06.19.35 # Commit bed634d in rockbox by 03Rafaël Carré: thumb-cc.py: fix for python 3.2 06.20.24 # the problem is that it is symlinked 06.21.42 Quit Topy44 (Ping timeout: 276 seconds) 06.22.21 *** Saving seen data "./dancer.seen" 06.23.15 # <[Saint]> Anyone know who owns/runs/manages/whatever the Rockbox commit log Twitter account? 06.23.55 # <[Saint]> It occurs to me that it would be a whole lot more useful if it actually gave a link to the commit. 06.24.26 # <[Saint]> As it is, it simply states "this happened" which is useful, but could be more so. 06.31.03 # that would be zagor 06.33.22 # it would be http://git.rockbox.org/?p=rockbox.git;a=commit;h=XXXX (XXX = short id) 06.36.37 Quit Thra11_ (Ping timeout: 240 seconds) 06.36.50 Quit anewuser () 06.51.24 # Commit ed38c5d in rockbox by 03Rafaël Carré: remove unused prototypes 06.56.14 # Commit 7ca2081 in rockbox by 03Rafaël Carré: remove debug-target.h 07.02.50 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 07.06.11 Quit [Saint] (Ping timeout: 250 seconds) 07.10.28 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 07.14.40 Join stoffel [0] (~quassel@pD9E42742.dip.t-dialin.net) 07.19.57 # Commit 803408f in rockbox by 03Rafaël Carré: simplify copy_padded 07.29.24 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 07.30.56 # Commit dd57c01 in rockbox by 03Rafaël Carré: simplify yearday_to_daymonth() 07.32.20 Quit [Saint_] (Ping timeout: 244 seconds) 07.33.52 Join HaloNachos117 [0] (~181eb2a3@www.haxx.se) 07.36.06 # Commit c4a51d2 in rockbox by 03Rafaël Carré: missing const 07.37.29 # Hi, I just wanted to celebrate the return/resurrection of a great old player. My old Sansa Fuze v2 has a cracked screen, so I've not been able to use it for a long time. However, with Rockbox, I'm now able to use the voice feature. Thanks a lot to the dev's out there for making something so awesome! 07.37.55 Quit HaloNachos117 (Client Quit) 07.39.54 Join HaloNachos117 [0] (~181eb2a3@www.haxx.se) 07.40.22 # Hi, I just wanted to celebrate the return/resurrection of a great old player. My old Sansa Fuze v2 has a cracked screen, so I've not been able to use it for a long time. However, with Rockbox, I'm now able to use the voice feature. Thanks a lot to the dev's out there for making something so awesome! Why didn't I think of doing this sooner? 07.40.28 Quit HaloNachos117 (Client Quit) 07.45.57 # <[Saint]> Gotta love those... 07.46.20 # % git grep ifdef|wc -l 07.46.20 # 8781 07.46.41 # <[Saint]> "Hi, just wanted to say you're awesome and I appreciate it, no complaints...bye!" 07.46.51 # <[Saint]> that's my type of user... 07.47.44 # <[Saint]> funman: Ô_o 07.49.08 # funman: perhaps related to FS#12657, some stkov corrupting skin memory? 07.49.08 # http://www.rockbox.org/tracker/task/12657 3ThinBasic causes panic on Nano 1g (bugs, unconfirmed) 07.49.46 # kugel: cant tell without jd opinion 07.50.26 # the skin engine seems to have a stack heavy function somewhere, or perhaps it recurses too deep 07.50.36 # it is not a stkov in this case 07.51.35 # something allocates from skin_buffer, then modifies skin_buffer pointer then reads from allocated memory 07.51.43 # and it is dead wrong 07.53.10 # kugel: core_alloc.c has no license ? 07.54.00 # it should 07.54.16 # i probably have forgotten to add the header 08.03.51 Quit bluebrother (Ping timeout: 244 seconds) 08.04.24 Quit fs-bluebot (Ping timeout: 276 seconds) 08.04.40 Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) 08.05.49 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 08.06.07 Quit remlap (Ping timeout: 240 seconds) 08.06.44 Join fs-bluebot [0] (~fs-bluebo@f053153074.adsl.alicedsl.de) 08.18.47 Nick JdGordon is now known as MrsJD (~jonno@rockbox/developer/JdGordon) 08.19.42 Join jdgord [0] (~jdgord@rockbox/developer/JdGordon) 08.21.12 Join ender` [0] (krneki@foo.eternallybored.org) 08.21.29 Nick MrsJD is now known as JdGordon (~jonno@rockbox/developer/JdGordon) 08.22.23 *** Saving seen data "./dancer.seen" 08.25.38 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.31.33 # funman: what have you done!!!! :) 08.31.37 Join c3sso [0] (~tux@89.106.213.194) 08.43.42 Quit jdgord (Read error: Connection reset by peer) 08.45.47 # <[Saint]> JdGordon: did your work with skin code formatting (line breaks/indentation) actually go in, and is it explained anywhere what's accepted if so? 08.46.29 # i think so 08.46.32 # <[Saint]> I hate it...but for the general public to jot go insane immediately, I'm going to have to work on the readability of these conditions of mine. 08.46.43 # <[Saint]> *to not 08.49.17 # <[Saint]> When even I find it hard (actually close to impossible) to parse what I'm writing, I /probably/ shouldn't expect anyone else's experience to be any different, I guess. 08.49.55 # <[Saint]> And I would like for people to he able to learn from the code, not be baffled by it. If at all possible. 08.53.29 # <[Saint]> I remember the old "happy accident" way of splitting long lines with a #, but I don't know what the rules are now indentation and line breaking is actually a thing. 08.58.02 # JdGordon: ? 09.39.14 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 09.39.14 Quit n1s (Changing host) 09.39.14 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.49.02 # 03:20 < saratoga> well just quickly trying a 96k sampling rate file with two strong ultrasound tones, both Hermite and linear are horrible, but hermite sounds a lot less bad 09.49.21 # saratoga: that sounds about as i'd expect it to be, so seems you've succeeded 09.49.51 # you won't get much better than that with a pure interpolative approach 09.52.02 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.52.02 Quit bertrik (Changing host) 09.52.02 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.56.26 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.04.22 Quit tchan (Ping timeout: 246 seconds) 10.15.07 Join bitcraft [0] (~bitcraft@50-103-46-79.dklb.il.frontiernet.net) 10.18.05 # Commit 51a73d8 in rockbox by 03Michael Sevakis: Stop clickiness on manual track changes as best as possible. 10.18.56 Quit bitcraft (Remote host closed the connection) 10.21.44 # 51a73d8 build result: All green 10.22.27 *** Saving seen data "./dancer.seen" 10.22.51 # funman: isn't the if condition in commit 803408f inverted, should be if (src[i] == 0) or if (!src[i]) afaict 10.24.40 # why not even make it a memcpy();memset(); combo? 10.25.20 # ah, nevermind 10.25.37 # strcpy();memset(); would work 10.26.12 # strlcpy* 10.26.44 # yeah 10.29.09 # Commit 3f61caa in rockbox by 03Nils Wallménius: rbcodec: abstract tdspeed buffer allocation 10.29.26 Join Syconaut^ [0] (viper@c-4dfd72d5.162-1-64736c10.cust.bredbandsbolaget.se) 10.35.58 Quit c3sso (Ping timeout: 245 seconds) 10.36.37 # hm, how can I make sure a semaphore isn't released before the semaphore_wait() call? 10.37.34 Quit mc2739 (Ping timeout: 260 seconds) 10.39.13 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.39.53 # kugel: ?? 10.40.50 # hm, iiuc our semaphores can be signalled before the wait() call in which case wait() returns immediately no? 10.42.53 # yes 10.43.17 # that's what's supposed to happen 10.43.27 # then the deadlock is somewhere else. however it works with a few printf()s in the code 10.44.19 # deadlock? 10.45.27 # http://pastie.org/3872330 10.47.45 # * jhMikeS tried an I/O thread some time ago 10.48.57 # are you actually disabling "interrupts"? 10.50.28 # kugel: I remember you left that bit out. You'll probably corrupt stuff if signaling from amother thread and not going through the right bits 10.51.07 # where should I disable interrupts? 10.51.36 # stupid sdl thread create/exit debug 10.51.50 # makes it slow 10.51.55 # I suppose semaphore_release will if the functions are implemented 10.52.41 # for the whole gimmick to work it needed sim_enter_int_handler (or whatever that was called) 10.53.25 # seems to work with that indeed 10.56.49 # it should work without too IIUC though 10.58.02 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 10.58.13 # no, it won't, I think it'll deadlock :) 10.58.17 Quit pamaury (Changing host) 10.58.17 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.58.24 Join jdgord [0] (~jdgord@rockbox/developer/JdGordon) 10.58.42 # if the sem can be signalled before wait()? 11.00.58 # the internal mutex in there will left unlocked, not protecting the scheduler lists 11.05.28 Quit jdgord (Read error: Connection reset by peer) 11.06.01 # how? 11.06.58 Join LinusN [0] (~linus@giant.haxx.se) 11.06.59 # set_irq_level just locks then unlocks the internal mutex 11.07.45 # the calls in the kernel then leave the lists unprotected from preemtive manipulation 11.07.51 # if I don't call the sim_(enter|exit)_irq_handler pair it's not locked in the first place 11.08.16 # because? 11.08.36 Join jdgord [0] (~jdgord@rockbox/developer/JdGordon) 11.09.18 # which mutex exactly? the irq sim_irq_mtx is locked in sim_enter 11.09.32 # yes 11.09.48 # set_irq_level does it too but doesn't keep it locked 11.10.12 # which set_irq_level call? 11.10.22 # in kernel-sdl.c 11.10.47 # who calls it? 11.11.28 # the sem functions, the queue functions, the scheduler, 11.12.50 # things that act like interrupts must call sim_enter/exit_irq_handler before interacting with the kernel 11.13.05 # okay 11.13.30 # * kugel stops trying to understand why the kernel goes insane without 11.13.45 # linked lists and other data structs 11.14.23 # using it for disk IO would increase the chances of breakdown 11.15.01 # stderr redirect in gdb doesnt appear to work 11.15.04 # you might even miss waking up the thread approaching the block 11.15.54 # it would be blocking but not yet visible to whoever is waking it because not everything is updated 11.18.07 Quit jdgord (Read error: Connection reset by peer) 11.21.48 # jhMikeS: there's one place left in rbcodec accessing global_settings, the dsp_callback function (dsp_misc.c). wtachi's patch moves it out to the rb specific helper file, i think it makes sense since it's rather specific to our acritecture. but i see you have added a FIXME comment to it to move the sw volume stuff, comments? 11.23.11 # the patch is in g#145 but requires some syncing 11.23.13 # 3Gerrit review #145 at http://gerrit.rockbox.org/r/#change,145 : rbcodec refactoring: dsp_callback by Sean Bartell (changes/45/145/2) 11.24.36 # n1s: yeah, it should be in the pcm driver so it adjusts everything! :) 11.25.39 # otherwise it has to be painstakenly written into everything using pcm directly and to every pcm channel 11.26.19 # so it shouldn't actually be in dsp at all 11.27.38 # I think not. Besides it would have alot of latency there. 11.28.43 # it sounds rather easy to do, what's the catch? ;) 11.30.00 # double buffer in the affected drivers (which is what, just a MIPS target or two?) 11.30.16 # yeah seems only the onda targets use this 11.30.34 # HAVE_SW_VOLUME_CONTROL would be a pointless define too 11.30.44 # nothing should have to know 11.31.29 # so faking volume control in the target driver 11.31.51 # yeah 11.32.14 # i can try to whip something up but i don't have one of the affected targets 11.32.45 # I wouldn't mind one, if nothing else than to just learn MIPS assembly effectively 11.33.51 # has anyone done anything with them in recent history? 11.34.12 # seems like it just got dumped 11.34.21 # not anything i remember 11.34.24 # funman: Right, forgot about that 11.34.37 # I've killed that client for the minute 11.34.54 # the only more neglected target I can think of is the i.FP 11.35.42 # actually, not really. seems most of them just age :) 11.35.55 # like milk, not wine :p 11.37.50 # these ports build at least :) 11.38.16 Quit kevku (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) 11.38.25 # funman: Oh, I see you fixed it :) 11.39.21 # i'm not sure if a blind patch would help either especially since i'm confused by thsi dma stuff... 11.42.01 # seems pretty much only mcuelenaere was active on that port 11.42.41 # keeping those ports running is like changing the oil on an engine with a missing cylinder head 11.42.48 # s/running/building 11.44.21 Quit funman (Read error: Operation timed out) 11.45.49 # jhMikeS: yeah, last commit by him touching that port was in jan last year :/ 11.46.55 # I wonder if anyone but me noticed the recording screen going haywire on gigabeat S :\ 11.47.32 # * jhMikeS awaits it to be magically fixed 11.48.19 Join funman [0] (~fun@rockbox/developer/funman) 11.50.59 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 11.58.57 # jhMikeS: the pcm-alsa backend needs it too (not on ypr0 though because we can access the codec there) 12.00.18 Quit remlap1 (Quit: Leaving.) 12.01.14 # can I turn the sdl debug messages off? it makes my work unbearably slow 12.02.44 Quit funman (Ping timeout: 260 seconds) 12.03.29 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 12.03.38 # which ones? 12.04.13 Join funman [0] (~fun@rockbox/developer/funman) 12.05.28 # huh. they're gone now 12.05.43 # viola! 12.05.49 # wth 12.06.28 Quit factor (Ping timeout: 252 seconds) 12.06.35 # ahh 12.06.39 # they only appear within gdb 12.06.57 # so it's not about sdl actually 12.07.09 # so assumin it's not ok to kill sw volume and not acceptable to push untested patches to the onda port and pretend they take care of it, how should the sw volume stuff be handled? 12.07.39 # the listener can imagine it's quieter? 12.07.56 # can't the pcm mixer apply the volume? 12.07.58 # For sim it's in the pcm driver 12.08.00 # ah yes, or hold the headphone further away 12.08.01 # it can 12.08.22 # no positive gain though, just 0 or less 12.08.35 # that should be fine 12.08.38 # decibally speaking 12.14.23 # go for it then :) 12.17.24 # that's mixer abuse 12.17.50 Quit funman (Ping timeout: 252 seconds) 12.18.13 # really? 12.19.07 Join funman [0] (~fun@rockbox/developer/funman) 12.19.12 # it's common that the mixer module handles global volume as well isnt it? 12.21.22 # it may be, so long as the mixer is used. several things don't use it though 12.22.29 *** Saving seen data "./dancer.seen" 12.23.16 # right. but i don't see how it's mixer abuse 12.23.29 # maybe it could be implemented in pcm.c instead to catch it all, but the sim does it in its pcm driver 12.23.42 # more stuff goes through the mixer than through dsp so it's an improvement :) 12.27.36 # spawning mass threads doesnt work well in gdb 12.28.17 # man, i don't really want a single i/o thread which is a waste of resources 99% of the time (even if it idles) 12.28.33 Quit funman (Ping timeout: 250 seconds) 12.30.10 Join funman [0] (~fun@rockbox/developer/funman) 12.31.56 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 12.32.16 # use an existing thread like the input one? 12.39.09 # trying that right now 12.43.12 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 12.47.59 # horribly slow via SDL_PushEvent 12.58.00 # event queue processing is slow 12.58.47 # SDL_PushEvent + 1-thread-per-transfer is almost as slow as SDL_PushEvent only (while 1-thread-per-transfer was blazing fast outside gdb) 13.08.41 Quit Elfish (Ping timeout: 252 seconds) 13.08.48 Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) 13.09.54 Quit Cthulhux (Ping timeout: 252 seconds) 13.10.10 Join Cthulhux [0] (cthulhux@rosaelefanten.org) 13.10.47 Quit Cthulhux (Changing host) 13.10.47 Join Cthulhux [0] (cthulhux@piratenpartei/ni/tux) 13.23.07 # ha! 13.23.26 # according to http://gameprogrammer.com/fastevents/fastevents1.html SDL_WaitEvent sucks. and it's true 13.36.13 # http://pastie.org/3872960 (jhMikeS ^) 13.49.08 # jhMikeS: "Well, he's no Jan Brady"? 13.51.13 Quit Keripo (Quit: Leaving.) 13.59.16 Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) 14.03.26 # hmm, i'm not sure how to hook this in to pcm.c i guess just throwing in loops for applying gain in pcm_play_data_start and pcm_play_dma_complete_callback would not be ideal 14.10.06 Join anewuser [0] (~anewuser@190.207.222.122) 14.10.06 Quit anewuser (Changing host) 14.10.06 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 14.22.31 *** Saving seen data "./dancer.seen" 14.25.48 Join FrenchVerbs [0] (~chatzilla@c-71-193-88-22.hsd1.mn.comcast.net) 14.26.45 # Hey guys I'm on the latest version of rockbox with an ipod classic. Everytime I boot up I get a *Panic* audio_buffer_noalloc(): EOM (65536 > 0) What does this mean? 14.28.41 # Would clearing rockbox database in the boot menu help? 14.29.46 # I've gotta go to school, but I'll hang out in case someone can help me out. 14.34.51 # quick hack in pcm.c to set volume there http://pastie.org/3873163 works in the sim at least 14.35.29 Quit bertrik (Remote host closed the connection) 14.35.36 # would somethign like this but cleande up of course be the way to do it or do we need to buffer pcm while applying the gain? 14.35.57 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 14.35.57 Quit bertrik (Changing host) 14.35.57 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 14.43.47 Quit kadoban_ (Ping timeout: 265 seconds) 14.45.30 Join Thra11 [0] (~thrall@31.185.180.140) 14.46.42 Quit bertrik (Read error: No route to host) 14.49.56 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 15.00.43 Join eyfour [0] (~a4@85.252.220.105) 15.11.28 Join enthdegree [0] (~enthdegre@wikimedia/enthdegree) 15.18.07 Quit Cthulhux (Ping timeout: 252 seconds) 15.23.20 Quit eyfour (Quit: WeeChat 0.3.5) 15.23.52 Join Cthulhux [0] (cthulhux@piratenpartei/ni/tux) 15.24.23 Join eyfour [0] (~a4@85.252.220.105) 15.27.03 # a bunch of the newer metadata parser files lack header 15.30.20 Quit TheLemonMan (Quit: WeeChat 0.3.7) 15.32.23 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.36.42 Quit stoffel (Ping timeout: 260 seconds) 15.37.05 Join funman_ [0] (~fun@rockbox/developer/funman) 15.37.26 Quit funman (Ping timeout: 265 seconds) 15.42.07 Quit funman_ (Ping timeout: 240 seconds) 15.43.17 Join funman [0] (~fun@altair.via.ecp.fr) 15.43.19 Quit funman (Changing host) 15.43.19 Join funman [0] (~fun@rockbox/developer/funman) 15.50.15 Join Topy44 [0] (~Topy44@f048224156.adsl.alicedsl.de) 16.07.34 Join c3sso [0] (~tux@89.106.213.194) 16.10.46 Quit enthdegree (Ping timeout: 255 seconds) 16.12.55 Join stoffel [0] (~quassel@pD9E42742.dip.t-dialin.net) 16.22.34 *** Saving seen data "./dancer.seen" 16.39.59 Join megal0maniac [0] (~megal0man@196.213.53.210) 16.40.39 # Quick question. My Fuze+ has died completely, or so I thought. Can still access recovery mode. Is it possible to fix it? 16.42.51 # I guess that isn't really a quick question... :) 16.50.52 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 16.52.29 # Have to go. Will re-join IRC when I get home and review the logs. If anyone knows how to dump a firmware image (or simply recover,) please let me know 16.52.32 # Thanks 16.54.11 Quit megal0maniac (Quit: Konversation terminated!) 16.55.07 # megal0manic: it is possible to reinstall a firmware image, but it would interesting to know why it failed in the first place 16.58.31 Part Zagor 17.07.35 Join mortalis [0] (~mortalis@77.108.98.177) 17.10.41 Join megal0maniac [0] (~vwmazfa@197.171.142.46) 17.11.38 Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) 17.12.57 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 17.13.49 Quit megal0maniac (Client Quit) 17.28.46 Quit factor (Read error: Connection reset by peer) 17.32.20 Join megal0maniac [0] (~megal0man@41.52.11.242) 17.33.16 # Hello. Can't check the logs at the moment, but does anyone know how to restore a Fuze plus from within recovery mode? 17.35.07 # megal0maniac: yes, it's written on the wiki 17.35.29 # http://www.rockbox.org/wiki/SansaFuzePlusPort#Linux_AN1 17.35.40 # I only saw how to get it into Recovery mode, not how to flash it... 17.37.00 # the link I gave you explains everything, I wrote it so that anyone can restore its device (if it's still working) 17.37.03 # Alright, thanks. Will have a closer look when I get to a computer 17.38.23 # It's odd. It just freaked out completely and switched off. Only recently did I manage to get it into recovery mode... 17.39.09 Part LinusN 17.41.40 # indeed 17.43.07 # Thanks again for your hard work :) 17.43.08 # I'll brb 17.43.15 Quit megal0maniac (Quit: used jmIrc) 17.44.00 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.46.43 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 17.47.25 Quit TheLemonMan (Quit: WeeChat 0.3.7) 17.51.06 Quit kugel (Remote host closed the connection) 17.55.01 Join MethoS- [0] (~clemens@134.102.106.250) 17.56.33 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.57.33 # jhMikeS: re-using the input thread is suboptimal too. it loses input events when being spammed and/or blocked by I/O 17.59.40 # the result is that it's not much more responsible than without this (with sigaltstack threads existing solution is not functional) 18.05.34 Quit anewuser (Ping timeout: 255 seconds) 18.11.23 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.22.38 *** Saving seen data "./dancer.seen" 18.22.43 # grr, this header mess is infuriating 18.25.29 Quit mystica555 (Ping timeout: 252 seconds) 18.27.13 Quit [Saint] (Read error: Connection reset by peer) 18.35.31 Join megal0maniac [0] (~megal0man@dsl-244-87-212.telkomadsl.co.za) 18.38.28 # @pamaury I was looking at the wrong wiki page :$ Busy installing Ubuntu (only distro I have on hand) and hopefully get it sorted soon 18.39.38 Join saratoga [0] (98032941@gateway/web/freenode/ip.152.3.41.65) 18.40.16 # preglow: so if I want to try an oversampling hermite interpolator, what is the correct type of filter to use for upsampling? 18.42.48 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.43.20 # Commit 7803f31 in rockbox by 03Nils Wallménius: Don't reinvent ctype.h functions 18.44.51 # n1s: good catch 18.45.10 # kugel: for 803408f strlcpy is not usable because it nulkl terminates the copy 18.46.04 # just overwrite that byte? 18.48.40 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.48.57 # ah but it could write 1 byte too much 18.58.05 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 18.59.18 # * n1s pokes CIA-79 19.01.17 Join prof_wolfff [0] (~prof_wolf@213.37.48.196.static.user.ono.com) 19.01.39 # Commit dae7a29 in rockbox by 03Rafaël Carré: fix a mistake of 803408f18 spotted by n1s 19.05.27 Join lebellium [0] (~chatzilla@e179077231.adsl.alicedsl.de) 19.12.42 Quit krnlyng (Read error: Connection timed out) 19.14.53 Join ej0rge [0] (~alhaz@207.135.137.71) 19.15.12 # So i just noticed something weird about the behavior of the equalizer on my gigabeat S 19.15.34 # It strikes me as odd that i should be able to clearly hear a tonal difference between EQ enabled and EQ disabled when the EQ is zeroed out 19.15.45 # Any thoughts? 19.23.19 # Not sure about Rockbox, but in the world of pro / studio audio, this is normal. 19.24.05 # ej0rge: given a non-0 precut there will be a volume difference at least 19.24.16 # The sound is still passing through some or other circuitry, and while it isn't intentionally changing the sound, it does have an effect. I'd imagine that it's a similar scenario in rockbox 19.24.39 # megal0maniac: it's not. the EQ is pure software 19.25.17 # gevaerts: Stranger still, when i loaded the "Default" EQ preset, the difference seemed to go away 19.25.32 Join megal0maniac__ [0] (~michael@dsl-244-87-212.telkomadsl.co.za) 19.26.12 # iirc there are some rockbox targets with hardware eq features that are supported, but those are always in a sub-menu separate from "Equalizer", right? 19.26.55 # gevaerts: loading the default preset does not seem to have changed any values, but I am unsure of my conclusions. I'll come back and/or log a bug if i duplicate the behavior on another device. 19.27.02 # or find some way to make this one do it again 19.27.22 # Yes, but then it's passing through algorithms instead of circuitry. Same priciple, I'd imagine 19.27.43 # megal0maniac: unless the setting is "Do nothing" - in which case, mathematically, it should do, nothing. 19.27.50 Quit megal0maniac (Quit: Konversation terminated!) 19.28.07 # he didn't seem all that megalomaniacal to me . . . 19.28.20 # I'm still here :P 19.28.26 # oh! 19.29.02 Join anewuser [0] (~anewuser@190.207.222.122) 19.29.03 Quit anewuser (Changing host) 19.29.03 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 19.29.28 # megal0maniac__: On an analog EQ, there are intrinsic qualities of the circuitry - such as phase distortion from passing through banks of capacitors - that are unavoidable 19.30.00 # megal0maniac__: software eq *shouldn't have as many intrinsic artifacts. But I am not an expert. 19.30.22 # Different machine. If it's set to 0, but on, then wouldn't it be passing through some sort of algorithm? I haven't seen the source, and wouldn't understand it anyway, but it's the only explanation I can think of. Same is true for Waves plug-ins, but this is done deliberately... So I don't actually know, but that's my 2 cents :) 19.30.54 # megal0maniac__: Sure, but just as your spreadsheet is the same going into a zip file as it is coming out, heavy math doesn't mean that the output changes 19.31.34 # it is, at least, not intrinsic to the method 19.31.41 # Fair point.. What is the audible difference? 19.31.55 # When i turned on the eq, it sounded muffled 19.31.59 # slightly 19.32.09 # treble rolloff was notable 19.33.04 # ej0rge: the fixed point math isn't perfect so you can't really compare the eq to the zip algo 19.33.06 # It's possible that I've just had so many versions of rockbox on the thing, and played with the eq settings so little, that i had something stuck somewhere that didn't go away until i loaded a preset 19.33.15 # n1s: fair enough 19.33.21 # it should however not apply any gain for a band if it's set to 0 19.33.59 # also note that the beast has both hardware and software eq, i'm not sure how the hw one behaves 19.34.53 # n1s: yeah, me either, but my assumption is that those are implemented in the 'tone controls' menu, like the tone controls on my old H120 19.35.02 # nope 19.35.07 # ah 19.35.09 # ok 19.36.35 # well, I have more beasts. I'll see if i can find or force the condition, if the mood strikes me 19.37.11 # well, you're partially right it's under tone controls but controlled differntly to the usuall bass/treble ones 19.37.47 # ej0rge: so you're sure all bands have 0 gain and just enabling the eq makes the audio change? 19.40.38 # and as gevaerts pointed out precut also at 0? 19.41.47 # ATA Error: -2 19.42.03 # I take it this is not good... 19.44.52 # n1s: That is what i observed 19.45.12 # n1s: but it doesn't seem to do that ever since i loaded the "default" preset 19.45.40 # megal0maniac__: when has an ATA Error been good? 19.49.50 Join [Saint] [0] (~Saint]@101.98.158.103) 19.49.51 Quit [Saint] (Changing host) 19.49.51 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 20.04.38 Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) 20.05.15 # * megal0maniac__ rages 20.05.39 # Seems as though yet another Fuze+'s internal memory has failed 20.06.06 Quit remlap (Ping timeout: 240 seconds) 20.16.37 Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) 20.22.42 *** Saving seen data "./dancer.seen" 20.24.22 # saratoga: i just wouldn't go there 20.24.43 # saratoga: that kind of upsampling resamplers only work if you can make the upsampling implicit 20.24.47 # like with polyphase filters 20.25.02 # with "work" i mean being fast enough 20.26.12 # is that comparable to SSAA (super sampling anti aliasing)? 20.26.24 # i mean upscaling then downscaling again? 20.26.47 # yeah 20.27.01 # though ssaa synthesizes the scene in its upsampled domain directly 20.27.19 # instead of starting in one sample rate, then upsampling, then downsampling to yet another rate 20.27.48 Quit remlap1 (Quit: Leaving.) 20.27.54 # right 20.29.25 # saratoga: using either fir or iir filters for upsampling combined with spline downsampling pretty much requires you to actually calculate all the upsampled samples explicitely before downsampling with a spline again, the performance hit would be huge 20.30.16 # preglow: with FIR, you can just compute the output samples your polynomial actually needs right? 20.30.28 # JdGordon: ping 20.30.35 # saratoga: yeah, but the spline resampler would always need like every other sample, for example 20.30.45 # saratoga: so you wouldn't be able to craft an optimization around it 20.30.49 # yeah, but for 2x thats not too bad 20.30.53 # wouldn't <- 20.31.23 # looking at that paper, it seems like the actual computational expense of oversampling is relatively small compared to the improvement in snr 20.31.30 # for low ratios anyway 20.31.33 # like 2x or 4x 20.31.50 # i'm pretty sure you'd be better off just implementing a polyphase sinc resampler, like libsrc or the speex one 20.32.16 # the problem with that though is that you need fairly high order to get good results 20.32.25 # high order for excellent results 20.32.32 # if i understand you correctly 20.32.35 # but good results don't need much 20.32.43 # actually, what do you mean by sinc resampler? 20.33.02 # upsamplign to the LCM, sinc filtering, and then downsampling? or something else 20.33.12 # that's the explicit form of it 20.33.26 # but there's a polyphaseish form of it that's very popular 20.33.35 # https://ccrma.stanford.edu/~jos/resample/ 20.33.47 # where the upsampling is implicit 20.33.57 # well, seems implicit when you calculate it 20.34.13 # yes, we have code for doing that on the tracker 20.34.29 # its not as efficient as I would like 20.35.31 # fs#12223 20.35.32 # http://www.rockbox.org/tracker/task/12223 3sinc resampling for rockbox (patches, unconfirmed) 20.35.55 # ~25MHz for 48k to 44.1k resampling 20.36.56 # the idea of the polynomial filters is that they're quite fast, and with a low degree of oversampling the overhead is much less then upsampling to ~1MHz needed for the sinc method 20.39.12 # actually the ASM version of that is much faster 20.40.26 Join dhrasmus [0] (~dhrasmus@75-175-2-105.ptld.qwest.net) 20.44.44 Quit dhrasmus (Client Quit) 20.45.25 Quit saratoga (Ping timeout: 245 seconds) 20.47.19 # well, the trick with this method of sinc resampling is that you don't need to do that upsampling explicitely 20.48.25 Quit TheLemonMan (Quit: WeeChat 0.3.7) 20.48.28 # but anywho, experimenting is good 20.48.37 # but you should consider doing said experimentation in matlab :> 20.52.18 Join jfc [0] (~Fung@inet-hqmc05-o.oracle.com) 20.54.18 # by the way ffmpeg and libav got 2 competing resampling libraries 20.59.58 Quit c3sso (Ping timeout: 260 seconds) 21.07.34 Join T44 [0] (Topy44@f048224156.adsl.alicedsl.de) 21.09.32 Quit Topy44 (Read error: Connection reset by peer) 21.10.48 Part eyfour ("WeeChat 0.3.5") 21.11.21 Join c3sso [0] (~tux@89.106.213.194) 21.11.46 Quit megal0maniac__ (Quit: Ex-Chat) 21.18.40 Quit c3sso (Ping timeout: 265 seconds) 21.19.49 Join TheLemonMan [0] (~LemonBoy@adsl-ull-43-248.45-151.net24.it) 21.25.19 Join dhrasmus [0] (~dhrasmus@75-175-2-105.ptld.qwest.net) 21.30.24 Quit benedikt93 (Quit: Bye ;)) 21.45.48 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.51.53 Join domonoky1 [0] (~Domonoky@agsb-5d871b1d.pool.mediaWays.net) 21.53.14 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 21.54.13 Quit domonoky (Ping timeout: 260 seconds) 22.06.22 Join enthdegree [0] (~enthdegre@wikimedia/enthdegree) 22.15.47 Quit stripwax (Quit: http://miranda-im.org) 22.18.23 Quit preglow (Changing host) 22.18.23 Join preglow [0] (thomj@rockbox/developer/preglow) 22.20.38 Quit mortalis (Quit: Leaving) 22.22.01 Quit enthdegree (Read error: Operation timed out) 22.22.44 *** Saving seen data "./dancer.seen" 22.34.18 Quit dhrasmus (Quit: Leaving) 22.43.30 Quit nosa-j (Read error: Connection reset by peer) 22.44.29 Join nosa-j [0] (~m00k@adsl-74-235-42-27.clt.bellsouth.net) 22.48.59 Quit stoffel (Remote host closed the connection) 23.01.50 Quit Rower85 (Quit: Hmmm...) 23.14.15 Join Pro7__ [0] (~Pro7@87.254.70.6) 23.19.42 Quit nosa-j (Ping timeout: 245 seconds) 23.20.29 Join nosa-j [0] (~m00k@adsl-74-235-42-239.clt.bellsouth.net) 23.27.26 Quit y4n (Quit: We're fucking 3LN!) 23.30.39 Quit FrenchVerbs (Quit: ChatZilla 0.9.88.2 [Firefox 15.0a1/20120506030520]) 23.42.01 Join kevku [0] (x@Gizka-1-pt.tunnel.tserv24.sto1.ipv6.he.net) 23.58.24 Join Sorrento [0] (~sorrento@c-68-61-186-14.hsd1.mi.comcast.net)