--- Log for 29.08.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 8 hours ago 00.05.05 *** Saving seen data "./dancer.seen" 00.09.04 # has anything started to examine the clip zip firmware ? 00.14.06 # pamaury, yes 00.14.42 # who is doing that ? 00.14.47 # there is already a basic framework to build the bootloader (with stubs for the lcd/backlight driver and a guesswork implementation for the buttons) :D 00.15.11 # yes I know but it doesn't mean someone has really started to look for the differences :) 00.15.19 # So, now that that's solved, I actually have another issue, which, if fixed, will mean I can use Rockbox on my nano. The issue is that when I first start up Rockbox after installation. (This was on a 2nd and 1st gen) The database initialization screws up, and says I have 443 tracks in my database. (When I have zero.) When I try and "Play" a track on the 2nd gen (Which did have tracks) I get an error message with what I can only assum 00.16.06 # But basically we are sure that it's the same soc right ? 00.16.17 # I am looking at the OF and trying to implement an LCD driver now, saratoga is also looking at the OF 00.16.26 # sure enough 00.16.51 # the codec registers and pmu registers seem to match at least 00.16.53 # Clip zip? Did Sanza put out a new media player? 00.17.03 # and it has the same amount of memory as the clip+ 00.17.15 # a lot of the GPIOs even seem to match up 00.17.22 # nice, I hope there will be no nasty differences that will bite us :) 00.17.49 # I think I'll buy one as soon as it becomes available for sale in the EU 00.17.54 # The screen of the clip zip is nice 00.18.09 # I'm tempted to buy one now ^^ 00.18.48 # pamaury, not so sure, in the pictures in the abi review thread, it appears to have some crosstalk, but I'm not seeing that in other reviews and it could just be an artifact of photography 00.18.59 Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se) 00.19.14 # the OF is already prepared to accept two different kinds of LCD by the way 00.19.28 # evildaemon: the number shown by the database initialisation is the number of *files*, not audio tracks. Also, there's a bug that makes the initialisation fail (or at least do interesting things) if it finds no audio tracks at all 00.20.14 # pamaury, the tricky and dangerous part in my opinion is to get our dualboot code working 00.20.31 # Thank you for clarifying the first part. 00.20.36 # yes, the amsv2 bootloader is f a tricky part 00.20.37 # Explains a great deal. 00.21.08 # But, I still had this problem even when I had tracks on the pod? 00.21.20 # evildaemon: you also got cut off at "message with what I can only assum". IRC does have a line length limit 00.21.20 # in contrast to the clip+, the clip zip again uses a 2x3 key scan matrix for some of the buttons 00.21.47 # "assume to be an ARM assembly op code." 00.22.42 # pamaury, I did already prepare mkamsboot to patch the OF with our bootloader, the missing thing is the dualboot part 00.23.13 # I wonder if the usb part is the same, same part => same problems :( 00.23.21 # Our amsinfo tool parsed the OF without any problem by the way :) 00.24.05 # Did you also disassembled the clipv2/+ os ? Can you tell if it's the same or it is really different ? 00.24.24 # (I'm interested in the usb part of course) 00.25.25 # I haven't looked at the usb part yet, mostly buttons, radio and lcd so far 00.25.40 # evildaemon: right. If you get that sort of thing with a current build (or the latest release), we wouldn't mind a bug report with as many details as you have. It's probably a good idea to check the filesystem for errors first though 00.26.47 # The 2nd gen's filesystem was screwed, haven't tried the first gen yet. 00.27.40 # 1st gen works. *shrug* 00.27.52 # If you have filesystem corruption, we won't even try to promise correct playback... 00.27.58 # Lol. 00.28.01 # Duh. 00.28.20 # Ideally we'd handle that better, but that's not too easy 00.28.23 # I just assumed that the database thing was indicative of the same problem. 00.28.45 # But it's not, so I'm happy. 00.28.48 # Thanks guys. 00.29.34 # We'd like that one to be fixed too of course, but not that many people understand the database code well enough to fix it while being confident nothing else breaks... 00.29.58 # As long as this thing can play .ogg/.flac now, it was worth the trouble. 00.29.59 # bertrik: ok, tell me if you see something related to usb :) 00.30.18 Quit simonlnu (Ping timeout: 260 seconds) 00.31.04 # I can look for stuff using a specific base address 00.31.34 # Try to have a look at the same one has in the clip+ 00.32.07 # nope, there's nothing referencing 0xc6000000 in the main firmware block 00.32.39 # in the clip+ OF there are just a few lines, all the rest is done via a base pointer so it's hard to follow 00.33.01 # I seem to remember the entry point was in the dbop handler or something similar 00.38.05 Quit ChickeNES (Quit: Computer has gone to sleep.) 00.38.37 Quit ender` (Quit: Why shouldn't truth be stranger than fiction? Fiction, after all, has to make sense. -- Mark Twain) 00.38.57 Quit pamaury (Remote host closed the connection) 00.40.29 Quit bertrik (Quit: :tiuQ) 00.53.42 # New commit by 03jethead71 (r30373): codec_main() prototype inside codec_crt0.c is no longer needed since it's in codecs.h now. 00.55.57 # r30373 build result: All green 01.04.40 Join Galois [0] (djao@efnet-math.org) 01.12.13 Quit TheLemonMan (Quit: leaving) 01.14.06 Join TheLemonMan [0] (~giuseppe@ppp-83-10.26-151.libero.it) 01.14.06 Quit TheLemonMan (Client Quit) 01.14.26 Join TheLemonMan [0] (~giuseppe@ppp-83-10.26-151.libero.it) 01.18.47 # pamaury: just skimming the fuzev2 and clipzip usb_functio files, they're nearly identical 01.18.50 Quit neferty (Ping timeout: 252 seconds) 01.19.12 # the first half looks like they took the same precompiled binary and just relinked it (e.g. only the return addresses seem to be changed) 01.19.31 Join neferty [0] (~andor@173.242.127.201) 01.19.49 # the second half looks like they recompiled some of the functions with minor changes or an updated header or something as there are minor changes (different register numbers flipped around, etc) 01.22.48 Quit sideral (Quit: Leaving.) 01.23.03 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 01.41.06 Quit Zarggg_ (Quit: Rebooting client...) 01.42.34 Join ageis [0] (~ageis@c-76-127-201-198.hsd1.ma.comcast.net) 01.43.47 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 02.03.30 # [Saint]: it isnt only that the specific part of the manual is well written (I'm fairly sure most of the manual is), its also how discoverable the information actually is 02.04.30 # given it is so big, and we know people think its TL;DR, unless people actually read it cover to cover most info is completly ignored 02.05.10 *** Saving seen data "./dancer.seen" 02.05.11 # * JdGordon had to click through 3 links to find the section on config files just now 02.05.22 # and thats *knowing* where in the menu structre it lives 02.24.15 Quit jhMikeS (Read error: Connection reset by peer) 02.29.13 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 02.41.34 Quit TheLemonMan (Quit: leaving) 02.41.52 Join TheLemonMan [0] (~giuseppe@ppp-83-10.26-151.libero.it) 02.42.25 Quit TheLemonMan (Client Quit) 02.45.28 Quit MethoS- (Remote host closed the connection) 03.03.47 Quit kadoban (Ping timeout: 245 seconds) 03.24.14 Quit mgue (Ping timeout: 276 seconds) 03.25.17 Join mgue [0] (~mgue@p5DDA1787.dip.t-dialin.net) 03.47.33 Quit mgue (Ping timeout: 240 seconds) 03.49.08 Quit [Saint] (Ping timeout: 250 seconds) 03.50.15 Quit nick-p (Quit: Leaving) 03.58.51 Join [Saint] [0] (~st.lasciv@203.100.215.45) 04.05.12 *** Saving seen data "./dancer.seen" 04.06.36 Quit ageis (Ping timeout: 240 seconds) 04.06.59 Join ageis [0] (~ageis@c-76-127-201-198.hsd1.ma.comcast.net) 04.20.11 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 04.30.47 Quit amiconn (Disconnected by services) 04.30.48 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.30.48 Quit pixelma (Disconnected by services) 04.30.50 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.30.52 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.31.08 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.43.26 Join Blue_Dude [0] (~chatzilla@adsl-74-235-206-237.mco.bellsouth.net) 04.45.37 # Just wanted to throw this out there: something recently (last few days) broke speed and pitch. Playback freezes when attempting to play back at anything other than 100%/100%. I'll file a bug report, but I don't know if I have the time to chase down the cause or the revision. 04.46.17 # * [Saint] points accusingly at jhMikeS... 04.46.23 # <[Saint]> "He probably did it!" ;) 04.47.30 Quit [7] (Disconnected by services) 04.47.43 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.51.04 # Probably. :) 04.51.24 # Now immortalized as FS#12250. 04.51.25 # http://www.rockbox.org/tracker/task/12250 3Playback freezes when using speed or pitch change (bugs, new) 04.51.47 # <[Saint]> Silly question...but, verified with SVN head? 04.51.56 # <[Saint]> there was some poking around last night. 04.52.44 # Hm... Lemme go back with a completely clean checkout and try again. I don't think it will matter but it can't hurt to check. 04.53.09 Quit Galois (Remote host closed the connection) 04.53.26 Join Galois [0] (djao@efnet-math.org) 04.54.02 Join PurlingNayuki [0] (~PurlingNa@113.97.68.216) 04.55.47 # Another (?) problem: a kernal panic when playing back a particular mp3 file at 140% speed. No clue what causes that. Good news is that the panic is now gone. Bad news is that it freezes like all the others. 04.59.09 Join simonlnu [0] (3rjyM1OEA7@unaffiliated/simonrvn) 05.06.19 Quit simonlnu (Ping timeout: 260 seconds) 05.11.18 Join simonlnu [0] (wXFXzg9VZ4@unaffiliated/simonrvn) 05.12.13 # Yeah, still munged up with a clean install. Was worth a try. 05.14.01 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 05.16.10 Quit simonlnu (Ping timeout: 260 seconds) 05.19.28 # * jhMikeS 05.19.37 # has been playing things at different speeds 05.19.42 # Is the freezing better than panic? :P 05.20.38 # it's not doing either 05.20.49 # I'll try another device 05.22.48 # I'm working from a e200 device. I haven't tried a sim. 05.24.16 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 05.24.22 # aha, it happens with tdspeed, not with normal resampling 05.24.56 # not freezing but not able to fill the sample buffer 05.25.22 # which maxes out the thread priority, making the UI sticky 05.25.25 # Yeah, I'm going off the pitch quickscreen and bookmarks. Both of which go off of tdspeed. 05.25.50 Join simonlnu [0] (7TFWnpQ4bI@unaffiliated/simonrvn) 05.25.54 # maybe tdspeed made assumptions about buffer sizes? 05.26.01 # "Freeze" might have been a bad word. It's not locked up, but playback stops and eventually the UI drops. 05.26.09 Quit PurlingNayuki (Quit: PurlingNayuki) 05.32.24 # might want to check before pcm buffer updates? 05.34.46 # FYI, I reverted to an older checkout (r30000, just 'cause it's nice and round) and the slowdown and panics are gone. Which is not surprising since it's using the old engine, but now you know. 05.36.10 # <[Saint]> Not that useful, but, good to know ;) 05.36.16 # I know it worked while working on engine updates, for mixer and pcm buffer, not so sure which it didn't like, if any 05.37.03 # No, not useful at all really, but the player works until the bug is chased down. :) 05.38.27 # if tdspeed can't deal with pretty much arbitrary sizes buffers or something, then it's just outright broken anyway 05.38.27 # I listen to a lot of voice material and depend on speed. 05.38.45 # * [Saint] can't resist. 05.38.52 # <[Saint]> "Drugs are bad...mmmmmkay?" 05.39.02 # Oh, no you don't... 05.39.05 # @-@ 05.39.07 # Never mind, you went there. 05.39.56 # I'll just chew on these size 8 1/2's for a few minutes. 05.41.49 # well, I'm building to r30365 and will see if r30366 is upsetting the delicate flower 05.42.17 # * [Saint] sees a comment in the forums from saratoga and wonders if dircache actually makes a notable difference in a flash based player, or if the extra buffer would be of more value. 05.43.10 # <[Saint]> in a HDD player, sure...dircache FTW. But in my flash based players I just disable it. 05.43.16 # probably with opening and closing file descriptors, since that seems unduly slow 05.43.53 # <[Saint]> Hmmm. I wonder if there's a meaningful way I can test this myself. 05.44.15 # test_disk 05.44.21 Join Rob2222 [0] (~Miranda@p4FFF2876.dip.t-dialin.net) 05.46.28 Quit Horschti (Quit: Verlassend) 05.47.31 # <[Saint]> Oh, yeah...right. I should have been more specific. Without assuming you all have a doorway into my thoughts (you don't want this). 05.48.02 # <[Saint]> I was thinking along the lines of a double-blind test where I attempted to identify if dircache was enabled, or disabled. 05.48.11 Quit Rob2223 (Ping timeout: 240 seconds) 05.50.47 # I could probably tell by looking at the buffering screen :) 05.56.06 # seems it doesn't like r30366 05.59.01 Quit jfc (Read error: Operation timed out) 06.05.13 *** Saving seen data "./dancer.seen" 06.05.47 Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net) 06.09.04 Quit ChickeNES (Client Quit) 06.13.46 Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com) 06.15.21 Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 06.18.15 Quit Scromple (Ping timeout: 246 seconds) 06.18.19 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 06.19.43 Quit Scr0mple (Ping timeout: 245 seconds) 06.21.11 Quit Blue_Dude (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603]) 06.26.57 Quit user829385 (Quit: Leaving.) 06.35.10 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 06.36.19 Join [Saint_AndChat] [0] (~Saint]@203.100.215.45) 06.37.22 # Also FYI, r30365 works correctly with regard to tdspeed (you knew that already), but also crashes with an "undefined instruction" panic when trying to play back a particular mp3 file at 140% speed. Dunno yet why it does that. No problems at 100% speed and the file passes a corruption test. 06.37.32 Quit Blue_Dude (Client Quit) 06.40.58 # tdspeed needs to give a proper output estimate. space near the end of the buffer, while it may have that much free, is not necessarily contiguous, since it has a small guardbuffer rather than automatic wrap 06.42.48 Quit nick-p (Quit: Leaving) 06.57.15 Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 06.59.27 Quit Scromple (Ping timeout: 264 seconds) 07.26.52 Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net) 07.44.38 Quit liar (Read error: Connection reset by peer) 07.45.43 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 07.45.55 Quit ChickeNES (Quit: Computer has gone to sleep.) 08.05.15 *** Saving seen data "./dancer.seen" 08.10.00 Quit powell14ski_ (Quit: powell14ski_) 08.45.09 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.47.18 Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net) 08.48.23 Quit ChickeNES (Client Quit) 08.50.00 Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net) 08.57.36 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.57.36 Quit bertrik (Changing host) 08.57.36 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.57.46 Join TheLemonMan [0] (~giuseppe@ppp-146-29.26-151.libero.it) 08.58.07 Quit ChickeNES (Quit: Computer has gone to sleep.) 09.00.03 Join Bagder [241] (~daniel@rockbox/developer/bagder) 09.01.05 Join ender` [0] (~ender@foo.eternallybored.org) 09.11.09 Quit TheLemonMan (Quit: leaving) 09.11.30 Join TheLemonMan [0] (~giuseppe@ppp-146-29.26-151.libero.it) 09.11.50 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 09.11.50 Quit pamaury (Changing host) 09.11.50 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.17.30 Join n1s [0] (~quassel@rockbox/developer/n1s) 09.21.43 Quit Scr0mple (Quit: Leaving) 09.23.27 Join n17ikh [0] (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) 09.29.13 Quit bertrik (Ping timeout: 240 seconds) 09.30.41 Quit n17ikh (Quit: ZNC - http://znc.sourceforge.net) 09.39.05 Join LinusN [0] (~linus@giant.haxx.se) 09.40.20 Quit [Saint_AndChat] (Remote host closed the connection) 09.43.21 # <[Saint]> Can someone compile/upload for me please...clean, svn head, 240x320 and 480x800 RaaA .apk if its not too much trouble? 09.44.13 # * [Saint] wished RaaA was in the build system. 09.44.45 # <[Saint]> Or that his build machine didn't need a new PSU. 09.44.59 # <[Saint]> *wishes 09.55.15 # I think we compile most (if not all) files with -fomit-frame-pointer right ? Did anyone think about implementing backtracing on panic ? 09.58.16 # yes we compile everything with -fomit-frame-pointer 10.01.52 # i think we have quite some asm using the fp reg so i wonder how gcc would handle that 10.03.39 # But in C functions, the compiler can tell the offset of the stack pointer to the return address, so it's probably possible to do it 10.03.49 Join Buschel [0] (~chatzilla@p54B66FFB.dip.t-dialin.net) 10.03.56 # for asm functions, it's indeed more difficult 10.05.01 # On the other hand, our panic screen is basically useless in many cases so backtrace would be nice 10.05.17 *** Saving seen data "./dancer.seen" 10.05.24 # sure it would be nice 10.06.50 # i wonder if we would like to have it enabled always, since it would mean slightly worse code 10.07.45 # I don't know, it depends on the size of data you need to backtrace 10.09.17 # but it also means that you have to do a debug build to get the information 10.31.42 Join JdGord [0] (~AndChat@42.62.218.156) 10.43.25 # I really should not stash important changes and go for holydays, now I'm lost in my own code :) 10.45.35 Join casainho [0] (~chatzilla@bl20-221-34.dsl.telepac.pt) 10.47.39 Quit JdGord (Quit: Bye) 10.53.35 # does someone know where I can find some documentation about the debug sections produced in debug compilation ? 10.56.58 # [Saint]: did you find someone to make you the builds you need? 10.57.41 # <[Saint]> user890104: I didn't, no. 10.58.06 # ok, i think i can help you then 10.58.14 # <[Saint]> Thanks, appreciated. 10.58.27 # <[Saint]> No rush, or obligation...but I'd appreciate it. 10.58.40 # these are portrait and not landscape, right? 10.58.58 Quit TheLemonMan (Quit: Lost terminal) 10.59.11 # <[Saint]> Correct. 10.59.41 # ok, building 11.01.46 Join TheLemonMan [0] (~giuseppe@ppp-146-29.26-151.libero.it) 11.08.29 Nick bug2000 is now known as bug (~bug@unaffiliated/bug2000) 11.08.37 Nick bug is now known as bug2000 (~bug@unaffiliated/bug2000) 11.12.07 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 11.14.03 # n1s: our asm on ARM doesn't depend on the fp reg being free anymore iirc 11.15.39 # backtrack is probably difficult since panics can called from from the code (several stacks) and in exception handlers (another different stack) 11.15.55 # backtrace* 11.17.38 # true, but perhaps that can be solved (at partially) 11.18.24 # I think we can use gcc to get the direct caller though 11.18.52 # you mean using the debug info ? 11.19.23 # some builtin 11.20.05 # Perhaps, but we want the full trace, the direct caller is not always relevant 11.27.52 Join mt [0] (~mt@rockbox/developer/mt) 11.30.57 # * JdGordon is zonked 11.48.22 Join MrNorrell [0] (~7d3cad45@giant.haxx.se) 11.49.54 Quit MrNorrell (Client Quit) 11.52.47 Join MrNorrell [0] (~7d3cad45@giant.haxx.se) 11.56.15 Quit MrNorrell (Client Quit) 12.05.19 *** Saving seen data "./dancer.seen" 12.19.25 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 12.35.22 Join user829385 [0] (~aoeu@112.166.15.141) 12.38.59 # <[Saint]> kugel: Ping? 12.39.18 # [Saint]: ?gniP 12.39.51 # <[Saint]> user890104 is having some "issues" building RaaA... 12.39.53 # <[Saint]> [22:33] make: /home/venci/android-sdk-linux_x86/platform-tools/aapt: Command not found 12.39.53 # <[Saint]> [22:33] make: *** [/home/venci/rockbox/build-raaa-480x800/bin/resources.ap_] Error 127 12.40.17 # <[Saint]> this doesn't exist in the current SDK, is it too new? 12.40.54 # <[Saint]> "this" == android-sdk-linux_x86/platform-tools 12.41.19 # <[Saint]> that dir isn't present in the latest SDK 12.41.38 # you need to install the platform tools first 12.42.19 # <[Saint]> he's run ./android, with the same params as the installtoolchain script. 12.42.43 # <[Saint]> "./android update sdk --no-ui --filter platform,tool" 12.43.02 # <[Saint]> and (according to him) this dir is not present. 12.43.38 # the platform-tools is not there indeed, that's created with the installation of the platform tools package 12.43.50 # <[Saint]> user890104: Do you care to coment, so I'm not talking on your behalf? 12.43.58 # <[Saint]> Apparently there's some step you're missing. 12.44.05 # I don't know the filter for that (let me remind you that I never used or touched installToolchain.sh :) ) 12.44.08 # i have platforms/android-4/tools/aapt and platforms/android-3/tools/aapt instead in the sdk dir 12.44.15 # <[Saint]> kugel: But, shouldn't ""./android update sdk --no-ui --filter platform,tool"" create this? 12.44.51 # I don't know the android command line 12.45.14 # <[Saint]> all that says is "instal platform tools, and all the platform packages" 12.45.29 # <[Saint]> (without bugging me with a UI) 12.45.54 # ah, add platform-tool to that list 12.46.20 # i.e. ./android update sdk --no-ui --filter platform,tool 12.46.26 # ffs, damn irssi 12.46.45 # ./android update sdk --no-ui --filter platform,tool,platform-tool 12.47.28 # <[Saint]> Aha, right. I had to direct him to the commandline ./android install, due to X issues. 12.47.52 # user890104: ^ 12.48.03 # yeah, done that, thanks 12.48.04 # <[Saint]> I pulled that from ememory, then checked it against installtoolchains, it seems installtoolchains doesn't install platform-tools wither. 12.48.13 # <[Saint]> *memory 12.48.21 # <[Saint]> *either 12.48.22 # I can see that yes 12.48.27 # <[Saint]> damn keyboard. 12.54.38 Quit mt (Ping timeout: 260 seconds) 13.02.03 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 13.04.50 Quit kadoban (Ping timeout: 264 seconds) 13.06.47 Quit avacore (Read error: Operation timed out) 13.07.53 Join _Zagor [242] (~bjst@rockbox/developer/Zagor) 13.08.24 Quit Zagor (Ping timeout: 252 seconds) 13.09.10 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 13.20.08 Nick _Zagor is now known as Zagor (~bjst@rockbox/developer/Zagor) 13.31.37 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 13.42.44 Join MethoS- [0] (~clemens@134.102.106.250) 13.42.49 Part LinusN 13.43.04 Join LinusN [0] (~linus@giant.haxx.se) 13.45.24 Quit ender` (Read error: Connection reset by peer) 13.46.55 Join ender` [0] (~ender@foo.eternallybored.org) 13.53.45 Quit nick-p (Quit: Leaving) 14.05.20 *** Saving seen data "./dancer.seen" 14.07.37 Join ptrkmj_ [0] (~chatzilla@95-25-84-98.broadband.corbina.ru) 14.08.53 # The file "binutils-2.20.1.tar.bz2" downloaded by the rockboxdev shell script is considered broken for me 14.09.50 # the url is http://www.rockbox.org/gcc/binutils-2.20.1-ld-thumb-interwork-long-call.diff 14.10.49 # broken how? 14.10.59 # <[Saint]> I think you'll need to be more specific on how you consider it to be broken. 14.12.15 # sorry 14.12.33 # ROCKBOXDEV: extracting binutils-2.20.1.tar.bz2 14.12.38 # "bzip2: Compressed file ends unexpectedly; perhaps it is corrupted" 14.12.57 # <[Saint]> Download it manually. 14.14.01 # ok 14.20.55 # (Also, the script trys to download file binutils-2.20.1.tar.bz2 from http://mirrors.kernel.org but it doesn't exist anymore, it's binutils-2.20.1a.tar.bz2 now (since 26th august) ) 14.28.52 Part LinusN 14.29.06 Join LinusN [0] (~linus@giant.haxx.se) 14.31.16 # arghh, test_codec is totally fucked up if HAVE_ADJUSTABLE_CPU_FREQ is defined :/ 14.34.24 # menu entries beyond "boost" are doing weird things 14.40.33 Join T44 [0] (~Topy44@f049067004.adsl.alicedsl.de) 14.44.16 Quit Topy44 (Ping timeout: 245 seconds) 14.50.49 # gevaerts: hey, I just read the mail that I successfully passed gsoc! Thank you a lot. 14.53.22 # [Saint]: should I report the file name error in the script ? or maybe it is updated automatically 14.55.13 Quit ptrkmj_ (Quit: ChatZilla 0.9.87 [Firefox 3.6.20/20110803131630]) 14.55.48 # which compiler is that for? a new binutils version probably means we need to verify targets using it dont break 15.00.21 # 2.20.1 is used on cf and arm iirc 15.00.36 # New commit by 03buschel (r30374): Fix logic of test_codec for targets with HAVE_ADJUSTABLE_CPU_FREQ. 15.00.37 # but 2.20.1a sounds like re-packaging so probably not an issue 15.03.48 # r30374 build result: All green 15.29.45 # but why the hell did they kill the old version? 15.30.30 # they keep like every version since 1996 but deleted the one we use 15.30.34 # <[Saint]> kugel: Congratulations, from myself, and from many others I'm sure. 15.30.43 # <[Saint]> It sounds soppy, but I'm proud of you. 15.35.25 # they are replaced on the official gnu ftp too, something must have been really wrong with them 15.40.17 Join mt [0] (~mt@41.234.33.83) 15.45.01 Quit mt (Ping timeout: 264 seconds) 15.48.32 # New commit by 03buschel (r30375): Final commit to get test_codec working properly for both freq-scaling and non-freq-scaling targets. 15.48.46 # test_codec menu and statemachine is a mess... 15.49.59 Join mt [0] (~mt@41.234.33.83) 15.51.25 # r30375 build result: All green 15.54.45 # [Saint]: thank oyu 16.01.31 Quit mt (Ping timeout: 264 seconds) 16.02.27 Quit Bagder (Quit: Konversation terminated!) 16.05.21 *** Saving seen data "./dancer.seen" 16.06.28 Quit antil33t (Read error: Connection reset by peer) 16.06.40 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 16.06.47 # <[Saint]> kugel: No, really...thank you. You've brought many great things to this project 16.06.53 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 16.14.25 # gevaerts: I should have time the next 2 weeks, so I wait for an OK to commit the buflib patches 16.14.49 Quit Poodlemastah (Quit: ZNC - http://znc.in) 16.15.07 Join Poodlemastah [0] (~Poodlemas@h-241-205.a218.priv.bahnhof.se) 16.15.48 Join mgue [0] (~mgue@p5DDA3B7F.dip.t-dialin.net) 16.18.19 # I also must not forget to upload the code to google :\ 16.18.19 Quit ageis (Read error: Connection reset by peer) 16.21.09 Join y4n [0] (y4n@unaffiliated/y4ndexx) 16.21.09 Quit simonlnu (Read error: Connection reset by peer) 16.21.20 Quit liar (Read error: Connection reset by peer) 16.21.27 Join simonlnu [0] (d6DH4Q57Bo@unaffiliated/simonrvn) 16.23.10 Quit MethoS- (Remote host closed the connection) 16.23.16 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 16.25.48 Quit Poodlemastah (Quit: ZNC - http://znc.in) 16.26.07 Join Poodlemastah [0] (~Poodlemas@h-241-205.a218.priv.bahnhof.se) 16.28.44 Quit mgue (Ping timeout: 240 seconds) 16.30.30 Join mgue [0] (~mgue@p5DDA1645.dip.t-dialin.net) 16.31.01 Quit simonlnu (Ping timeout: 250 seconds) 16.31.56 Quit antil33t (Read error: Connection reset by peer) 16.32.16 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 16.35.34 Quit markun (Ping timeout: 268 seconds) 16.38.30 Join simonlnu [0] (P4vjJlN0nJ@unaffiliated/simonrvn) 16.39.09 Part LinusN 16.42.16 Join [Saint_AndChat] [0] (~Saint]@203.100.215.45) 16.47.56 Quit factor (Quit: Leaving) 17.05.57 Part Zagor 17.06.28 # kugel: I'd say committing now (or soon) is fine 17.10.53 Quit liar (Ping timeout: 258 seconds) 17.12.27 Quit y4n (Disconnected by services) 17.12.33 Join y4n [0] (y4n@unaffiliated/y4ndexx) 17.12.46 Quit tchan (Quit: WeeChat 0.3.5) 17.16.51 Quit simonlnu (Remote host closed the connection) 17.17.48 Quit y4n (Read error: Connection reset by peer) 17.18.43 Join y4n [0] (y4n@unaffiliated/y4ndexx) 17.21.20 Quit y4n (Client Quit) 17.29.22 Quit [Saint_AndChat] (Remote host closed the connection) 17.42.06 Quit casainho (Remote host closed the connection) 17.42.38 Join casainho [0] (~chatzilla@2.81.221.34) 17.47.48 Quit casainho (Remote host closed the connection) 17.48.23 Join casainho [0] (~chatzilla@bl20-221-34.dsl.telepac.pt) 17.49.12 Quit Keripo (Ping timeout: 260 seconds) 17.55.10 Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu) 18.03.20 Join y4n [0] (y4n@unaffiliated/y4ndexx) 18.05.22 *** Saving seen data "./dancer.seen" 18.06.03 Join MethoS- [0] (~clemens@134.102.106.250) 18.08.26 Quit user890104 (Read error: Connection reset by peer) 18.09.35 Join user890104 [0] (~Venci@6bez10.info) 18.13.24 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.14.55 Quit MethoS- (Remote host closed the connection) 18.21.19 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.30.25 # What should lcd_update_rect do with invalid coordinates? 18.31.08 # 1) assume it won't happen, 2) not update the lcd, 3) correct the coordinates or 4) throw a panic or something similar ? 18.36.00 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.37.56 # I think I'll go for 3) (and 2) if they're still not valid after correction) 18.41.42 Quit ReimuHakurei_ (Read error: Connection reset by peer) 18.41.52 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 18.43.47 Quit ReimuHakurei (Read error: Connection reset by peer) 18.44.02 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 18.55.54 # * bertrik wonders why we have prototypes like lcd_write_command/lcd_write_command_e/lcd_write_command_ex and lcd_write_data in lcd.h 18.56.28 # nobody calls these functions except the lcd drivers themselves 18.56.43 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.56.54 Quit casainho (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603]) 19.01.39 Join Strife89 [0] (~Strife89@207.144.201.128) 19.13.48 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.19.26 Join froggyman_ [0] (~seth@50.105.142.145) 19.20.04 Quit froggyman (Read error: Connection reset by peer) 19.24.36 Quit antil33t (Read error: Connection reset by peer) 19.25.00 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 19.39.56 Quit antil33t (Read error: Connection reset by peer) 19.40.18 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 19.43.08 Quit bluebrother (Disconnected by services) 19.43.10 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 19.45.05 Quit fs-bluebot (Ping timeout: 245 seconds) 19.46.11 Join fs-bluebot [0] (~fs-bluebo@g231120173.adsl.alicedsl.de) 19.47.57 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.48.01 Join simonlnu [0] (QwJqhIJggf@unaffiliated/simonrvn) 19.54.17 Join ptrkmj [0] (~chatzilla@95-27-214-13.broadband.corbina.ru) 19.55.48 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 20.04.34 Join biopyte [0] (~kiwi@89.204.153.253) 20.05.26 *** Saving seen data "./dancer.seen" 20.06.13 Quit Keripo (Quit: Leaving.) 20.06.28 Join Lear [0] (chatzilla@141.191.216.81.static.g-hn.siw.siwnet.net) 20.07.02 Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu) 20.07.40 # Hi, I just bought a mini speaker for my sansa clip. i wonder if i could use the clip as an alarm clock, in a way that it boots up at a certain time. I guess not. Probably the clip has to be turned on allt he time in order to function as an alarm clock. but that would also consume a lot of energy if its turned on the whole night. could someone comment on this, pleae? 20.08.18 Quit y4n (Read error: Connection reset by peer) 20.09.26 # <[Saint]> biopyte: I suggest reading the manual. 20.09.50 # <[Saint]> Even googleing "Rockbox+Manual+Alarm" will give you all the info you need. 20.11.02 # <[Saint]> System - Time and Date - Wake-Up Alarm 20.11.23 # ok 20.11.57 # imjust checked the manual. i dont see that it would answer my particular question 20.12.25 # wake-up alarm ... got it 20.12.25 # thanks 20.12.50 # <[Saint]> Why would the manual *not* answer your question? 20.12.59 # cool 20.13.07 # <[Saint]> Its a manual, it contains very detailed info on *all* the players settings. 20.13.34 # it's ok ... said I found it 20.17.21 # bye 20.17.26 Quit biopyte (Quit: Leaving) 20.17.48 # <[Saint]> I know, I'm just wondering what made you think that the manual wasn't the best place to, or wouldn't answer you, specific question. 20.17.52 # <[Saint]> bah! 20.34.03 Join y4n [0] (y4n@unaffiliated/y4ndexx) 20.43.46 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 20.45.50 Join [Saint] [0] (~st.lasciv@203.100.215.45) 21.01.48 Quit y4n (Read error: Connection reset by peer) 21.02.47 Join y4n [0] (y4n@unaffiliated/y4ndexx) 21.18.24 Join ReimuHakurei_ [0] (~kudo@wireless.sit-co.net) 21.18.52 Quit ReimuHakurei (Read error: Connection reset by peer) 21.18.58 Nick froggyman_ is now known as froggyman (~seth@50.105.142.145) 21.19.06 Quit froggyman (Changing host) 21.19.06 Join froggyman [0] (~seth@unaffiliated/froggyman) 21.22.05 Quit ptrkmj (Quit: ChatZilla 0.9.87 [Firefox 3.6.20/20110803131630]) 21.26.39 Quit Lear (Quit: ChatZilla 0.9.87 [Firefox 7.0/20110824172139]) 21.41.03 Quit ReimuHakurei_ (Ping timeout: 240 seconds) 21.42.19 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 21.45.23 Quit ReimuHakurei (Read error: Connection reset by peer) 21.45.52 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 21.49.55 # bertrik: lcd_write_* are asm functions for several drivers, hence the prototype 21.50.38 # As for lcd_update_rect() - it's supposed to crop the coordinates to valid range, and if height or width end up being zero, just return 21.54.42 Quit ReimuHakurei (Ping timeout: 250 seconds) 21.55.27 Quit y4n (Quit: The world around me drops away, replaced by worlds being created and destroyed by my imagination.) 22.02.29 # [Saint], odd, because the clipv1 doesn't have a wake-up alarm as far as I can tell 22.02.58 # clipv2 and clip+ (AMSv2) do have it 22.05.27 *** Saving seen data "./dancer.seen" 22.06.23 # found the SPI settings for the clip zip, the clip zip lcd driver is now nearly done except for actually testing it on a real device :D 22.07.33 # details :) 22.09.15 # actually making it work is left as an exercise to the reader 22.15.08 Join ptrkmj [0] (~chatzilla@95-26-18-158.broadband.corbina.ru) 22.16.53 # Is support for True Audio on RB as good as it is for FLAC and WavPack? 22.20.17 # ptrkmj: I'm not even sure what you're asking. 22.21.50 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 22.22.33 # Well, I'm trying to figure out what codec would be the best for use with Rockbox. So far I chose 3 candidates: FLAC, WavPack, and True Audio. 22.22.59 # Given that they're all lossless, so that you can transcode files between them with ease, you could just try them all. 22.23.26 # Since it's hard for us to know what you're valuing about each of them, it's hard for anyone to know what you'd consider "as good" support. 22.23.46 # Probably, I would not see any difference. 22.23.50 # Right. 22.25.44 Quit niekie (Read error: Connection reset by peer) 22.26.13 # Which of the above codecs would be best regarding battery time? 22.26.50 # Depends on the player. Large filesizes tends to hurt more on hard disk based players, slower decoding speed tends to hurt more on players where disk access is "cheaper" in terms of battery cost. 22.27.37 # I have an had disk based ipod 5g 22.28.15 # So the FLAC is going to hurt more? 22.28.21 # Probably whichever one gets the best filesizes with your music, though if there's not a huge difference in filesize, again, the more optimized one might be best. You'd really just need to do some testing with your actualy music. 22.28.48 # Since filesize differences can vary greatly with the audio encoded. 22.29.35 # I doubt that filesizes wil vary significantl 22.30.26 # The smallest filesize would be achieved with Monkey's Audio Normal mode 22.30.43 # but it's the hardest to decode 22.31.14 # As I said, you'd really just need to do some testing. 22.31.40 # I probably won't since I'm too lazy :) 22.31.41 # My biggest suggestion would be doing a proper blind or double blind test against some high quality lossy encoders. Typically on portable hardware it's very, hard to tell the difference anyway 22.32.15 # flac is by far faster than both tta and wavpack 22.32.42 # so uses less cpu time, so if the file sizes are similar it will probably get the best runtime 22.33.18 # FLAC is almost "free" to decode on some devices, decoding fast enough that the CPU almost never boosts. 22.34.33 # Using lossy format would require doing extra encoding. Storage is cheap so I don't want to bother. 22.34.44 # Speaking of flac, I don't mean to bother everyone in here again, but I'm having another issue. It can be summed up as: When i save .ogg files to my rockbox'd 1st gen ipod nano, it converts the .ogg to a .flac, increasing the file size for presumably no good reason. Is this normal? 22.36.03 # evildaemon: Whatever you're talking about has nothing to do with Rockbox. 22.36.05 # Do you know any comparisons similar to that: 22.36.24 # Rockbox runs on the player, and has no interaction with the file transfers. It's just a dumb disk as far as the PC is concerned. 22.36.30 # http://synthetic-soul.co.uk/comparison/lossless 22.36.31 # (it's from 2008) 22.36.50 # Llorean: Fair enough. It's probably an issue with my music software then. 22.38.23 # ptrkmj: http://www.rockbox.org/wiki/CodecPerformanceComparison#Portal_Player_40ARM7TDMI_41 has performance comparisons for various codecs on the cpu used in the ipod video 22.38.35 Quit Stummi (Quit: Bye!) 22.40.51 # thanks, it will come useful 22.41.46 # * amiconn summons thomasjfox 22.41.57 # indeed, FLAC is a piece of cake for CPU 22.43.17 # 2.5 more efficient than WavPack 22.43.24 # *times 22.43.59 # True Audio decoder seems not optimized 22.44.11 # correct 22.44.22 # well, not very much at least 22.46.32 # i think its been optimized some since that test 22.48.17 # oh i guess not 22.50.15 # True audio is rather difficult to optimize due to its structure 22.50.35 # (source code structure, not format structure) 22.51.31 # Iirc it calls many functions for each sample 22.51.47 # (instead of looping over a block of samples) 22.51.57 # it performs comparably to WavPack on PC 22.54.29 # What is the meaning of the 4rd column in CodecPerformanceComparison charts? Do portable CPU have variable clock freq.? 22.55.25 # it's the number of MHz of the cpu that is needed for realtime decoding 22.55.48 # some of the cpus does have variable speed 22.56.11 # so it's an estimate? 22.56.28 # no, it's a calculated number 22.57.02 # max speed/realtime factor 22.58.40 # hmm, is this useful in any way? % of realtime is probably enough to judge the performance 22.59.21 # it's just a different representation of the same thing, yes 22.59.52 # its a more interesting number then % realtime 22.59.58 # yes 23.00.10 # since its linear in performance 23.00.38 # verses scaling with 1/x 23.02.52 # I wonder how would simple WAV perform 23.03.13 # iirc it needs about 1MHz 23.03.31 # which is basically the codec shuffling data 23.03.56 # not very interesting though 23.04.22 # Probably would drain battery faster than compressed codecs on HD-based targets 23.04.29 # yeah 23.04.46 # wav is probably just a test of how fast the ram is on your player 23.06.01 # New commit by 03bertrik (r30376): sansa clipzip: implement more functions in the lcd driver 23.08.25 # New commit by 03bertrik (r30377): sansa clipzip: correct GPIO used for backlight 23.09.01 # r30376 build result: All green 23.09.22 Quit n1s (Remote host closed the connection) 23.12.21 # r30377 build result: All green 23.16.59 Quit Strife89 (Quit: Heading home.) 23.20.31 Quit Keripo (Quit: Leaving.) 23.21.14 Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu) 23.24.02 Quit Keripo (Client Quit) 23.28.24 # http://flac.sourceforge.net/comparison_all_ratio.html 23.28.26 # Can you tell me the difference between 'Total' and 'CPU' times? 23.28.43 Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu) 23.29.44 Join leavittx [0] (~leavittx@cl-534.mbx-01.si.sixxs.net) 23.30.53 Quit leavittx (Remote host closed the connection) 23.31.28 Join niekie [0] (~niek@CAcert/Assurer/niekie) 23.31.42 Quit domonoky (Read error: Connection reset by peer) 23.34.32 Quit niekie (Read error: Connection reset by peer) 23.34.45 Join niekie [0] (~niek@2001:470:9326::3) 23.34.47 Quit niekie (Changing host) 23.34.47 Join niekie [0] (~niek@CAcert/Assurer/niekie) 23.34.53 Quit niekie (Remote host closed the connection) 23.36.34 Join niekie [0] (~niek@CAcert/Assurer/niekie) 23.41.03 # total probably refers to the sum of time spent in the codec and waiting on file IO 23.44.24 Join Horschti [0] (~Horscht@p5DD56C3D.dip.t-dialin.net) 23.44.24 Quit Horschti (Changing host) 23.44.24 Join Horschti [0] (~Horscht@xbmc/user/horscht) 23.46.44 Quit Horscht (Ping timeout: 252 seconds) 23.54.12 Join evilnick [0] (~evilnick@5e03124a.bb.sky.com) 23.54.12 Quit evilnick (Changing host) 23.54.12 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 23.55.02 Join MethoS- [0] (~clemens@134.102.106.250)