--- Log for 29.09.110 Server: pratchett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 0 hours ago 00.01.04 # hello, the 3.6 firmware for sansa clip v1 is giving me a 404 error. 00.02.33 # Is there a mirror somewhere, or should I just go for the current build (I'm doing a new install)? 00.04.40 # when 3.6 was released, clip wasn't considered stable yet, so the build doesn't actually exist - use the current build instead 00.04.58 # cool, thanks 00.07.16 Quit MagusG (Ping timeout: 265 seconds) 00.07.33 Quit Staphylo (Quit: Bye les gens =)) 00.11.19 Quit bricks (Quit: CGI:IRC 0.5.9 (2006/06/06)) 00.13.14 Quit jgarvey (Quit: Leaving) 00.14.18 # pixelma: (for logs) I uploaded new version of the patch to FS#11641. This time it should apply cleanly. 00.19.10 Quit liar (Ping timeout: 240 seconds) 00.20.37 Quit wodz (Quit: Leaving) 00.23.05 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 00.29.45 Join drizztbsd_ [0] (~quassel@82.84.100.107) 00.31.00 Join drizztbsd__ [0] (~quassel@dynamic-adsl-78-12-185-162.clienti.tiscali.it) 00.33.01 Quit drizztbsd (Ping timeout: 272 seconds) 00.34.55 Quit drizztbsd_ (Ping timeout: 272 seconds) 00.35.17 Quit domonoky1 (Read error: Connection reset by peer) 01.01.16 Quit ender` (Quit: printk("; corrupted filesystem mounted read/write - your computer will explode within 20 seconds ... but you wanted it so!\n"); -- /usr/src/linux/fs/hpfs/super.c) 01.03.47 Join Strife89TX [0] (~cstrife89@adsl-80-164-93.mcn.bellsouth.net) 01.05.15 Join Topy [0] (~Topy44@g228134251.adsl.alicedsl.de) 01.05.24 # we should release 3.7 so people stop asking about 3.6 on the clip! 01.08.27 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 01.08.31 Quit T44 (Ping timeout: 245 seconds) 01.14.51 Quit kugel (Ping timeout: 240 seconds) 01.21.41 Quit esperegu (Read error: Connection reset by peer) 01.22.19 Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) 01.31.58 Join freedrull [0] (~freedrull@freedrull.xen.prgmr.com) 01.35.41 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 01.40.09 Quit Nausicaa (Ping timeout: 272 seconds) 01.47.55 Part freedrull 01.49.22 Quit DerPapst (Quit: Leaving.) 01.52.38 *** Saving seen data "./dancer.seen" 02.04.35 Quit t0rc (Ping timeout: 276 seconds) 02.06.09 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 02.06.56 Join shai__ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 02.09.27 Quit _s1gma (Quit: Leaving) 02.09.52 Join JdGordon [0] (7bf38c1f@gateway/web/freenode/ip.123.243.140.31) 02.10.33 Quit shai_ (Ping timeout: 272 seconds) 02.16.22 Quit mt (Remote host closed the connection) 02.20.38 Join ntryon [0] (~ntryon@42.interlockroc.net) 02.21.13 Join ntryon_ [0] (~ntryon@42.interlockroc.net) 02.25.35 Quit ntryon (Ping timeout: 265 seconds) 02.27.18 Join Barahir [0] (~jonathan@frnk-590f7d14.pool.mediaWays.net) 02.33.28 Join Tux2 [0] (~Tux2@174-29-227-211.hlrn.qwest.net) 02.38.54 Join komputes [0] (~komputes@ubuntu/member/komputes) 02.46.28 # from last nights buffering talk... I'm scared to think what would happen to the skin engine if it went to handle allocations instead of simple pointers 02.47.24 # the whole thing is linked trees, pointers to alloced arrrays, pointers to structs.. if even the block could move around it would be a nightmare 02.48.16 # but if the initial block could be compacted once we know how much has been used, and guarenteed to not be moved (without an exensive reload) then it might be ok 02.48.31 # ^ saratoga_, Torne, Unhelpful 02.49.26 Quit stripwax (Read error: Connection reset by peer) 02.50.14 Quit simonrvn (Read error: Connection reset by peer) 02.50.46 # @Torne: yes, i realize that special cases could potentially be expensive, my expectation was that they would also be very rarely *used*. the idea is that this sort of thing only happens on things like skin change, maybe a user changes one of the resizeable buffers that we can currently only size on boot, etc. 02.51.29 # if there's a playback stall it won't surprise anybody much as it immediately follows a user interaction - the same thing already happens if you change to a theme w/ different AA size, and i have seen almost no complaint about it. 02.59.06 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) 02.59.19 Quit factor (Ping timeout: 272 seconds) 03.00.24 Quit Ramsey[LC] (Remote host closed the connection) 03.00.53 Join Ramsey[LC] [0] (~RamseyLC]@71.158.161.74) 03.05.15 Join clone4crw [0] (~Calvin@97-86-227-168.dhcp.roch.mn.charter.com) 03.06.01 Quit Judas_PhD (Quit: This is a quitting message) 03.15.36 Quit Xerion (Read error: Connection reset by peer) 03.32.25 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 03.32.29 Quit komputes (Remote host closed the connection) 03.44.35 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) 03.50.05 Join Strife89 [0] (~Strife89@adsl-80-164-93.mcn.bellsouth.net) 03.52.41 *** Saving seen data "./dancer.seen" 03.56.58 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 04.14.01 Quit engwan_ (Ping timeout: 276 seconds) 04.14.59 Quit clone4crw (Quit: leaving) 04.15.36 Join simonrvn [0] (simon@209.214-ppp.3menatwork.com) 04.21.59 Quit amiconn (Disconnected by services) 04.21.59 Quit pixelma (Disconnected by services) 04.22.00 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.22.00 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.22.16 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.22.17 Quit Strife89 (Quit: Leaving) 04.22.20 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.25.44 Join anewuser [0] (anewuser@unaffiliated/anewuser) 04.30.34 Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) 04.36.51 Join engwan_ [0] (~engwan@112.202.22.199) 04.40.34 Quit Barahir (Read error: Operation timed out) 04.45.01 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 04.56.55 Quit engwan_ (Ping timeout: 255 seconds) 04.57.34 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) 04.59.08 Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) 04.59.44 Part Keripo 05.01.57 Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) 05.14.30 Quit MethoS- (Read error: Connection reset by peer) 05.27.16 Join Barahir [0] (~jonathan@frnk-590ffacd.pool.mediaWays.net) 05.30.43 Join froggyman [0] (~seth@unaffiliated/froggyman) 05.32.05 Quit ntryon_ (Ping timeout: 265 seconds) 05.33.52 Quit ps-auxw (Ping timeout: 245 seconds) 05.41.03 Join factor [0] (~factor@74.196.132.161) 05.45.32 Join ps-auxw [0] (~arneb@p4FF7EF43.dip.t-dialin.net) 05.46.16 Quit edboyer93 () 05.46.25 Quit clone4crw (Ping timeout: 255 seconds) 05.52.44 *** Saving seen data "./dancer.seen" 06.11.11 Quit Horscht (Quit: Verlassend) 06.18.53 Quit bluebrother (Ping timeout: 265 seconds) 06.20.13 Join bluebrother [0] (~dom@f053154024.adsl.alicedsl.de) 06.20.13 Quit bluebrother (Changing host) 06.20.13 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 06.44.11 Quit Tux2 (Quit: I can't stay forever... but I will be back!) 06.53.06 Quit Nausicaa (Ping timeout: 252 seconds) 07.02.03 Join powell14ski_ [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 07.05.51 Quit krazykit (Quit: awe yeeeeeee) 07.12.21 Quit togetic (Ping timeout: 252 seconds) 07.33.40 Join Staphylo [0] (~Bullet@AMontsouris-159-1-51-172.w92-128.abo.wanadoo.fr) 07.39.51 Quit Judas_PhD (Quit: This is a quitting message) 07.47.06 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 07.52.47 *** Saving seen data "./dancer.seen" 08.01.21 Quit anewuser (Ping timeout: 272 seconds) 08.10.19 Quit Staphylo (Quit: Bye les gens =)) 08.45.43 Join einhirn [0] (~Miranda@wlanstaff083.rz.tu-clausthal.de) 08.46.01 Quit einhirn (Client Quit) 08.50.32 Join einhirn [0] (Miranda@wlanstaff083.rz.tu-clausthal.de) 08.55.33 Join ender` [0] (krneki@foo.eternallybored.org) 08.56.01 Join einhirn_ [0] (Miranda@wlanstaff083.rz.tu-clausthal.de) 08.59.18 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.59.22 Quit einhirn (Ping timeout: 240 seconds) 09.01.16 Quit einhirn_ (Ping timeout: 240 seconds) 09.03.31 Quit GodEater (Read error: Operation timed out) 09.07.05 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 09.08.08 Join esperegu [0] (~quassel@145.116.15.244) 09.11.42 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 09.11.42 # * pixelma wonders about the number of reports (in the forum) of problems with installation, seemingly bootloader installation, on PP Ipods 09.12.15 # I believe there are 4 since yesterday 09.18.09 Quit Judas_PhD (Quit: This is a quitting message) 09.22.23 Join GibbaTheHutt [0] (~moo@78-105-152-175.zone3.bethere.co.uk) 09.28.31 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 09.28.31 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.28.31 Quit bertrik (Changing host) 09.28.31 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.30.24 Quit einhirn (Read error: Connection reset by peer) 09.30.34 Join swilde [0] (~wilde@aktaia.intevation.org) 09.39.57 Quit JdGordon (Ping timeout: 252 seconds) 09.43.12 Join wodz [0] (~wodz@chello087206240131.chello.pl) 09.44.45 # pixelma: could you try FS#11641 on Your Ondio? It *should* apply cleanly 09.46.35 # So I mentioned this yesterday or the day before but I'm having a weird problem on the last few revisions with the clipv1 09.48.11 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 09.49.06 # on newer operating systems with identical hardware (think windows 7 or ubuntu don't work vista/xp do) I get "*PANIC* SD Xfer read err:0x8 Disk0" 09.49.27 Quit einhirn (Client Quit) 09.49.42 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 09.50.01 # and by "don't work" I mean "the error is reproducible" 09.50.55 # the build I installed ~2-3 days ago didn't have any problem 09.52.48 *** Saving seen data "./dancer.seen" 09.53.16 # try bisecting 09.53.49 # 2-3 days means only a couple commits 09.57.48 Join Rob2222 [0] (~Miranda@pD9FE2992.dip.t-dialin.net) 09.59.27 Join utanapischti [0] (~username@p4FF2D005.dip.t-dialin.net) 10.01.18 Quit Rob2223 (Ping timeout: 252 seconds) 10.03.28 Quit sasquatch (Ping timeout: 245 seconds) 10.05.02 # uberushaximus: that's *really* weird. That panic is in the SD code. That really shouldn't be influenced by the OS you use... 10.06.49 # I also don't see anything in the svn log during the last two weeks that looks even vaguely related 10.11.07 Quit antil33t (Read error: Connection reset by peer) 10.11.16 Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) 10.15.28 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 10.19.11 # wodz: Sorry, I was asleep last night - I can test tonight 10.19.45 # ok, thx 10.22.26 Quit Guest30770 (Quit: Leaving.) 10.23.47 Join {phoenix} [0] (~dirk@p57AA4269.dip.t-dialin.net) 10.24.36 # Silly question, why I don't wish to be trolled for asking, but as I've noticed, Rockbox has a 3 month release cycle. I'd like to know if there is anything extremily wrong or lots of belated bug fixes which delay the release or there is just no apperant reason or what so ever. 10.26.37 # There's a combination of things going on I'd say 10.27.00 # in my experience the changes to the skin engine still aren't settled, e.g. you can experience screen cuorruption sometimes and in different ways on at least the targets with monochrome screens 10.27.37 # (a) someone has to take the initiative to start the release process, and nobody has yet, and (b) several people (I'm one of them) feel that the recent skin changes aren't stable enough yet 10.27.50 # Possibly (a) is caused by (b) 10.28.29 # I see, well, I can't help with that, I only use one spesific skin on a spesific device. 10.28.30 Quit Judas_PhD (Quit: This is a quitting message) 10.37.23 Join DerPapst [0] (~Alexander@dslb-088-069-157-050.pools.arcor-ip.net) 10.40.31 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 10.53.41 # http://download.rockbox.org/daily/fonts/rockbox-fonts.zip -- Seem to be 9/2009 is that right? 10.54.01 # 23-Sep-2009 10.54.42 # sounds very possible 10.55.05 Quit wodz (Quit: Leaving) 10.55.28 # gevaerts: Except it seems the normal rockbox build got newer font files in it. 10.58.40 # gevaerts: Also, according to rasher.dk, rockfont.bdf supports Hebrew, yet with either of the files [latest / fonts build] Hebrew isn't working correctly. 10.59.10 # rasher's page is auto-generated as far as I know 10.59.19 # * gevaerts isn't a font specialist 11.05.35 # Unhelpful: if the special cases are very rarely used that makes them even *more* expensive in terms of binsize, code complexity and space for potential bugs to hide :) 11.06.25 # Torne: i suppose. very cheap in terms of run time, and not hard to test as we already have lists of things we can't change without reboot right now. ;) 11.08.11 # but we don't test stuff particularly methodically a lot of the time. :) 11.08.44 # i am just, mostly, waving my paw a bit and assuming that a special purpose malloc can be made to work fine :) 11.08.54 # i have the vaguest of vague ideas about what that would be 11.08.58 # i may well be wrong :) 11.09.25 # could just say "we have a real malloc, only for MMU devices" ;P 11.11.04 # there's not really a significnat benefit to the MMU here 11.11.13 # unless you promote all allocations to multiples of 4kb 11.11.15 # which would suck 11.11.23 # and we'd need to start having actual pagetables :) 11.12.18 # Torne: wouldn't a benefit w/ an MMU be that we could compact and remap existing allocations, while still using the classic malloc pointer interface instead of some sort of handle-based thing? 11.13.01 # but you can't. 11.13.16 # you can sort of half do it in a very limited way for chunks of 4kb, at the cost of loads of overhead and extra memory used 11.13.29 # virtual memory is not all that ;) 11.14.03 # heh 11.15.03 # * Torne thinks a useful thing to do, at this point, would be to throw some logf's in there so someone can look and see how many buffer_allocs there actually are and what sizes they are and why they exist 11.15.55 # maybe later ;) 11.16.37 # gevaerts: Where can I get the real latest 8-rockfont.fnt? 11.16.56 # Torne: useful things? is that how development works? 11.17.35 # heh 11.18.43 # occasionally :) 11.20.05 # it's more fun to debate how best to implement things i believe to be gross misfeatures :) 11.21.35 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 11.32.31 Quit Strife89TX (Quit: Leaving) 11.52.50 *** Saving seen data "./dancer.seen" 11.53.23 Join einhirn_ [0] (Miranda@wlanstaff083.rz.tu-clausthal.de) 11.56.48 Quit einhirn (Ping timeout: 240 seconds) 12.05.43 Join Barahir_ [0] (~jonathan@frnk-590f4cfe.pool.mediaWays.net) 12.07.42 Join wodz [0] (~5f303f8a@giant.haxx.se) 12.08.48 Quit Barahir (Ping timeout: 240 seconds) 12.09.03 # gevaerts: Yes, I'm quite happy to do the release stuff, but have been waiting as I picked up that people weren't entirely happy with the state of some things 12.10.57 # like what? 12.11.06 # (not questioning you, just curious) 12.11.23 # mainly skin stuff 12.11.45 # I only mean unhappy as in some bugs need squashing :) 12.11.57 # But I may well have got the wrong end of the stick 12.15.25 # Torne: until one or two weeks ago there were regular crash reports on the forums. Things have been improving since then, but there are still issues for some people 12.16.14 # hm 12.16.24 # i'm concerned about the recent spate of people having issues installing on ipod 12.16.44 # but maybe it's just a coincidence and they all have knackered drives :) 12.17.09 # Several of them seem to be 1st gen Nanos, right? 12.17.26 # i think so 12.17.39 # there was also one guy reporting the "buttons don't work after hold" thing on ipodvideo 12.17.46 # which we thought we fixed ages ago 12.18.00 # but then a couple of people complained it still happened on the mini 12.18.10 # hadn't heard anyone mention it on any other model until now 12.18.43 # I wonder if this is just a sign of a new large group of people discovering rockbox 12.18.53 # We have been in the news in some circles recently 12.18.54 # possibly. 12.19.13 # oh, it's a good job nwe didn't do anything to host the psgroove thing it seems 12.19.21 # since sony are now suing the crap out of eveyrone who is 12.19.41 # ah, I wanted to look up when the fix got committed exactly, because the guy with the buttons not working after hold said he would be using r3.6 12.19.49 # pixelma: i'm pretty sure it was long before 3.6 12.19.53 # as in "release" 12.19.55 # lemme check, it's on my watchlist 12.20.32 # What skin change seems to have caused all the instability? 12.20.36 # there are also these instability issues on some Fuzes 12.20.54 # Llorean: basically the entire skin handling was rewritten since 3.6 12.21.06 # Llorean: there were quite a few in quick succession :\ 12.21.18 # Some instability is not really unexpected in those conditions 12.21.41 # gevaerts: True. I was just curious if it was done right after 3.6, or like... within the last month or so. 12.21.54 # I mean it seems like 3 months ought to be enough time to get stability at least reasonably recovered. 12.22.03 # the fix for the wheel thing was committed in july 2009 so it should be in 3.6 12.22.14 # Llorean: part of it was gsoc 12.22.20 # unless subsequent changes to the wheel driver (nano2g being merged with it) broke it again :) 12.24.20 # * Llorean will try to dig up his 1G Nano tomorrow. 12.24.43 # yeah i should actually update my ipodvideo and test it for a bit 12.25.05 # Though if I recall mine tended to be one of the ones that didn't show issues the last few times we had "only some players have this problem" types of issues too. 12.25.37 # * Llorean does wish Rockbox were releasing more consistently. 12.27.17 # I'm still pondering if we should maybe provide *both* shutdown workarounds as alternatives 12.32.54 Quit petur (Quit: *plop*) 12.37.10 # Torne: What are they? How? 12.37.45 # Llorean: currently the ipods clear the latter part of IRAM on shutdown to try and make startup not fail 12.37.56 # this doesn't seem to work for everyone, but it has no negative effect i'm aware of 12.38.16 # the older workaround of shutting down by rebooting to the OF made lots of people's players behave weirdly but fixes the problem for more people 12.39.37 # Except those it makes behave weirdly? 12.40.07 # no, some of those people are the same people :) 12.40.26 # Well new weird behavior doesn't really make it a "fix" does it? 12.41.06 # * Torne shrugs :) 12.42.22 Join timc [0] (~tim@112.166.15.141) 12.42.25 Nick timc is now known as Guest75106 (~tim@112.166.15.141) 12.46.54 Part LinusN 12.47.06 Join LinusN [0] (~linus@rockbox/developer/LinusN) 12.48.05 Part LinusN 12.49.25 Join MethoS- [0] (~clemens@134.102.106.250) 12.50.32 Join LinusN [0] (~linus@rockbox/developer/LinusN) 12.54.49 Part LinusN 12.55.03 Part Zagor 12.55.12 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 13.00.18 Quit Hadaka (Ping timeout: 240 seconds) 13.02.38 # gevaerts: Another possibility is that the psgroove build of Rockbox has other unexpected bugs for whatever reason, and that's why these people are having additional difficulties? 13.03.20 # Llorean: I'd hope they try a standard build first 13.03.40 # Hah. One can hope for anything, I suppose. 13.10.07 Join LinusN [0] (~linus@rockbox/developer/LinusN) 13.10.20 Join Hadaka [0] (~naked@naked.iki.fi) 13.21.29 Part LinusN 13.25.55 Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) 13.35.16 Join krazykit [0] (~kkit@24-148-89-52.frg-bsr1.chi-frg.il.cable.rcn.com) 13.36.53 Quit wodz (Quit: CGI:IRC (Ping timeout)) 13.50.12 Join wodz [0] (~5f303f8a@giant.haxx.se) 13.50.24 # teru: ping 13.50.41 # wodz: pong 13.51.07 # I updated patch for png plugin 13.51.33 # I saw it. 13.51.39 # I refactored code so decoder is selfstanding and do not depend on global vars 13.51.58 # I have fixes for mrobe scaling in my tree also 13.52.54 *** Saving seen data "./dancer.seen" 13.53.03 # I fixed simple_resize_bitmap() and realy do not wan't to touch smooth_resize_bitmap() 13.56.07 # what is the point of different draw_image_rect() separate for every format? 13.56.15 # teru:^ 13.56.58 # jpeg doesn't create native bitmap. 13.57.23 # I see 13.59.12 # wodz: I tried v2 patch on my gigabeat but I only get "Invalid CRC". I guess *(uint32_t *)(in + N) doesn't work but not sure. 13.59.21 Join n1s [0] (~n1s@nl118-174-240.student.uu.se) 13.59.21 Quit n1s (Changing host) 13.59.21 Join n1s [0] (~n1s@rockbox/developer/n1s) 13.59.47 # do we look for magic values to determine decoder or we simply relay on file extension? 14.00.07 # just only file extention. 14.03.54 # strange 14.04.23 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.06.38 # teru: could You prove this by changing *(uint32_t *)(in + N) to in[N]<<24 | in[N+1]<<16|in[N+2]<<8|in[N+3] and see if this passes CRC check? 14.09.01 # I'll try. 14.09.50 # wodz: most pc's are little endian so testing that in the sim on a pc should work 14.09.59 # it works on sim 14.10.37 Quit einhirn_ (Ping timeout: 240 seconds) 14.10.41 # (also casting a char pointer to a larger type and dereferencing it can cause data aborts on arm) 14.10.49 # if the char pointer is not aligned 14.11.52 # this is probably the case :/ 14.12.48 # teru: what gigabeat is that? 14.13.05 # gigebeat X30 14.13.44 # then it would throw an exception on a misalinged access which it isn't doing if it complains about invalid crc 14.15.20 # Doesn't the gigabeat F/X have some unusual behaviour with unaligned accesses? 14.15.56 # oh, i thought any of our arm's other than the beast aborted 14.16.14 # anyway I'll change back to byte-by-byte png interpretation 14.16.18 # if it doesn't abort it probably gives back rotated data or something 14.17.09 Quit bertrik (Read error: Connection timed out) 14.17.12 # wodz: there are functions for reading from a char array and translating into integer of chosen endianness in many places in rockbox 14.17.42 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 14.17.45 # I know my F usually freezes with code that makes other ARM DAPs give data aborts 14.18.20 # hmm, i think that is configurable for at least some cores, maybe it's just turned off for some reason on the f/x? 14.19.30 # ? I am aware of betoh16(), betoh32() and little endian variants but this takes value as argument not ptr to array 14.20.44 # for example apps/metadata/metadata_common.c get_(long|short)_(be|le) 14.21.38 # are they any faster than 'get-byte-shift' stuff? 14.22.02 # what processor is the gigabeat f? 14.22.03 # no, they do exactly that but since you seem to have trouble tested functions could be nice 14.22.17 # Torne: arm9tdmi 14.22.30 # maybe their bootcode enables unaligned 14.23.20 # hm, except a tdmi wouldn't have the register 14.23.49 Quit wodz (Quit: CGI:IRC) 14.27.20 # changed betoh32(*(uint32_t) (X)) to (((uint32_t) (X)[0] << 24) | ((uint32_t) (X)[1] << 16) |((uint32_t) (X)[2] << 8)|((uint32_t) (X)[3])) and it worked. 14.27.36 # Oh right, yes :) 14.27.46 # ARMs without CP15 don't genreate alignment faults 14.27.51 # they just return rotated data, always 14.28.10 # so ARM7TDMI and ARM9TDMI will just fuck up 14.28.34 # ARMs with CP15 default to generating alignment faults, but it can be turned off (until ARMv7 where it defaults to allowing them) 14.29.26 # n1s: the beast probably aborts, ARMv6 still doesn't allow it by default even though it does the right thing 14.31.39 # Torne: according to this http://svn.rockbox.org/viewvc.cgi/trunk/firmware/target/arm/imx31/crt0.S?r1=17458&r2=17495 strict alignment is disabled, not that i know why though 14.32.32 # it probably shouldn't be 14.32.49 # unless we have ARMv6 specific code which is using it specifically 14.33.19 # is a misaligned long load faster than individual byte loads on v6? 14.33.26 # not if it's not cached 14.33.27 # unaligned cache fills are slower and it only works for LDR, not LDM (or LDREX/etc) 14.33.48 # i forget the exact cycle timing of doing the load unaligned 14.34.08 # but generally the code would have to be *really* heavily dependent on accessing unaligned data for it to be faster to not fix it 14.34.30 # we do use unaligned loads explicitely on coldfire in some place(s) as it's faster there 14.34.50 # well, the core->cache interface only knows aligned accesses 14.35.02 # so the unaligned accesses are emulated on core by rotates and stuff 14.36.02 # if we do actually do it anywhere i'd be curious to see benchmarks 14.36.03 # hmm, the case i remember is bitstream reading in codecs so if it fetches subsequent memory to the cache probably doesn't hurt 14.36.16 # n1s: well the cache->core transfer is more expensive too, is my point 14.36.21 # it's not just potentially having to bring in more cachelines. 14.36.22 # ah 14.37.07 # * Torne shrugs 14.37.23 # since we run on armv5 there must be an aligned versoin of any code that does it too 14.37.27 # so it would be easy to bench :) 14.37.32 # well, easysh 14.37.50 # i could bench on my beast, although test_codec runs are abit skewed i think, since when the core is running at full speed memory accesses will be relatively slower 14.38.04 Join Jaykay [0] (~chatzilla@p5DC56D49.dip.t-dialin.net) 14.38.08 # It was always traditional to leave it disabled so that you didn't accidentally write code that wouldn't work on ARMv5 14.38.15 # unless i misunderstood all that 14.38.19 # but ARM themselves now allow it by default in v7 14.38.25 # so, who knows :) 14.38.32 # * n1s tests 14.39.49 # also i guess the armv5 and armv6 versions of a given bit of code are not necessarily comparable anyway 14.42.35 Nick drizztbsd__ is now known as drizztbsd (~quassel@dynamic-adsl-78-12-185-162.clienti.tiscali.it) 14.54.51 # hmm, usb inside rockbox is super screwy on my beast 14.55.12 # keeps disconnecting and reconnecting and then died with a black screen and shut off 14.55.29 # bootloader usb is still stable as a rock 14.58.24 Join anewuser [0] (anewuser@unaffiliated/anewuser) 14.58.42 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.59.35 # Torne: doing a straing long load + byteswap instead of 4 individual byteloads in the ffmpeg bitstream reading code speeds up flac decoding by 3.5% on the beast 14.59.49 # s/straing/straight/ 15.00.00 # Heh 15.00.07 # well, ok then 15.00.33 # so now the flac 8 test file decodes in 3.56s instead of 3.69 :) 15.00.34 # i assume it's already hidden behind a macro 15.00.39 # yep 15.00.57 # is it already ifdef'ed for v6, then, or are you adding that? 15.01.58 Part Zagor 15.02.17 # i'd have to add that, it's just #ifdef for coldfire ATM 15.02.57 # well, sounds worthwhile :) 15.04.23 # it could even be generalized into htobe32(*(const uint32_t*)(x)) as htobe will not do anything on coldfire 15.06.19 # there's also ROCKBOX_STRICT_ALIGN which is defined for all ARM cpus (as well as sh and mips) but this is checked in only one place 15.07.15 # in, dircache.c 15.15.55 Join {-phoenix-} [0] (~dirk@p57AA5117.dip.t-dialin.net) 15.19.50 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 15.20.05 # New commit by 03nls (r28183): ARMv6 supports unaligned memory accesses and they are enabled on our only ARMv6 target so we might as well use them. Speeds up decoding of a flac8 ... 15.20.17 Quit {phoenix} (Ping timeout: 272 seconds) 15.21.00 # hmm, my checkin seems to have hung 15.21.58 # r28183 build result: All green 15.23.26 # New commit by 03teru (r28184): explicitly set img->using_preloaded_icons in parse_image_load() and don't rely on parse_image_display(). 15.23.28 # the command still hasn't returned... 15.24.03 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 15.25.04 # r28184 build result: All green 15.47.08 # gevaerts: At least on SH the C string "Game" needs 8 bytes 15.50.10 # amiconn: because of alignment or something else? 15.50.24 # btw, no sh targets have these codecs anyway 15.52.58 *** Saving seen data "./dancer.seen" 15.55.54 # Yes. For some reason, sh-elf-gcc aligns all strings at 4 byte boundaries 15.56.36 # We would save quite a bit of binsize if we could change that. Unfortunately I never found out whether that's possible 15.57.30 # that seems stupid if the alignment isn't required by something 15.59.32 # It *may* be required by gcc's inline string/mem copying stuff 16.15.51 Join Nausicaa [0] (~Nausicaa@c-71-239-58-153.hsd1.il.comcast.net) 16.16.21 Quit antil33t () 16.19.25 Join sudoman [0] (d8ecfce7@gateway/web/freenode/ip.216.236.252.231) 16.36.43 Quit {-phoenix-} (Remote host closed the connection) 16.37.19 # [14:27:45] ARMs without CP15 don't genreate alignment faults <== At least that's not true for PP 16.38.35 Join engwan_ [0] (~engwan@112.202.22.199) 16.38.54 Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) 16.39.01 # [14:55:11] keeps disconnecting and reconnecting and then died with a black screen and shut off 16.39.19 # ^ that's probably due to USB charging. I do have the same problem when using my hub 16.39.40 # My hub does proper overcurrent shutdown, and the charging code draws more than what's allowed 16.39.52 # amiconn: ah, i'll test disabling that 16.40.36 # amiconn: the cache cell probably does it as an external abort 16.41.17 # amiconn: that was it, thanks 16.41.17 # amiconn: there's no such thing as an alignment fault without CP15, anyway; all aborts are external. they might still be caused by wrong alignment, but it's up to the external device 16.44.04 Join HeWhoMustNotBeNa [0] (~pbbbhhttt@119.153.38.29) 16.44.54 # awfully quiet in here isnt it? 16.46.22 # always 16.46.38 # nobody talked for almost sixty whole seconds 16.46.47 # lol 16.47.19 # n1s: So, bringing the sample rate topic in here. 16.47.25 # its a conspiracy against me, a conspiracy of silence 16.47.30 # A setting for "preferred sample rate" that resamples everything to it? 16.47.39 # Torne: Okay, regardless of how it's generated, PP fires data abort on unaligned accesses 16.48.04 # * Llorean would prefer, then, if there was also an option of "native" that disabled features incompatible with native sample rates, but played things back at their native ones, too, possibly 16.48.08 # right, but htat's unrelated to whether any other ARM does 16.48.14 # because it's external. 16.48.16 # Llorean: i'm no expert but that's the approach i think seemed the most feasible from previous discussions on the subject 16.48.22 # n1s: It's kinda funny that my laptop doesn't do overcurrent shutdown, but my external (powered) hub does 16.48.27 # a normal ARM7TDMI wouldn't. 16.48.34 # hey guys, what are the chances of getting flamed (or worse) for asking a truly noob question in here 16.48.56 # I usually connect the charger in order to avoid the effect. It also doesn't happen if the beast is fully charged 16.49.19 # amiconn: i used the frontside ports on my computer... i wonder why our usb charging does this, shouldn't it negotiate the current? 16.49.29 Join togetic [0] (~togetic@unaffiliated/ibuffy) 16.49.35 # It does, but somehow the calculation seems to be off 16.49.42 # HeWhoMustNotBeNa: virtually none, provided you're polite about it :) 16.50.06 # I.e. it calculates how much the charger is allowed to draw for a certain amount of total current, but that calculation is a bit off 16.50.18 # i should be able to accomplish that I think, being polite that is 16.50.19 # HeWhoMustNotBeNa: Though, if it's *truly* noob-ey, you might check the manual first to avoid being referred to it. 16.51.03 # Llorean, i am trying to read as much as possible.....but my 3 year old daughter wants me to vacate the pc so time is of the essence 16.51.28 # Llorean: it's not only a problem of dsp things but switching the actual DAC to a new samplerate needs, to be done and at an exact time and this switching introduces glitches AFAIU 16.52.12 # is it safe / advisable to use the rockbox utility to install rockbox for a noob like me? 16.52.24 # n1s: If you don't care about gapless, couldn't you let the PCM buffer empty of 44.1 content, switch, then start decoding 48 content? 16.52.42 # HeWhoMustNotBeNa: Rockbox Utility is intended to be very safe. 16.53.09 # Llorean: probably 16.53.13 # excellent. thanks Llorean 16.53.38 # Llorean: yeah, that'd be the easiest way 16.53.40 # n1s: I'd say that sort of thing is reasonable enough for people who want multiple sample rates mixed. 16.54.05 # I'd *suspect* that at least within a single album they'll always be the same sample rate, and that's (to my experience at least) where gapless is generally important. 16.54.46 # Llorean: i'm cynical so i expect people will complain whatever we do :) 16.55.00 # You could also just not bother fixing any of the DSP stuff to work with 48khz, and just require people to use resampling if they want DSP, since that affects audio quality anyway. :-P 16.55.11 # Llorean, i was reading different instructions elsewhere and there are 2 files for the installation there 1. Rockbox ipod nano 1g 2. ipod patcher 1g nano 16.55.28 # HeWhoMustNotBeNa: that's to do it manually; just use the utility 16.55.33 # HeWhoMustNotBeNa: Just use our manual. Other instructions aren't supported. 16.55.34 # if I use the utility would, it have the ptcher builtin? 16.56.19 # Llorean, many thanks.....i had to read those instructions as I want to port psgroove on the nano later 16.56.23 # the utility downloads everything it needs automatically 16.57.01 # then I would like to thank all the people who have made this utility 16.57.16 # i shall go the utility way now 16.57.19 # HeWhoMustNotBeNa: The psgroove patch isn't really supported. You can get help installing normal Rockbox in here (which is dead simple on the Nano and pretty much automated) but for help with the psgroove stuff you should contact its author. 16.57.51 # i know Llorean, i wasnt going to ask about psgroove in here in the first place 16.58.14 # i'm very thankful for all of your help.....i shall bother you guys again if i run into any problems 16.58.22 Quit einhirn (Ping timeout: 265 seconds) 17.01.46 Join Xerion [0] (~xerion@541907CA.cm-5-2a.dynamic.ziggo.nl) 17.02.29 Quit teru (Quit: Quit) 17.14.42 # Would not an interim solution be to keep the all-44 playback and introduce an "audiophile grade" resampler and tell the audiophools to stuff themselves if they think 48->44 is bad because "it is not integral"? 17.15.53 # Isn't it that a better resampler is too expensive in terms of cpu cycles? 17.16.02 # Would adding a higher quality resampler be easier than enabling native playback in a "no DSP, no crossfade, no gapless" way? 17.16.19 # the expense is only born by those who choose to use it. 17.16.49 # Llorean, I would think a higher quality resampler would be /preferable/ to "no DSP, etc" 17.16.57 # evilnick_B: Yeah, it's like saying "aren't the constant spinups of FLAC too expensive on disk targets?", people can deal with it if that's what they really want. 17.17.20 # soap: Which DSP are we really talking about here? How many of them are things "audiophiles" are actually going to turn on? 17.17.53 # I'm not talking about disabling them entirely, just disabling them when someone switches from "resample everything to 44.1" to "native playback" 17.19.19 Quit AlexP (Remote host closed the connection) 17.19.36 # I don't care which DSP is affected. If we consider DVD audio rips there is a source of legit 48K material which should not be burdened by either forceable PC-side resampling or lack-of-DSP. A good resampler should have identical perceptual quality to native 48k, so I don't see the advantage of native 48k playback if it would be burdensome on the rest of the Rockbox audio chain. 17.20.23 # (and when I say "I don't care" I mean "I don't think it matters") 17.20.44 # People aren't going to stop asking for native support just because there's a good resampler. 17.21.12 # What's better? Saying "no, you can't have it" or "you can have it, but when you're using it some other features may not be available"? 17.21.28 # people aren't going to stop asking for all sorts of indefensible things. 17.21.40 Join AlexP [0] (~alex@rockbox/staff/AlexP) 17.21.47 # But this is one that could not only be provided, but falls into the category of "better making use of the hardware's features" 17.22.11 # If you could tell them "Rockbox's resampler is just as good as native 48k" (which you can't now)... 17.22.53 # but a better resampler serves more people than native 48k on the hardware which can do 48k. 17.23.14 # i think native 48k is probably not that hard to do 17.23.18 # How bad is our resampler? 17.23.22 # really bad 17.23.27 # it allows all the crazy sampling rates, and supports all the (powerful enough) software decoding targets. 17.23.33 # For 48->44.1 is it noticeable? 17.23.35 # most of the stuff will work with 48k more or less, since its so close to 44.1k 17.23.48 # Llorean, saratoga_ why do you think it's really bad? Has anyone ever measured it? 17.23.52 # could probably use the EQ as is and just shift the center frequency values a couple percent 17.24.00 # bertrik: its linear interpolation 17.24.04 # bertrik: I don't know how bad it is, that's why I'm asking. I've just been told it's bad. 17.24.30 # saratoga_, so, that doesn't have to be so bad 17.24.45 # Is linear interpolation really that bad a way to resample audio? I don't know much about it, but it seems it'd be semi-reasonable. 17.24.56 # theres only one way to do linear interpolation, so it pretty much has to be bad 17.25.52 # give me a sec, i'll make a plot 17.25.56 # i've got matlab open 17.28.12 # It would be nice to have some hard data on the various methods (and their computational impact) 17.29.07 # Llorean, it worked...i have rockbox on my nano now.........many thanks 17.29.30 # but how do i switch between rockbox and the default os? 17.29.41 # That's described in the manual 17.30.03 # there now 17.30.58 # bertrik: at FS/3, resampling via linear interpolation down by 20% results in an aliased copy of the signal thats attenuated by 7dB relative to the peak 17.31.15 # source peak i mean 17.32.29 # i havent used this thing for ages and i forgot what the select button was 17.32.30 # oops 17.32.34 Quit tchan (Quit: WeeChat 0.3.3-dev) 17.32.36 # i'm looking at rockbox/firmware/target/arm/ipod/button-clickwheel.c line 357: "static bool hold_button = false;". is that correct? and does it have anything to do with this: http://www.rockbox.org/tracker/task/5230 ? 17.33.18 # sudoman: how can a variable declaration on its own be incorrect? 17.34.07 # saratoga_: We're primarily talking about 48->44.1 though 17.34.13 # gevaerts, it says shutting down and then it restarts :( 17.34.20 # or Llorean for that matter 17.34.22 # 48/44.1 17.34.26 # opps 17.34.38 # i'll try 9% 17.35.14 # Llorean: I could make out an additional hiss when playing back a really bad quality 11.025kHz file in swcodec Rockbox compared to it being played back in foobar2000 but that's an extreme example (and since it was bad quality to start with...) 17.35.16 # saratoga_, the signal is a 16 kHz sine I assume? 17.35.31 # gevaerts: well i'm not very experienced in this, but in context, it looks like the the test: "if (hold_button)" is only being performed if the "hold_button" in the previous test is true, but it should be peformed if there's any difference to "hold_button_old" 17.36.12 # why is "hold_button_old" automatically false? what if it was on before? 17.36.25 # * what if it was on hold? 17.37.17 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.37.59 # pixelma: I'm kinda surprised that upsampling from a fraction of 44.1 causes noticeable sound problems. 17.38.08 # * Llorean doesn't know why he would expect it not to though, just does. 17.39.51 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 17.40.04 # bertrik: http://duke.edu/~mgg6/pics/10khztone_resample48to441.png 17.40.08 # oh, just looked it up... it's even an 8kHz mono file 17.40.21 # gevaerts: what do you think? 17.41.48 # bass frequency obviously work a lot better, higher ones a lot worse 17.43.06 # I believe preglow also had a distinct opinion about our resampler ;) 17.43.39 # just thinking he could add some facts to the discussion 17.43.40 # didn't he write it? 17.44.47 # saratoga_, I'm not sure how to interpret that. Isn't the blue peak at around 1050 the same as the red peak at around 1250 the same, except resampled? 17.45.12 # bertrik: yes, when you resample the size of each frequency bin changes, so the FFT peaks won't line up 17.45.20 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.45.50 # The next highest blue peak is about 25 dB down 17.46.29 # thats not very good 17.47.02 # I agree, but far from the 7 dB you mentioned earlier :) 17.47.27 # thanks for all your help guys!!! 17.47.33 # bye from Pakistan 17.47.36 Quit HeWhoMustNotBeNa () 17.48.55 Join Staphylo [0] (~Bullet@AMontsouris-159-1-51-172.w92-128.abo.wanadoo.fr) 17.50.29 # bertrik: like I said it depends on frequency 17.50.41 # so as you decrease the test tone frequency you will decrease the aliasing 17.51.33 # and unfortunately as you increase the frequency it aliases into lower frequencies 17.52.42 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.53.00 *** Saving seen data "./dancer.seen" 17.53.16 # Is this 9% frequency change, or 20% ? 17.53.55 # 9% 17.54.01 # do you have matlab? i can give you the code 17.54.03 # its just 2 lines long 17.54.13 # no, I don't 17.54.27 # ah ok 17.55.00 # well heres what i did: http://pastebin.com/0qWR3T55 17.55.05 # should give you an idea what you're looking 17.56.16 # the basic problem here is that linear interpolation takes quiet high frequency noises and turns them into (perceptually louder) mid frequency noises 17.57.59 # how much more complex are better resampling algos? 17.58.34 # linear needs, like a an add and a shift per sample, right? 17.59.18 # sudoman: yes, isn't that what happens? 18.00.40 # n1s, it uses a multiply for each input sample plus some adding 18.01.18 # bertrik, oh 18.01.49 # its only a shift if you're resamplilng by a factor of 2 :) 18.03.08 Join hebz0rl [0] (~hebz0rl@dslb-088-067-199-113.pools.arcor-ip.net) 18.03.26 # gevaerts: it looks like "if (hold_button)" on line 368 won't be tested if hold_button is false because it is nested by the previous condition wich assumes that hold_button_old is false. so if the hold button is turned off then the input won't be unlocked. 18.04.26 # right, i wasn't thinking :) 18.04.31 # gevaerts: maybe line 368 shouldn't be nested by line 364 18.04.44 # cubic interpolation would be the next simplest thing, i think it needs something like a dozen multiplies per output sample 18.04.45 # Has anyone currently online ever done an ams sansa recovery? 18.05.10 # sudoman: "which assumes that hold_button_old is false"? Where does it do that? 18.05.11 # though maybe non-polynomial resampling would be more efficient 18.05.32 # sudoman: except for the first time after boot 18.05.37 # i really don't know much about the various algorithms other then linear < cubic spline < sinc 18.05.46 # Probably somebody has already designed 48->44.1 khz algorithms 18.05.51 # "hold_button_old = hold_button; hold_button = button_hold();" right above 18.06.09 # sudoman: That sets hold_button_old to whatever hold_button is, not false 18.06.26 # oops, i meant: " static bool hold_button = false; bool hold_button_old; /* normal buttons */ hold_button_old = hold_button;" 18.06.29 # yeah theres hundreds on PC, but most of them use 50-100MHz on an Intel machine since they insist on having >120dB accuacry or something stupid 18.07.17 # sudoman: did you miss the "static" there? 18.07.24 # saratoga_: "like a dozen multiplies per output sample" assuming 44.1kHz output in stereo would mean about 1 million multiplies per second, which *should* be doable 18.07.27 # What accuracy would be considered reasonable for rockbox, something like 60 dB? 18.07.56 # i'm not sure 18.08.01 # noob question: what does static do? 18.08.12 # it makes the variable static 18.08.27 # i guess we should probably run the rockbox resampler (on the Sim) through RMAA and see what that says 18.08.31 # (it survives after the function exits) 18.08.56 Quit n1s (Quit: Lämnar) 18.09.00 # oh, so it only runs once? 18.09.06 # it 18.09.11 # 's only initialised once, yes 18.09.24 # i wonder if its just easier to support 48kHz though 18.09.29 # ok, ic sorry for the confusion 18.09.53 # i think the EQ wouldn't care at all since its only a 9% difference, so unless you want a 20kHz EQ band its going to be the same coefficients anyway 18.10.30 # probably just a matter of fishing out all those nasty built in assumptions about how long a sample lasts in the PCM system 18.11.22 # AFAIU, the sample frequency is important basically only in apps/dsp.c where we now have NATIVE_FREQUENCY, so we could make NATIVE_FREQUENCY a variable instead of a constant 18.12.29 # apply_crossfeed would need slightly different delay constants, but i doubt anyones going to notice 18.12.44 # ah, yes indeed 18.13.46 # we should probably ask Blue_Dude 18.13.53 # he was the last person to really work on the PCM code 18.14.04 # but i don't see anything in there thats all that tied to the exact value of sample rate 18.14.46 # EQ will fail badly if you try to use it on say 32kHz audio, but its probably reasonable to just disable it for really low sample rates or else force resampling in that case 18.16.18 # cross fade could be tricker to deal with, since i'm not sure how easy it is to see what the sample rate of a track is before you start playing it 18.22.50 Join [sko] [0] (~sko]@p57A98798.dip0.t-ipconnect.de) 18.30.07 Quit kevku (Remote host closed the connection) 18.37.32 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 18.38.48 Join _s1gma [0] (~d.d.derp@77.107.164.131) 18.38.55 Quit togetic (Ping timeout: 245 seconds) 18.39.30 # www.hpl.hp.com/techreports/2002/HPL-2002-159.pdf 18.39.38 # "fast" FIR based resampler on ARM 18.39.53 # although at 13 taps I'm not sure if its fast in the sense we think of :) 18.39.54 Join Jerom [0] (~jerome@95.171.137.111) 18.41.39 # looking online, a lot of arm stuff seems to use hermite splines for interpolation, which is basically just fitting a 3 order polynomial to the input data and then reading out the value at the output sample positions 18.43.23 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 18.44.29 Join togetic [0] (~togetic@unaffiliated/ibuffy) 18.51.42 Join {phoenix} [0] (~dirk@p57AA5117.dip.t-dialin.net) 18.52.44 Quit sudoman () 18.58.27 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 18.58.29 Join crow [0] (~crowmo@chello080108001109.35.11.vie.surfer.at) 19.11.05 Quit yorick (Read error: Operation timed out) 19.13.08 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 19.13.18 Quit DerPapst (Quit: Leaving.) 19.13.30 Join yorick [0] (yorick@unaffiliated/yorick) 19.24.15 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 19.24.23 Join leachim6 [0] (~leachim6@rrcs-97-78-139-149.se.biz.rr.com) 19.24.27 # hey 19.24.35 # does USB mode work at all in rockbox on the Fuze2? 19.24.50 # like, wile using rockbox, can I plug in the cable to have it charge in the car? 19.24.53 # no data, just charging 19.25.13 Join Maggux [0] (~quassel@krlh-4d0350fa.pool.mediaWays.net) 19.27.40 # nevermind, I got my answer. 19.28.35 Quit bmbl (Quit: Bye!) 19.34.53 Join Horscht [0] (~Horscht@p4FD4EF13.dip.t-dialin.net) 19.34.53 Quit Horscht (Changing host) 19.34.53 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.38.28 Join Buschel [0] (~chatzilla@p54A3BBE7.dip.t-dialin.net) 19.40.09 # liar: you there? 19.45.29 Quit crow (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 19.47.36 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 19.48.04 Join crow [0] (~crowmo@chello080108001109.35.11.vie.surfer.at) 19.53.04 *** Saving seen data "./dancer.seen" 19.57.30 # liar: (for the logs) from your nano2g patch I understood that you own an LCD type (2) ILI9320. it would be great if you could test FS#11646. this patch was already verified on LCD type (7) and needs test on the LCD type that you own. 19.59.01 # seems that patch I was missing for my nano 2g :D 19.59.12 Quit Jerom (Ping timeout: 252 seconds) 20.01.16 # crow: do you own an nano2 2g with ILI9320 ? 20.02.27 Join hadoukenx [0] (83d2648b@gateway/web/freenode/ip.131.210.100.139) 20.08.34 # I've searched the forum and know that most accessories are unable to interact with rockbox, but is rockbox capable of interpreting input signals over its serial port currently? 20.09.08 # hadoukenx, that depends on the target 20.09.16 # the specific player I mean 20.09.17 # sorry, sansa specifically 20.09.27 # c200 or e200 series 20.09.56 # v2 for both 20.10.17 # I think we have don't even have a serial driver for the sansas 20.10.27 # Buschel hmm how to know that? 20.11.17 # I don't know if there is currently anything known about the protocol used for sansa accessories 20.11.29 Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) 20.12.49 Quit kevku (Client Quit) 20.12.50 # crow: just go to the debug menu, enter the battery debug screen's second screen (right-scrolling the nano's wheel) and there it is 20.12.52 # saratoga_ (and others): There's another problem wrt native 48kHz (and other sample rates) support: Not all targets can do that 20.13.42 # I.e. most targets can do several sample rates, but no target can do all 9 (or 12, if you allow up to 96kHz) standard rates 20.13.59 Join Jerom [0] (~jerome@ks27625.kimsufi.com) 20.14.25 # Most notably, coldfire can only do 11.025, 22.05, 44.1, 88.2 20.14.39 # So we still need a good resampler 20.15.35 Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) 20.15.48 # preglow wanted to look into this, as he asked for a recording of the iriver H1x0 OF resampling result for 48 -> 44.1 about 4 weeks ago 20.16.00 # Unfortunately he seems to have disappeared again :\ 20.16.58 Join wodz [0] (~wodz@chello087206240131.chello.pl) 20.18.58 Join DerPapst [0] (~Alexander@p5797CBDC.dip.t-dialin.net) 20.25.19 Quit leachim6 (Ping timeout: 255 seconds) 20.31.50 # he posted in the forum today or yesterday ;) 20.32.04 # but about recording for D2 20.33.50 # Buschel when i go to Debug Menu i see battery 4.104V ; 4.104-4.118V (5mV) 20.34.05 Join komputes [0] (~komputes@ubuntu/member/komputes) 20.34.05 # crow: now scroll to the right 20.34.18 # crow: you will see another screen with lots of text then 20.36.58 # Buschel yea i see that screen, which option do i am looking for 20.37.25 # crow: LCD type 20.38.56 # Buschel dont see that option. 20.39.02 # crow: must be either ILI9320 or LDS176 20.39.50 # Buschel LDS176 :) 20.40.12 # Buschel it was under Debug Menu> View HW info :) 20.40.30 # crow: good news for you, bad news for me... good = my patch will work for you, bad = still need a tester with the other type 20.40.59 # Buschel type: 1, (7) LDS176 20.41.14 # crow: really? damn, my memory (brain, not RAM ;-) is tricking me 20.41.34 # Buschel well i am with rockbox just fev daysso i will not see much on battery drain.. 20.42.00 Quit hadoukenx (Quit: Page closed) 20.43.16 # crow: with the patch your LCD should make this wheeeee sound anymore 20.43.34 # crow: of course "should _not_ make..." 20.48.05 Quit CGL (Remote host closed the connection) 20.52.41 # Buschel didnt sow that jet :) 20.57.22 # crow: then you're a lucky one :) 20.58.28 # Buschel well as i wrote, i have rockbox just fev days.. 20.58.31 Part Guest75106 ("Leaving.") 20.58.51 # installed with rockbox installed which picked up for my nano 2g latest rockbox version 21.07.13 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 21.13.54 Join webguest76 [0] (~56164ee6@giant.haxx.se) 21.15.10 Quit webguest76 (Client Quit) 21.24.32 Join kinky [0] (~kinky@brmn-4db711ea.pool.mediaWays.net) 21.24.38 # greetings 21.24.48 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 21.26.46 # I've installed the rockbox daily build (r28184-100929) about an hour ago, and now I realise that the sound output is "wobbering". Every 1-2 seconds, the sound is going down and high again, it's really annoying. On the OF, the problem is nonexistant. 21.27.30 # what device do you have 21.27.53 # saratoga_: a sandisk clip+ 21.28.07 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.28.14 Quit stripwax (Client Quit) 21.29.07 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.29.26 Quit stripwax (Client Quit) 21.33.48 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.37.43 # so, should I replace my .rockbox folder with an older version? maybe this one? : http://download.rockbox.org/daily/sansaclipplus/rockbox-sansaclipplus-20100927.zip 21.39.16 Quit togetic (Quit: WeeChat 0.3.0) 21.39.31 Quit anewuser () 21.40.02 # kinky: It'd be much more use to check recent changes to svn that affect your target/playback and revert to a build before any likely change happened 21.41.07 # The Daily builds are just whichever svn revision happens to be checked in each day at a certain time. i.e. they're not special. 21.42.18 # * gevaerts suggests waiting for a developer who's familiar with the clip+ 21.42.24 Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 21.42.33 # evilnick_B: I will look around a lil bit in the repo, regarding major changes 21.42.44 # got my clip+ just yesterday :o 21.46.54 Quit [sko] (Quit: Leaving.) 21.53.05 Quit stripwax (Ping timeout: 245 seconds) 21.53.08 *** Saving seen data "./dancer.seen" 21.55.34 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 22.00.59 # Are there anywhere more levels for Bubbles? or just the 7 22.04.06 # amiconn, can I assume the iRiver H3x0 OF resampling would be equivelent to the H1x0 OF resampling? 22.04.21 # I don't know 22.04.46 # The reason why preglow asked for the H1x0 output is that it can be recorded digitally 22.04.46 Join simonrvn_ [0] (simon@64.235.201.43) 22.04.53 # I could record a loop of the RMAA test sweeps as resampled by the H3x0 if that would be of any service. 22.04.58 # ahh 22.05.03 # * amiconn did this using his archos recorder and the wavrecord plugin 22.05.25 # As well as an optical->coax s/pdif converter 22.06.49 Join al4711 [0] (~al@ursaminor.bursik.net) 22.07.21 Quit al4711 (Client Quit) 22.07.50 Quit simonrvn (Ping timeout: 240 seconds) 22.07.50 Nick simonrvn_ is now known as simonrvn (simon@64.235.201.43) 22.07.52 Join al4711 [0] (~al@ursaminor.bursik.net) 22.09.28 # evilnick_B: took a look at the svn, nothing worth mentioning regarding my case there 22.09.54 # kinky: What does "wobbering" mean? 22.10.22 # evilnick_B: the sound-level falls and rises every 1-2 seconds 22.10.50 # but not on every song, just some of them 22.11.45 # well, I think I'll stay with this version until weekend and then try the newest one 22.11.53 # Is it the same songs each time? Or does one song sometimes do it and then sometimes not? 22.12.08 # Basically, can you rule out there being an error in those music files themselves? 22.12.10 # evilnick_B: happens on the same songs everytime 22.12.17 Quit Nausicaa (Read error: Connection reset by peer) 22.12.27 # evilnick_B: on the OF, the problem is nonexistant 22.12.39 # so it should be no file related issue 22.13.05 # Which codec is this? 22.13.06 # checked the same song on both RB and OF 22.13.10 # That doesn't matter. If you can find out what the affected files have in common then it'll help a developer to reproduce the issue and hopefully fix it 22.13.37 # And does it happen with different codecs? 22.13.41 # Today I wanted to install rockbox on my IPod Classic 6st Generation but the RockboxUtility told me that this device is not supported. I'am willing to help to run rockbox on this device. I have tried to find some hint in the faq where I can start, I hope you can give me a hint. Thanks 22.14.16 # al4711: check out the NewPort wiki page 22.15.11 # thanks 22.16.38 # al4711: possibly for the classic http://www.freemyipod.org/wiki/Main_Page can help, or the people in #freemyipod 22.16.55 # al4711: A word of warning, unless you have experience in coding/cracking encryption or a vast amount of spare time then it'll be an uphill struggle. 22.17.06 # Actually, it will be anyway even if you do have those skills 22.17.52 # evilnick_B: seems like they're all mp3's with variable bitrate, 128kbps (v1) 22.18.23 # Sorry, but I'am not sure if I understand you right evilnick_B. Do you mean the 6st Generation is in someway encrypted?! 22.18.55 # it was, but someone cracked the encryption a year or two ago 22.19.17 # Do you think it is possible to replace the current IPod SW with rockbox on this device? 22.19.29 # yes of course its possible 22.19.30 # Ah ok I will google for this issue 22.19.35 # ;-) 22.19.38 # Anything is possible, but it's a very difficult and time-consuming job 22.19.42 # did you read the wikipage? 22.19.55 # I'am started 22.20.08 # well stop wasting time 22.20.20 Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) 22.20.30 # kinky: Your best bet would be to post on the forum/bug-tracker and attach a file that doesn't work if at all possible 22.20.56 # or try one of the files in the sim 22.21.14 # evilnick_B: will do that tomorrow, need sleep now :o 22.21.15 # What do you mean?! 22.21.30 # what does who mean? 22.21.50 # I refer to 'saratoga_: well stop wasting time' 22.23.11 # stop wasting our time because you haven't bothered to read up on whats involved 22.24.41 # somewhat harsh 22.24.53 # Ok I have seen that it is a lot more then just write some code ;-( . You need also to dig into the HW. Thanks for the hint to the NewPort page I think I will follow your advise. 22.25.17 Quit esperegu (Read error: Connection reset by peer) 22.25.48 Part kinky 22.27.17 # somewhat more direct 22.27.25 # the less harsh version was less understandable 22.27.33 # ;) 22.27.35 # I'am sure there are some guys from time to time to want to port rockbox and after reading what does this means the knowledge or the time consuming the most guys quickly rethink about this idea 22.27.44 # now I'am one of this guys ;-) 22.27.52 # yeah someone does this every day or two 22.28.15 # I will try to find a device on which rockbox works stable. 22.29.25 # maybe there should be a new faq entry 'how can I port rockbox to my device' or something similar 22.29.38 # There is, it is the NewPort wiki page 22.30.05 # I have overread this point in the FAQ sorry 22.38.10 # New commit by 03wodz (r28185): fix bitmap scallers smooth_resize_bitmap() and simple_resize_bitmap() to properly handle LCD_STRIDEFORMAT == VERTICAL_STRIDE case 22.38.18 # New commit by 03wodz (r28186): imageviewer bmp - drop special case for grey bitmap scaller 22.39.51 # r28185 build result: All green 22.40.17 # thanks for the talk and rockbox. good luck. by aleks 22.41.37 # r28186 build result: 51 errors, 0 warnings (wodz committed) 22.41.48 # grrr 22.44.37 # all monochrome targets 22.44.52 Quit al4711 (Quit: Bye all ;-)) 22.45.01 # Maggux: I believe there are 99 or 100 levels in bubbles 22.45.49 # hmm but grep -rn _simple_resize_bitmap * gives me no hits 22.47.04 Join insp_ [0] (~chatzilla@customer-217.241.livas.lv) 22.47.15 # http://build.rockbox.org/shownewlog.cgi?rev=28186;type=mrobe100sim#prob1 says "apps/plugins/imageviewer/bmp/bmp.c:285: undefined reference to `simple_resize_bitmap'" without the _ 22.47.28 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 4.0b6/20100914073604]) 22.48.32 # http://build.rockbox.org/shownewlog.cgi?rev=28186;type=archosfmrecorder has _ 22.51.32 # interesting 22.51.37 # hmm I don't understand this error 22.52.16 # isn't the leading _ just part of the C ABI on some platforms? 22.53.04 # or in fact in the spec :) 22.54.52 # simple_resize_bitmap() seems to be within #if LCD_DEPTH > 1 22.55.40 Quit crow (Remote host closed the connection) 22.56.09 # wodz: moving that #endif up a bit makes things link 22.58.29 # It probably should still be tested then of course 22.59.30 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.59.33 Quit evilnick_B (Quit: Page closed) 23.00.04 # but look at http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/lib/pluginlib_bmp.c?r1=25843&r2=28185 23.00.21 # I don't change #if #endif order 23.03.42 # now I understand 23.03.57 # You removed grey_resize_bitmap, so things now use simple_resize_bitmap 23.04.42 # yes but I changed simple_resize_bitmap to work in that case. I missed that it won't be compiled at all on monochrome 23.05.22 # yes 23.05.36 Quit stripwax (Ping timeout: 245 seconds) 23.06.27 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.06.57 # are the strncat and strncpy functions not implemented because you guys don't care about buffer overflow or you are doing it some other way ? 23.07.01 Quit GibbaTheHutt (Ping timeout: 276 seconds) 23.07.47 # It was felt that strlcat and strlcpy offer better semantics 23.08.17 # The difference may be subtle, but the l variants are often what people meant anyway 23.08.51 # If you want the n semantics, use memcpy 23.09.05 # New commit by 03wodz (r28187): fix red ... 23.10.15 # didn't know these functions exist, thanks. I feel like an idiot now :p 23.10.38 # They're not universally available 23.10.42 # r28187 build result: All green 23.11.26 # So people don't always know about them 23.12.06 Join GibbaTheHutt [0] (~moo@78-105-152-175.zone3.bethere.co.uk) 23.13.57 Quit stripwax (Ping timeout: 265 seconds) 23.17.29 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.25.38 Join clone4crw [0] (~calvin@97-86-227-168.dhcp.roch.mn.charter.com) 23.32.28 Quit Maggux (Remote host closed the connection) 23.32.52 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.10/20100914125854]) 23.33.43 Quit panni_ (Read error: Connection reset by peer) 23.33.49 # did sandisk ever contact anyone about a Fuze+? 23.34.04 Join panni_ [0] (hannes@ip-178-203-81-220.unitymediagroup.de) 23.43.57 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 23.48.00 Quit jgarvey (Quit: Leaving) 23.48.24 Quit domonoky (Read error: Connection reset by peer) 23.53.10 *** Saving seen data "./dancer.seen" 23.56.45 Quit bertrik (Quit: sleeo) 23.57.57 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net)