--- Log for 25.05.109 Server: jordan.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 16 hours ago 00.00.16 # gevaerts: obviously we can't "really" operate on the filesystem while running as a USB block device, but perhaps there could be a middle ground, of treating the filesystem as read-only, and updating any cached FS structures that are written to by the USB host 00.00.49 # Unhelpful: that would provide a pretty efficient cache, but is it really worth it? 00.00.51 # the benefit being that we might be able to identify file reads and pre-cache blocks before they're requested. 00.01.24 # ie, "host read the directory, then the first block of this file, and we know where the rest of the file is stored" 00.01.41 # If filesystems are reasonably defragmented, just getting the next chunk in advance will be good enough in 95% of cases 00.02.13 # a fat filesystem that's reasonably defragmented? ;) 00.02.28 # surely those exist :) 00.03.15 # * Unhelpful is certain they are purely theoretical ;) 00.03.50 # Seriously though, we're working with 64k blocks. I'd expect even a horribly fragmented fat filesystem to gain a lot from reading 64k in advance, Not as much as by knowing the FAT, but good enough 00.04.54 # actually, in the FAT case we can just use the FAT itself and ignore directories altogether. That will tell us where the next block is 00.04.57 # fair enough then. there is also the side effect that the dircache, if loaded into RAM, could be kept synced. 00.05.18 Quit kushalone (Client Quit) 00.05.19 # i thought the FAT itself was only used for files in the root 00.05.43 # isn't the FAT this huge linked list of blocks? 00.06.30 # I'm a bit afraid to make a horribly complicated thing that turns out to improve read speed (which almost nobody notices anyway) by 2% 00.07.46 Quit miepchen^schla () 00.08.00 # Also, I expect that pre-reading the wrong block from disk will actually make things slower 00.08.37 Quit amiconn (Nick collision from services.) 00.08.40 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 00.08.49 Quit pixelma (Nick collision from services.) 00.08.49 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 00.09.00 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 00.09.03 Quit HellDragon (Client Quit) 00.09.07 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 00.11.44 Join kushalone [0] (n=kushal@12.169.180.178) 00.13.32 Join MarcGuay [0] (n=chatzill@ip216-239-87-191.vif.net) 00.13.42 # JdGordon1: I think I found something accaptable for the splash issue 00.14.25 Join HellDragon [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 00.14.35 # kugel: I was wondering about the clock issues being discussed in the New Ports thread, are they important to getting the MMU working? 00.14.52 # saratoga: I don't know 00.15.25 # it seems like battery benchs aren't too important without MMU 00.15.29 # but probably, as we seem to be too fast after enabling mmu&caches. That won't get better with optimized frequencies 00.15.47 # i expect the relative importance of some of the bus clocks to change quite radically once the caches are on 00.17.26 # if FlynDice's find helds true and we can do mp3 @ 90MHz without caches or mmu, I'm wondering how urgent getting the caches to work is then 00.18.53 # thats on the clip? 00.19.09 # e200v2 iirc 00.19.41 # mp3 is almost entirely out of IRAM, so what hes probably doing is optimizing the IRAM access times 00.20.09 # he maxed the pclk 00.20.13 # that said I dislike the idea of running without the CPU caches, you're not supposed to do that 00.22.21 # which is the clock for peripherals (which includes the as3514 codec) IIUC 00.22.22 Join miepchen^schla [0] (n=miepel@p579ECD16.dip.t-dialin.net) 00.22.43 # saratoga: sure, I didn't want to say we shouldn't 00.23.38 Quit SirFunk (Read error: 110 (Connection timed out)) 00.24.00 Quit pixelma (Nick collision from services.) 00.24.00 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 00.24.07 Join Llorean1 [0] (n=DarkkOne@adsl-99-148-246-63.dsl.hstntx.sbcglobal.net) 00.24.18 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 00.25.10 Join faemir [0] (n=faemir@88-106-152-205.dynamic.dsl.as9105.com) 00.26.28 Quit archivator () 00.28.43 Quit MarcGuay_ (Read error: 110 (Connection timed out)) 00.30.35 Quit kushalone (Client Quit) 00.40.31 Quit Llorean (Read error: 110 (Connection timed out)) 00.55.03 Quit ender (" It's a good thing money can't buy happiness. We couldn't stand the commercials.") 00.56.41 Nick Llorean1 is now known as Llorean (n=DarkkOne@adsl-99-148-246-63.dsl.hstntx.sbcglobal.net) 00.56.46 Quit bertrik (Read error: 113 (No route to host)) 00.57.03 Quit DrMoos ("Rockbox rules the DAP world") 01.11.25 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 01.12.14 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 01.22.00 # svn is really crawling tonight 01.25.23 Quit barrywardell (Read error: 104 (Connection reset by peer)) 01.25.54 Join barrywardell [0] (n=barry@rockbox/developer/barrywardell) 01.28.05 # is doing % 2 on an int32 going to use a divide or a shift ? 01.28.09 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 01.35.13 *** Saving seen data "./dancer.seen" 01.40.22 # saratoga: It should just use an AND 01.41.34 # of course, thanks! 01.42.36 # New commit by 03saratoga (r21071): Commit FS#10234 - Spacerocks respawn invulnerability by Eric Clayton. Gives you a couple seconds of invulnerability after respawn. 01.43.33 Quit barrywardell (Remote closed the connection) 01.51.52 # x % 1, but gcc should be doing that for you 02.04.10 # you mean & ? 02.08.29 # ... of course. this appears to be a bad day for me. i'll go back to editing the scaler ;) 02.11.12 Quit HellDragon (Client Quit) 02.13.52 Quit jordan` (Read error: 104 (Connection reset by peer)) 02.14.02 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.14.59 Join jordan` [0] (i=gromit@78.235.252.137) 02.15.58 Quit jordan` (Read error: 104 (Connection reset by peer)) 02.17.18 Join jordan` [0] (i=gromit@78.235.252.137) 02.17.36 Quit jordan` (Read error: 54 (Connection reset by peer)) 02.18.49 Join jordan` [0] (i=gromit@78.235.252.137) 02.24.07 Quit jordan` (Read error: 104 (Connection reset by peer)) 02.30.37 Join HellDragon [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 02.32.52 Join jordan` [0] (i=gromit@78.235.252.137) 02.36.08 Quit Llorean ("Leaving.") 02.37.50 Quit efyx_ (Remote closed the connection) 02.40.04 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-6f523c5a36bea87f) 02.42.39 Quit HellDragon (Client Quit) 02.46.42 # New commit by 03saratoga (r21072): Forgot to add Eric Clayton to the CREDITS file for FS #10234. 03.11.37 Quit gevaerts (Nick collision from services.) 03.11.49 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 03.19.13 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 03.25.44 # JdGordon1: so, what was the reason to deactivate statusbars before loading a plugin? 03.30.19 Quit Thundercloud (Remote closed the connection) 03.35.17 *** Saving seen data "./dancer.seen" 03.38.23 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-d738135d6380d7b1) 03.50.02 # kugel: do we clock off of the internal 24MHz oscillator on AMS? 03.50.36 # I don't know 03.58.48 Join toffe82 [0] (n=chatzill@ip72-193-163-193.lv.lv.cox.net) 04.02.14 Quit kugel ("exit(0);") 04.17.54 Quit saratoga ("http://www.mibbit.com ajax IRC Client") 04.30.15 Join tmzt [0] (n=tmzt@adsl-99-164-62-86.dsl.akrnoh.sbcglobal.net) 04.34.38 Join secleinteer [0] (n=bend@70.230.163.149) 04.35.20 # hi, i found this (http://www.rockbox.org/mail/archive/rockbox-dev-archive-2008-06/0078.shtml) thread on the ml, and i was wondering if any progres has been made since on running rockbox on android 04.35.25 # anyone know? 04.40.31 # how would that even work? android is java-based, rockbox is c even the sdl version 04.40.32 Part toffe82 04.43.28 # until there's a native-code C API for android, it's unlikely that there will be a proper rockbox port 04.43.38 Quit miepchen^schla (Read error: 101 (Network is unreachable)) 04.44.12 # tmzt: well that message is from almost a year ago...maybe there have been some developments 04.44.14 # since android is not a single cpu 04.44.18 # i doubt that will happen 04.44.44 # or even a single archetchure 04.44.55 # its made to run with java, they dont care much about C apis methinks 04.46.28 # martian67: as long as there is a C compiler, a fair amount can be done without worrying much about CPU-specific details. gcc has libraries for supporting almost all C math/logic operations on CPUs that don't have instructions for them. 04.47.07 # is there a sdl pseudo-target for console linux? 04.47.20 # well of course, but that wouldnt be a port to android 04.47.34 # it would be a port to one or many of the platforms android runs on really 04.50.02 # tmzt: there are the SDL-based simulators. 04.50.22 # yes, but those are currently X or win32 based? 04.50.38 # martian67: i'm just saying, a C API is a real possibility, and it will be needed if CPU-intensive code is ever to be part of an application. 04.50.42 # I know there was the beginnings of an ezx port, using the simulator code I think 04.50.47 # tmzt: they are SDL based. 04.51.09 # is SDL used for audio as well? 04.51.31 # Unhelpful, mmh of course 04.53.10 # i don't know, but i can't imagine it would use anything else when it already depends on SDL for graphics and input... 04.53.59 # okay, I might try using that for some of the htc-linux projects which has a similar approach to ezx, it would save writing a lot of code for a media application 05.00.14 Quit AndyI (Read error: 110 (Connection timed out)) 05.07.21 # i don't know much about java; does it have support for calling c code, like python does? 05.07.27 Join lymeca [0] (n=lymeca@dsl-74-220-76-19.dhcp.cruzio.com) 05.07.35 # perhaps that could be used to port rockbox? 05.09.15 # moreover, android is oss, so it should be possible to create a 3rd party api 05.11.45 Join [TiZ] [0] (n=trent@FL-ESR1-72-49-150-188.fuse.net) 05.12.36 Part [TiZ] ("Leaving") 05.25.47 Join [TiZ] [0] (n=trent@FL-ESR1-72-49-150-188.fuse.net) 05.26.47 # <[TiZ]> Hi. I'm using Rockbox 3.2 on my 5th generation iPod, and I need disk mode. Built-in disk mode is not working, and the original firmware won't boot. Is there any way at all to activate Rockbox's disk mode in 3.2? 05.27.23 # No, there isn't because it just isn't even compiled in in 3.2. 05.27.48 # <[TiZ]> I see. Bummer. :( 05.28.56 # [TiZ]: use a current build. 05.29.39 # <[TiZ]> I intend to if I manage to get the iPod to connect to my computer somehow. 05.31.03 # You could try to get an adapter for the HDD, so you can connect it the your PC and install a current build that way. 05.32.17 # <[TiZ]> I suppose that is an option, for last resort. 05.34.56 # I think you may have a bigger problem if disk mode isn't working. 05.35.21 *** Saving seen data "./dancer.seen" 05.35.41 # <[TiZ]> I should hope it's restricted to the OF. Rockbox itself is working perfectly fine. 05.36.56 # But, (asking more knowledgable people here) isn't the OF separate from disk mode? 05.41.05 Nick JdGordon1 is now known as JdGordon (n=jonno@c-67-160-44-90.hsd1.wa.comcast.net) 05.47.49 Quit Horscht ("Verlassend") 05.55.12 Quit mirak ("Ex-Chat") 05.58.40 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 06.14.25 Join Llorean [0] (n=DarkkOne@adsl-99-148-246-63.dsl.hstntx.sbcglobal.net) 06.27.44 # * JdGordon has the proof-of-concept background WPS patch working 06.30.49 # I think as long as the WPS doesnt try to update the viewport where the UI is it should work pretty easily... 06.31.07 Quit [TiZ] ("Leaving") 06.34.06 # arg, the e200 cabbie wps doesnt use conditional viewports :? 06.34.23 # /?/////////// :p 06.35.27 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.43.58 # bah! why does my test .wps not work but cabbie does?! 06.50.44 # spite? 06.51.45 Join LinusN [0] (n=linus@gateway/web/cgi-irc/labb.contactor.se/x-e978c53419ae2615) 06.51.56 Part LinusN 06.52.03 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 06.59.27 # very possibly 06.59.49 # no, all the statis wps tags need a bit of work to get working correctly 07.18.34 Quit Rob2223 (Read error: 54 (Connection reset by peer)) 07.18.37 Join Rob2222 [0] (n=Miranda@p4FDCE6ED.dip.t-dialin.net) 07.19.22 Join renke [0] (n=renke@134.106.200.211) 07.30.06 Quit advcomp2019 (Read error: 104 (Connection reset by peer)) 07.30.28 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 07.35.24 *** Saving seen data "./dancer.seen" 07.36.20 Join matsl_ [0] (n=matsl@dhcp86.contactor.se) 07.39.49 Join Lss [0] (n=Lss@cm13.delta91.maxonline.com.sg) 07.40.10 Quit bubsy ("Mrrrrreow!") 07.48.46 Join Mathiasdm [0] (n=Mathias@vpnf142.ugent.be) 07.50.16 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 07.57.59 Quit BHSPitLappy ("Ex-Chat") 08.02.28 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.06.44 Quit Mathiasdm ("Yuuw!") 08.07.59 # Bagder: hi, unfortunately i have to stop providing the rbclient service from xen.ihme.org because that host will be moved to a new virtual machine. But maybe i could allocate a separate virtual machine for the rbclient after that :) 08.15.45 Quit jmillikin (Read error: 110 (Connection timed out)) 08.26.06 # ok 08.26.33 Quit Tristan (Remote closed the connection) 08.27.39 Quit bertrik (Read error: 60 (Operation timed out)) 08.29.55 Quit renke (Read error: 110 (Connection timed out)) 08.36.42 Join petur [50] (n=petur@rockbox/developer/petur) 08.36.54 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 08.37.23 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.37.24 Join Rob2223 [0] (n=Miranda@p4FDCE8A4.dip.t-dialin.net) 08.54.40 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.00.24 Join flydutch [0] (n=flydutch@host105-166-dynamic.8-87-r.retail.telecomitalia.it) 09.13.56 Quit Lss (Read error: 113 (No route to host)) 09.14.19 Join Lss [0] (n=Lss@cm13.delta91.maxonline.com.sg) 09.15.45 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 09.34.45 Join petur2 [50] (n=petur@rockbox/developer/petur) 09.35.25 *** Saving seen data "./dancer.seen" 09.39.41 Quit Rob2223 () 09.44.57 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 09.46.05 Join Rob2222 [0] (n=Miranda@p4FDCE8A4.dip.t-dialin.net) 09.52.18 Quit petur (Read error: 110 (Connection timed out)) 09.56.07 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 10.09.32 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 10.12.34 Join Sedgewick [0] (n=Sedgewic@81.200.132.126) 10.23.01 # http://grubbn.org/u/dn-desaku/wordpress/2009/05/24/rockbox-review-its-awesome/ 10.26.39 # Bagder: well, it *is* :) 10.26.53 # * Bagder thirds that 10.27.26 # the backdrop is out of place? 10.27.39 # I don't know what he means by that 10.28.31 # I think he just means it doesn't suit his taste 10.28.48 # probably, yes 11.02.06 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 11.11.31 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 11.35.28 *** Saving seen data "./dancer.seen" 11.38.17 Join mcuelenaere [0] (n=quassel@78-21-191-122.access.telenet.be) 11.38.39 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 11.41.44 Join mcuelenaere_ [0] (n=quassel@78-21-191-122.access.telenet.be) 11.42.25 Quit mcuelenaere (Read error: 60 (Operation timed out)) 11.42.44 Nick mcuelenaere_ is now known as mcuelenaere (n=quassel@rockbox/developer/mcuelenaere) 11.49.59 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.05.28 # Unhelpful: does something like http://pastie.org/488881 look good? 12.06.25 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 12.27.53 Join renke [0] (n=renke@134.106.200.158) 12.33.47 Join Vytenis [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 12.34.42 Quit Vytenis (Client Quit) 12.34.59 Join VytenisS [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 12.35.19 # New commit by 03funman (r21073): mkamsboot: really error out if OF model is different from bootloader model ... 12.36.38 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 12.37.34 Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) 12.37.44 # Hello, I need a little help. When i generate .lng file with genlang ant choose clip as the target the language file wont work on player, when chossen it's not accepted and gets reset to the previous language, but for example if i choose e200 as a target and place the .lng file on my clip it will work, but however wont show language specific symbols 12.37.52 Join funman [0] (n=fun@rockbox/developer/funman) 12.46.54 Join FrankTM [0] (n=frank@212-182-153-12.ip.telfort.nl) 12.57.20 Join Horscht [0] (i=d53dbb62@gateway/web/ajax/mibbit.com/x-2c0ed6ba9b2497c6) 12.57.39 # hello 13.12.30 # New commit by 03mcuelenaere (r21074): * read_bmp_*(): add FORMAT_RETURN_SIZE ... 13.14.14 # !seen atz 13.17.45 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 13.18.25 Quit einhirn (Read error: 54 (Connection reset by peer)) 13.18.49 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 13.28.52 # breakage... 13.29.09 # mcuelenaere: lua.rock doesn't link for crosscompiled win32 sims... 13.29.37 # Tons of "undefined reference to `_errno'" 13.31.37 # would it need something like mingw? 13.33.31 # amiconn: since last commit or even before? 13.33.53 # I have no idea what it did before. Didn't build rockbox for some time... 13.33.59 Join Casainho [0] (n=chatzill@bl11-203-136.dsl.telepac.pt) 13.35.32 *** Saving seen data "./dancer.seen" 13.42.48 # hmm is http://www.rockbox.org/twiki/bin/view/Main/UiSimulator#Building_Windows_sim_in_Linux up to date? 13.45.09 # I get '*** Your compiler (/usr/bin/colorgcc) does not produce Win32 executables!' upon configuring 13.45.17 # * mcuelenaere guesses colorgcc is messing up things 13.45.59 Quit HellDragon (Read error: 104 (Connection reset by peer)) 13.47.32 # mcuelenaere: Same problem exists on Cygwin 13.49.51 # http://pastebin.ca/1433826 (linux) 13.55.11 # amiconn: I'm able to reproduce them 13.57.50 # hmm rockpaint seems to also user errno, but ifdef's them out for simulators and mingw 13.58.04 # err #if !defined(SIMULATOR) || defined(__MINGW32__) || defined(__CYGWIN__) 14.00.15 # New commit by 03mcuelenaere (r21075): Fix mingw & cygwin builds 14.02.16 Quit Horscht ("http://www.mibbit.com ajax IRC Client") 14.02.20 # http://forums.rockbox.org/index.php?action=dlattach;topic=14064.0;attach=3694;image : does the very fast battery drop indicate wrong battery levels ? 14.08.03 # does anyone know how to determine weather i have a sansa fuze v1 or v2 14.08.28 # FrankTM you check the firmware version. 14.09.57 # is it that simple :P 14.10.44 # it is. i mean, you could open it up too if you like. either way. 14.10.44 # 1.02.26 14.10.53 # that's a v1 fuze, then 14.11.26 # thanks 14.18.17 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 14.19.28 # Anyone know why clip is'nt showing any symbols that is not in the english alphabet ? For example if i chose russian language that it wont show even a word, just everything black 14.20.15 # VytenisS: you probably don't use an unicode font 14.20.35 # maybe 14.21.19 # yup, you are right 14.21.21 # thanks 14.22.25 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.22.42 # One more question, why clip wont load a .lng file that i generated with genlang with clip as a target, but will load if i choose e200 as a target ? 14.23.54 # very good question 14.23.58 # that sounds... weird 14.24.18 # VytenisS: did you run a diff between the files ? also with the .lng generated in normal clip build ? 14.24.55 # diff between the files ? I am quite new at this 14.26.03 # funman: hey 14.26.04 # VytenisS: you can do like that: xxd file1.lng > file1.txt ; xxd file2.lng > file2.txt ; diff -u file1.txt file2.txt 14.26.22 # hi kugel :) 14.26.35 # funman: What's that number being written into CCU_SRC? 14.26.36 # ok will try that 14.27.04 # in system_init() 14.27.23 # kugel: devices to be reset mask : all devices but ROM, VIC, IRAM & DRAM (last 4 bits) 14.27.55 # CCU_SRC has only 16bits 14.28.51 # it has 24 for me (datasheet) and is defined as long in as3525.H 14.29.06 # huh? 14.29.32 # I have v1.13 of the DS, and it has 16bits 14.29.48 # 5882ac9c50e5a0e6b57b12042e56e63e AS3525_Datasheet_v1_13.pdf 14.30.08 # funman: I can't build .lng file with the normal clip build only with genlang. When compiling it shows: make: *** No rule to make target `/home/vytenis/rockbox/rockbox/lithuanian/apps/lang/Lithuanian.lng', needed by `/home/vytenis/rockbox/rockbox/lithuanian/lang/max_language_size.h'. Stop. 14.30.11 # ah lol 14.30.30 # the other 8bits are on the other page 14.30.34 # ah i understand :) description starts at bit 16 on the 2nd page 14.30.49 # VytenisS: try make clean before ? 14.31.29 Quit funman ("leaving") 14.31.59 # the number is still more than 24bit, isn't it? 14.32.25 # shows the same error after make clean 14.34.52 # have you added the lang to SOURCES? 14.34.59 # apps/lang/SOURCES I mean 14.35.04 # Yes I did 14.36.13 # Well found mine mistake, i wrote Lithuanian with capital in the SOURCES 14.37.26 Quit tvelocity (Read error: 104 (Connection reset by peer)) 14.51.13 Join AndyI [0] (i=AndyI@212.14.205.32) 14.53.19 Part secleinteer 14.56.18 Quit jfc (Read error: 54 (Connection reset by peer)) 15.00.58 Quit renke (Read error: 110 (Connection timed out)) 15.03.29 Join Mathiasdm [0] (n=Mathias@vpnb179.ugent.be) 15.06.08 Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) 15.14.50 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 15.15.00 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-fc577a588297eb4a) 15.17.50 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 15.18.52 Quit Sedgewick (Connection timed out) 15.22.20 Quit kugel (Read error: 110 (Connection timed out)) 15.22.53 Join Mathiasdm2 [0] (n=Mathias@vpnk138.ugent.be) 15.33.00 Join {phoenix} [0] (n=dirk@p54B47316.dip.t-dialin.net) 15.33.13 Quit Mathiasdm2 ("Yuuw!") 15.34.24 Quit Mathiasdm (Read error: 110 (Connection timed out)) 15.35.34 *** Saving seen data "./dancer.seen" 15.52.19 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 15.56.34 Join kugel [0] (n=kugel@rockbox/developer/kugel) 15.57.45 Join n1s [0] (n=n1s@rockbox/developer/n1s) 16.00.57 Quit Casainho ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 16.15.01 # amiconn: as it happens, i was reading the wrong programmer's manual, since addi is not an sh-1 instruction. what i was doing was reformulating the 32x32->top32 multiply a bit, so that it includes a rounding add, and based on the assumption that the top 24 bits are always zero and are discarded. 16.15.26 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 16.16.15 # what i ended up with was this: http://pastie.org/489034 16.17.01 # Just curious... who was working on the majority of the GoGear ports? Was it lowlight? 16.18.49 Quit Thundercloud (Remote closed the connection) 16.19.25 Join funman [0] (n=fun@rockbox/developer/funman) 16.20.48 # mcuelenaere: that looks good, i would amend it to this, though: http://pastie.org/489036 16.21.20 # New commit by 03mcuelenaere (r21076): Lua: port viewports + add test_viewports.lua 16.21.26 # then you can get the size needed to load the image at the desired size, do the load, and realloc down when you get the actual image size 16.22.53 # problem is: I'm not sure how to realloc Lua data.. (if that's even possible) 16.24.07 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 16.24.20 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-d64766338a5b96be) 16.25.36 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 16.26.33 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.29.01 # mcuelenaere: you have a lua_malloc... that basically turns an malloc allocation into a garbage-collected lua one? 16.29.57 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-3f464ae6ba7f88f3) 16.30.09 # Unhelpful: sort of, it turns a malloc() allocation into a garbage-collected lua variable of type userdata 16.30.39 # I could look in the internals for another lua_malloc() though, there's probably some way to realloc() somewhere 16.30.49 # could your image loader get the size-to-load, malloc that, do the load, realloc down, and then lua_malloc that? 16.30.52 Quit Horscht (Read error: 104 (Connection reset by peer)) 16.31.45 Join tchan1 [0] (n=tchan@c-67-173-9-133.hsd1.il.comcast.net) 16.32.12 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.32.54 Part LinusN 16.33.25 # hmm there's no API for that, but it's possible 16.33.53 Quit tchan1 (Client Quit) 16.34.25 Join tchan1 [0] (n=tchan@c-67-173-9-133.hsd1.il.comcast.net) 16.35.11 # it looks like your malloc lib has a realloc, so that could certainly work. and the realloc shouldn't be able to fail, since it's always going to be smaller than the original allocation. 16.36.36 Quit tchan (Nick collision from services.) 16.36.41 Nick tchan1 is now known as tchan (n=tchan@c-67-173-9-133.hsd1.il.comcast.net) 16.36.47 Join Blue_Dude [0] (n=chatzill@adsl-235-206-15.mco.bellsouth.net) 16.36.53 Part Blue_Dude 16.37.48 # yes the malloc lib has, but Lua wouldn't know the buffer has been resized though 16.38.18 # it would be easier to 'wrap' a buffer into a Lua object, but I can't really see how to do that 16.38.34 # unless I take care myself of the GC 16.38.46 Quit Horscht (Read error: 104 (Connection reset by peer)) 16.38.52 Quit barrywardell (Read error: 104 (Connection reset by peer)) 16.39.05 # hrm, so the lua_malloc calls malloc itself? 16.39.09 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.39.37 # does it matter that lua doesn't know it? 16.41.03 # hrm, good question - a bitmap should be treated as read-only data anyway. 16.41.57 # what if you want to make a paint-like app? 16.41.58 # if all lua does is keep track of it to free() it when it's not used anymore, a realloc() halfway should not be a problem 16.42.18 # hmm yes but it also keeps hold of its size 16.43.51 Join saratoga [0] (i=9803c6dd@gateway/web/ajax/mibbit.com/x-a5977941214bdb23) 16.44.41 Quit funman ("leaving") 16.44.42 Quit Horscht (Read error: 104 (Connection reset by peer)) 16.45.41 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.45.46 # I'm not sure whether that impacts some sort of memory usage calculation 16.45.57 # Unhelpful: currently it isn't.. 16.46.17 # and I don't see why it should? 16.49.13 Quit Horscht (Client Quit) 16.50.58 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.52.35 Quit Horscht (Read error: 104 (Connection reset by peer)) 16.53.06 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 16.53.50 # hrm, i guess you could treat it as writable. in that case you need to handle the size correctly. i don't really see somebody rewriting rockpaint in lua, though. ;) 16.55.06 # Unhelpful: a Lua image is always an object containing height, width & a pointer to the data 16.55.20 # users can never write directly to the data without passing a boundary check 16.55.36 # a boundary check on the coordinates? 16.55.43 # yes 16.57.00 # * kugel wonders whether lua scripts could be auto-run 16.57.01 # New commit by 03mcuelenaere (r21077): Fix some typos 16.57.22 # so I could make me a nice welcome screen :) 16.57.41 # kugel: it could yes :) 16.57.42 # if the user always has to address the image via coordinates, after a boundary check, and the length is never needed for one, it seems to me like you can safely resize the data after load. 16.58.08 # are there C functions for that? 16.58.18 # * mcuelenaere wouldn't want to resize an image in Lua 16.58.39 # you'd have to do a boundary check for every pixel.. 16.59.25 # no no, i mean to resize the allocation. the loader resizes the data :) 17.00.26 # it seems to me as if the boundary check on the coordinates would protect from writes past the end of the buffer. lua shouldn't need to know the buffer size for anything else. 17.01.08 # hmm yes, but lua doesn't really handle the boundary checks; my wrapper does this 17.01.42 Quit Zagor ("Don't panic") 17.02.02 # perhaps I should've said 'a Rockbox Lua image' 17.02.35 # this may be a stupid question :) 17.02.39 # what it UMS-mode? 17.02.53 # universal mass storage 17.03.06 # kugel: no :) 17.03.14 # usb mass storage. Also known as msc 17.03.30 # ah. i'm wondering how to get my fuse into that mode: P 17.03.57 # gevaerts: but the U in usb stands for universial? :) 17.04.21 # kugel: (pedantic mode) No, it doesn't ;) 17.15.36 Quit matsl_ (Read error: 110 (Connection timed out)) 17.19.30 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.19.37 # New commit by 03mcuelenaere (r21078): Fix FORMAT_RETURN_SIZE in read_bmp_*() when scaling (thanks to Andrew Mahone) 17.20.06 # Unhelpful: regarding IMDCT, I got a reply from Loren over at ffmpeg saying that the MDCT is symmetric and thus we don't need to compute the whole thing 17.20.21 # which reminded me of this blog entry i'd read ages ago: http://guru.multimedia.cx/mdct/ 17.23.44 Quit kugel (Read error: 110 (Connection timed out)) 17.35.35 *** Saving seen data "./dancer.seen" 17.37.22 Quit Lss (Read error: 104 (Connection reset by peer)) 17.37.45 Join Lss [0] (n=Lss@cm13.delta91.maxonline.com.sg) 17.38.56 Quit Lss (Read error: 104 (Connection reset by peer)) 17.42.47 Quit Horscht (Read error: 104 (Connection reset by peer)) 17.43.38 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 17.46.15 Join salty-horse [0] (n=ori@bzq-79-177-132-117.red.bezeqint.net) 17.46.26 Join renke [0] (n=renke@e177184185.adsl.alicedsl.de) 17.46.36 # yo. recompiled rockbox. unzipped to device. getting "incompatible version" error when starting plugins. why? 17.47.01 Join Lss [0] (i=Lss@cm163.delta95.maxonline.com.sg) 17.47.08 # That usually happens if you didn't overwrite the plugin directory 17.49.35 # I did the regular "make unzip and unzip on device" method :) 17.50.06 # make unzip? 17.50.50 # well, try to make clean rebuild and make zip and unzip again. Also make sure to safely remove/unmount the dap befor pullign the cable 17.51.49 # n1s, "make zip" 17.51.50 # ok 17.52.32 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 17.52.48 Join Ubuntuxer [0] (n=johannes@dslb-094-220-227-201.pools.arcor-ip.net) 17.53.35 Quit preglow (Remote closed the connection) 17.55.12 # what's pdbox? a new kind of music browser? 17.57.31 # i believe its the puredata gsoc project 17.58.36 # correct... 17.58.54 # its kind of a "music instrument" 17.59.30 # and wincents GSOC project. :-) 17.59.54 # n1s, I forgot to restart the device. the "should reboot?" prompt is too easy to skip without noticing 18.03.05 Join wincent [0] (n=wincent@host-091-097-048-211.ewe-ip-backbone.de) 18.03.12 # the text viewer isn't very intuitive. I thought "reflow lines" was supposed to wrap long lines, but instead it appears to remove newlines 18.03.44 # wincent, hi!. what's pdbox? (please don't use "puredata" to describe it since I don't know what that is from their website) 18.04.23 # "Sound environment" is imprecise too :-) 18.04.53 # It is a program that creates sound. 18.04.59 # music? 18.05.06 # Yes. 18.05.18 # you feed it patterns in various forms and set up channels and play them? 18.06.18 # You build synthesizer (or anything which works with sound) in a full-featured PD environment, and then you let pdbox play it on a DAP. 18.06.22 Quit petur ("work->home") 18.06.44 # wincent: I hope you'll write some documentation for it ;) 18.06.52 # nice 18.07.17 # I will! (I will have to :-) , that much I understood already) 18.08.20 # The documentation of the building process of Pure Data designs is what I intend to do after I delivered pdbox at the end of GSoC. 18.09.14 # sounds great! 18.10.30 Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) 18.11.29 Join tvelocity [0] (n=tony@adsl4-166.her.forthnet.gr) 18.14.00 # gevaerts: Couldn't you simulate bad sectors? 18.14.53 Quit LambdaCalculus37 ("gotta run!") 18.14.55 # linuxstb: I can, up to a point. I'd also like to compare behaviour with the OF 18.15.42 # Ah OK. 18.16.20 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 18.17.08 Join funman [0] (n=fun@rockbox/developer/funman) 18.20.56 Quit martian67 (Connection timed out) 18.21.19 Join SirFunk [0] (n=Sir@208.15.25.145) 18.23.27 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-c29cf2db614bd73b) 18.25.32 Join Riku [0] (n=Lss@cm13.delta91.maxonline.com.sg) 18.25.46 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 18.28.28 Quit Ubuntuxer ("Leaving.") 18.31.56 Join Rondom [0] (n=Rondom@dslb-084-057-179-009.pools.arcor-ip.net) 18.32.12 Quit funman ("leaving") 18.37.59 Join kugel [0] (n=kugel@rockbox/developer/kugel) 18.38.51 # kugel: hey, i took 8799 and made it work with the wps updating in the background... sort of :) 18.39.30 # ah, interesting 18.40.13 # except right now only the dynamic tags get updated 18.40.20 Quit SirFunk (Read error: 110 (Connection timed out)) 18.40.20 # and actually, my text wps doesnt work at all :p 18.40.44 # JdGordon: What I planned for the splashes for is to add a one-shot event at each splash(0,...), then the caller must send the cleanup event (the callback will just update the screen [not clear]) 18.41.22 # yeah, that could work... i still dont think its really needed 18.41.52 # I really don't want dead splash parts on the screen 18.43.58 Quit Lss (Read error: 110 (Connection timed out)) 18.44.33 Join _Auron_ [0] (n=DarkAuro@ppp-70-242-123-180.dsl.rcsntx.swbell.net) 18.45.32 # anyway, the ncie thing about the wps thing was its a 5 line addition to your patch :) 18.45.42 # + a bit more to actually make it work 18.46.17 # the question is.. do we want to keep the current statusbar stuff around? we can just about make it in the wps anyway 18.46.41 # I don't care 18.46.58 # amiconn, here? 18.47.01 # did you read my questions about the statusbar stuff in SVN? 18.47.23 # no? 18.49.29 # Why is the statusbar disabled when entering plugins. also, it seems to get re-enabled twice 18.49.39 # after exiting 18.51.34 # because of the whole viewport change thing... 99% of plugins expect the have the full screen, the statusbar got in the way 18.52.16 # I think we should change those 99% then to deactivate it explicitely 18.53.02 # sure, go for it.... 18.53.24 # but, though it's deactivated, a do_menu() with hide_bars = false will show the statusbar.. 18.55.00 Join bertrik [0] (n=bertrik@87.211.49.117) 18.55.37 # it gets activated there 18.56.05 # yes, but that seems weird to me 18.56.57 Quit MarcGuay (Read error: 104 (Connection reset by peer)) 19.00.04 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 19.05.16 Quit dmb (Read error: 104 (Connection reset by peer)) 19.08.51 Join dmb [0] (n=dmb@unaffiliated/dmb) 19.10.13 Join Ubuntuxer [0] (n=johannes@dslb-094-220-227-201.pools.arcor-ip.net) 19.11.44 Quit VytenisS ("Quit") 19.19.14 Join fyre^OS [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 19.19.54 # saratoga: quite a bit of that is over my head :/ 19.22.03 Join miepchen^schla [0] (n=miepel@p579ECC76.dip.t-dialin.net) 19.25.13 # gevaerts: i just tried with a friends ipod video, and that works fine as a hid device, but my nano doesn't 19.27.20 # Unhelpful: I'm pretty sure our IMDCT already exploits that symmetry, but we can probably improve it by removing the symmetric coefficient calculation to the windowing code, which would save several loads and stores per sample 19.27.26 # and of course a good deal of memory 19.28.35 # ok... i see that the MDCT doesn't seem to have a DC value (ie a constant basis function)? 19.30.25 # Unhelpful: yes because of that factor of 1/2 added to the frequency 19.31.02 # i assume thats to prevent the transform from being even about 0 but i don't know 19.33.03 # there's an optimization specific to fixed-point implementations that involves the DC coefficient. i saw it in the 16-point expanded IDCT, and copied it to the other IDCT sizes for core jpeg. plugin jpeg still doesn't have it, and i'm trying to figure out if the mpeg plugin does, but that has an entirely different IDCT implementation 19.34.12 # and obviously it doesn't apply to MDCT... 19.34.14 # figuring out what different DCT related transforms do compared to one another is astonishingly complicated 19.34.36 # you would think understanding the transform would make understanding the implementation easier but that has not been the case in my experience 19.35.17 # hm 19.35.29 # saratoga: I have mp3 @ 80Mhz 19.35.29 Join BryanJacobs [0] (n=BryanJac@www.q3q.us) 19.35.31 # on the fuze 19.35.36 *** Saving seen data "./dancer.seen" 19.35.59 # nice 19.36.06 Quit fyrestorm (Read error: 110 (Connection timed out)) 19.36.09 # the datasheet says that asynchronous clocking creates some sync overhead 19.36.24 # yeah you'd have to have at least one extra cycle of delay to sync the clocks 19.36.51 # I don't know whether this is going to be different with caches, but as of now it seems the 60 extra MHz cannot even it out 19.37.09 # you save 60MHz just by syncing the buses? 19.37.21 # more 19.37.39 # saratoga: there's *some* value added to the DC in our MPEG IDCT before any other math is done, but it doesn't seem to be a correct rounding factor. 19.37.41 # mp3 is @ 160MHz or so with 248MHz cpu and async 19.37.43 Join dp45349 [0] (n=621cc6c1@gateway/web/cgi-irc/labb.contactor.se/x-378cf74fe0814395) 19.37.58 # hello 19.38.01 # 248/31 cpu 19.38.04 # it maybe that theres some additional overhead when accessing the IRAM when async 19.38.13 # with cpu @ 192/64, mp3 is at 80MHz 19.38.34 # I'm fairly sure other codecs are faster too 19.38.38 # if i remember correctly the iram had some rather complicated clocking needed since its actually 1T DRAM, so maybe it doesn't like async 19.39.12 # the key seems to be the PCLK too, having it at 64MHz all the time gives much better performance overall 19.39.13 # nice to see some benchmarks in the forum thread :) 19.39.18 # quick question why hasn't case game been committed? is there something i can help with? 19.39.25 # we really need MMU working so we can see which of these bus changes actually matter :( 19.39.25 # the optimization in question adds the 1<<(shift-1) rounding factor to the DC coefficient before including it in the output, rather than adding a rounding factor to each output value before shifting them down to the output size 19.40.05 # saratoga: if it turns out that 248MHz but with async are never worth it, we can cap it to 192 and reduce the core voltage too 19.40.38 # if the codec i2c is really a problem to enable MMU and more advanced clocking, I'm in favour of a workaround. 19.40.39 # the next integer multiple is 256, which is slightly overclocked, I'm not sure whether it's possible to use that 19.41.14 # i'd be ok with almost anything to get MMU working in SVN, then try to fix things from there 19.41.32 # i remember with PP it was months and years before we had things like boosting and DMA working in SVN 19.42.12 Join petur [0] (n=peter@rockbox/developer/petur) 19.42.30 # I think we should do another bench to see if PCLK constantly at 64MHz has much impact, and if not change SVN to use the 192/64 combo 19.42.30 Quit dp45349 (Client Quit) 19.42.53 # if 192/64 works I would be ok with just using it for now 19.42.58 # if no bad impact, that is 19.43.00 # we can always power optimize things later 19.43.23 # the lcd is much faster with that pclk too 19.44.17 # i was getting 80fps for fullscreen update a few hours ago 19.44.52 # the as3525 datasheet has a set of clocking settings IIRC. Knowing and documenting the exact settings of the OF would be a good thing too IMO. 19.45.14 # iirc, what we have in SVN is what the OF does 19.45.48 # bertrik: the ds only lists some fastbus settings 19.46.00 # with fastbus we're limited to 65MHz IIRC 19.46.06 # hmm true, they are all fastbus 19.46.08 # IIUC* 19.46.15 # what is fastbus? 19.46.34 # FCLK = PCLK, mostly 19.46.54 # page 100 describes the 3 settings 19.49.26 # is that the same as running the bus synchronously? 19.51.08 # sync is another setting. fastbus means the bus clocks must be the same, sync means the cpu clock can(must actually) be higher than the ahb bus freq but must be a integer multiple, with async it doesn't have to be an integer multiple 19.52.14 Quit robin0800 (Remote closed the connection) 19.52.14 # ah ok so basically sync runs the cpu clock off a multiplied version of fclk, while fast bus runs the peripheral and fclk together 19.52.17 # if only this clocking business wasn't so flexible, the choice would've been much easier :| 19.52.43 # we could possible also use a sync setting with cpu 248/62, pclk 62 19.53.34 # Mikachu: can you submit a bug report? 19.53.51 # gevaerts: sure, do you know if it is working for anyone with a nano? 19.54.25 # lucky galeon remembered my password, i haven't logged into flyspray in 3 years or so :) 19.54.59 # no idea, but if it works normally otherwise, I don't see any reason why your nano should be different 19.55.16 # my bootloader is pretty old, but that shouldn't matter right? 19.55.44 # does usb work otherwise? 19.55.53 # yeah, i can transfer files fine 19.55.59 Quit mirak (Read error: 113 (No route to host)) 19.56.02 # and lsusb shows the hid endpoint 19.56.42 # then I don't really see how the bootloader could matter, no 19.57.33 # kugel, saratoga, I'll have a go at an codec i2c workaround soonish. THe problem seems to be that the i2c 'busy' bit doesn't get set immediately after starting a transfer, making the CPU think it's already done. 19.58.00 Join funman [0] (n=fun@rockbox/developer/funman) 19.58.18 # bertrik: so it just needs a little delay? 19.58.28 # bertrik: just adding a delay before busy check is enough 19.59.06 # * kugel overclocks his fuze 19.59.12 Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) 19.59.23 # the real problem is that the devices deadlock. at reproducable occasions though (the same timeframe of a given .mpg for example), especially when using pcm 19.59.34 Quit Ubuntuxer ("Leaving.") 19.59.47 # the OF uses a nice interrupt-driven i2c driver, but when doing a codec read/write, it *polls* until the nicely written interrupt-handled transfer is done. 20.00.01 # I saw on ABI that using crossfade apparently gives an immediate freeze as well 20.00.22 # why can I get 80MHz mp3 with 192/64, but not with 256/64? 20.00.28 # bertrik: you can try to patch the OF (from the bootloader!) 20.01.07 # ah there we go, it just needed some time :> 20.01.59 # how bad would it be to 'idle' at 64 MHz (instead of a lot slower)? 20.02.31 # for now its fine, but eventually we want to idle slower 20.02.32 # gevaerts: would you say it is "Drivers"? 20.02.53 # I don't think 62 or 31 makes much difference 20.02.54 # ideally unboosted should be ~25MHz on ARM9 20.03.08 # but for now losing a little battery life is hardly a pressing concern 20.03.37 # also, we don't have a idle state. If we run the pclk below 61 we get much slower decoding overall 20.04.02 # New commit by 03MarcGuay (r21079): Specify that the Battery Capacity setting is used for runtime estimation, not battery percentage remaining. 20.04.05 # Mikachu: close enough 20.04.06 # the beast shows that running at 250 or 500MHz all the time doesn't have much impact too 20.04.11 # linuxstb: ping 20.04.27 # though, that's arm11 20.05.02 # i think more advanced arm cores can internally adjust some of their clocks automatically 20.05.47 # and it's not really idling, but in a lower power 'wait-for-interrupt' state, right? 20.06.04 Join MarcGuay [0] (n=chatzill@ip216-239-87-191.vif.net) 20.06.24 Quit funman ("leaving") 20.06.49 # I wonder if we could run at 256MHz? 20.07.29 # I've not noticed a problem so far. And the chip has a anti-overheat mechanism 20.07.49 # bertrik: something like that 20.09.03 Join jmillikin [0] (n=jmilliki@c-24-130-227-85.hsd1.ca.comcast.net) 20.09.15 # if anyone wants to do codec development on a PC without using the simulator, http://www.q3q.us/harness.tar.bz2 contains a command-line utility that will just run your codec on an input file and produce a WAV as output 20.09.28 # and 256 is just 6MHz over specs (2,4%) 20.09.48 # it also ignores sleep() so you can run as quickly as your computer is capable of going - no real-time decoding 20.10.52 # BryanJacobs: "as quickly as your computer is capable of" in a single core then I guess? 20.10.59 Quit mirak (Read error: 113 (No route to host)) 20.11.11 # Bagder: yes, it pretends to be a single core, no threading right now 20.11.23 # is that a really important feature? 20.11.31 # nono, I was just curious 20.12.04 # I just meant that it won't pause for the timestamp to catch up with decoding progress 20.12.32 # I tested with the wavpack codec and the output is correct 20.12.54 # next step: port the correction-file handling to the wavpack codec 20.14.35 # gevaerts: http://www.rockbox.org/tracker/task/10242 20.15.30 # Thanks. I'll point tomers to it as soon as I see him 20.15.52 # i didn't see you or him in the assignee list 20.15.52 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 20.17.04 # hm, that list seems out of date 20.17.12 # it lists me :) 20.17.38 # exactly :) 20.18.10 Quit renke ("leaving") 20.18.39 # salty-horse: am now 20.19.09 # Bagder: What do you think - would it be a good idea if a few build servers would crosscompile win32 sims? 20.19.34 # probably 20.19.36 # There was this breakage of win32 sims today which didn't affect linux sims at all... 20.19.39 # hi amiconn. I'm wondering about the reflow feature of the text viewer. (I see that you committed something related to it ages ago) 20.19.53 # should it really join short lines into one line? is that what's it is supposed to do? 20.20.39 # It is supposed to join adjacent lines into one, and only leave paragraphs if there is an empty line inbetween 20.20.40 # "reflow" sounds to me like it ought to remove single line breaks, wrap long lines, and treat double line breaks as paragraph breaks 20.21.43 # reflow sounds like nothing to me 20.21.44 # amiconn, ok 20.21.54 # shouldn't be a separate feature to only wrap long lines? 20.21.56 # basically, converting text for a fixed line length to read nicely on the screen 20.23.06 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-014d6a2159b08bd4) 20.23.28 # :o 20.23.36 # bubbles is playable now on the fuze 20.23.52 # salty-horse: Iirc one of the line wrap options does that 20.24.23 # Bagder: Is it also possible to have a table that check if the manuals build? Right now it is quite hard to spot if they are broken. 20.24.55 # AlexP: yeah, I'd like that... is "just" for someone to do it... 20.24.57 # amiconn, can you tell me what option is that specifically? 20.25.11 # Bagder: hehe, as always :) 20.25.26 # yups 20.25.42 Join akpup420 [0] (n=puppy@pool-72-92-7-42.phlapa.east.verizon.net) 20.26.09 # Bagder: Problem is that this would make sim builds somewhat undeterministic 20.26.26 # amiconn: why? 20.26.39 # Because of how builds are distributed 20.26.51 # we'd create a new "arch" that does cross-compiled sims 20.27.04 # If some build servers are building linux sims and some are building win32 sim, reds would jump around 20.27.04 # as servers would need to be specificly marked to support that 20.27.13 # Hmm, you mean build every sim twice? 20.27.23 # no, I meant cc-sims to be a special build 20.27.31 # in its own column 20.27.38 # Right now the selection is automatic, based on which sdl-config is found by 'configure' 20.27.43 # more columns???? 20.27.45 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 20.27.48 # more columns! 20.28.10 # hello, i am looking at rockbox.org, i am thinking about trying it out, but idk if my nano is a first gen, how would i find this out? 20.28.24 # If you have native sdl-config first in the path, it will build linux sims, if you have migw32 sdl-config first, it will crosscompile win32 sims 20.28.43 Quit BryanJacobs ("null") 20.28.43 # saratoga: the fuze is incredibly responsive with my current setting 20.28.47 # Requirements are mingw32, and a crosscompiled sdl (which is simple) 20.28.48 # amiconn: well, I consider that a pretty shake way to do things anyway so I'd rather also change that 20.29.14 # Hmm, but how? 20.29.22 # akpup420: There is a page on the Apple website that should help you - I don't the address sorry. A google should also help 20.29.23 # The command is 'sdl-config' in both cases 20.29.36 # search for _all_ sdl-configs, then check which ones that seem to be for cross-compiling 20.29.49 # thanks alexp 20.29.54 # all in the path I mean 20.30.14 # akpup420: http://support.apple.com/kb/HT1353 20.30.20 # * amiconn wouldn't know how to do this 20.30.43 Quit flydutch ("/* empty */") 20.30.47 # why would that be tricky? 20.31.03 # surely the cross-compiled one has some properties we can cehck for? 20.32.54 Join BryanJacobs [0] (n=BryanJac@www.q3q.us) 20.33.24 # test_codec is weird! 20.33.48 # hm wait 20.34.20 Join biengo [0] (n=quassel@xdsl-213-196-243-204.netcologne.de) 20.35.11 # Bagder: Hmm, sdl-config --libs lists (among others) -lmingw32 20.35.23 # And -mwindows 20.35.34 # that looks like some nice strings to scan for 20.35.51 # iPod nano (4th generation) 20.36.24 # Hmm, but how to find all "sdl-config" in the path? 20.36.58 # akpup420: Bad luck 20.37.02 # findtool in the configure script already "walks" the path, it should just do something similar 20.37.41 # I wonder if checking crosscompiled sims will help fix those warnings... 20.38.08 # hmm 20.38.42 # pixelma: The -ffunction-sections one? I guess this isn't fixable in a sane way 20.38.55 Quit Xerion (Read error: 104 (Connection reset by peer)) 20.39.04 # I meant these 20.42.09 # hello 20.42.16 Quit saratoga ("http://www.mibbit.com ajax IRC Client") 20.42.38 Part akpup420 ("Leaving") 20.45.49 Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) 20.49.15 # mcuelenaere: hi. You could use lua_getfield() to simplify your code (check_tablevalue, instead of lua_pushstring and lua_gettable) 20.49.44 # hmm thanks 20.49.51 # is there also a shortcut for the lua_settable? 20.49.55 Quit Bombe (Read error: 60 (Operation timed out)) 20.50.04 # mcuelenaere: which lua_settable? 20.50.38 # the opposite of lua_gettable :p (it sets a value to a key in a table, e.g. tab['test'] = 42) 20.50.51 # lua_setfield 20.52.07 # btw, if you have the opportunity to borrow it at some library, you should check "Programming in Lua, Second Edition". It's really nice to grasp all the possibilities of lua 20.53.41 # you might also want to have a look at luaL_newmetatable( L, "typename" ) to initialize or fetch the type's meta table when needed 20.54.10 Join msscott [0] (n=chatzill@pool-71-113-37-217.sttlwa.dsl-w.verizon.net) 20.54.39 # dionoea: I think I use luaL_newmetatable() for struct rockboxlua_image 20.55.04 # ah right, you use it in the init. 20.55.21 # The way I use it most of the time is, in the object's constructor code: 20.55.44 # dionoea: does http://pastie.org/489243 look wrong? (can't get it working yet) 20.55.47 # if (luaL_newmetatable(L, "type")) { initialize to metatable; } lua_setmetatable(L,-2); 20.56.08 # that way you don't need a specific init function. (luaL_newmetatable() is like a lua_getmetatable() if it already exists) 20.56.26 # ah-ha, I finally found some info on the Wavpack algorithm itself: http://www.wavpack.com/WavPack.pdf 20.56.46 # hmm yes, currently being done in rli_new() & rli_alloc() 20.56.55 # s/currently/that's &/ 20.58.11 # mcuelenaere: looks fine. (but then that stack is always tricky) 20.59.05 # hmm it seems to work now 21.01.11 Join funman [0] (n=fun@rockbox/developer/funman) 21.01.22 # dionoea: hmm if lua_isnoneornil(L, -1) == true, does that mean a none/nil value is on stack? 21.01.50 # yes, it means that the top element is none or nil 21.02.02 # (if it's none that would mean that the stack is empty) 21.02.16 # hi funman 21.03.19 # mcuelenaere: is there rockbox specific code in anything besides rocklib.c ? 21.03.36 # dionoea: there is 21.03.48 # some code is commented out/removed and a little bit got added 21.03.57 # ok 21.04.07 Join p3tur [50] (n=petur@rockbox/developer/petur) 21.04.14 # but all the wrappers are in rocklib.c (currently) 21.04.37 # (except the dynamically generated ones, see actions.lua) 21.05.13 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 21.05.23 # docall() in rocklua.c could be simplified (using -1 instead of lua_gettop()) 21.05.32 Part taylor_ ("Leaving") 21.05.56 # New commit by 03mcuelenaere (r21080): Lua: re-use the viewport pointer; also use the shorter lua_getfield() & lua_setfield() notations (thanks Antoine Cellerier) 21.05.58 # so, test_codec says "126MHz needed for realtime" 21.06.09 # ah no, maybe not. 21.06.15 # but the buffering screen shows that it decodes at 80MHz??? 21.06.17 # dionoea: feel free to improve :) 21.06.42 # Ok, I'll commit anything I find then :) 21.07.16 Join saratoga [0] (i=98039dd8@gateway/web/ajax/mibbit.com/x-f738a9ce101d510a) 21.08.23 # who's right there? 21.08.24 # BryanJacobs: I sent you that link a week ago: http://www.rockbox.org/irc/log-20090519#21:06:18 21.08.46 # its from a book on data compression by the wavpack author 21.08.51 # Is there an install method for unkown player models? 21.09.07 # saratoga: must have missed it, sorry, reading now 21.09.17 # kugel: maybe the timer is wrong on AMS? 21.09.35 # that or the defines aren't right in the debug screen, which is probably more likely 21.09.48 # I don't think the debug screen is wrong 21.10.06 # it's mostly at 64MHz, only boosts sometimes shortly 21.10.13 # mcuelenaere: why aren't the math, io and os libs provided? to save on memory? 21.11.01 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 21.11.14 # (package would also be nice to share code between lua plugins) 21.11.45 # Could someone please delete http://forums.rockbox.org/index.php?topic=21767.0 for me? I didn't mean to double post it 21.12.22 # done 21.12.23 # either someone was really fast, or you didn't actually double post 21.12.42 # Wait, didn't double post 21.12.44 # Oops 21.13.10 # you need it undeleted? 21.13.23 Quit SirFunk (Remote closed the connection) 21.13.31 # though i think thats been discussed a lot before 21.13.36 # * Hillshum just reposted 21.14.18 # saratoga: and I think it should be done 21.15.42 # hi dionoea 21.16.41 # dionoea: mostly because they aren't compatible with Rockbox 21.16.49 Join SirFunk [0] (n=Sir@208.15.25.145) 21.16.52 # (ie no FP, not fully POSIX-compatible etc) 21.17.24 # feel free to implement them though :) 21.17.26 # mcuelenaere: ok. most of os, io and package should work though. I'll give it a try if I find some time 21.17.30 # (I've taken a short look at io) 21.18.06 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 21.19.10 # I guess that io.popen() is the only io function that couldn't be supported 21.19.48 Quit Rondom ("Ex-Chat") 21.20.00 # os.execute() and os.setlocale() (setlocale could be changed to a nop) 21.21.07 # yeah but io works with FILE*, and RB works with int's 21.22.12 # but FILE works too, doesn't it? 21.22.38 # ah ok. shouldn't be too complex to replace the FILE functions with fd ones :) 21.22.56 # kugel: does Rockbox has support for FILE? 21.24.06 # and as this Lua is fixed-point only, all math functions will need fixed-point ones (I've seen there exist some of them in pluginlib) 21.26.30 # what is lua useful for in rockbox? general scripting ? 21.26.52 # the maximum amount of sample history necessary for decoding a WavPack sample is the last 8 samples - just saying it here for history 21.27.31 # saratoga: something like that yes; easing the development of plugins/games I guess 21.28.09 # so it can draw to the screen? 21.28.31 Part BryanJacobs 21.28.40 # yes it can 21.28.56 # mcuelenaere: I'm not sure. I seem to remember use of it, but I can't find it anymore 21.28.58 # it's supposed to be able to do everything a normal plugin can do :) 21.29.12 Join VytenisS [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 21.29.25 # can you write lua scripts in the text_editor plugin and then run them? 21.29.30 # 21.30.10 # kugel: perhaps you mixed up with DIR*? 21.30.29 # Mikachu: if you really wanted to, you could yes 21.30.32 # perhaps 21.31.05 # * Hillshum considers text input on RB to be a bit slow for writing code on it 21.32.06 # if i finish 5165 it could be pretty quick :) 21.32.31 Join kugel_ [0] (n=kugel@e178118149.adsl.alicedsl.de) 21.32.41 Quit kugel (Nick collision from services.) 21.32.47 Nick kugel_ is now known as kugel (n=kugel@e178118149.adsl.alicedsl.de) 21.33.03 # * linuxstb has a habit of missing BryanJacobs... ;( 21.33.54 # http://git.mika.l3ib.org/?p=rockbox-svn.git;a=blob;f=apps/plugins/aaaatextinput.c;h=c28e42c788166 is how far i got btw :) 21.34.47 # Mikachu: Have you posted it to flyspray? 21.35.37 # Mikachu: what does that do? 21.35.39 *** Saving seen data "./dancer.seen" 21.36.20 # Hillshum: i have not 21.36.28 # kugel: it does the honeycomb thing mentioned in a comment 21.36.36 # here http://www.rockbox.org/tracker/5165 21.37.08 # Mikachu: can't you do drawline() with a helper function to reduce code duplicity? 21.37.20 # mcuelenaere: that is super ugly debug code 21.37.29 # still ;) 21.37.31 # from 3 years ago 21.37.58 # It might get more attention on flyspray 21.38.07 # than on my hd, yes :) 21.38.22 # i only just started looking at my old patch pile yesterday 21.38.43 # amazingly most of it worked without a lot of changes after 3 years 21.39.27 # i also like how i put h instead of u in row 5 21.39.34 Join BryanJacobs [0] (n=BryanJac@www.q3q.us) 21.40.16 # linuxstb: ^ 21.40.46 # BryanJacobs: linuxstb misses you 21.40.58 # Mikachu: ? 21.41.05 # 21:33:02 * linuxstb has a habit of missing BryanJacobs... ;( 21.41.29 # ah well, we'll catch up eventually 21.41.33 # BryanJacobs: Hi... 21.41.43 # my prediction came true! 21.41.44 # * Mikachu throws confetti 21.41.54 # * Mikachu predicts a possible anti-climax 21.42.22 # linuxstb: I got the harness working, you can now run whatever plugin you like as a standalone executable 21.42.29 # **codec 21.42.33 # not plugin 21.42.34 # I was just looking at your "harness", and wondering if you were planning on making it work with the existing files in-place, rather than copying everything into a new directory. I don't know if those files have been changed at all. 21.42.51 # linuxstb: the only files not changed were the wavpack ones 21.43.08 # and I figured since the codec is actively being developed, it's OK to work on it out-of-tree 21.43.10 # right? 21.43.51 # Doesn't that make it less useful in the long-term? 21.44.25 # I don't understand - could you explain the use case? 21.45.04 # kugel: would the hardest part be getting the screen to go sideways? 21.45.34 # rotating fonts, but that's already done in mpegplayer 21.46.21 # then getting the keymaps 21.47.20 # BryanJacobs: I mean it can be useful for general codec testing/hacking for any codec. It just seems more practical to be able to compile the existing rockbox files in-place, rather than needing to cp them. 21.47.34 # linuxstb: give me a minute 21.47.55 # symlinks? 21.48.27 # Mikachu: I don't think it'd be worth it to bother with them 21.49.16 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-d5cf130fb5378abe) 21.51.28 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 21.52.32 Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) 21.54.01 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 21.54.58 # linuxstb: now I get a "floating point exception" 21.55.09 # it compiled with the wavpack codec still in-tree though 21.56.25 # oops, it's because I didn't set the sample rate 21.56.27 # 21.58.37 # ok, all set: http://www.q3q.us/harness.tar.bz2 21.58.45 Quit robin0800 (Remote closed the connection) 21.59.46 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.02.56 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 22.04.34 # New commit by 03MarcGuay (r21081): Improve the c100 keymap and button names. 22.04.38 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 22.04.40 # BryanJacobs: That looks better. Could you post it to flyspray - I think it would be useful to commit (maybe not exactly in its current form, but something similar) 22.04.53 # linuxstb: doing cleanup / code style now 22.06.59 Quit SirFunk (Read error: 110 (Connection timed out)) 22.07.09 # Horscht: I think FS#10239 is now reasonably safe if you want to have a go 22.07.41 # Only test if you have backups though, I can't promise perfection 22.07.44 Quit biengo (Read error: 113 (No route to host)) 22.07.46 # mcuelenaere: See the red? 22.07.55 # Hi everyone! 22.08.18 # Mono issues, seems. 22.08.21 # MarcGuay: now I do 22.08.50 # BryanJacobs: Also, can you think of a more descriptive name than "harness"? 22.09.20 # linuxstb: idk - what should we call it, "thing which lets you run codecs as standalone executables"? 22.09.34 # codectester? 22.09.49 # Mikachu: it currently doesn't verify the output, but works for me 22.09.53 # your vote, linuxstb? 22.10.22 # or runcodec, testcodec 22.10.48 # codec-executer :-) 22.10.58 # domonky: I like that, functional naming is good 22.11.10 # let's be british and call it codec-executor 22.11.32 # codec-standaloner? 22.14.49 # funman: I'm going to do a 256/64 bench, I'm quite interested in the outcome 22.15.05 # New commit by 03mcuelenaere (r21082): Should fix red 22.15.09 # kugel: with the default&normal frequencies being? 22.15.19 # 64MHz 22.15.26 # fastbus? 22.15.38 # synchronous 22.16.10 # for synchronous cloking you must use a fclk higher than, and an integer multiple of, pclk 22.16.21 # what's the the default frequency for anyway? 22.16.23 # so 128MHz for 64MHz pclk 22.16.38 # default is for more power saving (usb mode?) 22.17.03 # more than normal? 22.17.25 # 64MHz fclk unboosted works so far, faster than what's in SVN 22.17.52 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 22.18.04 # switching to fastbus didn't get me anyway, all frequencies dropped horribly to 24MHz or something 22.18.10 # anywhere* 22.18.27 # ? 22.18.46 # kugel: 64MHz fclk with 64MHz pclk without fastbus is illegal 22.19.19 # it's in integer multiple :) 1x 22.19.46 # I read that it's illegal, but it seems to work. Also, SVN seems to be more illegal? 22.20.07 # as I said, I failed at switching to fastbus somehow 22.20.20 # yes, this is why i ran the benchmarks with the nice graphs, to make SVN legal :) 22.20.46 # kugel: I don't understand what "all frequencies dropping 24MHz" means 22.21.33 # I wanted to do 192/64 with pclk at 64 too, unboosting was just switching to fastbus 22.21.50 # but I didn't 64MHz, rather 24MHz (and it was horribly slow) 22.22.21 # funman: kugel: I've almost got a patch put together to make changing frequency schemes on the ams sansa a bit simpler, should I post it to flyspray or the forum do you think? 22.22.21 # http://pastie.org/489328 22.22.35 # flyspray 22.22.59 # kugel: _you_ didn't 64MHz ? 22.23.01 # OK let me tie it up should be 30 mins or so 22.23.16 # funman: I didn't get to* 22.24.14 # AHB freq = pclk? 22.24.22 # kugel: http://pastie.org/489331 here is the patch I used in my benchs 22.24.23 # yes 22.24.32 # AHB freq = APB freq = pclk on the Sansa AMS 22.24.45 # (i learned it from FlynDice :P ) 22.26.03 # http://www.rockbox.org/tracker/task/10243 22.28.47 # funman: that's the same for the unboosting part as what I did 22.29.46 Join tessarakt [0] (n=jens@e180076121.adsl.alicedsl.de) 22.30.55 # i see no performance loss with it 22.32.22 # BryanJacobs: that looks very useful 22.32.26 Join Bombe [0] (n=droden@freenet/developer/Bombe) 22.32.33 # will it work with any other codecs? 22.33.41 # saratoga: should work with any codec 22.34.02 # the biggest problem with using it is avoiding having to pull in half of Rockbox because of metadata parser dependencies 22.34.45 # but you can always just fake the metadata decode by hardcoding in the length and sample rate of the file you're using... 22.34.47 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 22.36.12 Join matsl_ [0] (n=matsl@82.182.85.76) 22.37.28 Quit funman ("leaving") 22.38.27 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 22.38.29 Join funman [0] (n=fun@rockbox/developer/funman) 22.39.30 # guests - bye all 22.40.01 Part BryanJacobs 22.41.22 # funman: I think I got it 22.41.39 # but it's slower, and playback stopped at the first rebuffer 22.42.50 Quit linuxstb (Remote closed the connection) 22.43.50 # hm, maybe not slower 22.44.42 # 10% boost rate 22.44.43 # playback stops for me with svn as well 22.44.51 # really? 22.44.56 # totally fine for me 22.45.10 # I made two battery benches without problems 22.46.16 Quit {phoenix} (Remote closed the connection) 22.46.17 Quit matsl_ (Read error: 104 (Connection reset by peer)) 22.46.37 # for me too, it seems to stop randomly 22.47.06 # it get some stops occasionally too 22.47.10 # I'm only getting stopping playback on my clip 22.47.22 # very much more frequent on the clip too .. 22.47.25 # never on my fuze (not on my previous one too) 22.47.42 Quit efyx_ (Read error: 54 (Connection reset by peer)) 22.47.52 # I had some aac's (IIRC) making some kind of bwwwooooAAAAAH noise sometimes 22.48.28 # wasn't that an issue with the codec? 22.48.37 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 22.49.00 Join efyx_ [0] (n=efyx@82.224.140.171) 22.49.43 # ok, rebuffering also works now again 22.50.21 Quit mcuelenaere (Remote closed the connection) 22.50.56 # funman: I've noticed that going to 62MHz pclk already makes decoding much slower again 22.51.16 # do you mean 64 -> 62 ? 22.51.19 # I think I needed 110MHz instead of 90Mhz which I got for 64Mhz 22.51.23 # yes 22.51.53 # do you have these results with test_codec 22.51.53 # ? 22.52.05 # test_codec seems unreliable 22.52.12 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 22.52.35 # that one told me that I was at 126MHz for realtime, while the bufferscreen says 80MHz 22.52.59 # i'm more encline to trust test_codec (didn't read bufferscreen code) 22.53.13 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 22.53.56 # well, the buffering screen just records the frequencies, and calculates avarage 22.54.25 # but that includes the cpu time for the frequent lcd updates, of course (but that actually means test_codec should tell me even less that 80Mhz) 22.55.19 # or that 126MHz mean something different than what the buffering screen shows 22.56.05 # but it's definitely hardly boosting, so 80MHz seem correct 22.57.12 Join Hillshum [0] (n=ubuntu@75-165-244-181.slkc.qwest.net) 22.59.15 Quit efyx_ (Remote closed the connection) 22.59.23 # kugel: have you changed firmware/export/config-fuze (or clip) ? I think the buffering screen uses the CPU_FREQ define in there rather then the one in the target tree 22.59.26 # but i could be mistaken 22.59.27 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 22.59.47 # I'm just about to upload this to FS, see what you think http://pastie.org/489364 23.00.06 # FlynDice: remove apps/plugins/SOURCES? 23.00.22 # say what? 23.00.39 # saratoga: they are in clock-target.h 23.00.53 # unless its just for testing then never mind 23.01.17 # saratoga: it uses CPUFREQ_MAX (which is not in config-fuze.h) 23.01.39 # FlynDice: and mmu-arm* :) 23.01.53 # well, on the other hand, it decods the file in 200% realtime. 23.02.16 Quit p3tur ("Zzzzz") 23.02.24 # ach yes I see it, mixed up with the mmu stuff, I tried to remove most of it 23.02.26 # does that directly translate to the MHz needed for realtime as in the calculation test_codec uses? (it does jsut CPU_FREQMAX / speed) 23.02.34 # independantly of CPU_FREQ_NORMAL? 23.04.16 Join matsl_ [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 23.04.29 # btw, are we using PLLB? if not, we can power it down 23.05.04 # kugel: try running without it? 23.05.18 # it's powered down already 23.05.25 Quit petur ("Zzzz too :)") 23.05.28 # where? 23.05.40 Join salty_horse [0] (n=ori@bzq-79-177-132-117.red.bezeqint.net) 23.06.00 Quit n1s ("Lämnar") 23.06.15 # not explicitely though - it's powered down at reset 23.06.57 # are you sure? I apparently missed that part when reading the ds 23.07.50 Join topbloke [0] (n=x@adsl-99-34-90-33.dsl.chcgil.sbcglobal.net) 23.08.46 # can you turn off the rockbox USB on ipod video? 23.09.12 # you mean you want to charge it without going to disk mode? 23.09.16 # just hold down menu when you plug it in 23.09.33 # ok 23.09.45 # it doesn't work on PS3 if you just plug it in when its off 23.10.03 # turn on the iPod first 23.10.31 # :) that works 23.10.40 # but with the old one you didn't have to! 23.10.48 # New commit by 03lowlight (r21083): 3 new ports: Samsung YH-820, YH-920, and YH-925. Mostly functional. Audio working on 820 & 925 (untested on the 920). No battery readings. No ... 23.10.54 # \o/ 23.11.00 # now that's a commit 23.11.02 Join Dauron [0] (n=DarkAuro@ppp-70-242-123-180.dsl.rcsntx.swbell.net) 23.11.19 # finally! 23.11.32 Join low_light [0] (i=ad58bb86@gateway/web/ajax/mibbit.com/x-d66812edd54cf72b) 23.11.38 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-fd9647e0371a44ac) 23.11.44 # low_light: <3 23.11.51 # low_light: nice one there 23.11.54 # nice entrance 23.12.12 # Bagder: 9 new builds to add ;) 23.12.19 # haha indeed 23.13.38 # * funman builds a yh920 rockbox 23.13.55 # * kugel builds for yh925(GS) 23.13.57 # test the usb. it works fine for me 23.14.14 # what's different with the GS version? 23.14.51 # kugel: you can verify that CGU_PLLBSUP == (1<<3) 23.15.21 Quit itcheg (Client Quit) 23.18.47 # low_light: I'm not sure, but that one is designed for canada 23.18.56 # the VID/PID are the same 23.21.15 Quit bmbl ("Woah!") 23.22.10 Quit salty-horse (Read error: 110 (Connection timed out)) 23.22.23 # the configure menu is getting impressive 23.22.32 # I mean the target selection 23.22.45 # and the build table 23.22.50 Join _fml [0] (n=4fd3c951@91.191.140.131) 23.23.01 # indeed 23.23.21 # <_fml> He-he. I see "HAVE_AK4537". Will we also have "HAVE_AK47"? 23.23.30 # \o/ 23.23.33 # sound works too 23.23.33 # what does the build system do with the builds it makes for unsupported targets? 23.23.50 # that's a secret :) 23.24.26 # they're not added to the download server 23.24.36 # well some are (beast) but most aren't 23.24.47 # ams sansa's are too 23.24.58 # ams sansa's are? 23.24.59 # I think all are 23.25.28 Join newbe [0] (n=4e3612d5@gateway/web/cgi-irc/labb.contactor.se/x-d340eb2c460a0744) 23.25.32 # yes 23.26.49 # well, it depends on what you mean with where they appear 23.26.49 Quit _Auron_ (Read error: 110 (Connection timed out)) 23.26.49 # gevaerts, thanks for the headsup 23.26.49 Nick Dauron is now known as _Auron_ (n=DarkAuro@ppp-70-242-123-180.dsl.rcsntx.swbell.net) 23.27.28 # I didn't find the time to test this out today. Depending on wether i have time tomorrow i'll give it a whirl 23.27.29 Quit newbe (Client Quit) 23.27.35 # a quick look at http://download.rockbox.org/daily/ says no 23.27.51 # they're sort of hidden 23.27.54 # right, the ones in daily/ are explicitly built daily 23.28.08 # that too :) 23.28.10 # the zips made in the distributed builds are differenet 23.28.29 # they can all be found if you craft the url a bit 23.29.27 Quit _fml ("CGI:IRC (EOF)") 23.30.31 # low_light: USB works now :) 23.31.19 # interesting. Might stop compiling then 23.33.34 Quit Nico_P (Remote closed the connection) 23.34.41 Quit martian67 (Remote closed the connection) 23.34.44 Quit Hillshum ("Ex-Chat") 23.35.11 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.35.16 # low_light: yellow... 23.35.37 Quit martian67 (Remote closed the connection) 23.35.41 *** Saving seen data "./dancer.seen" 23.36.05 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.36.33 # how did that warning pop up? 23.37.04 # tools rebuild? 23.37.12 # ah yes 23.38.34 # funman: The 920 sim uses the 925 image for now (they look almost identical). If you feel the need to change it you can. 23.39.39 # low_light: usb works fine now 23.39.45 # On a sad note, the microdrive in my 820 died. 23.39.56 # CF mod it, then? 23.40.02 # I have to see if it's the same as the mrobe100 or hdd1630 23.41.57 # not sound however .. causes deadlocks 23.42.46 # New commit by 03bagder (r21084): fix yellow by acknowledging the fread() return code and also allow ... 23.43.02 # funman: that's what happed to the 925 before I found the magic gpio bit. 23.43.20 # hum ok, i know what to do now ;) 23.43.44 # i suppose the OF bootloader doesn't used sound? 23.44.43 # funman: akcodec-yh82x_yh92x.c line 60. 23.45.07 # I looked and that bit was also set in the 920. 23.45.31 # 92205cb8e23724a802ceb24482cf6b96 fw_yh920.mi4 23.45.42 Quit BHSPitLappy (Remote closed the connection) 23.46.31 # The OF bootloader will have a sound test section. 23.47.28 # low_light: the key bindings for dir skipping are in the way :( 23.48.07 # we could remove them, you can also skip dirs by pressing, releasing, then holding |<< and >>| respectively 23.51.29 # New commit by 03bagder (r21085): Added: ... 23.51.30 # kugel: "Keymap needs work" ;) 23.51.44 # hence I'm already looking at it :) 23.51.53 # aha, the cia bot also announces www commits 23.53.16 # heh, i have cia for rockbox set up in another channel and it shows commits differently than here 23.53.33 # Mikachu: and later I bet ;-) 23.53.43 # actually the timestamp was identical 23.54.06 # this one runs in the post-commit hook on the svn server 23.54.44 # and I believe zagor modified the output 23.57.36 # and the backlight of the 925 is still overly weird!