--- Log for 26.05.109 Server: jordan.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 16 hours ago 00.00.02 # oh crap, I errored 00.00.09 # 103 builds in the table 00.00.22 Quit mirak (Remote closed the connection) 00.00.53 # maybe we could have seperate tables for targets and bootloaders 00.01.18 # though i guess thats not really any more sensible then putting them together 00.01.53 # low_light: is akcodec initialized before or after first display of "AKM Codec Test started" ? 00.03.15 # * kugel doesn't quite get why the context menu isn't working 00.05.47 # hm, if I press the context button to long, audio drops out 00.07.21 # ah I think I found it 00.09.52 # Congrats on the new targets, chaps and chapesses 00.09.55 Quit amiconn (Nick collision from services.) 00.09.57 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 00.09.58 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 00.09.58 Quit pixelma (Nick collision from services.) 00.10.13 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 00.10.17 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 00.13.29 # I see the modifications of GPO32 & GPIOF for now, the rest must not be far .. 00.14.33 Quit domonoky (Read error: 104 (Connection reset by peer)) 00.14.51 # low_light: congrats for the port, i'll try to do my part :) 00.16.11 # funman: in the OF, the GPIOB bit is set during a sys_init type funciton, separate from the codec stuff. 00.17.09 # hum my YH920 has problems with usb, not only with the OF but also with rockbox (now I'm sure it's a hardware related problem) 00.18.30 Quit bertrik (Read error: 113 (No route to host)) 00.18.42 # did you notice the 0x700000C0 register ? 00.19.01 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 00.21.21 # Are we looking to build new bootloaders for Version 3.3 when it releases? 00.23.57 # If we're going to include USB we're going to need to. 00.24.15 # * Llorean would really like to see the charging issue solved on iPods first. 00.24.19 # Is USB going to be included on PP even with the charging issues on all (????) iPods? 00.24.23 # jynx. 00.24.29 # soap: There's a patch for it in the tracker, I think 00.24.32 # From dreamlayers. 00.24.49 # The "dumb" patch which assumes you have a power supply which can provide 500ma? 00.25.04 # Yeah, I think that's the one. 00.25.16 # Llorean: What's the FS# (if you remember it)? 00.25.20 # I can't remember, sorry. 00.25.26 # I'll search. 00.25.28 # That one works very well for me - but I think that is the last thing which should be in a release. 00.25.40 # soap: Why? 00.25.44 # funman: yes, but I didn't see it in the OF FW file. I believe I tried it on the 820/925, but it was setting that GPIOB bit that got things working for me. 00.25.53 # soap: All it needs is an option like the H300 has. 00.26.08 # I'm thinking of #8802 00.27.00 # low_light: can you share your yh920 disassembly ? 00.27.09 # http://www.rockbox.org/tracker/task/8802?string=8802 00.27.14 # soap: IIRC the H300 has an option that basically boils down to whether or not to request 500 00.27.24 # Llorean, because whatever amperage we're pulling w/o that patch fails even to trickle charge my 5G when it is idle, and if that patch is "dumb" enough to pull more amps than it should - we'd be creating a monster. 00.27.40 # Llorean, but the H300 charges on the lower setting, does it not? 00.27.52 # And does it _take_ 500 or _request_ 500? 00.28.01 # I guess it takes. 00.28.09 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 00.28.43 # soap: I'm not sure what you mean by "creating a monster"? 00.28.51 # If it takes, then you are absolutely right that is precedent, but how many of the iPods can charge in a current build w/o that patch? 00.29.01 # I'm missing something 00.29.08 # What does being able to charge in current builds have to do with anything? 00.29.25 # Creating a monster in that we are giving users two options. Option 1 being "pretends to charge but doesn't" and option 2 being "unsafe charging behavior". 00.29.44 # My understanding is that the only expected "unsafe" thing about it is failure to connect. 00.29.56 # The host will refuse its demand for 500 and it won't show up as a UMS device 00.30.02 # Because if USB is enabled and there is no safe way to charge what has been delivered in terms of stable functionality to the user? 00.30.29 # Since we may have new bootloaders, should we also bump the version numbers for e200rpatcher, iPodpatcher, and Sansapatcher as well? 00.30.36 # "Don't try charging from unpowered hubs or chargers which have lower ratings." 00.30.42 # soap: We get better runtime than the OF. That means that, generally, we're using less power than them. If they can charge, they're probably getting 500 as well. 00.31.06 # iPod chargers have a rating of 1000 actually, or every one I've seen has 00.31.13 # and USB ports? 00.31.25 # Compliant ones are 500 00.31.38 # The only ones that are a problem are ones that don't actually follow USP specifications, if my understanding is clear 00.31.39 # lsusb -v shows "MaxPower 500mA" for my ipod nano, i don't know if it means it's actually using that though 00.31.47 # since when does Rockbox assume the user's hardware is acting in compliance. 00.31.57 # Since it's necessary to charge. 00.32.02 # ? 00.32.25 # soap: We assume the host supports UMS for UMS connections 00.32.33 # We also assume it provides the amount of power USB is supposed to provide 00.32.36 # That seems pretty reasonable. 00.32.46 # The way I read dreamlayers' comment (the quote above) is do not use that patch and plug into a port (of any sort) which is not rated for 500ma. 00.33.01 # We have an option "Unpowered connection" resting somewhere in the menus for people to turn on if they need to connect to an unpowered hub/port 00.33.26 # speaking of which.... egt around to testing the usb charge only patch? 00.33.47 # JdGordon: Just got back to my players last night. What FS# is it? 00.33.54 # just a fyi (maybe interesting for tomers) - http://svn.rockbox.org/viewvc.cgi?view=rev;revision=21054 works well with foobar2000 and my c200 00.34.04 # 10198 00.34.08 # soap: My understanding of *why* not to, though, is just that it will fail to connect. 00.35.41 # I don't get that from what dreamlayers said in the FS task. 00.36.38 Join JdGordon| [0] (i=43a02c5a@gateway/web/ajax/mibbit.com/x-61793cde847eabe6) 00.37.29 # soap: What he says doesn't indicate anything about what will happen. 00.37.48 # I'm just relaying what I was told when I came in here and asked several people about what the dangers of it would be. 00.38.18 # Not to mention the concerns dreamlayers brings up in his last comment (2009-03-25) regarding the use of said patch to charge through accessories. I take that comment to reinforce my belief that the caution is so that 500ma is not blindly drawn from a device incapable of safely delivering said current. 00.39.17 Join lee321987 [0] (n=chatzill@64.24.51.170) 00.39.41 Quit lee321987 (Client Quit) 00.40.52 # New commit by 03kugel (r21086): Samsung YH*: A few keymap tweaks (still nothing final yet) ... 00.41.36 # soap: That's something we can never know without a lot of experimenting though. 00.41.57 # There would be no way to tell in advance if accessories have over current protection. 00.42.02 # And we're not talking about charger mode 00.42.08 # We're talking about during a USB connection 00.42.25 # During a USB connection (as we do have charger detection already and can distinguish) we should treat it like a USB port 00.42.43 Quit efyx_ (Remote closed the connection) 00.43.16 # (final thing I will say, as dreamlayers is likely the one to answer this) but the "monster" I spoke of is that. Giving a user the choice of "no charge" or "unsafe charge" seems really odd when the option of rebooting into Apple's Disk Mode is so (relitively) painless. "This might cause hardware damage, all the possibilities haven't been tested." seems like an odd disclaimer to make of a release. 00.44.18 # the samsung fails at charging for most of my usb ports too (in the OF) 00.44.47 # My iPods charge fine on my MacBook, except for my iPod 2G since that has a bad FireWire port. 00.44.57 # LambdaCalculus37, USB charge? 00.45.21 # soap: With the ones that support it, yes. 00.45.27 # low_light: did you get that backlight? 00.45.39 # which models are that? A 5th gen? 00.46.00 # soap: Both my video and my Color. 00.46.15 # My fifth gen won't charge under any circumstances (charger or USB port) in Rockbox w/o that patch. 00.46.48 # soap: Ahh, that's why. I was charging via the OF. 00.46.53 # the only thing foobar2000 seems to not know about is the "key" I should be able to access with ACTION_USB_HID_MENU (Power button on c200) - it just doesn't "see" that button. Don't know whose fault it is though... 00.48.06 # * LambdaCalculus37 wonders if we should be creating a separate target for the GoGear HDD6330 00.48.50 # Is it known what iPods can USB charge currently in Rockbox (not OF) reasonably? (reasonable being playback stopped, backlight/LCD off, 12 hours or less) 00.49.32 # soap: Even the OF isn't expected to work with low powered USB ports 00.49.37 # * Llorean just found it on Apple's site 00.49.38 # soap: My brother's iPod mini charges well in Rockbox. 00.50.31 # Llorean, I've never had the OF fail to charge, even on my wife's 199x (P-II) laptop. 00.50.33 Quit matsl_ (Read error: 60 (Operation timed out)) 00.50.45 # Maybe that laptop has a 500ma port - I don't know. 00.50.54 # Is it USB 2.0? 00.50.57 # no 00.51.23 # Does it work with USB-powered disks? 00.51.36 # HDDs? No. 00.51.51 # I'm just sayin', the apple site itself says they aren't expected to work on low-powered ports (such as those in keyboards or bus-powered hubs) 00.52.29 # I have a bus-powered hub - I'll add that to my list of limited things I have the means to test tonight. 00.52.34 # It doesn't even just say they won't charge, it says they will not work, which makes me think it may be a similar situation to what gevaerts mentioned (failing to connect on the request for 500, not able to reconnect after) 00.53.32 # soap: I'm only suggesting we use the charging for when we detect it IS a USB connection and not a charger (we've already done that detection for years on iPod). 00.53.35 Quit robin0800 (Read error: 110 (Connection timed out)) 00.53.58 Quit ender` (" If you're feeling good, don't worry, you'll get over it.") 00.54.31 # JdGordon: Trying to test your patch. Having a real odd problem getting the build on my Nano. 00.54.55 # Ok, I have a dead Nano plugged into a bus-powered hub, in OF, dead battery. 00.54.59 # low_light: Ping 00.55.15 # (well, will be OF, hold switch is on) 00.55.31 # soap: Dead battery isn't the question. 00.55.35 # Will it connect to a computer? 00.55.41 # It just did. 00.55.51 # got enough charge to boot and connected instantly. 00.55.58 # Apple's site says it won't work 00.56.04 # Then again, my Nano currently charges in Rockbox. 00.57.53 # * LambdaCalculus37 is reading some of the info on the GoGearHDD6330 00.58.51 # soap: Willing to try with your Video? 00.59.07 # Try plugging it into an unpowered hub? 00.59.20 # soap: Yeah, see if it connects properly. 00.59.24 # With or without FS#8802? 00.59.25 # New commit by 03kugel (r21087): Samsung YH*: enable bmp scaler and core jpeg support 00.59.33 # soap: Without, I guess. 00.59.38 # Just curiosity here 00.59.41 # Ok, let me go get it. 00.59.42 Quit agaffney ("Reconnecting") 00.59.46 Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) 01.00.05 # The Apple site suggests that Disk ipods are more problematic (it says the Nano and Shuffle will work even USB 1.1, while other iPods won't, and not to expect unpowered ports to work at all) 01.00.23 # Put the Nano on charge on a current (well current until kugel just acted) build with a battery @ 6%. Started battery bench, no playback, see how long charging takes. 01.00.51 # what? 01.00.52 # Nano is on a powered hub.. 01.01.10 # I was teasing about the definition of "current", kugel. 01.01.30 # ah, heh 01.01.31 # JdGordon: Having issues with the patch. There was one failed hunk, I fixed it, but the error I'm getting is related to a different file (settings list, which isn't where the failed hunk was 01.01.57 # current has another meaning for me if the word charge and/or battery is near :) 01.02.52 Quit funman ("leaving") 01.03.36 # Unhelpful: ping 01.04.40 # let's see how big the binsize delta is 01.07.40 # Llorean: probably the usual dependancy problem... delete the whole build folder and start again 01.07.45 # make clean doesnt remove enough 01.07.48 # JdGordon|: I did it in a new folder 01.07.53 # arg 01.07.55 # It seems to be a LANG_ problem 01.08.03 # missed a hunk? 01.08.43 # hmm, Nano disconnected when I plugged in the Video 01.09.02 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 01.09.09 # JdGordon|: Only one hunk failed, and it was where you removed all the #defines in USB.H and replaced them with two lines. 01.09.53 # By "all" I just mean "many", sorry 01.09.56 # Not *every* #define 01.10.06 # ok, i guess ill look later... (trying to do real work now :p ).. can you have a look at the manual part of the patch? 01.12.02 # oh, I fixed yellows :) 01.12.05 # Well, the text looks okay to me. 01.12.25 Join renke [0] (n=renke@e177184185.adsl.alicedsl.de) 01.12.35 # it reads funny though... i tried to rearrange it so the default is first but gave up 01.14.27 # It may be a little wordy, but I've never been good at not being wordy I think 01.16.51 # My iPod Video mounts in Rockbox and OF through an unpowered hub, and I am able to successfully transfer files to it. 01.18.19 # Llorean, JdGordon|: I would suggest a "When set to Off" instead if "When this is Off", the latter sounds a bit weird to me 01.18.37 # s/if/of 01.19.10 # Originally I wasn't sure if it was going to be "off/on" or "charging/connect" or some other pair 01.20.54 # i belive its on/off 01.21.03 # although its easy enough to change 01.22.15 Quit matsl (Read error: 60 (Operation timed out)) 01.22.40 # 16k, not bad, and totally worth it 01.24.17 Quit msscott (Remote closed the connection) 01.26.11 Quit HellDragon (Read error: 60 (Operation timed out)) 01.26.58 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-e662c44523b74ecf) 01.28.25 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 01.31.31 Quit Thundercloud (Remote closed the connection) 01.32.12 Quit HellDragon (Client Quit) 01.35.44 *** Saving seen data "./dancer.seen" 01.38.57 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 01.40.55 Quit low_light ("http://www.mibbit.com ajax IRC Client") 01.41.14 Join pyro_maniac [0] (n=pyro@91-64-227-210-dynip.superkabel.de) 01.41.37 Part pyro_maniac ("Leaving.") 01.43.46 Quit renke (Read error: 110 (Connection timed out)) 01.47.35 Join jordoex [0] (n=quassel@S0106002129693a39.vc.shawcable.net) 01.47.54 # for what its worth blindly pulling 500ma off of any connected port is pretty typical 01.48.03 # the Sansas do it 01.48.47 # in practice the 500mA specification seems to be the maximum a device can pull, but most devices supply much more to protect against non-compliant devices and people stringing multiple devices onto a passive hub 01.48.57 # the sansas do not have the problem of exessive current drawing while file transfers though 01.49.37 # kugel: Sansas pretty much had the same problem iPods do now before charging support went in. 01.49.58 # It's not excessive. Most disk based iPods just draw more because there's a disk to spin, and they still pull the 100 that Sansas used to pull 01.50.06 # IIUC, the problem with the ipods is, that they tend to even discharge when transfering 01.50.29 # Yes, they do, but not because of any excessive activity 01.50.36 # Just because they don't yet pull full power from the PC 01.50.37 # due to the disk(?) 01.50.55 Quit lightbulbjim ("leaving") 01.52.19 # USB has to be boosted. That combined with the disk (and I'm not sure, is the screen always lit?) leads to decent power usage just naturally 01.52.32 # Meanwhile we draw what is essentially minimal power. 01.53.04 # the e200s actually would have discharged with just 100mA too, since they needed about 150mA with the wheel light on IIRC 01.53.27 # saratoga: I seem to remember whether they discharged or not seemed to vary from reporter to reporter back then 01.53.43 # probably if they had the wheel light on 01.54.14 # did you messure what the wheel draws? 01.54.27 # yes but i lost the notes 01.54.38 # it was about 150mA with wheel + screen 01.55.11 # i'm sure its in the october or november 2007 IRC logs if really needed 01.55.56 # hmm skimming that task, whats the reason we can't just request 500mA ? 01.57.10 # saratoga: Fear that accessories may not deal with it well because the Apple firmware distinguishes what's connected by voltage, mainly, I think 01.57.47 # And it would be nice to have a setting for "low draw" mode for when someone really wants to hook it up for a short time to something that doesn't provide full power, I guess. 01.58.09 # Llorean: does the case where its connected to a USB port and the OS grants 500mA work ok? 01.58.18 # As far as I know, yes. 01.58.24 # I haven't tested it personally. 01.58.32 # so the problem was just AC chargers? 01.58.39 # lol, the OF is messed up with rockbox on the samsung 01.58.48 # screen morrored and flipped 01.58.53 # AC chargers (which I believe we can already distinguish on the iPod anyway), Accessories, and what happens if the OS doesn't/can't grant 500 01.59.32 # and I suppose theres no way to detect voltage sag and stop charging? 01.59.55 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 01.59.57 Quit LambdaCalculus37 ("Fwump") 02.01.05 Quit kugel ("exit(0);") 02.05.23 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 02.06.59 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-3a324a34dfe8bd67) 02.07.19 Quit jordoex (Read error: 60 (Operation timed out)) 02.12.01 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 02.15.41 Quit barrywardell (Remote closed the connection) 02.20.04 Quit salty_horse ("Leaving") 02.26.30 Quit HellDragon (Read error: 104 (Connection reset by peer)) 02.26.30 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 02.26.44 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 02.32.52 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-cd02b63f8e717018) 02.36.05 # kugel: what's up? 02.41.53 Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") 02.45.03 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-830d86a0c611a098) 02.46.18 Quit tessarakt ("Client exiting") 02.48.41 Join evilnick_home1 [0] (n=evilnick@pool-173-52-140-75.nycmny.east.verizon.net) 02.53.24 # saratoga, as per your question to Llorean regarding the FS charging task: 02.54.25 # I have been using that patch daily since it was posted and have successfully charged on a variety (ok, four) of computers and wall chargers. This is with my iPod Video. I was getting no appreciable charge w/o the patch. 02.54.49 Quit evilnick_home (Read error: 60 (Operation timed out)) 02.55.25 # I was getting no charge either via USB computer ports /or/ via my Griffin cigarette lighter -> usb charger. I did not test w/o the patch on the Apple wall charger (which I also have). 02.55.48 # soap: The griffin one, does it detect properly as a charger or do you have to hold Menu? 02.55.56 # If that is a test which anyone finds desirable (with battery bench) just tell me and I can do it. 02.56.08 # Llorean, let me go double check. 02.56.14 # * Llorean never really did find out of when we added USB support, we broke the old charging we used to have. 02.56.19 # *out if 02.57.29 # (side note) I so very rarely touch the OF, when I press Menu+Select the piezo startles me. BRB. 02.57.41 Join barrywardell [0] (n=barrywar@79.97.87.212) 02.58.35 Quit barrywardell (Client Quit) 03.00.00 Join barrywardell [0] (n=barrywar@79.97.87.212) 03.01.45 # Both the Griffin PowerJolt (12v -> USB) and Apple's Original AC->USB chargers are detected as chargers by my iPod Video. 03.01.51 # (in Rockbox) 03.02.13 # Those chargers used to charge while playing in Rockbox just fine (as in pre-USB) 03.02.21 # Did we have some code that's disabled now that we have a proper stack? 03.02.32 # Well, those *sorts* of chargers. 03.07.24 # I'll post battery benches tomorrow. Nano via USB and Video via wall charger. Will switch and do the opposite the next night. 03.08.26 # Well, you already said it doesn't seem to charge for you via the cigarette lighter adapter. 03.08.33 # I know my Nano used to charge by my Griffin one just fine. 03.08.49 # Then again, Nanos use a bit less power so it may have just been that I was coming in under the line. 03.14.09 Join JdGordon| [0] (i=43a02c5a@gateway/web/ajax/mibbit.com/x-21a268e2e27cd927) 03.18.53 Quit martian67 (No route to host) 03.20.03 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 03.25.57 # I'd rather "have it in writing" than my anecdotal evidence. ;) 03.26.12 # Gotcha 03.33.33 Join froggyman [0] (n=47ba0b80@gateway/web/cgi-irc/labb.contactor.se/x-482066994945dce0) 03.35.47 *** Saving seen data "./dancer.seen" 03.36.23 # i think this is finally ready: http://pastie.org/489582 03.38.19 # includes the "new scaler math" that gevaerts and i have tested on ARM and Coldfire, and preserves the old math on sh-1, where it costs fewer multiplies. only real questions i have left are 1) is sc_mul_u32_rnd correct/optimal 2) is some of the #ifdef stuff to preserve the old math on SH-1 a little too ugly 03.47.16 Quit barrywardell () 03.52.09 Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") 04.05.53 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 04.11.00 Quit bittin```` (Read error: 110 (Connection timed out)) 04.25.14 Quit bertrik (Read error: 113 (No route to host)) 04.29.29 Quit froggyman ("CGI:IRC") 04.42.38 Quit miepchen^schla (Read error: 101 (Network is unreachable)) 04.47.55 Join bubsy [0] (i=Bubsy@94.139.72.137) 05.02.58 Quit Riku (Read error: 104 (Connection reset by peer)) 05.34.23 Quit Horscht ("Verlassend") 05.35.49 *** Saving seen data "./dancer.seen" 06.05.18 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.27.03 Quit topbloke ("bye") 06.28.25 Quit markun (Read error: 54 (Connection reset by peer)) 06.28.32 Join markun [50] (n=markun@rockbox/developer/markun) 06.30.12 # :'( so close! just need to get one extra redraw and background wps will work perfectly 06.32.09 # I tihnk I have to resort to clearing the 4 rectangles around the UI viewport... arg :/ 06.35.29 Join AndyIL [0] (i=AndyI@212.14.205.32) 06.40.15 # grrrr 06.46.35 Quit AndyI (Read error: 110 (Connection timed out)) 06.48.32 # ... getting closer :) 07.06.41 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.12.53 Join JdGordon| [0] (i=43a02c5a@gateway/web/ajax/mibbit.com/x-535b7fe3fe0bbbf7) 07.13.01 Quit JdGordon| (Client Quit) 07.25.49 Join renke [0] (n=renke@134.106.200.218) 07.35.51 *** Saving seen data "./dancer.seen" 07.38.25 Quit tchan (Remote closed the connection) 07.39.01 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 07.40.20 Quit fyre^OS (Read error: 54 (Connection reset by peer)) 07.56.56 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.57.17 # fuck yeah! /me loves it when simple solutions work 07.57.56 # oh man this is awesome! 08.00.01 # Unhelpful: What is the advantage of the new scaler math? It might be better to use it on SH1 as well even if it is a little slower, if there are other advantages 08.03.44 # * JdGordon curses the 3 month release cycle..... 08.03.52 # its almost lockdown/cleanup time again 08.07.49 # JdGordon: Does the list viewports patch work pretty well? 08.08.01 # It seems a pretty big change to be trying to squeeze it in right before the freeze. 08.08.17 # from my limited testing it appears to work 08.08.53 # there will probably be small redraw glitches in the wierd screens which can be fixed when found 08.09.18 # I guess that means you saw the tracker comment? :p 08.09.23 # Yup 08.10.08 # I mean, if you got it in during the next few days, that'd give time for it to be tested (so that it could be reverted for the branch if it turned out more problematical than expected) 08.10.38 # kugel has been working on it for ages now so im pretty confident the big bugs are known and fixed 08.11.37 # Does it work well with remotes? 08.11.40 # I assume that if/when background WPS goes in, we will want to keep the current statusbar avilable (at least for a while anyway) 08.11.58 # it *should*, I cant imagine why it wouldnt.... 08.12.12 # Unhelpful: The SH1 sc_mul_u32_rnd does add %[t2], %[r] twice, and seems to miss add %[t3], %[r] instead 08.12.55 # JdGordon: Either way, with short freezes, we should be being careful about what goes in for the period leading up to them too. 08.13.12 # It shouldn't be a race to get a feature done before the freeze. 08.13.19 # Otherwise this is a quite clever way to handle the 64 bit intermediate (exploiting the fact that it actually isn't full 64 bit) 08.13.58 # meh, well, I actually thought there was nothing interesting in the next release.. completly forgot about the recent (and enabled) additions 08.14.20 # Llorean: Imo it wouldn't be wise to have a freeze around devcon 08.14.39 # JdGordon: It doesn't really matter whether there's something interesting, the idea is just to have a regular "stable" release. 08.14.50 # i know... i know... 08.15.18 # amiconn: I don't know if it's that big of a deal. 08.15.43 # JdGordon: Does list viewports give anything user visible without background WPS? 08.16.09 # JdGordon: And as I said, I'd be a lot more happy if it got in *soon* so there could be some more widespread testing before the freeze. ;) 08.16.30 Join ender` [0] (n=ender@84.255.206.8) 08.16.31 # amiconn: yeah, it might mean some nasty bugs get fixed though? 08.17.05 # Llorean: umm, no not really... without the WPS addition it just lets you position the list to fit in a ncie background or something 08.17.36 # * JdGordon thinks that background images could cause problems here 08.17.44 # JdGordon: Well, that's still something user visible. Cause problems how? 08.17.51 Quit jmillikin (Read error: 110 (Connection timed out)) 08.17.58 # who thought it was a good idea to let users choose a differnt image in the wps than in the menus? :/ 08.18.21 # the menu background will get shown under the wps parts i tinhk 08.18.27 # Ah, that's not good. 08.18.46 # thats also the fault of the themer though 08.18.59 # there isnt really anything that can be done about that 08.19.26 # untill we allow each viewport to specify its background image 08.19.39 # As long as current themes aren't broken, and new themes can be made "properly" I don't really see a problem if it's also possible for people to make them badly 08.21.19 # So the WPS background is treated as a sort of "full screen" backdrop, while the list backdrop only shows up in the list viewport, or what? 08.22.34 # right now its a bit of a hack (which probably wont get any better)... the wps is told to update, that will take out the whole screen if the themer isnt careful, the list *should* then get drawn where it was told to 08.23.07 Quit renke (Read error: 110 (Connection timed out)) 08.23.39 Join Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 08.23.57 # I've attached the test.wps to the FS comment 08.24.25 # So contant WPS updates even when not in the WPS? 08.24.25 # Isn't that pretty harmful to battery life? 08.25.23 # I seem to recall significant battery life savings by just putting it in the list rather than the WPS during playback. 08.25.52 # well, yes.. but its pretty :) 08.26.04 # this will need a setting to disable it 08.26.35 # and make it work with the "dont update the wps if the backlight is off" code 08.26.45 Join SUSaiyan` [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) 08.26.52 # So it's still got a pretty long way to go anyway? 08.27.29 Quit SUSaiyan (Read error: 113 (No route to host)) 08.27.37 # not really, those 2 bits are small 08.28.23 Quit Zarggg (Read error: 60 (Operation timed out)) 08.28.45 # I imagine "update WPS while list is shown" will be an 'invisible' setting, set by themes, rather than a user setting? Basically, when the WPS is loaded, it'll tell Rockbox via this setting whether some part of it is visible in the list and needs updating? 08.29.26 # And I guess, defaulting to "Off" and needing to be added to existing themes unless there's a better way 08.31.08 # well, it would be up to the theme .cfg more than the .wps i tihnk... 08.31.16 # Sorry, yeah, theme. 08.31.24 # But 'hidden' setting and all that. 08.31.26 # but yeah, hiden like the .icons file 08.32.09 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.34.51 Join matsl [0] (n=matsl@dhcp86.contactor.se) 08.36.00 Join Rob2223 [0] (n=Miranda@p4FDCD00E.dip.t-dialin.net) 08.40.01 Join wincent [0] (n=wincent@host-091-097-048-211.ewe-ip-backbone.de) 08.40.28 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.52.01 Join flydutch [0] (n=flydutch@host100-164-dynamic.8-87-r.retail.telecomitalia.it) 08.53.37 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.00.49 Join einhirn [0] (n=Miranda@p4FC61AC0.dip0.t-ipconnect.de) 09.20.45 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.22.35 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.24.32 Quit bertrik (Read error: 113 (No route to host)) 09.27.50 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 09.27.57 Join Demy [0] (n=40fc73b2@91.191.140.131) 09.28.01 # Heya 09.28.18 # hi 09.28.35 # Heya 09.28.44 # hmmm 09.28.48 # Lagggg 09.28.56 # Shoulda loaded this onto mirc instead web 09.29.17 # :( Someone has BOth my nicks on this network apperantly 09.29.25 Nick Demy is now known as CizziIII (n=40fc73b2@91.191.140.131) 09.30.21 # CizziIII: Do you have a rockbox-related question? 09.30.25 # Can't register nicks? 09.30.33 # Oh I do, is there a way to purge the database? 09.30.43 # "Initialize Now" regenerates it from scratch. 09.31.07 # Mmkay, is there a reason it likes to add some files twice? (I already checked to see if the file was in there twice.) 09.31.25 # Often this means there's a recycle bin or .trash folder or similar that you're not spotting 09.31.27 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.31.43 # I have neither of those on here. 09.32.15 # And when I plug it into my PC via USB I only see one file. I've done searches on the drive aswell. 09.32.52 # Have you checked to see what file each of those database entries point to? As i said, they often really do point to a second copy that's hidden. 09.32.52 # Make sure you have your PC's file browser set to show hidden files. 09.33.32 # PC is set to show hidden files, and the database entties for both times leads back tot he same file. 09.33.53 # It happens on and off and usually after Music's been on it for awhile. It's just. odd. 09.33.55 Join petur [50] (n=petur@rockbox/developer/petur) 09.34.11 # CizziIII: How did you check what they lead to? 09.34.47 Quit bmbl ("Woah!") 09.35.29 # Er, I'd have to run through what I did again, give me a second. 09.35.53 *** Saving seen data "./dancer.seen" 09.36.52 # Nevermind, I'm able to check paths in folders nott he database, I had no clue where they were pointing to in the database. 09.44.35 # CizziIII: from the While Playing Screen, go to the context menu, then "Show Track Info". 09.47.36 # Got it, none of the songs on this update are doubleadding though, I'm just missing album artwork? O.o 09.49.52 # Bah... I'm guessing the Album art I add in iTunes won't carry over for the eockbox album art stuff? 09.50.20 # rockbox* 09.50.25 # correct. Rockbox expects it to be in a certain place. See the AlbumArt wiki page. 09.51.35 # ALright, cool. Thanks. 09.59.31 Quit Thundercloud (Remote closed the connection) 10.02.03 Part Llorean 10.02.29 Join Llorean [0] (n=DarkkOne@adsl-99-148-246-63.dsl.hstntx.sbcglobal.net) 10.15.12 # I see multiple copies of some songs in the database 10.15.20 # I suspect this is due to m3u playlists though 10.16.25 Quit JdGordon (Read error: 60 (Operation timed out)) 10.20.24 # the database isn't aware of playlists 10.24.30 # hm, I wonder why it happens, then 10.25.22 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 10.25.31 # it's not a showstopper to me, not much more interested than mild curiosity 10.25.48 # Have you checked them manually from the context menu to verify that they're all the same actual file, and not duplicates in trash or similar? 10.26.45 # Llorean: do I need to enable a debug option? context menu lists only "Playlist" item 10.28.46 # the properties plugin also shows path and filename (from the file browser), or the WPS context menu while the track is playing 10.29.06 # lucent: While playing the song, the WPS context menu should have an option for properties or file info 10.29.22 # lucent: I guess you are using the context menu on an item in the database browser 10.29.33 # oh, alright then. right you are pixelma 10.30.55 # of course... you will only find the (potentially different) files in the file browser if you already know the path... stupid me 10.32.43 # 1) ##MUSIC#/Music/Alias @ Ehren/Lillian/Alias & Ehren - Cobblestoned Waltz.mp3 10.34.04 # 2) ##MUSIC#/Music/Alias @ Ehren/Lillian/Alias & Ehren - Coblestoned Waltz.mp3 10.35.19 # I assume the difference in the strings is a typo? 10.35.22 # 3) 3) ##MUSIC#/Music/Alias @ Ehren/Lillian/Alias & Ehren - Cobblestoned Waltz.mp3 10.35.25 # yes 10.35.31 # You don't need to paste them all here. 10.35.39 # my typing is not quite 100% tonight, it's not a paste 10.35.42 # This is a recent official build of rockbox? 10.35.46 # I didn't know if they would be different 10.35.54 # nah, just SVN clunky-ness 10.35.57 # Well, I meant, there was no reason we needed to knwo any of the strings. 10.36.07 # you asked for them. 10.36.11 # I asked you to check them 10.36.24 # then too bad, I can't untype them 10.36.26 # A simple "they're the same" or "they're different" was more or less what I wanted. 10.36.26 # :) 10.36.54 # You should try using an SVN build, and report a bug if you can get a clean database to show duplicates. 10.38.00 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 10.38.02 # okay, thanks for that information 10.38.09 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-5bd3078ac5f9fecc) 10.40.33 Part webmind 10.49.12 # ah, I forgot to check but I see there are now 106 builds in the table 10.49.55 # I also removed the slowest server since I think it delayed more than it helped 10.50.21 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 10.53.41 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 10.55.57 Quit einhirn (Read error: 104 (Connection reset by peer)) 11.01.41 Quit CizziIII ("CGI:IRC (EOF)") 11.03.30 # Bagder: Being which? 11.03.37 # oldsch00l 11.04.04 # it did lots of >400 second builds lately 11.05.40 # curious difference between the YH models: the 920 one uses far less ram... why? 11.06.07 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 11.06.18 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-fd5fcad7bd90b984) 11.14.36 Join pyro_maniac [0] (i=foobar@p57BBA367.dip0.t-ipconnect.de) 11.20.10 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 11.35.56 *** Saving seen data "./dancer.seen" 11.37.35 Join petur2 [50] (n=petur@rockbox/developer/petur) 11.37.59 Quit petur (Nick collision from services.) 11.38.03 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 11.38.55 Join n1s [0] (n=n1s@rockbox/developer/n1s) 11.43.55 Join stripwax__ [0] (n=Miranda@87-194-34-169.bethere.co.uk) 11.53.33 Quit stripwax (Read error: 110 (Connection timed out)) 11.54.50 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 11.56.37 Quit n1s (Read error: 104 (Connection reset by peer)) 11.57.28 Join n1s [0] (n=n1s@rockbox/developer/n1s) 12.07.05 Quit stripwax__ (Read error: 110 (Connection timed out)) 12.10.46 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 12.18.04 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 12.20.54 Quit robin0800 (Remote closed the connection) 12.26.21 Join kugel [0] (n=kugel@141.45.204.41) 12.26.39 # Bagder: the 920 is greyscale 12.26.47 # others are color 12.26.49 # ah, that explains it 12.26.57 # thanks 12.27.39 # the 925 is doing really well, it seems almost complete once we get some battery charging/monitoring 12.29.52 Quit itcheg (Remote closed the connection) 12.31.36 Join funman [0] (n=fun@rockbox/developer/funman) 12.35.41 Quit daurnimator (Read error: 101 (Network is unreachable)) 12.39.49 # kugel: FlynDice I put the patch I used for benchmarks at FS#10191 12.40.59 # funman: the rebuffer problem was apparently a currupted file. It messed up my battery bench last night :( 12.41.19 # :/ 12.42.35 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.43.07 # do we have benches for the higher pclk already? 12.50.44 # do you mean higher than 62 ? that'd be only 64 12.56.05 Join Rasi [0] (n=carnager@e182052104.adsl.alicedsl.de) 12.56.08 # hello 12.56.16 # just checked the website for e200v2 support 12.56.22 # and its not even listen as "soon to come" 12.56.38 # i thought its already usable, more or less? 12.56.43 # Rasi: you can help us making it come sooner 12.57.41 # was just wondering, why there is no mentioning of it 12.57.55 # anyway, whats the place to look for, if i decide to help out? 12.58.40 # one of the places is here : i'm one of the v2 "ams" port guys 12.58.44 # I doubt there will ever be a "soon to come list"... also, there is a "Status for current and work-in-progress targets" link 12.59.00 # pixelma: thats the one i mean 12.59.06 # work-in-progress 12.59.16 # it only talks about the C200 12.59.24 # Rasi: look for "sansa ams" 12.59.31 # and it lists the v2 Sansas (though a bit hidden) 12.59.38 # Rasi: even for ports that are almost good enough to be "supported" there's no guarantee that they ever will be... 12.59.41 # ah 12.59.41 # i'll change it to mention explicitely e200v2 12.59.43 # stupid me 12.59.54 # A coming soon list just wouldn't work 13.00.00 # As nobody knows what soon is 13.00.05 # yea yea, that wasnt my question at all :) 13.00.23 # Rasi: fixed :) - so you wanted to help .. ? :) 13.00.26 # The Beast for example has been in an almost-good-enough state for several months 13.00.35 # funman: depends on how i can :) 13.00.41 # And there is a reason it isn't supported yet - feel free to dive in and help develop, but until it is supported it isn't really for end users 13.01.26 # yea i know that 13.01.42 # my question was only about me being too blind to see that it actually IS mentioned :P 13.02.01 # Rasi: if you want to help on the technical side first you should read the last forum pages, and flyspray tickets mentioned here. You can also help on integration of firmware patcher into rbutil (C++ & Qt4), and work on the manual (I already started for the Fuze & the Clip, so it's relatively easy) 13.03.30 # pixelma: by the way, most of the front device svgs in the manual look like they were made on your computer : can you draw pictures for Fuze and Clip ? (e200v2, m200v4, c200v2 can use their predecessors images) 13.07.03 Quit kugel (Read error: 110 (Connection timed out)) 13.08.58 Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) 13.18.46 Quit timc (Read error: 104 (Connection reset by peer)) 13.21.20 # probably, if I find some time to do it 13.34.12 Join preglow [0] (i=thomj@rockbox/developer/preglow) 13.35.59 *** Saving seen data "./dancer.seen" 13.36.09 # Samsung YH920 is greyscale? Greylib already working? 13.37.05 # amiconn: yes it's working in my unmerged patch 13.38.04 # funman: did you have incomplete splashscreens on the yh-920 too? 13.38.09 # yes 13.38.18 Join BXCracer_ [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 13.38.52 # is this mentioned somewhere or is it enogh that you and me know this? 13.39.25 Quit BXCracer_ (Client Quit) 13.39.33 # well i don't know, i have no idea what the problem could be, and now i'll focus on merging my few diffs, and finding how to enable sound :-) 13.40.33 # ok so i will take a look later and maybe i will write it down somewhere 13.40.44 Join timc [0] (n=aoeu@221.201.167.174) 13.41.25 # pyro_maniac: you can look at plugins if you want 13.42.04 # funman: ok, i hope i will find some time later 13.52.04 Join kugel [0] (n=kugel@rockbox/developer/kugel) 13.52.14 # amiconn: well, plugins don't run yet, so no greylib 13.52.54 Quit kugel (Remote closed the connection) 13.59.42 Quit evilnick_home1 ("Leaving.") 14.00.20 Join evilnick_home [0] (n=evilnick@pool-173-52-140-75.nycmny.east.verizon.net) 14.07.46 Quit matsl (Read error: 110 (Connection timed out)) 14.15.20 Quit Rasi ("WeeChat 0.3.0-dev") 14.19.43 Quit linuxstb (Read error: 113 (No route to host)) 14.27.19 # amiconn: the main advantage is speed on CPUs with a fixed multiply cost. the input size limits also go up a little bit, but the "old math" limits with the sh-1 16x16 multiply used in the first stage are already quite good: a maximum downscaling factor of 1/257, and maximum input size of 2^24 pixels. 14.28.13 Join matsl [0] (n=matsl@dhcp86.contactor.se) 14.28.20 # i see the mistake regarding t2/t3... that's fixed now. 14.32.46 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/ajax/mibbit.com/x-cf6cf576868432cb) 14.43.17 Quit flydutch ("/* empty */") 14.59.30 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-e3754cb15caca197) 15.01.39 # i'm a bit lost in YH920 disassembly, I only found some parts of the code lowlight wrote in akcodec-yh82x_yh92x.c 15.09.39 Quit gevaerts (Nick collision from services.) 15.09.48 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 15.10.31 Quit funman ("leaving") 15.16.04 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 15.16.36 Join darkham [0] (n=darkhamm@79.46.183.156) 15.22.42 Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-3f2a88d030237c95) 15.36.00 *** Saving seen data "./dancer.seen" 15.37.00 Join jfc [0] (n=john@dpc691978010.direcpc.com) 15.38.57 # pixelma, petur: Unfortunately, after removing the "start recording" part of the new_file action, the REC button no longer starts recording (it just splits). It seems intuitive that it should start recording, especially on the h300. 15.44.53 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 15.47.22 # ah, you removed the REC function of the REC button... I though PLAY was splitting... never used splitting... 15.47.28 # I wonder if the GoGear HDD6330 should be given its own target instead of just modifying the HDD1630 build to accommodate for it. 15.48.40 Quit stripwax (Read error: 104 (Connection reset by peer)) 15.49.21 # lowlight: Ping, around? 15.49.40 # * LambdaCalculus37 sees he isn't here 15.50.20 # lowlight (for the logs): I want to talk with you about possibly splitting the HDD6330 and HDD1630 into their own separate targets. It may make it easier to build and work on it. 15.50.28 # using rockbox as a foobar2000 remote is fun :D 15.51.44 # MarcGuay: I assume the recscreen uses ACTION_STANDARD_OK as the "normal" way of starting a recording? Maybe the keymap should just be adapted a bit... 15.51.48 # * martian67 has a fantasy of rockbox as a usb monitor 15.51.56 Join renke [0] (n=renke@g225192215.adsl.alicedsl.de) 15.51.59 # I cant ever see that being realistic though 15.52.00 # lol 15.58.03 # martian67: not technically impossible :) 16.01.07 # neither is a rockbox powered spacecraft :P 16.24.55 Join akur [0] (n=akur@193.136.33.133) 16.25.02 Part akur 16.35.02 Join funman [0] (n=fun@rockbox/developer/funman) 16.36.37 Quit renke ("Lost terminal") 16.37.56 # gevaerts, I am trying to compile a new build using udma patch and your FS10239 16.38.12 # unfortunately, UDMA patch seems out of sync and fails 16.38.55 # http://pastebin.ca/1434994 16.40.33 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 16.41.05 # http://pastebin.ca/1435000 respectively 16.41.34 # Horscht: rolling back your checkout to r21082 should help. You only miss the new YH-* port bits then 16.44.47 # ok, thanks 17.06.05 Quit Zagor ("Don't panic") 17.08.24 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 17.08.39 Quit daurn ("Cyas") 17.17.22 Quit darkham (Read error: 110 (Connection timed out)) 17.23.33 Quit SirFunk_ (Read error: 110 (Connection timed out)) 17.24.32 Quit matsl (Read error: 110 (Connection timed out)) 17.30.07 Join petur2 [50] (n=petur@rockbox/developer/petur) 17.30.28 Quit petur (Nick collision from services.) 17.30.30 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 17.31.49 Nick Zarggg_ is now known as Zarggg (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 17.36.04 *** Saving seen data "./dancer.seen" 17.50.52 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 17.52.22 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 17.58.17 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 17.58.20 Quit faemir ("Leaving") 18.00.13 # pixelma, petur: What about making the record button (if available) do Record and Pause and move Split to another key? Then there would be two buttons that did the same thing on those targets... 18.00.24 Part wookey_ 18.01.11 # Split seems a bit of a rarely used feature and would probably be okay on a long-select or similar... 18.02.08 # Wouldn't it seem a bit weird that play = pause on playback but Record = pause on recording though? 18.02.09 # Record should definitely start recording... As should Play... 18.02.48 Quit SirFunk__ (Read error: 110 (Connection timed out)) 18.02.54 # evilnick: I was thinking the record button and the play button would both do the same actions: Record and Pause Recording. 18.03.29 # except on the c200 were "Play" is also "Up" :\ 18.03.35 # And move split somewhere else.. 18.03.44 Join webguest50 [0] (n=3cf0b8fa@gateway/web/cgi-irc/labb.contactor.se/x-e93ab2afb48cfcf9) 18.03.54 # pixelma: The c200 and c100 are brutal. 18.04.25 # Hi. 18.04.48 # MarcGuay: Ah, I see. 18.04.49 # webguest50: Hello. 18.05.48 Quit n1s (Read error: 104 (Connection reset by peer)) 18.06.23 Join n1s [0] (n=n1s@nl104-208-152.student.uu.se) 18.08.11 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 18.15.51 # for those with knowledge of PP OF : the bl_*.rom is loaded to DRAM, does it copy a portion of it to IRAM, or is another piece of code loaded to IRAM ? 18.23.22 Join Rondom [0] (n=Rondom@dslb-084-057-153-052.pools.arcor-ip.net) 18.30.43 Quit petur ("work->sports") 18.32.57 Quit webguest50 ("CGI:IRC (EOF)") 18.37.16 Join andrewbeveridge [0] (n=andrew@88-109-101-174.dynamic.dsl.as9105.com) 18.37.39 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 18.40.05 Nick andrewbeveridge is now known as andrewxyz (n=andrew@88-109-101-174.dynamic.dsl.as9105.com) 18.40.50 Nick andrewxyz is now known as AndrewRB (n=andrew@88-109-101-174.dynamic.dsl.as9105.com) 18.45.35 Join Lss [0] (n=Lss@cm198.delta92.maxonline.com.sg) 18.49.32 Part AndrewRB ("Konversation terminated!") 18.49.55 Join AndrewRB [0] (n=irc@88-109-101-174.dynamic.dsl.as9105.com) 18.52.57 # hey, just curious, as I don't understand much of the hardware in my DAP... Why do we need an ADC to read button presses? 18.55.23 # well, afaiu that is one common hookup, they can also be hooked directly to a GPIO in which case you don't need an adc 18.57.22 # not quite certain that i understand the adc kind of button reading but i suppose they could use a resistor network for example and read the resistance with the adc 18.57.45 # right. ok. GPIO is just another acronym to me (...scurries off to google). ah, ok. It's just that from reading the target-specific button code for my D2, it looks like to read a button press we are reading an ADC, and I was wondering how button presses could be an analogue signal 18.58.16 Join miepchen^schla [0] (n=miepel@p579ECE9F.dip.t-dialin.net) 18.59.17 # true, I guess that is possible. but somehow given that the buttons in my D2 are the usual type in portable devices like DAPs - small, press-to-contact, soldered directly onto the PCB, I doubt it. It just stumped me =/ 18.59.21 # IANAEE (I Am Not An Electric Engineer) 18.59.33 # Nor am I, hence my lack of understanding ;-) 18.59.47 # thanks anyways =) 19.00.41 # AndrewRB: using a resistor network might save pins, is the usual reason, i think 19.00.55 # not all SoCs have loads of spare GPIOs once you've hooked up everythnig else 19.01.15 # if you arrange such that each button cuts in different valued resistors you only need one ADC pin to read a whole bunch of buttons 19.01.42 # Sure, op-amp. That helps me understand. thanks. 19.04.21 # there's never enough GPIO pins, from experience designing stuff :) 19.04.55 # pins require more space on PCB, I guess. 19.04.55 # once you turn on all the peripherals you need, and connect GPIOs for mandatory stuff like resets and so on, you never have enough for the actual general purpose stuff 19.04.58 # indeed 19.05.16 # who said size doesn't matter ;-) 19.05.23 # nobody around here, i'm pretty sure :) 19.05.30 # size doesn't matter. 19.05.56 # conversation stopper. 12 points. 19.05.57 # it's more the space to route the damn wires than for the actual pins, though :) 19.06.23 # wiring up a BGA package with 300+ pins requires a many-layer board, which is expensive 19.06.37 # see: pc motherboards 19.07.08 # the amazing thing is how cheap mobos are. 19.07.31 # * AndrewRB feels so inexperience whenever he reads acronyms which he doesn't understand >< 19.07.45 # ball grid array andrew? 19.07.45 # AndrewRB: SoC == system-on-chip, a processor + peripherals combined 19.07.52 # and yeah, he did BGA :) 19.08.30 # I know that, thankfully - read the spec on the TI site for my device's chip. BGA, no idea, google again. (ulp veering off topic sorry) 19.08.55 # ball grid array. a kind of chip package where the chip has a bunch of ball shaped pads on the bottom, instead of legs. 19.09.06 Join kugel [0] (n=kugel@rockbox/developer/kugel) 19.09.31 # inconvenient to solder or otherwise interfere with by hand :) 19.09.35 # funman: only 10h with 256/64 fclk and 64 pclk :( 19.09.41 # so you heat it in a reflow oven and they melt 19.09.49 # shorter signal path than pins, cheaper, etc 19.10.12 # * AndrewRB needs a new soldering iron 19.10.22 # me too man. once i get some money 19.10.25 # gevaerts, yay: http://horscht.googlepages.com/rockboxbench 19.10.26 # mine doesn't even have a thermostat 19.10.42 # i could use a scope that uses transistors too 19.10.57 # having to use a reflow oven moves it out of the quick hack arena somewhat :) 19.11.28 Quit linuxstb (Read error: 113 (No route to host)) 19.12.13 Join {phoenix} [0] (n=dirk@p54B46961.dip.t-dialin.net) 19.13.29 # kugel: i don't want to use illegal settings anyway, is there any gain from using 240MHz ? 19.14.00 # with 60MHz pclk or async? 19.14.34 # it seems that pclk is so critical for decoding, that we really should try to run it at 65MHz 19.15.46 # funman: with that 10h I'm much below svn runtime even though it boosts less 19.16.14 # we could try to reduce pclk when unboosted, but that leads to more boosting again :S 19.16.30 # when unboosted we also need decent graphic performance 19.17.17 # we could microboost in lcd_update(_rect)() (just going to 65MHz, keeping fastbus) 19.17.52 # * domonoky thinks we should concentrate on having stable clock settings, improving battery runtime can always be done later... 19.17.56 # is there a time penalty when switching ? 19.18.13 # we also need it for fast "file" transfers, but i don't know the performance loss here 19.18.30 # kugel: do you want my gnuplot scripts ? 19.18.39 # "my" = the one i stole on the web 19.19.28 # funman: the database doesn't mention any penalty 19.19.45 # datasheet* 19.20.08 # i meant arm specific, not as3525 19.20.16 # just wondering 19.20.53 # I'm not sure. maybe if we use async, but for sync/fastbus it should be "free" 19.20.56 # * domonoky thinks the clock switching penalty always comes in, if you need to change the PLL, and not only the divisors... 19.21.12 # we don't change the PLL at all 19.21.55 # and the clock generation is SOC specific, and not arm specific... at least as far as i know. 19.22.51 Join flydutch [0] (n=flydutch@host100-164-dynamic.8-87-r.retail.telecomitalia.it) 19.23.06 # domonoky: i meant is there a time penalty when switching AHB/APB synchronisation ? 19.23.20 Quit HellDragon (Client Quit) 19.23.33 # ah, thats different.. :-) *checking datasheet* 19.23.51 # funman: as I said, I don't think there is for sync/fastbus 19.24.22 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 19.24.27 # me too, but did you verify ? 19.24.30 # I'm guessing very few cycles, if at all 19.24.46 Part pondlife 19.25.04 # no, but I haven't read of any penalty in the ds 19.26.01 # perhaps they don't think someone would change it lot of times per second 19.26.14 # Horscht: not too bad apparently :) 19.26.25 # I really don't think that 19.27.16 # i think that the ams port is bug-free, but when i verify this it's obviously wrong :) 19.27.45 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 19.28.11 # yes, but *we* did the port, not ams, while they did the chip, not we. I trust them more than us :) 19.29.11 # gevaerts, indeed sir 19.29.39 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 19.29.43 # kugel: honestly, i have seen many bugs in the OF and i wouldn't trust ams 19.30.05 # ams doesn't have much to do with the of 19.30.23 # since we now have hidden bugs in our code, i want to triple-check every upcoming changes to not add new ones 19.30.48 # the only difference is probably that sandisk has some low-cost support contract. the rest of the OF is probably also only done using payed engineers and the datasheet 19.30.59 # kugel: i don't think so : the "AS3525*develop" thing surely means they provided sandisk with an IDE and precompiled libraries 19.31.48 # what'S "AS3525* develop"? 19.32.09 Join faemir [0] (n=faemir@88.106.152.205) 19.32.15 # the string in the very first bytes of each ams firmware. what have you been reversing ? :) 19.32.15 # what you see buggy is the GUI and sometimes codecs, that's surely not from AMS 19.32.36 # i didn't reverse gui and codecs but hardware bits, and i expect the hardware company to provide drivers for their hardware 19.33.04 # and you think those are buggy? 19.33.13 # yes, and that is pretty normal :-) 19.33.16 # there are bugs in there, or at least very strange things 19.33.34 # I haven't seen any bug in the OF that I considered driver related 19.33.59 Join BryanJacobs [0] (n=BryanJac@www.q3q.us) 19.34.01 Join JdGordon| [0] (i=836b0070@gateway/web/ajax/mibbit.com/x-231e970230607cc6) 19.35.15 # domonoky: have you found something in the datasheet? 19.35.21 # gevaerts, at first I was disappointed because I didn't get any different results... then I noticed the policy change again. Since the HID stuff went into SVN, my Ipod was once again identified as a new device which i had to set to performance profile again. 19.35.31 # back to the asynchronus/synchronus issue. its probably without time penalty, as going from fastbus -> synchronus, probably only enables a buffer register (flipflops) between the two busses. and asynchronus add a bit of clock logic... 19.35.37 # ah yes. The serial number changed 19.36.01 # That's actually on purpose, to make sure the OS actually looks at the new capabilities 19.36.08 *** Saving seen data "./dancer.seen" 19.36.22 # yeah, it just took me a little bit till I noticed :D 19.36.39 # kugel: i only had +1 hour of battery on my Fuze when using 31MHz pclk 19.36.45 # means less than 10% gain 19.37.05 # but all your benches are 1.5h over mine 19.37.17 # perhaps different volume/options 19.37.26 # * domonoky thinks for the start staying with 64Mhz plck will be fine. we can improve that later if needed. 19.37.34 # I used default settings (except for repeat mode, obviously) 19.37.34 # I used lcd off, vol -9dB for the Fuze 19.37.42 # regarding the next release... do we want to talk about postponing, or bringing it early so it doesnt end up having us frozen during the devcon? 19.38.01 # domonoky: i think also 19.38.26 # we could also freeze before devcon, and open trunk again just before it starts 19.38.40 # did you test FS#10191 ? that'd be a first step towards legal settings 19.39.46 Part pondlife 19.39.57 Part pyro_maniac ("Leaving.") 19.40.03 # I think we should go for 195/65+65 for now, with clocking down to 32.5+32.5 when unboosted 19.41.27 # why not the maximal speed ? 19.41.41 # why so poor lcd and ata performance ? 19.42.08 # and memory! 19.42.27 # maximal speed as in? maxing cpu clock or pclk? 19.42.35 # boosted cpu clock 19.43.12 # we need async then. from what I've noticed, 248MHz async is *slower* than 192 sync 19.43.36 # hum ok 19.43.45 # then why not using 248/62 ? 19.45.00 # because 64MHz is already much faster than 62MHz from what I've noticed (I have 90MHz with 64 vs 115 with 62 in the view buffering screen) 19.45.44 # I really slap AMS for capping the cpu to 250, and not *slightly* higher, like 265 19.46.00 # ^^ 19.46.15 # but apparently, the boosting rate is meaningless anyway, as I get less runtime with less boosting 19.46.31 # did you check test_codec ? 19.47.54 # not with 62 19.47.59 # calculation in buffering thread debug screen doesn't seem very precise 19.48.17 # it counts how much ticks happen boosted or unboosted it seems 19.48.36 # hm 19.49.11 # but it would be at least equally incorrect for 64 and 62, not? 19.49.30 # it would be equally not significative at all for 64 and 62 19.49.48 # :) 19.50.56 # funman: also, as I said, I'd be fine with microboosting for ata/dbop 19.51.32 # kugel: ok, if you test lcd, ata, battery, and codec performance 19.51.59 # why me? :((( 19.52.08 # you've got test_disk test_codec test_codec and battery_bench for it 19.52.18 # well you can also put that on MrSomeone todo list :) 19.52.28 # those tools are yours too 19.52.36 # i'm hacking EDA now 19.52.53 # European Defence Agency? 19.53.03 # also i don't think using lower pclk clock is useful at this time 19.53.07 # Embedded DisAssembler 19.53.10 # that's seems a dangerous area ;) 19.53.16 # oh, boring :p 19.53.20 # yes, C++ :( 19.57.41 # funman: I figured from my bench that maxing pclk all the time gives less runtime no matter of the performance 19.57.55 # (compared to your benches) 19.58.38 # i understand that higher frequency gives less runtime, but what do you mean about performance ? 19.58.56 # higher pclk gives better overall performance 19.59.11 # ok, so what's your conclusion ? 19.59.15 # and the better performance doesn't seem to pay of w.r.t to less boosting 19.59.20 # off* 20.02.08 # so do you think we should rather have long runtime and bit poor lcd performance for example, rather than good performance with shorter runtime ? (something in the middle, i.e. pclk a bit lower than the maximal value we use now) 20.02.41 # I'm only talking about unboosted state 20.02.50 # and yes, I think we want to maximize runtime 20.04.37 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.04.39 # we should make a difference between boosted cpu (for maximal _calculation_ speed) and boosted pclk (for maximal _peripherals_ (lcd, ata, usb, memory) speed) 20.05.02 # that would be microboosting then 20.05.24 # for ata,lcd,usb, I don't know if it will be doable for memory 20.05.38 # not really :') 20.06.08 # memory doesn't really need max pclk imo 20.06.23 # you can post your suggestion on the forum with a patch, and ask for testers 20.06.35 # kugel: well data transfers will be slower then 20.06.51 # sure, but the rest is slow too 20.06.59 # and unaligned ata transfers as well 20.07.04 Nick J-23 is now known as chrzescijanstwo (n=zelazko@unix.net.pl) 20.07.09 Nick chrzescijanstwo is now known as J-23 (n=zelazko@unix.net.pl) 20.07.23 # kugel: i suggest we wait for caching being enabled before we look for battery life 20.07.32 # I mean, I don't think ram access/read/write is slow enough to limit the cpu (which is on 32.5MHz too then) 20.07.40 # especially since we may have a different view of what "decent performance per pclk speed" is 20.07.49 Quit lymeca (Read error: 104 (Connection reset by peer)) 20.07.57 Join lymeca [0] (n=lymeca@dsl-74-220-76-19.dhcp.cruzio.com) 20.08.08 # right 20.08.28 # unaligned ata transfers count into microboosting for ata, doesn't it? 20.08.55 # I was thinking to do the microboost in sd_enable, which would then last as long as the whole transfer is active 20.09.48 # * domonoky would suggest to leave such microboosting things for later.. :-) 20.10.46 # FlynDice: btw, why are you so opposed to split up your boosting scheme work into 1 change per patch? 20.10.52 # perhaps "later", when we have caching on the AMS, we would then see that using 31MHz pclk is fast enough for decent performance 20.11.21 # I mean, I'd like to see something that makes dev's lifes easier in SVN too. but if it creates breakage, we can't know what of the several changes caused it 20.12.21 # if the CPU gets faster with caches, the slow periphery will limit / slow it down even more than without caches 20.12.37 # kugel: I'm not opposed to it I'm just not sure how to do it..... 20.13.35 # I just made a tool to use without actually thinking it would be considered to go into svn.... 20.13.55 # kugel: last patch looks OK (doesn't change the clocking scheme), if you approve it please commit 20.14.03 # kugel: but cache affects the memory accesses, and those also depend on plck, as far as i know. 20.14.09 # well, let me test it on my devices first :-) 20.15.32 # * Unhelpful pokes kugel 20.15.33 # domonoky: so, even fast cpu and fast memory wait for slow periphery? :) 20.15.36 # what'd you want? :P 20.15.43 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.16.04 Quit HellDragon (Client Quit) 20.16.06 # kugel: are sure the peripheral is the bottelneck ? 20.16.12 # Unhelpful: I just wanted to you to look at the yellows of the samsungs which were "fixed" by enabling jpeg and the scaler 20.16.31 # kugel: ah, ok. i'll take a look at that revision :) 20.16.44 # bbs 20.16.45 Quit funman ("leaving") 20.17.05 # domonoky: I have no idea. But a) I fear it will be and b) we already see now that raising pclk a bit gives much better decoding performance 20.17.26 # isn't the as3514 peripheral too? 20.17.47 # and decoding performance depends on many things... 20.17.55 # or am I confusing things again 20.18.04 Join funman [0] (n=fun@rockbox/developer/funman) 20.18.18 # so i think we should wait with complicated measures, until we have cache running, and know for sure its needed. 20.18.46 Join mirak [0] (n=mirak@85-169-201-135.rev.numericable.fr) 20.19.03 # kugel, what peripheral on the APB could cause such a slowdown? 20.19.18 # * domonoky speculates that the most demanding thing in playback is the codec itself, which means nearly only cpu and memory. 20.21.13 # maybe one of the drivers of one of the APB devices wastes a lot of time, like DBOP or I2S? 20.21.40 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.22.45 # hi, where in the source tree can i change the keymap for a specific target's touchscreen? "apps/keymaps/keymap-touchscreen.c" presumably applies to all targets 20.24.41 # what are you looking for exactly... 20.24.48 # AndrewRB: if you mean the touchscreen button grid, its the same for all touchscreen targets. 20.25.01 Join matsl [0] (n=matsl@host-90-237-166-249.mobileonline.telia.com) 20.25.15 # domonoky: yeah, I know. just wondering if there is any way i can change it for a specific target, without affecting others. 20.26.01 # only if you create another keymap-xxx.c file, and include it instead of keymap-touchscreen.c 20.26.31 # AndrewRB: aren't you just compiling for yourself? 20.26.49 # who cares about breaking other targets then? 20.27.00 # JdGordon|: well, I started off just adding function to the buttons on my D2 while in hold mode, ... now I'm wanting to test a few other things with the touch screen 20.27.32 # kugel: yeah, i'm just building for myself for the time being, I was just checking if there was some format/location for specific target touch screen keymaps 20.27.50 # ok, well I would suggest ignoring the grid stuff and work on the real touchscreen mode (stylus mode i tinhk we call it) 20.27.54 # domonoky: ok, thanks. 20.28.29 # JdGordon|: yeah, I guess that would be more productive. I was just playing around though, not doing any real "thinking" as they call it =P 20.28.47 Part LinusN 20.29.04 # The fuze LCD driver seems to not really use the FIFO capability of the DBOP, I think it can get quite a bit faster with FIFO 20.29.21 # hm, how? 20.30.18 # by trying to keep the FIFO full rather than empty in the data write loop in lcd_write_data (this function takes most of the bandwidth I presume) 20.30.40 # how big is the fifo? 20.30.52 # so instead of checking the empty bit, check for the almost full bit 20.31.15 # AndrewRB: I dont know what your skill level is.. but if you want something fun to do with the touchscreens... have a look at my email to the dev ml last week... 20.31.30 # bertrik: it seems 32bit 20.31.31 # ds says 128 words 20.32.23 # you mean writing 1byte at a time is faster than 2, just so that the fifo doesn't empty? 20.32.27 # JdGordon|: sadly, low. probably regarded as "hobbyist" level, as I've never had any professional use of any compiled language, and I've had no real experience electronics wise 20.32.40 # I think we can also use interrupts for that, that may speed it up a bit more 20.32.41 # JdGordon|: i'll have a look 20.32.56 Join merbanan [0] (n=banan@c-83-233-163-22.cust.bredband2.com) 20.36.53 # kugel, no I mean to keep writing until the FIFO is nearly full, so the data towards the display is a continuous stream without any time gaps between words 20.37.19 # I can write some code to try this principle, could you test it on your fuze? 20.37.25 # sure 20.38.08 Join neozen [0] (n=neozen@65.91.254.98) 20.39.20 # bertrik: filling the fifo full at start, then refilling it with a 2byte (=fb_data) once it's half full seems like a good idea 20.39.38 # kugel: please check FS#10245 20.41.32 # funman: if it works for you and you're fine with it, commit it yourself 20.41.46 # looking at it, it's surely an improvement over SVN 20.43.32 # kugel, yes that's what I mean, we don't have to completely fill it full at the start, but I think we should wait at the end of an lcd_write_data for fifo empty 20.43.54 # aren't we filling 2 bytes at a time right now? 20.44.06 # New commit by 03funman (r21088): FS#10245 by Jack Halpin : Adjust Clocking scheme on Sansa AMS 20.44.16 # that's half the fifo, so either we make it full in the beginning or it's getting empty 20.44.19 Quit barrywardell (Remote closed the connection) 20.45.23 # kugel, no as far as I understand, it has 128x32 words worth of FIFO 20.45.37 # I mean 128 words of 32-bit each 20.48.04 # I don't know how exactly the fifo level bits work, i.e. if progressively more "push fifo x full" bits get set, or if only ever one of those bits is high at a time 20.48.25 Quit kugel (Read error: 60 (Operation timed out)) 20.48.50 Join kugel [0] (n=kugel@rockbox/developer/kugel) 20.49.33 # saratoga: do you have a 8GB sansa ams ? (e200v2?) 20.49.50 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 20.50.20 Quit matsl (Read error: 110 (Connection timed out)) 20.53.26 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 20.56.58 Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) 20.57.11 # funman: do I really need to make a 3GB filesystem for your boundary patch or can I just run the test you described on the forum. I can unbrick my e200v2 if I screw it up... 20.58.17 # FlynDice: well you need to write data across the exact boundary, and if you already have a filesystem here it might screw up 21.00.56 Quit Horscht ("Verlassend") 21.01.16 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 21.02.22 # New commit by 03learman (r21089): Update the Swedish translation. 21.05.15 # funman: If you have some time to talk me through it I'm happy to give it a try, or if it takes too much time if you email me some steps to follow I could do that too. 21.05.35 # FlynDice: no problem i'm here 21.06.35 # mkfs.vfat /dev/sdb 8026111 (create a file system which fills the first bank, less one block) 21.07.45 # kugel, can you try this patch : http://pastebin.ca/1435302 21.07.54 # funman: lemme get set up here real quick 21.07.55 Join pyro_maniac [0] (n=pyro@91.64.227.210) 21.08.21 # then generate a file of 1kilo byte, filled with incrementing int values (00 00 00 00, 01 00 00 00, ...) int32_t buf[256];int i;for(i=0;i<256;i++) buf[i] = i; // write buf to a file 21.09.06 Quit Horscht ("Verlassend") 21.13.55 # funman: got a quick way I can make sure I'm on sde with the sansa? 21.14.25 # mount it from the file manager, check in which directory you are, and mount|grep directory 21.14.29 # New commit by 03dionoea (r21090): FS #10233 by Johannes Schwarz: "The following patch allows the user to resume his xobox game. The user has got the possibility to change the speed or ... 21.18.13 # funman: mkfs.vfat: Device partition expected, not making filesystem on entire device '/dev/sde' (use -I to override) should I override? 21.20.14 # shouldn't you format /dev/sde1 ? (I don't know how sansas are formated) 21.20.36 # -I 21.20.45 # dionoea: there is no partitions 21.20.45 # ok 21.20.54 # funman: ok :) 21.21.02 # err 21.21.02 # wait 21.21.07 # but the partition table is still important 21.21.07 Quit Rondom (Remote closed the connection) 21.21.10 # funman: no just 2 2Gb and one 4GB device 21.21.18 # er too late.. ;) 21.21.20 # FlynDice: use 7964671 blocks 21.21.30 # though actually i've got SD cards around here, would those work? 21.21.50 # i've got a 16GB one somewhere 21.22.00 # is there any specific reason that voice_thread.h redeclares some mp3_play_xxx functions that are already declared in mp3_playback.h? 21.22.09 # saratoga: nope, it's only about internal storage 21.22.54 # ok 7964671 21.23.15 # done 21.24.17 # then dd if=the1kfile of=/dev/sde bs=512 seek=7964671 21.25.00 Quit FOAD (Read error: 104 (Connection reset by peer)) 21.25.33 # I need to replace "the1kfile" right? 21.26.22 # yes, with the file you should have generated before :) do you want a program to generate it ? (it's just known data you'll be able to recognize on the screen) 21.28.09 # I'll just use saratogas from the forum 21.31.50 Join mcuelenaere [0] (n=quassel@78-21-191-122.access.telenet.be) 21.32.13 # er do I need to start with the patched rockbox already on my player...? 21.32.37 # yes 21.32.53 # let me do a quick rewind.... 21.33.07 # but since the partition size is < the size of 1 bank you have to trigger the call to sd_read_sectors() manually (from the debug screen for example) 21.33.08 Join _lifeless [0] (n=lifeless@188.16.111.36) 21.33.27 Join FOAD [0] (n=dok@dinah.blub.net) 21.34.14 # couldn't one write to the raw block device (unsafely of course)? 21.34.28 Quit Thundercloud (Remote closed the connection) 21.34.57 # Unhelpful: since the fat partition is smaller than 1 bank, no. 21.35.12 # i mean the raw whole disk device :) 21.35.39 # which would be *very* unsafe, although if you're writing past partition end, it should work. 21.35.44 # well with a corrupted fat, probably 21.36.07 # the e200v2 can be unbricked, but i should have advised to disable write support for the test 21.36.09 *** Saving seen data "./dancer.seen" 21.37.55 # ok : 4096 bytes (4.1 kB) copied, 0.212899 s, 19.2 kB/s 21.39.35 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 21.40.18 # 4kb ? :( 21.40.26 # so now I unplug and check the debug screen? 21.40.48 # right 21.41.02 # 4kb not right? 21.41.13 # well 1kb is enough 21.41.34 # we only need 2 sectors : 1 at the end of first bank, 1 at the start of 2nd bank = 2*512 = 1k 21.41.47 # we'll just ignore the 3 following k ;) 21.43.09 # ok here goes hmm loading firmware file not found... lemme try to reinstall RB 21.45.37 # funman: hi, was there code you wanted to test on 8gb fuze? 21.45.44 # I have 8gb fuze to ttest 21.45.45 # if you modified the partition, you need to recopy it :) 21.45.53 # lucent: FlynDice is just trying on his unbrickable e200v2 21.45.59 # * lucent :) 21.47.52 # funman: i meant using something such as dd to write to a whole-disk, not partition, device, without going through the filesystem. i'm not sure that's possible on windows... but you could definitely do it on unix with the correct permissions. 21.48.05 Quit blithe ("Lost terminal") 21.48.16 Join blithe [0] (n=blithe@blakesmith.me) 21.48.28 # also I note there was a regression in operation of the Fuze 8gb sometime between r20807 and r21026 which "stalls" at the bootload screen with uSD card inserted 21.48.54 # I know it's an actively developed target so I haven't yet bothered to dissect 21.49.19 # inserting uSD after boot time works just fine 21.49.27 # Unhelpful: you can definitely do it on unix (and on windows if you write a tool), and that's safe on sansa ams since the OF isn't visible through usb 21.51.21 Join Hillshum [0] (n=chatzill@75-165-244-181.slkc.qwest.net) 21.51.37 # lucent: hum so r21007 didn't fix it ? then i'm not aware of what could be the reason 21.52.02 # does any fuze owner here want to test a patch to increase display performance? 21.52.04 # funman: Unhelpful : you will loose all the OF settings and get some other odd behavior until you format from the OF 21.52.24 # i can boot fine my fuze with a usd card inserted (i didn't update the bootloader for long, but multivolume is disabled in bootloaders i think) 21.52.32 # I'm all too happy to be guinea pig and lab rat to test Fuze 8gb :) 21.52.49 # just need some verbose instructions on what to patch and how to test 21.53.23 # lucent, can you try this patch http://pastebin.ca/1435302 and see if the display still works? 21.53.23 # funman: sorry I must have screwed up while patching, compiling another now 21.54.01 # lucent, I don't know how to benchmark it though 21.54.16 # okay I will try this 21.54.17 # so there is some extra stuff exposed over USB 21.55.30 # lucent: bertrik you can build test_fps plugin 21.57.44 # funman: um, isn't there supposed to be something on the debug ports page to check, nothing extra there now when I look 21.57.58 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 21.59.04 # FlynDice: no "DIRxx" after "CP15" line in show I/O ports menu ? 21.59.39 Quit kugel (Read error: 60 (Operation timed out)) 21.59.52 # Nope, let me do a complete redo here though, 3rd times a charm right?... 22.00.50 # New commit by 03unhelpful (r21091): Use pre-multiplication in scaler to save one multiply per color component on ARM and Coldfire, at the cost of an extra add/shift in the horizontal ... 22.01.15 Join sko [0] (n=sko@M7268.m.strato-dslnet.de) 22.01.21 # big thanks to everybody who tested/advised on this mess :D 22.02.14 Join Lear [0] (i=chatzill@rockbox/developer/lear) 22.02.15 # bertrik: I tried your display patch on my e250v2, display is working 22.02.26 Join andrewbeveridge [0] (n=andrewbe@88-109-101-174.dynamic.dsl.as9105.com) 22.02.27 # oh nice, is it faster too? 22.02.33 # funman: hmm looking at the patch I used there's no changes to debug-as3525 was that extra? 22.02.44 # hmm... how to check? 22.03.13 # sko, wait, the patch was specifically for the fuze lcd, did you adapt it for the e200v2? 22.03.20 # yes 22.03.22 Join tessarakt [0] (n=jens@e180068084.adsl.alicedsl.de) 22.03.48 # the same function is used in lcd-e200v2.c, so it was quite easy 22.04.29 # FlynDice: you need http://www.duke.edu/~mgg6/rockbox/diskcheck.patch as well 22.04.45 # yep just looking there right now.. 22.05.22 # sko, AFAIK you can test it with the test_fps plugin, but that one needs to be manually enabled by editing a SOURCES file 22.05.56 # hm, I can do the same trick on a clip too (so I could test it myself) 22.06.36 # the clip has much less lcd data to transfer though, so any speed increase is likely to be much less than on e200v2 or fuze 22.06.44 Join kugel [0] (i=kugel@rockbox/developer/kugel) 22.07.04 # bertrik: sorry, I needed to run, now I can test it with test fps 22.07.55 # mcuelenaere: ping 22.08.14 # pyro_maniac: pong 22.08.20 # funman: patch doesn't apply cleanly now gimma sec to massage it 22.08.47 # mcuelenaere: after working on lua, what would you think about a light wight python? 22.09.02 # pyro_maniac: Python isn't easy to implement.. 22.09.14 Join r121 [0] (n=r121@CPE00018058f4bf-CM001371b7085e.cpe.net.cable.rogers.com) 22.09.22 # first find something you can do in python but not in lua :) 22.09.25 # bertrik: i have it... tried with patch now, now i have to make a clean build for comparison.. wait a moment 22.09.28 # mcuelenaere: i have seen a mini python that works on an arm 22.09.43 # and even on lower cpu 22.09.59 # Lua is meant for embedded stuff with low memory and cpu 22.10.00 # funman: enjoy programming? ;) 22.10.06 Join BdN3504 [0] (n=55b23cc5@gateway/web/cgi-irc/labb.contactor.se/x-5cc0ab6d8e144ef9) 22.10.30 # pyro_maniac: I don't see the need for Python when we already have Lua.. 22.10.34 # Unhelpful: :P i had fun when writing (very short) lua scripts 22.10.43 # + it requires much more CPU I guess 22.10.46 # funman: and they were full of bugs :) 22.10.55 # :) 22.11.02 # look at this first: http://code.google.com/p/python-on-a-chip/ 22.11.21 Part r121 ("Leaving") 22.11.26 # mcuelenaere: i doubt it requires loads more CPU, but cpython is not well-adapted to our environment. 22.12.14 # * lucent pokes his 8gb fuze with a patched display code 22.12.22 # I think there's quite a performance difference between a programming language and environment designed to run under restrained circumstances and another designed to be not 22.12.47 # or at least it isn't their first goal 22.13.18 # bertrik: I don't need to patch the bootloader do I? 22.13.25 # lucent, no 22.13.46 # anyway lua is 10000 times better than python :) 22.13.54 Quit kachna (Read error: 113 (No route to host)) 22.14.07 # perl wins 22.14.08 # mcuelenaere: just an idea ;) 22.14.20 # pyro_maniac: feel free to implement it yourself ;) 22.14.51 # mcuelenaere: i tried already, but i get stucked on some problems 22.15.02 # like? 22.15.06 Quit AndrewRB (Read error: 110 (Connection timed out)) 22.15.28 # shucks, I need to leave my player to charge for a few minutes before I can test 22.15.46 # I wish charging was supported under rockbox, all in good time I can wait 22.15.50 # mcuelenaere: dont know now. i will take a look later and maybe i can ask you again? 22.16.21 # you don't need to ask it specifically to me, I have 0 experience with (porting) Python 22.16.58 Join petur [50] (n=petur@rockbox/developer/petur) 22.17.03 # mcuelenaere: ok but i will try to continue 22.17.13 # funman: I get DIR:18 DIR4 : 8f which is not what saratoga said to expect I guess I'll rinse, blow dry and try again ;) 22.17.15 # kugel: i've fixed those yellows, do you want scaling/jpeg on or off for those targets? 22.17.57 # hm, the DBOP FIFO thing doesn't make much difference on my clip (actually seemed to get slightly _slower_) 22.18.06 Quit {phoenix} (Remote closed the connection) 22.18.09 # bertrik: it seems faster 22.18.30 # FlynDice: read my message below :) 22.18.39 # but only when boosted (with my 256/64MHz CPU + constant 64MHz pclk setup) 22.18.51 # it's not what we should expect either 22.19.10 # bertrik: tested with your patch, 8gb fuze display is still working 22.19.38 # yes, definitely 22.20.11 # let me upload the numbers 22.20.25 # bertrik: not really a difference, a little (0.5 - 1 fps ;) ) slower: http://pastebin.ca/1435368 22.20.33 # FlynDice: do you get the same numbers across multiple runs ? 22.20.47 # safetydan (logs): what exactly made you decide to use http://g.oswego.edu/dl/html/malloc.html as malloc library in Lua? 22.21.17 # FlynDice: also it should be 512-4 and 512, not 512 and 512+4 .. 22.21.23 # bertrik: http://imagebin.ca/view/mlFrTJ.html vs http://imagebin.ca/view/yh42Ix.html 22.21.27 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 22.21.28 # i should put correct instructions in the ticket 22.21.41 # Let me redo it it just takes a minute now that I'm " experienced"... 22.22.28 # and all the commands are in my bash cache... 22.22.34 # stock test_fps is useless 22.22.38 # it doesn't test boosted 22.23.03 # ah, ok, i was wondering about your screenshot right now ;) 22.23.03 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 22.23.06 # kugel: you can force boost in debug screen 22.23.14 # yes, I know 22.23.48 # kugel, almost 30% increase for boost is nice :) 22.24.09 # actually it was a bit weird 22.24.38 # in the first run with the built compiled yesterday I got repeatedly only 50fps for boosted full update 22.25.08 # then I compiled (iirc the same build, no svn up or so) with your patch, and got 80 22.25.30 # funman: what needs to be done one the plugins for the samsung devices? 22.25.34 # then I revert the patch again to be safe to have the same built except for the patch, and then I got 60fps 22.26.03 # I'm fairly sure I didn't change the built since the built that was on my fuze before :( 22.26.03 Quit BdN3504 ("CGI:IRC (EOF)") 22.26.08 # New commit by 03unhelpful (r21092): Fix yellow when building with HAVE_ALBUMART, without HAVE_JPEG/HAVE_BMP_SCALING. 22.26.18 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.26.40 # pyro_maniac: write keymaps 22.26.44 # Unhelpful: on of course :) I didn't even notice the yellows before I looked for the build table after my commit 22.27.20 # bertrik: if we make sure that the fifo is empty before returning 22.27.44 # do we even ask the hardware for the fifos? we can count ourself, which may (or may not) be faster(?) 22.27.53 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 22.30.22 Join Tomers [0] (n=chatzill@bzq-84-108-58-176.cablep.bezeqint.net) 22.30.53 # kugel, I think we don't know the exact state of the FIFO at that point (could be full, or full minus one byte), so we can't count 22.31.06 # do we know the size ? 22.31.09 # Hi all. I am building a plugin. I figured out I can use 'make rocks'. Is there another way to compile only one plugin? 22.31.27 # Tomers: edit /apps/plugins/SOURCES 22.31.28 # New commit by 03alle (r21093): Fix typo in the comment 22.31.35 # Tomers: make $PWD/apps/plugins/my.rock 22.31.37 # if we go really advanced we could exit without waiting for the FIFO to empty and do other stuff in parallel 22.32.12 # funman, yes, the ds says 128 words of 32 bit each 22.32.26 # funman: I get the same exact results each time. here are my steps: format disk with of, copy patched rockbox to disk, sudo mkfs.vfat /dev/sde 7964671 -I, sudo dd if=/home/jack/myfile.txt of=/dev/sde bs=512 seek=7964671, boot rockbox, rockbox shows no firmware found, copy rockbox to disk, rockbox boots and I get results 22.32.40 # that seems reasonable, but consecutive updates (i.e. test_fps) could be problematic? 22.33.20 Quit robin0800 (Remote closed the connection) 22.33.44 # FlynDice: can you give paste your current diff to rockbox? 22.34.05 # sure pastie coming up 22.34.11 # funman, Hillshum: Thanks 22.34.14 # Tomers: I played around a bit using my c200 to control foobar2000, works well except that foobar doesn't seem to know about the multimedia button that's on ACTION_USB_HID_MENU (Power button according to the keymap). Is it one of the more unusal multimedia buttons (so more likely a foobar problem) or could it be something else? 22.34.18 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 22.34.20 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 22.34.27 # bertrik: your patch makes it full, but then refills once it 22.34.27 # bertrik: really *really* fancy would be if there's an interrupt for fifo x% free 22.34.38 # it's full - 2bytes, right? 22.35.20 # I think we should wait for almost empty, then start the loop again. at the end wait for empty 22.35.30 # there is fifo half full, fifo full, fifo empty interrupts for MMC/SD controller 22.35.33 # (unless count ends the fun before that is 22.35.34 # ) 22.35.47 # pixelma: This button is reserved for future use. AFAIR it won't send any code over USB. It should pop a menu on the DAP's screen, to allow configuration, select key mappings, etc. 22.35.50 # or do you mean 'x' as in user-configurable? 22.35.53 # hm, why wait if you can just keep the FIFO topped off? 22.35.59 # funman: for dbop there seems to be only error interrupts 22.36.18 *** Alert Mode level 1 22.36.18 # New commit by 03alle (r21094): Fix typo in the menu entry 22.36.45 # Tomers: ah, that explains that. After looking at the keymap I thought it was a multimedia button too - thanks for the explanation :) 22.36.46 # well, maybe the controller gets interrupted when you refill the thing or it slows it down somehow 22.36.51 # Tomers: have you seen FS#10242? 22.37.10 # funman:http://pastie.org/490551 22.37.28 # or do you mean we can save power by doing WFI in the lcd_write_data loop? 22.38.16 Join froggyman [0] (n=47ba0b80@gateway/web/cgi-irc/labb.contactor.se/x-878cd7f548eb93c7) 22.38.19 # WFI? 22.38.48 # we can also try to write 4bytes at a time (IIRC that's also done on e200) 22.39.04 # hmm... added boosted values... not as on fuze: http://pastebin.ca/1435395 22.39.09 # wait-for-interrupt, waiting in a lower power state until an interrupt occurs 22.40.06 # bertrik: could either 1) do something else, and schedule to refill the fifo only after getting the interrupt 2) if there's no task to run, WFI 22.40.13 # do we have a low power state? 22.40.14 # sko, hmm hardly any difference 22.40.32 # gevaerts: FS#10242 is on my to do list. I tried to find a second hand iPod Nano 1st generation, and couldn't find one, plus these ipod DAPs a bit too over-priced, even for second hand. I hope the info in the FS item is enough 22.40.34 # FlynDice: try http://pastie.org/490560 (you didn't read all my message after saratoga's) 22.40.48 # funman: the current keymaps need to reworked? 22.41.00 # bertrik: he's using another boosting mechanism that me 22.41.04 # pyro_maniac: the plugin keymaps need to be written, they don't exist 22.41.11 # (that's the only explaination I have) 22.41.20 # yes, i used the debug menu 22.41.27 # Unhelpful, my feeling is that we don't have to wait so long that it's worth a task switch 22.41.34 # Tomers: he has an old bootloader IIRC. I don't see how that could cause this, but maybe it's worth checking (/me pings Mikachu) 22.41.42 # funman: ok 22.41.58 # i was confused with OF offsets when i first explained 22.42.06 Join charlesand [0] (n=4b96a806@gateway/web/cgi-irc/labb.contactor.se/x-cf1bc45c763b8f90) 22.42.20 # we need to remove the OF size when : writing the partition, writing the file with dd, reading from rockbox 22.42.27 # i.e. everytime 22.43.00 Quit Lear ("ChatZilla 0.9.84 [Firefox 3.5pre/20090523044232]") 22.43.06 # in wfi state, the isr will be called first, and cpu will resume after return ? 22.44.02 # kugel: sko are the results identical after several runs of test_fps ? 22.44.14 # yes 22.45.41 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.45.57 # one other thing I wondered about (possibly discussed to death already) is the effect of -O compiler settings for the ams targets 22.46.09 # yes, always the same values (with max. differences of 0.5 fps) 22.46.19 *** Alert Mode OFF 22.46.28 # bertrik: was there tests for other targets ? 22.46.46 # funman, I don't know, I didn't dare to ask :P 22.47.24 # Please enable my write rights to edit the rockbox twiki. I just registered and confirmed. thanks, charles. 22.48.22 # charlesand: Okay 22.48.38 # have to go now... night is to short :( i can do more tests tomorrow if there are some findings 22.48.59 Quit sko ("bye") 22.49.51 # charlesand: done 22.53.05 # Thank you Hillshum. Bye. 22.53.14 # np 22.53.50 # eh, compiled with -Os and now the down button no longer works on my clip ... 22.54.57 # bertrik: any delay loops and such written in c may be deleted in -Os if gcc decides they have no side effects, which may break a lot of drivers 22.54.57 Quit charlesand ("CGI:IRC (EOF)") 22.56.24 # bertrik: nops removed ? (shouldn't since the asm statement is flagged as volatile) 22.56.38 # (this happened when I switched coldfire to use Os, solved by coding the delays in assembler) 22.57.00 # funman: bank1 last: 7F bank2 1st 80 22.57.07 # ah and non volatile asm statements may be deleted too so beware 22.57.11 # FlynDice: \o/ 22.57.23 # 0x7F = 127 = buf2[127] , 0x80 = 128 = buf2[128] 22.57.56 # I guess that's good then.... ;) 22.58.06 # n1s, can't we also fix this by making the loops so smart that the compiler can no longer decide to remove them? 22.58.30 # bertrik: "volatile" keyword should prevent any compiler optimisation 22.58.43 # funman, yes that was what I was thinking about 22.58.57 # it doesn't 22.59.04 # hm 22.59.11 # sending 4 bytes didn't help 22.59.15 # but that might not affect anything right now 22.59.19 # bertrik: well, yes, like using volatile but asm is often nicer, not that it matters much how you solve it, but later gcc versions may become smarter :) 23.02.23 # you can also flag functions as volatile, right? 23.02.51 # does that means the calls are never optimized, or the function body, or both? 23.03.31 # * funman looks for a free copy of iso c standard 23.03.58 # on my clip, -Os is quite a bit slower than the default -O. -O2 is only slightly faster than the default -O 23.04.48 # ttp://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf if you are interested 23.06.30 # "accessing a volatile object has side effects" 23.07.43 # New commit by 03peter (r21095): Next round of pdbox patches from Wincent Balin: adapt dbestfit to rockbox, ifdef some printfs, and more 23.07.50 # funman: it is a side effect 23.08.18 # not sure what that means 23.08.53 # New commit by 03funman (r21096): FS#10216 : Sansa AMS : Do not cross a bank boundary in a single transfer (Only for 8GB or more -if they exist- players) ... 23.09.23 # kugel: it could modify memory for instance 23.09.59 Part BryanJacobs 23.14.24 Quit merbanan (Read error: 110 (Connection timed out)) 23.15.09 # funman: the freeze-on-boot issue only happens with an 8gb class 6 uSD 23.15.21 # funman: my 2gb uSD inserted boots fine 23.15.33 # funman: I may have been incorrect to say there is a regression 23.15.48 # maybe I just swapped cards without realizing which one is which :) 23.17.53 # lucent: look at ata_sd_as3525.c around line 250 "some MicroSD cards.." and try modifying the delays 23.18.05 # funman: okay will do 23.18.32 # kugel, it looks like basically only you found any useful display speedup from using the DBOP FIFO 23.19.25 Quit andrewbeveridge (Remote closed the connection) 23.19.45 Join andrewbeveridge [0] (n=andrewbe@88-109-101-174.dynamic.dsl.as9105.com) 23.20.57 # bertrik: as I said, I use another boosting mechanism 23.21.19 # maybe we wait until we change boosting, then revisit this 23.21.27 # can you explain what SVN uses and what you use? 23.21.31 # rockbox doesn't build with -O0 : /media/bordel/rockbox/firmware/target/arm/system-arm.h:242: error: impossible constraint in ‘asm’ 23.23.20 Join Ghost-Foc [0] (n=Adium@modemcable190.0-82-70.mc.videotron.ca) 23.23.38 Quit Ghost-Foc (Client Quit) 23.24.56 # bertrik: not really :S 23.24.58 Join Ghost-Fox1 [0] (n=Adium@modemcable190.0-82-70.mc.videotron.ca) 23.25.05 # hi 23.25.24 # SVN uses async which I suspect to slow things down more than running with a lower clock 23.25.38 # Ghost-Fox1: hi 23.26.11 # I'm looking how to compilling rock box plugin 23.26.17 # "< kugel> SVN uses async" <- svn up 23.27.08 # i committed FlynDice 's FS#10245 as r21088 23.27.11 # Ghost-Fox1: Is this a patch? 23.27.21 # funman: isn't it still at 248? 23.27.40 # Ghost-Fox1: just build rockbox, then all plugins are built as well 23.27.45 # boosted cpu frequency is 248MHz = 4*pclk = 4*62MHz so we use synchronous clocking 23.27.46 # well, anyway, it uses sync now, but the other guys maybe didn't svn up yet 23.28.07 # evilnick: No, i whant to know how to build a plugin in .rock. 23.29.02 # .rock s are plugins 23.29.39 # Ghost-Fox1: Can you describe exactly what you're trying to compile? All plugins are included in each build. 23.29.47 Quit n1s ("Lämnar") 23.30.40 # For start a simple hello world in c++ will be enout 23.31.00 # funman: is dbop at fullspeed too now (ie dbop clock == pclk)`? 23.31.07 Part Ghost-Fox1 23.31.34 # ah so we switch between normal and boost simply by switching between fastbus and sync, nice 23.32.44 # kugel: yep, that mush make a difference 23.33.06 # must* 23.33.21 # I've done that too in my tree 23.33.28 Quit bubsy ("Panic.") 23.34.15 Quit VytenisS (Remote closed the connection) 23.35.09 # so the only difference between my tree and svn is that I have pclk and plla a bit higher? 23.36.11 *** Saving seen data "./dancer.seen" 23.36.53 # svn diff will tell you :) 23.38.35 # svn diff will look like FlynDice's patch and tell me nothing without searching hours :( 23.39.16 Join HellDragon [0] (n=jd@modemcable022.187-203-24.mc.videotron.ca) 23.39.23 # svn diff, then interdiff his patch and your diff 23.39.29 # with some luck it won't be crappy 23.39.52 # or diff the tree with his patch applied with a tree that has your changes 23.40.40 Join bubsy [0] (i=Bubsy@unaffiliated/bubsy) 23.46.31 Quit petur ("Zzzz") 23.47.31 Quit domonoky (Read error: 54 (Connection reset by peer)) 23.49.06 # wow, it's hardly boosting on mp3 on my clip now :) 23.50.27 # bertrik: what does test_codec say ? 23.50.50 # :? file too large 23.51.02 # my test mp3 is 220kb or so 23.51.29 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 23.55.23 # bertrik: any idea why this doesn't work? http://pastie.org/490653 23.56.14 # kugel: goto is considered harmful :) 23.56.30 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 23.56.33 # funman: right, I should call it recursively :) 23.56.43 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 23.57.23 # kugel, it hangs? 23.57.29 # white screen at boot 23.57.47 # I want to wait for fifo half empty once the fifo was filled 23.58.35 # I guess each fifo level bit gets set only for a specific level, so there's a chance you might miss the half-full bit and wait indefinitely 23.58.52 Quit bmbl ("Woah!")