--- Log for 15.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 12 days ago 00.01.01 # * gevaerts thinks that the build page looks weird 00.02.58 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 00.02.59 # hmm, seems to be now building two targets at once? 00.03.23 # that too 00.04.45 # gevaerts: yeah I tried some "hot updating" but that didn't work too well yet 00.04.50 Quit jgarvey ("Leaving") 00.05.09 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 00.07.27 # Zagor: I'd really like a -uploadspeed parameter to help my poor adsl line survive a bit better (or maybe -curlopts?) 00.08.00 # * gevaerts decides to see if he can manage that 00.08.01 # amiconn: double-checked. the -meabi=4 flag alone does not break vorbis, only removing -mlong-calls also so that stubs will be generated causes breakage. this feature might need to wait for a newer binutils 00.08.20 # gevaerts: yeah I was just thinking about ways to deal with that 00.09.16 # Zagor: I'd just use .curlrc, but I don't want to limit my download speed, and someone forgot to make the rate limiting in curl direction specific 00.10.21 # maybe use a curlrc file in the checkout if it's there? 00.10.36 Quit Rob2223 () 00.10.37 # Unhelpful: I can only think of two possible causes, either a binutils bug or a hidden bug in our vorbis decoder 00.11.09 # gevaerts: I think Bagder accepts bug reports 00.11.50 # kugel: I think he prefers patches, but I don't feel like working on that right now :) 00.13.54 Quit robin0800 ("Nice Scotty, now beam my clothes up too!") 00.17.32 Join Rob2222 [0] (n=Miranda@p4FDCC04C.dip.t-dialin.net) 00.17.32 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 00.23.45 # linuxstb: i have the intention, yes...but have no clue when i will ever have the time to work on it... 00.24.44 # Unhelpful: Did you check whether the resulting call paths change? 00.28.42 Quit Zagor ("Leaving") 00.29.54 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.31.36 Quit bertrik (Read error: 113 (No route to host)) 00.39.21 Quit DarkDefender ("Leaving") 00.43.01 Quit evilnick ("Page closed") 00.44.59 Quit r4v5 (Remote closed the connection) 00.45.28 # * funman just sent an email to an atmel contact who might have informations on which SD controller is used in the Fuzev2 and Clipv2 00.48.09 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.48.40 Quit shotofadds ("Leaving") 00.49.25 Quit CaptainKwel ("Page closed") 00.50.58 Join Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 00.52.19 Quit stripwax (Read error: 104 (Connection reset by peer)) 00.52.22 Quit mirak ("Ex-Chat") 00.54.05 Quit Sajber^ (Client Quit) 00.54.33 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 00.54.40 Join Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 00.57.48 *** Saving seen data "./dancer.seen" 00.59.06 # gevaerts: see what I mean :D 00.59.59 Nick punyhumanright is now known as karma (i=amg@host193-123-47-78-dhcp.bshellz.net) 01.11.27 Quit flydutch ("/* empty */") 01.17.19 Part toffe82 01.22.41 Quit Thundercloud (Remote closed the connection) 01.23.55 Quit kugel (Remote closed the connection) 01.31.59 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 01.36.17 Quit graey (Read error: 110 (Connection timed out)) 01.41.33 Quit CIA-71 () 01.50.10 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 02.00.47 Join CIA-69 [0] (n=CIA@208.69.182.149) 02.05.28 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 02.16.48 # we might have to check the SD status register sent by cmd13 02.16.50 # amiconn: what exactly should i be checking? the basic process here is for gcc to always emit bl for calls, which is what it does without -mlong-calls, anyway. the assmebler then labels the callsites as R_ARM_CALL relocations, and then the linker either copies in the correct offset if they're in-range, or generates a stub to use as the bl target, the stub being __[label]_veneer: ldr pc, [pc, #-4] ; .word
02.18.34 Join z35_ [0] (n=z35@ool-45701ce5.dyn.optonline.net) 02.18.52 Quit z35_ (Read error: 104 (Connection reset by peer)) 02.21.17 # the #-4 seems a little weird to me, as the address is stored after the ldr... 02.21.39 Quit saratoga ("Page closed") 02.22.07 # Unhelpful: pc points 8 bytes after the current instruction when read (4 bytes in thumb, so always the size of 2 instructions) 02.22.19 Quit robin0800 ("Don't follow me") 02.22.38 Quit efyx (Remote closed the connection) 02.23.46 Quit CIA-69 () 02.23.54 # my attempts to use cmd55 (app cmd) after card init fails with CMD TIMEOUT ... 02.24.21 # ah, so #0 would be the place after the address, and -4 is the address, and that's entirely right. :) 02.24.34 # ^^ 02.25.30 # so, what i should be looking for is 1) any code aside from the call instructions themselves that differs 2) any calls to the wrong veneer function 3) any veneer that do not point where they claim to ? 02.26.52 # i have difficulty imagining how any of those things would happen... especially how #2 and #3 would produce the result i see (vorbis files skip on attempting playback without error report) 02.35.08 # If a codec skips a file, it is due to an error. That error might or might not be displayed 02.35.37 # Did you replace both core and codecs in your test, or did you mix them? 02.35.38 Join CIA-69 [0] (n=CIA@208.69.182.149) 02.37.51 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 02.42.47 # Hmm, vorbis is the only codec using setjmp... 02.43.16 # replaced both. since calls between the two are always via pointers, i *could* mix them... it might make it clear whether it's a core or a codec issue. 02.50.35 Quit bzed (Remote closed the connection) 02.50.38 Join bzed [0] (n=bzed@devel.recluse.de) 02.51.46 # You can only mix them if you're not using different abis 02.53.19 # amiconn: i'm not - i've built both with stock gcc except for the spec change to pass the -meabi=4 assembler option, but one of them is built with -mlong-calls, the other is not 02.53.48 # would being called via a veneer perhaps mess up setjmp or longjmp? 02.53.55 # * amiconn wonders how a real eabi build performs in this case 02.55.07 # that's a few days ago for me, but i believe what happened was that vorbis stalled at the start of the file, and that after stopping playback other things went wrong (that had worked before attempting playback) 02.55.30 # there are no stubs for setjmp or longjmp... 02.55.58 # nm on the .elf, since it's been through linking, tells you exactly which functions have stubs :) 02.55.59 # I suspected setjmp for a while, but the generated asm is okay, and being called via a veneer shouldn't matter as that doesn't touch lr 02.57.34 # precisely... the veneer doesn't do anything but load the new address into pc 02.57.51 *** Saving seen data "./dancer.seen" 02.59.55 # there are only four stubs, i could either 1) go around enabling or adding debug logfs or 2) try marking individual stubbed functions as long-call to see if that fixes it 03.00.03 # Yeah, but if you drop -mlong-calls, the rest of the code changes. All long calls are turned into 'bl' 03.00.28 # This may in turn change regiser allocation 03.00.32 Quit Stephen_ ("Leaving") 03.01.05 # it may, because with interworking it needs to load the target address into some other register first, doesn't it? 03.01.05 # * amiconn wonders whether there are asm blocks involved - another "popular" method for producing hard-to-find bugs 03.01.41 # Asm blocks with incorrect clobber lists or similar 03.02.35 # amiconn: and perhaps a missed clobber is harmless in one case due to different register allocation? 03.02.48 # yes 03.03.26 # * amiconn alraedy had to deal with such asm blocks 03.03.41 # an asm function that fails to save a clobbered register may have a similar effect, right? 03.03.45 # This kind of bug also tends to show up when switching to a newer gcc 03.06.34 # if the clobbered register is some calculated flag, or an test value for a loop condition, or such, that would also explain the behavior i'm seeing... 03.07.48 # whereas the idea of it having to do with the relocation itself would make it terribly hard to believe it would do anything but crash 03.12.05 Nick agaffney_ is now known as agaffney (n=agaffney@gentoo/developer/agaffney) 03.22.01 Join JdGordon| [0] (i=ae919271@gateway/web/freenode/x-8eefa34bf5a88223) 03.22.05 # add doesn't need a "cc" clobber, right? only adc would? 03.25.42 # CLIP_TO_15 could be optimized on armv6 with ssat, i believe... 03.26.57 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-c2db52f4af3f4c9f) 03.27.06 # Unhelpful: have you tested vorbis with ASM disabled? 03.27.16 # should give you a pretty big clue if its the problem or not 03.28.07 # it looks pretty easy to do, at least ;) 03.30.31 Quit funman ("free(random());") 03.30.34 # saratoga: it looked to me as if using 16-bit constants in mdct might possibly be helpful... especially if the large const array in the main loop is packed as well. it basically cuts loads of constants in half if they're packed two to a register. 03.30.56 # Unhelpful: i think thats worth trying 03.31.09 # for reference, cook uses the same imdct entirely in 16 bit precision with good results 03.31.24 # and I think theres an 8 bit version of it floating around thats supposed to be listenable 03.32.28 # the gains from the other things i mentioned amounted to about 2% 03.32.32 # though i'm curious if this would apply to ARM4 or just the ones with 16 bit multiply? 03.32.52 # i saw that, though I didn't see a commit for mp3? 03.33.31 # i didn't look at the mp3's mdct... for all i know it has both optimizations already :) 03.33.41 # oh I thought you mentioned MP3 before 03.33.50 # and no, it would not apply for arm4, so only some unsupported targets that are arm5e and arm6 03.34.02 # i tested mp3. i stopped when you said it had its own mdct 03.34.07 # ah ok 03.34.47 # i bet simply rearranging ops in the mp3 filterbank and imdct would improve performance on later arm targets, it was written targeting ARMv4 (and for the ifp port IIRC) 03.35.07 # and arm7tdmi has fewer restrictions due to pipelining 03.36.09 # you *can* load values stored as halfwords together with arm4, but you'll need 3 ops of fixup to use those constants if they're to be multiplied... an asr #16 will get you the top value, and an lsl #16 ; asr #16 will get you the bottom one 03.36.53 # yeah i remember looking into doing that and deciding it wasn't worth it 03.36.55 # if you're going to be *adding* the values, and the other side of the add need not be rotated, you may need only one fixup op, in which case it's more likely to pay off to save the load 03.38.04 # the lack of input shifts or immediates for the multiply and parallel-math ops really stings sometimes ;/ 03.38.58 Quit JdGordon| (Ping timeout: 180 seconds) 03.48.07 # disabling arm assembly in libvorbis = playback proceeds :) 03.58.09 Quit JdGordon ("Leaving.") 03.59.55 Join wannaplaylist [0] (n=813b5dd5@gateway/web/cgi-irc/labb.contactor.se/x-5df18766154a3fb3) 04.00.46 Join faemir [0] (n=faemir@78.33.109.163) 04.02.49 Join AndyI [0] (i=AndyI@212.14.205.32) 04.02.59 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 04.03.05 # I have a question for anyone about the 'on the go playlist creation'. I have never heard of rockbox til now so feel free to assume that i know precisely jack about it. I want to get an mp3 player that is cheaper and less 'locked in' i guess, than the ipod. Lots of them seem to not allow customized playlists though. Is the on the go feature in rockbox something that will allow me to make a folder of son 04.04.02 # well, 'the ipod' is just a device..it is the firmware that makes it 'locked in'... 04.04.14 # also, your message got cut off at allow me to make a folder of son 04.04.39 Join Strath [0] (n=Strath__@173-23-45-236.client.mchsi.com) 04.04.49 # and is rockbox like firmware that you install on an mp3 player?... ok let me post the rest... 04.05.01 # "Is the on the go feature in rockbox something that will allow me to make a folder of songs and put them on a device as a playlist? Thanks for any info." 04.05.32 # and yes...rockbox is a replacement firmware as it says on the front page... 04.06.43 # ok here is when the techidiot comes out... i really hesitate to alter the firmware on my ipod bc i don't want it be irreversible. just letting itunes update the ipod firmware killed all of my music once today... 04.07.55 Quit TheSeven (Nick collision from services.) 04.08.11 Join The_Seven [0] (n=theseven@dslb-084-056-163-085.pools.arcor-ip.net) 04.08.15 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-163-085.pools.arcor-ip.net) 04.08.38 # but i want a second mp3 player anyway and might get a sandisk type. 04.08.39 # it is extremely low risk to install and can easily be reversed....that said, some parts of rockbox can be a bit complex, so might a recommend a read through the manual to get yourself aquainted with how things work/what you should expect? 04.08.41 # does that on the go playlist that rockbox enables mean that i can drag and drop 1 or more folders to a device and have it keep that folder intact as a playlist? 04.09.27 # it means that you can load whatever music you want and while out and about add/move/delete whatever folders or files you wish from a playlist 04.10.29 # oh, i didnt know it was reversible... so you can have multiple customized playlists? thanks for your help. once i get a new player i will read the manual before i install stuff since i'm not familiar with it. 04.12.03 # you can do whatever you want with a playlist...i usually dont use pre-created playlists though and just make one of what i want to hear at any one time...the manual will probably give you a better image of how these things work though... 04.13.34 # ok. it sounds like the feature is what i was looking for at least. i didn't see any point in having 4G of music if i couldn't organize it into lists that i wanted... it seems most force you to use playlists they make that are an artist/album/genre, etc. 04.13.45 # thanks for the response 04.16.38 Quit AndyIL (Read error: 110 (Connection timed out)) 04.18.50 Join dys`` [0] (n=andreas@krlh-5f72d918.pool.einsundeins.de) 04.21.38 Join kamlurker [0] (n=chatzill@user-142gr2b.cable.mindspring.com) 04.25.15 Quit wannaplaylist ("CGI:IRC") 04.25.41 Quit kamlurker (Client Quit) 04.30.37 Join GreatBeaver [0] (n=chatzill@c-71-59-18-236.hsd1.ga.comcast.net) 04.30.50 # do people defrag their mp3 players? and what program? 04.31.11 # that doesnt really have anything to do with rockbox.. 04.32.05 # can rockbox have a built-in defrag? 04.32.35 # it would be silly to have one in rockbox...your computer can do a much better job of it 04.33.32 Quit dys` (Connection timed out) 04.39.05 Quit saratoga (Ping timeout: 180 seconds) 04.41.10 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) 04.47.15 Quit faemir (Read error: 110 (Connection timed out)) 04.52.24 Quit n00b81 (Read error: 110 (Connection timed out)) 04.57.52 *** Saving seen data "./dancer.seen" 04.59.03 Quit thegeek (Read error: 110 (Connection timed out)) 05.04.07 # hah... replacing *either* of vect_mult_bw or vect_mult_fw with the C implementation gets things back to working 05.05.56 Join derekja [0] (n=derek@cpe-72-225-238-206.nyc.res.rr.com) 05.06.52 # how do you make rockbox ignore the "the" in front of a band namd 05.07.24 # also, it keeps crashing on my ipod video 05.10.20 # i believe the C and asm versions could both be made slightly more efficient by passing the end address rather than the count... especially seeing as the caller *has* the end address and *calculates* the count for the call 05.12.52 # derekja: you dont.. and thats not really an argument which anyone can be bothered having... 05.13.14 # there is a correct way to do it... using the sort tag, noone has done it in a way we want it, so its not being done yet 05.16.00 # JdGordon: and idea why it keeps crashing on my ipod video? 05.16.06 # *any 05.16.20 # it being what? 05.16.38 # rockbox 05.21.10 Part derekja 05.21.11 Join derekja [0] (n=derek@cpe-72-225-238-206.nyc.res.rr.com) 05.21.15 Part derekja 05.22.02 Quit GreatBeaver ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 05.25.12 Quit Horscht ("Verlassend") 05.37.32 Join dash32 [0] (n=dash32@p54AB41FD.dip.t-dialin.net) 05.39.42 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.44.38 Quit gevaerts (Nick collision from services.) 05.44.51 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 05.47.02 Quit Llorean (Read error: 54 (Connection reset by peer)) 05.47.40 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 05.55.22 Quit Strath ("Leaving") 06.01.20 # are image co-ordinates viewport relative? or screen relative? 06.02.00 # JdGordon: isn't pretty much *everything* in core screen-relative? 06.02.06 # erm, VP-relative? 06.03.01 # hmm... customwps says it is... 06.03.10 # * JdGordon doesnt wan to do math 06.09.52 # anyone know the volume keys in the clip sim? 06.20.20 # New commit by 03jdgordon (r21877): display the volume as a number when its changing in the cabbie theme on the clip 06.25.47 Quit dash32 (Remote closed the connection) 06.28.17 Quit JdGordon ("Leaving.") 06.30.13 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 06.33.44 # * Llorean wonders why he only updated one WPS 06.38.25 Join webguest76 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-adc360879daa4cd3) 06.39.04 Join webguest51 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-ab8ebd6ce9048236) 06.39.08 Quit webguest76 (Client Quit) 06.39.30 Join webguest54 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-9b896a13434d3b00) 06.40.07 Join webguest13 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-0b0205d4d3be186a) 06.40.15 Quit webguest54 (Client Quit) 06.40.15 Quit webguest51 (Client Quit) 06.41.52 Join webguest58 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-9146c40def64ef72) 06.41.52 Quit webguest13 (Client Quit) 06.43.52 Join webguest15 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-8a20121c77698dcb) 06.43.52 Quit webguest58 (Client Quit) 06.44.02 Quit webguest15 (Client Quit) 06.44.09 Join webguest51 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-62b2e224399b1e77) 06.44.49 Join webguest41 [0] (n=40ffb426@gateway/web/cgi-irc/labb.contactor.se/x-d695543e2b2fa6ed) 06.44.49 Quit webguest51 (Client Quit) 06.45.33 Quit webguest41 (Client Quit) 06.52.57 Join webguest99 [0] (n=40ffb479@gateway/web/cgi-irc/labb.contactor.se/x-1f8b931ca7014544) 06.53.06 Quit webguest99 (Client Quit) 06.53.13 Part ybit 06.55.06 Join derekja [0] (n=derek@cpe-72-225-238-206.nyc.res.rr.com) 06.55.15 Quit derekja (Client Quit) 06.57.54 *** Saving seen data "./dancer.seen" 07.08.31 Quit dmb (Read error: 113 (No route to host)) 07.09.08 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.14.28 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 07.14.34 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 07.19.35 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 07.28.01 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.31.18 # JdGordon: will you update the other WPSs too? (I agree with Llorean and think the default WPS should be as similar as possible across targets and since all bitmap ones show a volume icon...) 07.32.33 # generally I like the info there though and even thought about changing them myself but there are version that don't use viewports at all so that means more work.... 07.34.52 # I can understand some making it unique per target to fit the hardware, but things like this where there's no reason it shouldn't be the same, it should really be done for all or none. 07.36.57 # yes, that's what I meant to with "as similar"... on that note, I'm reminded that I wanted to make a suggestion for the c200 using a 10-pixel high font to get one more line in the WPS to use for the playback times info (and generally better fit) 07.37.58 # they used the Sazanami-Mincho-Regular fonts and that one exists as 10 too (but of course is a bit smaller) 07.38.49 # emm... the 11-Sazanami for the c200 currently 07.39.21 Join stoffel [0] (n=quassel@p57B4C1FA.dip.t-dialin.net) 07.42.03 Join AndyIL [0] (i=AndyI@212.14.205.32) 07.44.12 Quit r0b- ("( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )") 07.50.13 Quit stoffel (Remote closed the connection) 07.50.39 Join stoffel [0] (n=quassel@p57B4C1FA.dip.t-dialin.net) 07.54.19 Quit AndyI (Read error: 110 (Connection timed out)) 08.10.21 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 08.10.23 Quit bertrik (Read error: 113 (No route to host)) 08.12.15 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 08.35.56 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 08.38.16 Quit r0b- (Read error: 110 (Connection timed out)) 08.38.35 Join Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 08.39.18 Part safetydan ("Leaving.") 08.43.58 Quit Zarggg (Read error: 113 (No route to host)) 08.44.42 Quit pixelma (Nick collision from services.) 08.44.44 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 08.45.00 Quit amiconn (Nick collision from services.) 08.45.02 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 08.45.03 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 08.45.22 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 08.47.32 Join Rob2223 [0] (n=Miranda@p4FDCCF5B.dip.t-dialin.net) 08.50.35 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 08.51.28 Quit TheSeven ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 08.57.55 *** Saving seen data "./dancer.seen" 08.58.00 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 09.05.27 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.14.58 Join petur [50] (n=petur@rockbox/developer/petur) 09.23.50 Quit scorche (Read error: 60 (Operation timed out)) 09.24.46 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 09.26.22 Quit BHSPitMonkey (Read error: 104 (Connection reset by peer)) 09.31.44 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.33.58 Quit stripwax ("http://miranda-im.org") 09.48.31 Quit Thundercloud (Remote closed the connection) 09.56.54 Quit jfc (Read error: 104 (Connection reset by peer)) 09.57.10 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 09.58.24 Join obo_ [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) 09.58.32 Quit obo ("No Ping reply in 90 seconds.") 10.02.17 Quit JdGordon (Read error: 110 (Connection timed out)) 10.03.21 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 10.10.20 Quit stoffel (Remote closed the connection) 10.21.22 Join FlynDice [0] (n=FlynDice@12-187-217-130.att-inc.com) 10.27.17 Join stoffel [0] (n=quassel@p57B4C1FA.dip.t-dialin.net) 10.33.14 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 10.37.19 # funman: (for the logs) RE: SD card speeds P.6 sd spec 3.4 SpeedClass, RE : 12.5/25 MB/sec __interface__ speed p.39 sd spec 4.3.11 High-Speed Mode 10.39.05 Join Jaykay [0] (n=chatzill@p5DDC6CAC.dip.t-dialin.net) 10.39.18 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 10.41.39 # i suggest closing of FS#5886, FS#6212, and FS#8895 with the reason "out of date", because FS#9873 is going to be committed 10.41.54 # they are all about adding some functionality to the rec button 10.48.40 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 10.57.58 *** Saving seen data "./dancer.seen" 11.19.59 Join graey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 11.21.38 # Jaykay: how about waiting until it's actually committed? 11.22.11 # Unhelpful: Btw, if loading 16 bit values together allows you to use ldmia, it pays off to do so on arm7 even if you have to do some unstuffing. The libdemac filters used to do that before I switched them to using 32 bit ints on armv4. 11.22.29 # gevaerts: they are out of date anyway because theres a newer patch with the same functionality 11.23.02 # Jaykay: a patch isn't better just because it's newer 11.23.09 # Unhelpful: Oh, and in my experience stating "cc" as clobbered is unnecessary. It won't hurt though 11.25.27 # gevaerts: then its better because it supports all targets :) 11.27.44 # Jaykay: even that is not good enough. If all else is equal, sure, but is it? 11.31.56 # gevaerts: i don't know, i don't know enough about the code. then i'll wait until FS# 9873 is committed :) 11.34.33 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.34.44 Quit bmbl (Remote closed the connection) 11.35.19 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.35.23 Quit bmbl (Remote closed the connection) 11.40.14 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.41.41 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 11.47.39 # amiconn: well, these two asm functions list everything they clobber properly, and they're only called in one place, and looking at the asm there i don't see anything suspicious - but replacing either one of them with the C version from misc.h stops vorbis from failing again... perhaps it's something that happens somewhere else because of a difference in size, as that function has no long calls in it, anyway... 11.49.02 # and i was looking at the bits in libtremor... i'm quite sure the multiply and vector functions don't do anything too silly, although the multilpy ones are not needed as it's quite easy to get gcc to generate the same asm with very readable C math 11.52.00 # vect_mult_fw might go a bit faster with all four smull in front and then the shifts, but i don't see how it can be trashing any registers without gcc knowing 11.53.37 # i believe the pattern used is especially poor on the newer arms... i'm pretty sure the arm1136 manual states that a shifted input register must be ready a cycle early 11.56.38 # * amiconn wonders what the XPROD32 macro in asm_arm.h is actually doing 11.57.20 # It calculates 'l', but doesn't return that as the result of the block... 11.58.50 # * amiconn also wonders why that file seems to be duplicated 11.59.17 # It's in codecs/lib/ as well as in codecs/libtremor/ 12.09.30 # Unhelpful: Hmm, if you're mixing arm asm and C there, the result will be incorrent. See the comments regarding delayed shifts 12.09.38 # *incorrect 12.10.58 Quit Jaykay (Read error: 110 (Connection timed out)) 12.14.10 # amiconn: i noticed that... however, if *either* of those is swapped out for the C version, it stops skipping vorbis tracks. perhaps the problem has something to do with where in memory some other value is being stored, because if the problem were one of these functions, it would matter which one i replace... and if it were both, i would *have* to replace both. 12.14.43 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.16.15 Quit bubsy () 12.17.58 Quit efyx (Read error: 113 (No route to host)) 12.18.49 Join bubsy [0] (i=Bubsy@94.139.72.137) 12.21.51 # Unhelpful: Btw, if you're looking for possible optimisations - asm_arm.h has several functions which could be sped up a lot using 'clz' on armv5 and above 12.22.18 Join daurn| [0] (n=daurnima@ppp118-208-169-5.lns10.mel4.internode.on.net) 12.22.19 Join daurnimator_ [0] (n=daurnima@ppp118-208-169-5.lns10.mel4.internode.on.net) 12.23.04 # the arm asm division should be using clz as well... and i should really get around to writing that specialized shifted-output divide for pictureflow 12.24.37 # Which division are you talking about? 12.25.07 # Gcc uses 'clz' in its division routine on armv5 and above. 12.27.40 Quit daurn (Read error: 60 (Operation timed out)) 12.28.24 Quit daurnimator (Read error: 60 (Operation timed out)) 12.31.46 # we'd talked about this before, but basically fdiv calculates (num << 10) / den by first using clz to see how far it can safely shift the numerator, and shifting the denominator right if needed, and then doing the division. 12.33.37 # since arm doesn't have a divider, and we have to loop, this could be handled more efficiently, i think, by producing shifted output in the division routine directly. essentially, shift the bit-to-set value left by 10, and do a normal division, with up to 10 extra iterations to fill in the fractional bits 12.34.55 # * amiconn was talking about libtremor and hence didn't expect Unhelpful suddenly jumping to pf optimisations 12.35.31 # * Unhelpful has a long to-do list :) 12.37.04 # i'd *really* like to know what's breaking libtremor, though... i think the asm blocks in question may be a red herring 12.38.16 # Since it doesn't crash, it should be possible to log the error. Adding log statements may change behaviour if it's really an alignment problem 12.38.52 # Did you try if it also breaks if you do an ordinary short-call build (i.e. not using iram at all - probably slow as hell)? 12.41.50 # no, i didn't... i think a good way to prove an alignment bug might be to just check the sizes for the two versions of that function and add a pad 12.43.53 # if i can "fix" the problem in short-call-with-stubs by changing code that shouldn't break or fix anything, i should be able to change the behavior just by adding a pad to whichever version of the function is smaller, if the size is causing the problem. 12.44.24 Quit courtc (Read error: 113 (No route to host)) 12.47.45 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.47.56 Nick daurnimator_ is now known as daurnimator (n=daurnima@ppp118-208-169-5.lns10.mel4.internode.on.net) 12.52.45 # That almost sounds like an off-by-one access somewhere 12.53.09 # Changing the code size will shift variables in memory 12.53.25 # Are you testing on a PP target? 12.54.04 Join mt [0] (n=mt@196.221.199.202) 12.55.26 Join webguest20 [0] (n=ad581cda@gateway/web/cgi-irc/labb.contactor.se/x-387c977555743bcd) 12.56.10 Quit webguest20 (Client Quit) 12.57.59 *** Saving seen data "./dancer.seen" 12.59.17 # e200 12.59.43 # the asm versions both unroll the loop by four... they're actually *larger* 13.02.39 # Hmm, the vorbis codec doesn't seem to use dualcore. Otherwise wrong cache line alignment would have been a potential cause 13.05.59 # from other channel: "successs". if i swap in the C versions for the asm ones, vorbis no longer fails tracks (although the output is wrong because of the delayed shift). if i just add a global asm with ".size 20" (20 being the difference in size of the two objects), it's broken again. 13.09.44 # Hmm, so we do have an alignment issue in the vorbis codec... 13.10.07 # * amiconn once tracked down such a beast by bisecting 13.11.21 # First, put the filler at the very beginning and find out which sizes make the code break and which don't. Then, bisect the filler position 13.14.29 # This is how I found that PP5002 doesn't like its sleep instruction at certain addresses 13.15.39 # ick. i'll take a shot at it tonight... i need to be getting to bed now. i guess i could start by moving the filler around to see which function doesn't want to be offset? 13.16.38 # I'd first check whether it's code or data 13.19.28 # FYI: We plan to disable the old build system tonight 13.22.45 # Nice :) 13.31.12 Join mt_ [0] (n=mt@196.221.199.202) 13.39.47 Join TheSeven [0] (n=theseven@dslb-084-056-163-085.pools.arcor-ip.net) 13.40.11 Join mt__ [0] (n=mt@196.221.199.202) 13.40.46 Quit mt_ (Read error: 113 (No route to host)) 13.45.11 Join bagderoid [0] (n=daniel@host-90-232-14-85.mobileonline.telia.com) 13.48.12 Quit mt (Read error: 110 (Connection timed out)) 13.48.23 # zagor maybe se should announce the build switch on the dev list 13.48.48 # bagderoid: yup, I'll do that. 13.49.23 Join funman [0] (n=fun@rockbox/developer/funman) 13.50.13 # FlynDice: i tried reading the status register with acmd13, but i got a data timeout when trying to read the register with DMA 13.50.23 # both on internal storage and µSD 13.51.10 # we should also make sure the instructions are accurate. 13.54.12 Nick mt__ is now known as mt (n=mt@196.221.199.202) 13.57.35 Quit aditya (Read error: 110 (Connection timed out)) 13.57.44 Join aditya [0] (n=aditya@59.95.46.133) 14.00.45 Join Jaykay [0] (n=chatzill@p5DDC669C.dip.t-dialin.net) 14.02.47 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 14.03.44 Join courtc [0] (n=court@unaffiliated/courtc) 14.04.43 # can a wiki admin explain the last two diffs here? 14.04.44 # http://www.rockbox.org/twiki/bin/rdiff/Main/WpsIaudioX5Graveyard?type=history 14.05.56 # is that just a file being attached, then a second version of said file being attached under the same name? 14.07.51 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 14.09.40 Part bagderoid 14.10.59 Quit Zarggg_ (simmons.freenode.net irc.freenode.net) 14.10.59 NSplit simmons.freenode.net irc.freenode.net 14.10.59 Quit Sajber^ (simmons.freenode.net irc.freenode.net) 14.10.59 Quit dionoea (simmons.freenode.net irc.freenode.net) 14.10.59 Quit archstech (simmons.freenode.net irc.freenode.net) 14.10.59 Quit Trista340 (simmons.freenode.net irc.freenode.net) 14.10.59 Quit crashd (simmons.freenode.net irc.freenode.net) 14.10.59 Quit avacore (simmons.freenode.net irc.freenode.net) 14.10.59 Quit Zambezi (simmons.freenode.net irc.freenode.net) 14.10.59 Quit Bagder (simmons.freenode.net irc.freenode.net) 14.11.08 NHeal simmons.freenode.net irc.freenode.net 14.11.08 NJoin crashd [0] (i=foobar@lostnode.org) 14.11.08 NJoin dionoea [0] (n=dionoea@yop.chewa.net) 14.11.23 NJoin Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 14.11.26 NJoin Bagder [241] (n=daniel@rockbox/developer/bagder) 14.11.40 Join avacore^ [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 14.11.44 Join Trista689 [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 14.12.08 NJoin Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 14.12.21 Quit Llorean (Read error: 104 (Connection reset by peer)) 14.13.08 # soap: good question :) 14.13.49 # And, since the new theme site is long up and running - can we lock the Graveyard pages from upload? Perhaps plan a migration path once-and-for-all from the wiki theme pages to the web theme site? 14.14.42 # that would be nice 14.22.09 Quit dfkt (Read error: 104 (Connection reset by peer)) 14.26.07 Quit robin0800 ("Don't follow me") 14.40.03 Join muesli [0] (n=4d15fa43@91.191.140.131) 14.40.10 # hi guys 14.40.58 # hi guys 14.41.26 # gfd 14.41.32 Quit muesli (Client Quit) 14.41.38 Join robin0800 [0] (n=robin080@81.98.157.181) 14.41.58 Join muesli [0] (n=4d15fa43@gateway/web/cgi-irc/labb.contactor.se/x-865534404ffd6131) 14.42.04 # test 14.43.00 # muesli: hi 14.43.02 # mmh..i have no rights to speak?? 14.44.20 # no, the channel is just not very busy right now 14.44.30 # and people are probably waiting to see if you actually have a question :) 14.44.41 # ah, here we are... 14.44.46 # g'day mates 14.44.54 # muesli: You can always log at the logs - http://www.rockbox.org/irc/ 14.44.58 # we 14.45.31 # ah ok..im using the web interface. takes some moments until my message shows up ;-) 14.45.31 # Torne: can you give me again the list of maintainers for linux arm machines? 14.45.40 # hm? 14.45.54 # russel king is the main linux-arm guy 14.45.58 # that's about all the list there is :) 14.46.33 # are there any differences between the manual for recorderv2 and fmrecorder? 14.46.33 # I remember you gave me a list of maintainers for specific machines (listed in arch/arm/tools/mach-types) 14.47.21 # anyway... referring to http://forums.rockbox.org/index.php?topic=22225.msg153300#msg153300 14.47.34 # question 3: whats the usb diskmode? 14.47.51 # funman: oh, the machine type registry is on the linux-arm site 14.48.01 # http://www.arm.linux.org.uk/developer/machines/ 14.48.05 # there's no guarantee it's up to date 14.48.12 # it's mostly "the person who asked for that machine type to be added" 14.48.24 # rather than any guarantee that that person still cares about that port 14.48.40 # thanks, i'll bookmark it anyway 14.48.49 # linuxstb: AAC extradata in rm seems to always be 3 bytes. (first 2 are 2h and 12h for the stereo samples I have, I'm guessing the first one could be channel config ?). Still can't figure what the other two are for, assuming I got the first one right ! 14.48.52 # http://www.arm.linux.org.uk/developer/machines/list.php?id=2096 for AS353X machine 14.49.47 # mt: Have you looked at the existing aac codec? How big is the extradata there? 14.50.30 # since extradata is used by the decoder i would expect it is the same ? 14.50.43 # funman: Yes, that's what I'm asking... 14.50.49 # You never know though. 14.50.56 Join muesli_ [0] (n=sdf@77-21-250-67-dynip.superkabel.de) 14.51.07 # ok...new try 14.52.06 # anyway... referring to http://forums.rockbox.org/index.php?topic=22225.msg153300#msg153300 14.52.07 # question 3: whats the usb diskmode? 14.52.07 # sorry 4 flooding the channel with my doublepost 14.52.11 Quit muesli ("CGI:IRC") 14.52.24 # muesli_: Then why ask again? 14.52.54 # i changed to mirc since the webinterface couldnt be used for a proper conversation 14.53.56 # linuxstb: (Just making sure) In apps/codecs/libm4a/m4a.h, is "codecdata" equivalent to what we referr to as codec_extradata ? 14.54.14 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.58.01 *** Saving seen data "./dancer.seen" 15.01.42 # second try: are there any differences between the manual for recorderv2 and fmrecorder? 15.02.13 # No, as these devices are technically identical 15.02.16 Quit antil33t (Read error: 104 (Connection reset by peer)) 15.02.30 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.02.30 # (except the v2 *may* have the radio, while the fmr *does* have the radio) 15.02.57 # why do they have different manuals then? 15.03.37 # Well, they wouldn't, but they are two different targets 15.04.04 # This is necessary because the scrambling is different - an fmr loader won't load a v2 firmware and vice versa 15.04.22 # But once descarmbled the code is identical 15.04.48 # but the manual for all h1xx is also the same file 15.05.31 # ttp://lists.denx.de/pipermail/u-boot/2009-June/053679.html < an email from Ulrich.Herrmann@ams about SD card / uboot \o/ 15.05.34 # +h 15.06.26 # Jaykay: Perhaps someone may add a note about the radio for the v2 only, then they will be no longer identical 15.06.38 Join saratoga [0] (i=439f4426@rockbox/developer/saratoga) 15.08.29 # amiconn: there is a note about the radio in the v2-manual... but this note could also be in the manual for both players 15.08.47 # Why should it? The fmr always has the radio 15.08.51 # a "Note: some v2's don't have a radio" is enough imo 15.10.28 # is there a way to contact David A Johnston? 15.10.57 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 15.11.55 # muesli_: hes a regular on the mailing lists, have you tried email? 15.13.25 # amiconn: imo there's no need for another manual for a single line, but it's not my choice :) 15.16.13 # saratoga uff..have no clue about the mailing list. just want to contact him since he seems one of the very ones who got a iriver h120 cf-modded 15.16.20 # few 15.16.34 # * LambdaCalculus37 has to finish his work on FS#10431 already :) 15.16.57 # http://www.rockbox.org/twiki/bin/view/Main/DavidAJohnston thats what i found 15.18.22 # muesli_: you can see his email on http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-07/0140.shtml 15.18.42 # ah sexy, cheers 15.20.20 # anyone else care to comment on this one : http://forums.rockbox.org/index.php?topic=22215.msg153250 ? 15.20.37 # hmm. maybe the Big Green build table should only show builds with problems? 15.21.10 # that "Tango Digital Media Platform" thing in the dmesg output is making my LibGphoto2Bug bump itch. But clearly hal is implemented slightly differently on his distro. 15.21.21 # Zagor: that's a nice idea 15.24.46 # Zagor: Isn't it also used to get build details on targets that have worked? But I guess that could be moved to the binsize table (if it even needs to be kept...) 15.26.04 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-a77289e156738188) 15.26.26 # linuxstb: the only thing it does is give easy access to the logs. we could always keep the big on a separate page for when you want to look at the them. 15.28.17 # Would it be possible to keep a larger archive of build info? Things like binsize for old commits would be interesting to be able to lookup. 15.33.13 Quit jfc (Read error: 104 (Connection reset by peer)) 15.33.35 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 15.33.39 # * mt points linuxstb to his question about 50 minutes ago :) 15.34.06 Quit jfc (Read error: 104 (Connection reset by peer)) 15.34.21 # * rasher points linuxstb to http://rasher.dk/rockbox/graphs/ (although that doesn't have as much info as the build system can retain) 15.34.27 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 15.34.43 # funman could you please also provide a link for http://www.rockbox.org/twiki/bin/view/Main/FrankOtto 15.34.47 Part n00b81 ("Leaving") 15.34.52 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 15.35.56 # no sorry 15.36.21 Quit antil33t (Read error: 113 (No route to host)) 15.36.27 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.40.12 # GodEater: I think the Tango Digital Media id is normal for one of the many USB modes in the PP ROM 15.40.33 # IIRC its the pre-manufactoring mode or something like that 15.43.40 # ah ha 15.44.19 # mt: Yes, I think codecdata == extradata. It's used to init the aac decoder in the call to NeAACDecInit2() in codecs/aac.c 15.46.10 # I guess then I shouldn't bother what those three bytes represent .. I just read them all at once into the codecdata array. 15.46.12 Quit jfc (Read error: 104 (Connection reset by peer)) 15.46.36 Quit Jaykay (Read error: 110 (Connection timed out)) 15.46.46 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 15.47.10 Quit bmbl (Read error: 110 (Connection timed out)) 15.48.30 # mt: Yes, this "extradata" is something which is just passed to the decoder - you shouldn't need to worry about the contents. 15.49.31 # * mt just thought of doing the same for cook, which should decrease the bin-size a bit. 15.49.34 # rasher: Is that done independently to the main build system? 15.50.03 # linuxstb: yeah 15.50.12 # yes and no 15.50.22 # * linuxstb won't say the obvious... 15.50.45 # Well, I *think* it gets some of the results from the build system, but I'm not entirely sure that bit of it works these days 15.51.27 # it should still work I think 15.51.36 # maybe it will stop tonight though... 15.54.33 Quit mt (Remote closed the connection) 16.00.08 Quit antil33t (Read error: 110 (Connection timed out)) 16.00.14 Join antil33t [0] (n=Mudkips@119.224.12.185) 16.04.15 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 16.04.48 # * funman just mailed the person paid by austriamicrosystems to port uboot/linux to the as353x SoC used in Clipv2/Fuzev2 16.07.42 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-348fb7d0e92a4bac) 16.08.37 # funman: Now to cross your fingers and hope for a good response. :) 16.09.11 Join BCM43 [0] (n=simon@dyn-160-39-29-37.dyn.columbia.edu) 16.09.14 # LambdaCalculus37: unlike the last persons i had contact with, this person seems to know what "patch" and "open-source" mean, so I have good hopes 16.09.43 # funman: Maybe he'll want to join us in the porting efforts? 16.09.51 # Is rockbox stable on the ipod video 60gb? I installed it for a friend and it keeps crashing. 16.10.21 # mt: do the floats in COOKContext do anything? if not would you remove them? it'll save some IRAM 16.10.28 # i think they are left over 16.10.39 # LambdaCalculus37: i don't know, i think he works on u-boot/linux on his paid time; i can't tell if he wants to work on open source for free, and i don't imagine austriamicrosystems paying him to work on rockbox 16.10.56 # BCM43: crashing when doing what? 16.11.54 # BCM43: Maybe you need to try the 32MB build 16.12.01 # (but yes, more info is helpful...) 16.12.57 # mt: also, the current decoder duplicates a very large trig table between the mdct library and libcook, but removing the duplication is giving me occasional audio glitches so removing it is apparently non-trivial or else I am missing something 16.15.32 Nick obo_ is now known as obo (n=obo@rockbox/developer/obo) 16.16.59 # New commit by 03zagor (r21878): Master no longer needs time reporting, since it knows that itself. 16.17.42 # petur are you there? 16.17.53 # yes 16.18.37 # nice :) just found your postings for a cd-modded h120 in this thread http://taperssection.com/index.php/topic,95239.0.html 16.18.43 # cd=cf 16.19.36 # and? 16.20.10 # could you please have a further look on http://forums.rockbox.org/index.php?topic=22225.msg153300#msg153300 some details are still not to me 16.20.17 # clear 16.20.17 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.23.53 # I'm not really up to date on the h1x0 CF mod state wrt bootloaders. I wanted to work on it and bricked my h120 (my own stupid mistake). That was a year ago :/ 16.24.01 # * petur looks at LinusN 16.24.13 # New commit by 03zagor (r21879): Added -ulspeed parameter to limit upload speed. 16.24.27 # mmh..but can you recall what bootloader you have used? 16.24.38 # the standard v6 or the pre-one? 16.24.43 # I didn't... 16.24.45 # New commit by 03zagor (r21880): Bumped client revision. 16.25.04 # that's how he bricked it 16.25.09 # hehe 16.25.52 # I guess V7 is the way to go 16.26.52 # but could you use the player as an usb-usm device as when using the hdd? 16.27.01 # TODO list for the upcoming bootloader revision 16.27.01 # H100: Support USB Diskmode for CFModded players 16.27.02 # funman: I was trying to get to folders in the menu 16.27.05 # that scares me 16.27.44 # BCM43: you need to provide a complete bug report: which steps exactly you did, what is the result, what is printed on screen 16.28.04 # muesli_: I don't understand that remark in the wiki, USB is handled by a bridge chip in hardware, I don't think the bootloader can do much there 16.28.59 # BCM43: Did you install the 60/80GB build or the 30GB build? If the former, then try the latter. 16.29.32 Join Ubuntuxer [0] (n=johannes@dslb-092-073-030-076.pools.arcor-ip.net) 16.31.09 # funman: ok, I was using the menu to get to diffrent items, and it would crash every 5 min or so, on artist most often, but on others too. It would simply reboot, showing the apple start up screen. 16.31.18 # linuxstb: but it is a 60gb. 16.32.03 # BCM43: I know. 16.32.27 # BCM43, purchased new from Apple? There is a strong possibility if you bought anywhere else than you have the logic board of a 30GB model inside the case of a 60GB model. The 30GB model has less RAM, and would suffer similar problems if you used the 60/80GB build. 16.32.42 # soap: nowhere near new. 16.33.02 # soap: ok, thanks 16.33.38 # \o/ the ams guy replied 16.33.39 # Hi everyone, I noticed that r21863 breaks the Lua plugin. Some statements don't work correctly anymore: string.format('simple %s', 'test') -> "simple" 16.33.57 # funman: Positively? 16.34.45 # not really : http://pastie.org/546840 16.35.02 # Grahack, hows the lua coding 16.35.21 # I understand that the SD controller is made by Synopsys ? 16.35.33 # daurminator: broken at the moment 16.39.41 # Synposys DesignWare Mobile Storage IP (I'm not sure what "IP" means there, it is used a lot on Synopsys website) 16.40.14 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.42.20 # funman: intellectual property, in this case it usually refers to the combination of the HDL code for the controler, and the code for the drivers 16.42.41 # does that person her tells you to contact work for AMS? 16.43.11 # yes, i have already been in contact with him and he seemed interested in rockbox on as3525 16.43.40 # funman: is there any linux source at all for the 353x? 16.43.51 # he didn't answer my mail from april 30th 16.43.57 # no there is no source at all 16.44.31 # ah so thats probably the legal issue he refers to 16.45.11 Join brokenscreen [0] (n=5dd4a78e@gateway/web/cgi-irc/labb.contactor.se/x-519ce15ada7f551a) 16.46.01 # LambdaCalculus379: I don't understand your reply in the flashwriter thread 16.46.41 # perhaps they want to release the code only to their customers, so there is less change it becomes available in the wild 16.46.45 # chances* 16.47.31 # is there a help channel ? 16.47.44 # this is it, for rockbox anyway 16.48.02 # ok 16.48.38 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.51.09 # ok well i dont get it baken to create my own menue / wps ~ is there ab GUI that can help me ? 16.51.28 # I don't think so 16.53.50 # ok well how can i tell RB to use only rthe upper right screen part of the display ? | the rest of the display is broken! 16.55.55 # in the wps you can simply not draw anything to other parts of the screen 16.55.56 # I'd use the existing voice system. 16.56.10 # brokenscreen: The only way would be to modify the LCD driver and compile your own version of rockbox - not trivial... 16.56.23 # (if you wanted all of Rockbox to just use that part of the LCD) 16.56.29 # as there is no existing framework to rework any part of the user interface outside the WPS. 16.56.58 # Grahack: that part should probably get reversed then 16.58.04 *** Saving seen data "./dancer.seen" 16.58.52 # n1s: shouldn't non-Rockbox code not get changed? (RE your strncpy commit) It seems to've broken Lua 16.59.07 # and here we go, i mailed this product marketing manager at AMS again 17.05.31 # mcuelenaere: As strncpy is in the plugin lib, I think it makes sense to revert for lua... 17.05.46 # linuxstb: yep, I'm going to do that 17.07.12 # brokenscreen: you're probably better off using voice navigation 17.07.13 Quit evilnick ("Page closed") 17.07.28 # nice idea :) 17.07.36 # thanks i will try that :) 17.07.44 Quit funman ("free(random());") 17.07.56 # petur thx 4 help, bye @ll 17.08.44 # thx 4 help making my ipod blind now :) 17.09.19 Quit brokenscreen ("CGI:IRC") 17.09.29 Quit muesli_ () 17.11.29 Join BryanJacobs [0] (n=bryanjac@128.151.67.243) 17.11.57 # Zagor: maybe an idea for the future : if you send ulspeed to the server, it could conceivably be used for allocation purposes as well 17.12.41 # actually we already record actual upload speed 17.12.57 # Zagor: are there still plans to add SSL and/or (verified) usernames/passwords to the new build system? 17.12.58 # ah, true. Probably more reliable 17.13.00 # and yes, it could be used. especially to avoid re 17.13.18 # really slow uplinks getting big builds 17.14.04 # obo: yes, but not today. we'll start with a free-for-all. 17.14.16 # what are the current build clients like? 17.14.22 # New commit by 03Ubuntuxer (r21881): Fix a bug in lib display_text.h, which inserts a unwanted blank line 17.14.29 # Zagor: I'm curious if you think its worth using 7zip for uploads? the builds are MUCH smaller in that format 17.14.36 # BryanJacobs: in what respect? 17.14.41 # hardware specs 17.14.43 # saratoga: it probably is, yes 17.14.47 # though it would require substanital time for the server to repack to zip 17.14.51 # BryanJacobs: _very_ varied 17.15.03 # saratoga: aha, is it that much slower? 17.15.15 # BryanJacobs: they range from 8-core xeon machines to arm :) 17.15.40 # Zagor: 7zip (de)compression is quite fast, but you still have to rezip them on the other end since we distribute zips 17.15.44 # BryanJacobs: the new system is designed to accomodate any speed. from very slow to very fast. 17.15.51 # New commit by 03Ubuntuxer (r21882): Tiny bug fix for help text in pegbox 17.15.54 # would a dual Xeon 3060 with a 100Mbps uplink, 2TB of hard drive space, and 3GB of RAM be helpful? 17.16.03 Quit BCM43 (Remote closed the connection) 17.16.10 # yes, very 17.16.14 # BryanJacobs: yes. every client is helpful. and such a beast is very much so. 17.16.47 # saratoga: ah, true. I'll guess we'll wait a bit with 7zip 17.16.58 # New commit by 03mcuelenaere (r21883): Revert r21863 partly: fixes Lua 17.17.13 # I also have a dual Xeon E5310 kicking around 17.17.21 # its a shame we can't just use 7z for the downloads, zip seems to work particularly poorly for rockbox for whatever reason 17.17.28 # also with 100Mbps uplink 17.17.56 # build crosscompilers now :-) 17.18.49 # why build after every commit - why not do bisection only in the event that something comes up red in a daily build? 17.19.25 # because we can :-) and we like to get fixes done as soon as possible. 17.19.34 # by that time whoever made the mistake has gone to sleep 17.20.02 # w/e, my power is included so no big deal 17.20.03 # shortly we'll be getting the CIA bots to yell here in the channel when a build fails 17.20.22 # Zagor: make sure to rate-limit that :) 17.20.50 # well as long as the builds take a few hundred seconds each, I'm sure we're pretty safe from spamming :) 17.21.09 # where can I see a list of build clients? 17.21.33 # there's no such list. clients come and go as they choose. 17.21.55 # here's a list of those who participated in the build of r21877: http://build.rockbox.org/data/21877-clients.html 17.22.15 # hm. this is also rather insecure. 17.22.39 # I mean, any rockbox dev can run arbitrary code on the build clients, and in addition the current implementation is vulnerable to a MitM 17.23.21 # What sort of SVN commit would run arbitrary code on a build client? 17.23.28 # yes it is. we'll be straigtening it up a bit later, but we're too impatient to wait for it :) 17.23.42 # but it'd be so easy to gpg-sign revisions... 17.23.43 # soap: a makefile change for example 17.23.44 # you could edit the make files or configure script to run whatever you wanted 17.23.50 # you can run things in a VM if you like. 17.23.52 # but in the end it will always be inherently unsecure as long as we build things from svn 17.24.06 # yes chroot or vm is a good idea 17.24.09 # gevaerts: I think I will, I've got Xen already running VMs 17.24.12 # but honestly unless you're running this thing as root its probably not a huge deal 17.24.25 # filling up the hard drive would be bad enough 17.24.31 # even /tmp can do that 17.24.48 # BryanJacobs: in that case I think it's a no-brainer. That also seriously reduces the risk of accidentally breaking the build environment for the client 17.25.10 # yep, a full VM sounds like the way to go 17.25.15 # chroots aren't good enough 17.25.26 # but yes some sort of secure communications would be nice so that I don't have to worry putting this on school machines and such 17.25.31 # I'll even give it a dedicated IP address, Because I Can (TM) 17.25.43 # BryanJacobs: now that *is* overkill 17.26.12 # I have one anyway - so why not? No packet processing in the Dom0 this way 17.26.25 # otherwise I'd have to NAT it 17.28.48 # saratoga: secure comm doesn't help. any dev can still change the rbclient script. 17.29.31 # Zagor: not really. Update commands are for a specific revision 17.29.48 # gevaerts: ok, so change a Makefile then 17.30.17 # those are the real risk, yes, unless you personally turn evil :) 17.30.26 # i'm not too concerned about developers 17.32.22 Quit toffe82 (Read error: 104 (Connection reset by peer)) 17.32.36 # saratoga: so basically you just want svn over ssl? 17.32.55 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-0e567c69905fbac3) 17.33.02 # * BryanJacobs thinks that it should be svn over ssl so that nobody EXCEPT rockbox devs can inject code into the machine 17.33.10 # secure communication with the build master, yeah 17.33.10 # otherwise, anybody can 17.33.28 # also it'd be nice to have verifiable revision signatures 17.33.44 # kinda like monotone enforces 17.33.51 Quit flydutch ("/* empty */") 17.33.54 # i don't know enough about networking to comment on the best way to do that though 17.34.08 # and while we're on the wishlist, how about a DVCS instead of SVN? 17.34.11 # BryanJacobs: does svn support that? 17.34.38 # BryanJacobs: we have git-svn support 17.34.42 # Zagor: svn has no built-in support for signed revisions. But you could still do a GPG signature on the manifest which would do the trick 17.35.04 # the manifest? pardon my ignorance :) 17.35.07 # where is this mythical git? 17.35.17 # check the wiki 17.35.25 # sorry, there's a unique identification for each revision 17.35.26 # theres a page explaining how to use it IIRC 17.35.34 # BryanJacobs: http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl 17.35.46 # if you sign that the whole revision is essentially verified provided that the hash is secure 17.37.42 # eww, this git-svn thing is icky 17.38.03 # don't use it problem solved 17.38.45 # * BryanJacobs wants to use HG 17.39.02 # http://mercurial.selenic.com/wiki/WorkingWithSubversion 17.40.33 Quit Ubuntuxer ("Leaving.") 17.41.03 Join BCM43 [0] (n=simon@dyn-160-39-29-37.dyn.columbia.edu) 17.41.32 # why does rockbox not ignore the preceding "the"? 17.41.49 # BCM43: because "the" is a drink in many languages 17.41.59 # gevaerts: really? 17.42.30 # BCM43: every "why does rockbox not" question generally has the same answer: because nobody has implemented it 17.43.03 # BCM43: also, where do you sort things like "The The"? 17.43.22 # gevaerts: under the, you only ignore the first one. 17.43.46 # BCM43: should it also ignore "le", "die", ...? 17.44.35 # ideally it would be based on the language of the file name 17.44.35 # gevaerts: you could set it to do or not do that, or use the system language 17.44.47 # i always thought the simplist option was to pick a half dozen of the most common articles, always ignore them, and wait for this to annoy someone enough that they implement a language independent system with the lang files . . . 17.44.57 # unfortunately that's not really feasible without some heuristics, so system language setting is a good second place 17.45.18 # saratoga: I'm with you :-) 17.45.20 # * gevaerts thinks that there is no halfway good way to do this 17.45.22 # saratoga: lol, annoy people till they fix it. 17.45.33 # BCM43: you *can't* fix it 17.45.55 # There is a patch to use artistsort tags in the DB: FS#7287 17.45.58 # gevaerts: well, first build a database of every song ever written (and those that have yet to be written)... 17.46.43 # from a theory perspective, if we had a black-box that accepts a song name and outputs the language in which it's written, this is a solvable problem 17.46.55 # provided that there are no words that are articles or not depending on context 17.47.34 # * gevaerts thinks that sort tags are the right way to solve this 17.47.48 # just because you can't make a solution that works for 100% of all possible inputs, doesn't mean you acn't make one that works for all common inputs and fails harmlessly on the others . . . 17.48.09 # BryanJacobs: I geuss you could just chage the band name to Doors, the 17.48.17 # saratoga: I'm just not thinking about this from an anglocentric point of view 17.48.37 # gevaerts: I don't think i'm being anglocentric here 17.48.48 # we can just throw up our hands if the tag is encoded in UTF-foo 17.48.50 # we could easily enough make the article list be present in the lang file for instance 17.49.00 # its only centric to languages that have articles 17.49.15 # which at least would include french, spanish and german 17.49.27 # saratoga: that would work if articles in one language wouldn't be nouns or verbs in another 17.49.32 # saratoga: what if I have my spanish songs pop (Paulina Rubio) on my english-language player? 17.49.57 # song tile "La Costa Verde" wouldn't be sorted as "Costa Verde, La" 17.49.58 # again, you can't be right everytime but you can be right most of the time for most people 17.50.10 # thats why you make it a setting 17.50.35 # and let people use funny file name, sort tags, or whatever if they can't manage 17.50.47 # [17:17:21] its a shame we can't just use 7z for the downloads, ... <== Why is that? 17.50.57 Quit Windlord ("http://windlord.co.cc/") 17.51.03 # amiconn: well I guess we could :) 17.51.12 # though i bet we'd have people complaining about it 17.51.12 Join bertrik [0] (n=bertrik@87.211.49.117) 17.51.33 # I dunno... 7z is about the best free compression program for Windows 17.51.41 # and it's readily available on all major Linux distros 17.51.57 # i'm sure we'd annoy Mac users though who tend to use oddball programs 17.52.04 # saratoga: It would probably be a very good idea if rbutil would support 7zip 17.52.12 # of course they're still welcome to use rbutil . . . 17.52.21 # no kidding about Mac users. Cyberduck? Who came up with that name? 17.52.25 # hmm maybe not such a bad idea afterall 17.52.54 # make sure rbutil works with 7z, tell users to use rbutil, or if they want to do manual installs get 7z support 17.53.08 # that doesn't sound half bad 17.53.24 # the nontechnical people use rbutil anyway, and the technical ones have no problem decompressing a 7z archive 17.53.28 # would save us a lot of bandwidth 17.53.52 Quit Zagor ("Don't panic") 17.53.53 # * BryanJacobs has a few TB of hosting bandwidth to spare 17.53.54 # you need some? 17.54.14 # you could probably setup a download mirror if you wanted to 17.54.33 # how much traffic do you guys get in a month? 17.56.51 # hundreds of thousands of .rockbox downloads 17.57.19 # which incidently means 7zip woudl save us hundreds of GB of bandwidth a month 17.57.30 Join webguest49 [0] (n=400789a2@gateway/web/cgi-irc/labb.contactor.se/x-9b299bacbf91fd35) 17.57.40 Quit webguest49 (Client Quit) 17.57.47 # hundreds of thousands, eh? 17.57.53 # * BryanJacobs goes to do some math 17.58.24 # BryanJacobs: have a look at http://daniel.haxx.se/blog/2008/05/15/rockbox-downloads-april-2008/ 17.58.28 # rasher: i just launched binsize-client.sh.. 17.59.01 # this doesn't include mirros 17.59.36 # this isn't bad, that's less than a terabyte of traffic total 17.59.57 # I have 3TB to spare per month 18.00.02 # @100Mbps 18.00.30 # hm. 18.00.41 # give me a week or two to set up a dedicated Rockbox VM 18.00.52 # BryanJacobs: have a look at http://www.rockbox.org/tracker/task/4755. Those people might want some help with hosting 18.01.27 # hosting a converted version of wikipedia? 18.01.36 # I already have an XML mirror 18.02.15 # the plugin isn't ready for commit yet, but if it gets in, lots of people will want a pre-converted version 18.02.20 # torrents sound like a good idea for something like that 18.02.32 # large files are best served P2P 18.02.44 # the 600k rockbox build zips are not 18.02.47 # at0m: it should let you in now. But it's not terribly important - gevaerts' host manages to keep up with the builds 18.03.24 Join JdGordon| [0] (i=ad81d397@gateway/web/freenode/x-4201b2af032c720e) 18.03.37 # BryanJacobs: just suggesting things :) 18.04.12 Quit saratoga ("Page closed") 18.04.46 # rasher: ah ok.. will let it run a couple days for a try. didn't know how much of a bottleneck building was 18.06.49 # at0m: it might not let you in for another 30 minutes iirc the system caches the list or hosts to allow 18.07.05 Quit AndyIL () 18.09.33 Join Strife89 [0] (n=michael@207.144.56.176) 18.09.36 Join funman [0] (n=fun@rockbox/developer/funman) 18.10.26 # BryanJacobs: i was wondering if you have fixed yourself milestones for your gsoc project 18.10.56 # to know if you have fullfilled all the requirements, and are now doing "extra work" outside the gsoc program 18.12.18 # funman: yeah, I did come up with milestones 18.12.30 # I'm a little more than halfway done with them 18.12.57 # left would be seeking support, sound for the more esoteric (read: non-stereo) hybrid files, and getting a patch integrated 18.13.20 # non-stereo as in mono or more channels? 18.13.27 # take your pick? 18.13.27 # or both 18.13.38 # mono, 6-channel, and 32-bit? 18.13.50 # I'll definitely do mono and maybe the other two 18.13.54 # also floating point 18.14.12 # I don't know if there is a channel mixer already in rockbox 18.14.21 # there must be for the ac3 18.14.22 # gevaerts: HID less build seems to do the trick with my c250 on this Mac... I automatically get the two volumes when I connect to USB. Although compared to last week I also updated the bootloader, maybe that could be a reason why it works now too. Any ideas what to check? 18.14.25 # it supports 5.1 18.14.48 # BryanJacobs: what do you mean by "floating point" ? I thought no rockbox target had a fpu 18.15.14 # Wavpack has an integer floating point system 18.15.17 Quit Strife89 ("Vamoose!") 18.16.29 # aren't "integer" and "(floating) point" mutually exclusive? 18.16.51 # or do you mean a floating point representation in integer registers 18.16.52 Join _zic [0] (n=user@91-165-243-225.rev.libertysurf.net) 18.16.53 # no, it does no floating point operations (thus, "is an integer system") but represents floating point data 18.17.04 # okay 18.17.05 # you got it there on the second line :-) 18.17.12 # thanks for the explanation 18.17.22 # and good luck for your work! 18.17.41 # thanks 18.18.10 # when you are done with wavpack, i might have work for you related to buffering .. ;) 18.18.48 # but I'm already working on buffering... 18.19.00 # one of the things I have to do is modify buffering to support two files at once 18.19.09 # i have started reading buffering.c/playback.c to fix problems on the Clip/m200v4/c200v2 (the ones with a tiny tiny audio buffer) but I didn't continue 18.19.17 Join AndyI [0] (i=AndyI@212.14.205.32) 18.19.33 # I think I understand how they work, so feel free to ask any questions 18.19.41 # I saw that, and thought now you would be more familiar with that code than most of us 18.19.55 # thanks, i'll ping you when i open up those files again ;) 18.20.25 # funman, I've been thinking a bit whether we could implement a kind of a continuous built-in-self-check 18.20.34 Quit petur ("work->....") 18.20.45 # bertrik: what do you want to check exactly? 18.20.59 # like adding magic values between data that we check at each thread switch, so we can check if something is corrupting something else 18.21.26 # i don't think the problem has to do with corruption, more like an infinite loop when the buffer is nearly full, which can be aborted under certain conditions 18.21.28 # add checks on missing initialisation / double initialisation on kernel/thread functions 18.21.31 # those would be called cookies btw 18.21.57 # they're used as part of many modern stack- and heap-protection schemes 18.22.09 # add checks to some functions to see if they are called from interrupt context while not allowed 18.22.15 # at least it is exactly what i saw on c200v2 when loading AA, not sure if the exact same problem affects the clip/m200v4 which don't use AA 18.22.51 # how much memory do these targets have? 18.22.52 # there is already a cookie mechanism for threads stacks (the last entry of the stack = 0xdeadbeef) 18.23.07 # IIUC, the 'ticks tasks' run in interrupt context, but this may not always be obvious when browsing through the code 18.23.13 # 2MB of SDRAM + 384kB of another kind of SDRAM (IRAM) 18.23.50 # ew. So maybe you should just eliminate the disk buffer and use only a PCM buffer? (as in, make the buffering calls just read from the disk directly and pass through into the codec) 18.23.57 # bertrik: right, but afaik only the button reading is made in tick tasks? 18.24.22 # if you have to ask means you don't know ! :P 18.24.37 Join toffe82 [0] (n=chatzill@74.0.180.178) 18.25.04 # I wouldn't be surprised if a couple of these checks would already trigger if we added them to rockbox 18.25.14 # BryanJacobs: right, nico_p even made a patch for this some time ago 18.25.36 # for example, quite a few mutex locks were used uninitialised until recently 18.26.28 # Heh... according to talk in #linux4nano-dev it turns out that the nano2g may have a similar, if not same, LCD as the Meizu M3. :) 18.26.50 # linuxstb found a few addresses and other bits of info that indicate that. 18.26.53 # well there is much more tick tasks 18.27.07 # funman, indeed the playback stops on the clip et al. seem to be too "clean" to be actual crashes 18.27.18 # LambdaCalculus37: wasn't it already known that the lcd _screen_ is identical? 18.27.36 # BryanJacobs: Tests have shown that direct-read playback on flash targets still costs battery runtime compared to proper buffering 18.27.49 # Not as much as on hdd targets, but still significant 18.27.59 # amiconn: i see no battery bench on fs#9332 18.28.04 # gevaerts: got to go now though - so any testing and checks need to be delayed 18.28.05 # funman: Not to my knowledge, no. 18.28.18 # the LCD controller addresses will be the same as they are part of the s5l8700 SoC 18.28.24 # funman: But now I do know. :) 18.28.25 # LambdaCalculus37, would be nice if it could be re-used 18.29.14 # amiconn: I can guarantee that would only be the case in the event of data reuse from the buffer (codec calls bufseek backwards) 18.29.34 # for linear-access files that CAN'T be true 18.30.00 # bertrik: I think it can be done. 18.30.28 # BryanJacobs: It *is* true, and there's even an explanation 18.31.10 # but but but... if you have buffering, the cost to get a byte to the codec is cost(disk read)+cost(memory copy)+cost(memory read) - with direct-from-disk it's cost(disk read)+cost(memory read) 18.31.32 # BryanJacobs: but codecs don't read in conveniently flash-block-aligned increments :) 18.31.36 # ah! 18.31.46 # I've got it. Thanks, Torne 18.31.50 # Most (all?) flash storage devices auto-sleep after a few milliseconds without access. So if you access it constantly, reading only small blocks at a time, it will never sleep 18.32.01 # also that 18.32.04 # and write batching, that too 18.32.07 # constantly opening pages, even different pages, is expensive 18.32.12 # But if you do proper buffering, you read a large chunk, then let it sleep 18.32.20 # I was just thinking of the flash chips as true random-access devices 18.32.43 # amiconn: then perhaps we can tweak the buffer size if we know this auto-sleep time 18.33.05 # funman: "as large as possible" is the global optimum 18.33.18 # The tweak is to make it as large as possible, like on hdd targets 18.33.31 # :-) 18.33.34 # It's the same effect, only to a lower degree 18.33.52 # I can imagine there's some kind of knee, above which any improvement is marginal 18.34.03 # Yes, sure 18.34.25 # not if the flash chip staying asleep matters... 18.34.25 # and my guess is that it's a lot smaller than the full RAM 18.34.25 # bertrik: yes, but that's also true of hdd targets, no? 18.34.26 # Typical auto-sleep times seem to be around 20..50ms 18.34.33 # the larger the buffer the lower the active/inactive ratio 18.34.43 # bertrik: which is why the 64mb ipod video doesn't get significantly better battery performance than the 32mb version if you normalise for the battery capacity 18.35.18 # Torne: that might also be because we don't buffer up a user's whole playlist? 18.35.24 # yes we do 18.35.40 # my "Woman in White Suite" is larger than the whole buffer 18.35.41 # Torne: Someone should test that using lossless audio files on a 64MB ipod. I'm sure the difference is measurable 18.35.45 # on the ipods it's because if the buffer is twice as big it takes twice as long to fill 18.35.59 # eventually the power drawn by the actual transfer dominates instead of the spinup power 18.36.14 # it's still an improvement, but much less than it is at lower memory sizes 18.36.15 # The power drain by the actual transfers is the same 18.36.26 # ..uh, yes 18.36.27 # hang on 18.36.29 # gotta love asymptotic behavior 18.36.31 # * Torne pokes self 18.36.53 # amiconn: why would lossless make any difference? 18.37.11 # Because it consumes the data much more quickly 18.37.45 # Torne: There is *one* usage case where a very large buffer is actually worse than a smaller one - if the user is undecided what to listen 18.37.53 # amiconn: yah, that's true 18.38.08 # * Torne is only considering battery benches, really, rather than reality :) 18.38.16 # i can't see how the codec matters, though 18.38.32 # i would expect the same relative difference between 32/64mb regardless of codec as long as the playlist is bigger than the buffer 18.38.52 # as far as i've seen from mine and other people's benches, the difference is 50% 18.39.03 # which is the difference in stock battery capacity between the two models 18.39.12 # It doesn't matter whether the playlist is bigger or smaller than the buffer, due to the way rockbox buffering works 18.39.18 # I wouldn't expect the same relative difference, because the ambient consumption matters more if that data are consumed more quickly 18.39.39 # BryanJacobs: well yes, sorry. you would have to also normalise for playback current usage 18.39.42 # codec matters in that the effect of the large buffer is likely hidden behind the rather disproportionately large "static" consumption of all the common components. 18.39.58 # Rockbox buffering doesn't go back. If the playlist is smaller than the buffer and repeat is enabled, it will buffer another copy of the playlist after the first, and then another one etc 18.40.16 # a low CPU / high disk consumption pattern would be needed to see a significant variation in power consumption. 18.40.17 # amiconn: ah, didn't know that, and all the batter ybench instructions explicitly say to use one larger than ram, so i assumed it was 18.40.24 # which is one of the things I'd like to fix, but OK... 18.41.06 # soap: yes, sorry 18.41.08 # Yeah, that's just to play safe, in case someone forgets to change the instructions when changing buffering behaviour 18.41.08 # you are right 18.41.09 # since EverythingButTheCPU appears to be eating most the battery anymore. 18.42.01 # Higher bitrate will cause more freqquent spinups, so the disk access becomes a larger fraction of overall power consumption. 18.42.26 # * Torne blames his inability to do arithmetic :) 18.42.31 # * Torne can only do math 18.43.36 # Just imagine you have an album that is exactly 4 times the size in lossless (flac) as it is in lossy (mp3), and that album fits exactly into the buffer on a 64MB ipod 18.43.37 # or you could look at it as "the access rate from the disk averages to the bitrate of playback, so higher bitrate means more power drawn by the disk" 18.43.41 # even with no cost for spinning up 18.43.52 # amiconn: yesyes, i see it now 18.44.03 Quit mcuelenaere (Remote closed the connection) 18.44.13 # though for the ipodvideo specifically the effect might still be small compared to the fact that the 64mb version has a 50% larger battery :) 18.44.17 # So on a 64MB ipod you would have 1 spinup perhour (assuming the album plays 60min), on a 32MB ipod you would have 2 spinups per hour 18.44.24 # which is a pretty hard improvement to beat 18.44.36 # For lossless this would mean 4 spinups per hour on 64MB and 8 spinups per hour on 32MB 18.44.38 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 18.44.57 # a compelling case for using a lossless codec over raw PCM! :-P 18.45.09 # BryanJacobs: as if there weren't cases fo rhtat before? :) 18.45.18 # I saw a retarded thread the other day about it 18.45.49 # http://www.head-fi.org/forums/f4/alac-vs-flac-my-very-first-impressions-172058/ there we go, for a laugh 18.46.30 # i guess if you had a flash based player with a large enough ram the cpu cost of decoding the codec might actually make it more power efficient to just buffer pcm, since the difference between idle and active flash consumption could be less than the difference between boosted and unboosted playback 18.46.35 # :) 18.46.40 # BryanJacobs: Btw, if I did understand the explanation of hybrid wavpack properly, it should be possible to reconstruct a lossless stream from lossy+correction without full decoding 18.47.01 # I'm not 100% sure - this is a kind of math I don't understand well 18.47.05 # but if yo uhave a flash based player you probably don't have room for pcm files :) 18.47.07 # amiconn: it almost is full decoding, you're only skipping the entropy step 18.47.20 # it's certainly NOT something you want to do inside the buffering thread 18.47.34 # unless that thread runs on a COP or something 18.48.23 # Torne, in that case you should likely decrease the CPU frequency at boost, or add a third frequency as you're apparently wasting cycles when at full boost - else you're consuming the same number of cycles to get compressed->uncompressed regardless of when you do it - be it upon buffering or later. 18.48.52 # BryanJacobs: what's depressing is not a month goes by on head-fi when you don't see someone questioning whether lossless is really lossless 18.48.54 # Iiuc lossy+correction is produced by quantizing rice codes. So that step should be reversable without decoding 18.49.18 # soap: that would still have such a point, jus tlater. If your boost freq was exactly the rate required to, say, decode flac in realtime then it's sitll possible for boosting the cpu to be more expensive than reading from flash, in theory 18.49.26 # at0m: errr... your binsize client is broken 18.49.35 # whether this is likely on any particular hardware, i have no idea. probably not. 18.49.38 # ej0rge: I wrote a program which sample-for-sample compares WAV files, I don't suppose that would be enough to convince people? 18.49.39 # but it's not impossible 18.49.41 # BryanJacobs: too much magical thinking at that site, and i get so tired of telling people that flac sounds exactly like pcm for the same reason that the math in a spreadsheet isn't corrupted by putting it in a RAR file 18.50.26 # the modern audiophile claims that the CPU load being higher during lossless is what accounts for the audible difference. 18.50.32 # it could be that the processor leaks noise into the audio 18.50.38 # *compressed lossless 18.50.52 # hehe 18.51.09 # soap: or they raise the bogeyman of 'jitter' 18.51.16 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 18.51.35 # * BryanJacobs facepalms 18.55.15 Quit JdGordon| (Ping timeout: 180 seconds) 18.58.08 *** Saving seen data "./dancer.seen" 19.00.01 # soap: we clearly need to do some proper double-blind testing to make said audiophiles look like clowns 19.00.46 Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) 19.00.53 # bertrik: I'm assuming from reading the drivers that we don't know the different lcd controllers in the Meizu M3? 19.01.48 # linuxstb, I know next to nothing about the meizu lcd drivers 19.02.00 # maybe markun does 19.02.01 # Denes isn't around any more? 19.02.30 # denes signed off 4 months and 13 days ago 19.02.35 # :( 19.03.10 # He left the project? 19.05.25 Join liqix [0] (n=user@58.31.89.130) 19.07.41 Part liqix ("ERC Version 5.2 (IRC client for Emacs)") 19.13.47 # still can't get SD status register transferred even after correcting my code .. :( 19.15.18 Join Lynx_ [0] (n=Lynx@xdsl-78-34-253-183.netcologne.de) 19.22.27 Quit BryanJacobs ("Java user signed off") 19.23.23 # if you want to help : http://pastie.org/547043 19.25.39 Join JdGordon| [0] (n=Miranda@131.107.0.69) 19.26.20 Quit itcheg (Ping timeout: 180 seconds) 19.26.43 Join M [0] (n=7bf3fc5d@gateway/web/cgi-irc/labb.contactor.se/x-29fb7c6773eaf6d0) 19.29.48 Quit M (Client Quit) 19.29.52 Join M [0] (n=7bf3fc5d@gateway/web/cgi-irc/labb.contactor.se/x-824399bff0c2734a) 19.31.23 # bertrik: BTW, the Nano2G seems to have the LCD controller at a different address to the 8700 - it's at 0x386000xx instead of 0x3c1000xx 19.32.00 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.32.41 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-3fcdec5575013c45) 19.32.42 # linuxstb, ok, interesting, didn't expect that 19.33.02 # No, but it looks like TheSeven has confirmed it - he's making the LCD do things now... 19.33.20 # yep 19.33.26 # red/green/blue screen works 19.33.37 # black/white and all that, too, of course :-P 19.34.00 # very cool 19.34.16 # TheSeven: can you look at the meizu M6 LCDs one of these days? ;) 19.34.43 # well, depends on what you mean by "look" 19.34.58 # I mean "make them work" of course! 19.35.20 Quit M ("CGI:IRC (Ping timeout)") 19.36.02 # QI have a Ipov video, i'm using a build from abt a month ago and when I use it with a FM tranmitter via the dock (using IAP) the info for next song shows in giberish 19.36.04 # well, i don't have such a thing... 19.36.35 # when I use it with out the FM transmitter all shows fine 19.37.00 # This is what I'm using for next %s%alNext: %Ia;%t4%s%alNext: %?It<%It|%Fn> 19.37.55 # any ideas on why using the IAP would cause this? 19.38.02 # linuxstb: What builds so far with the nano2g code in the trunk? 19.38.28 # LambdaCalculus37: The bootloader builds, but I haven't tested it, or checked that any of the code shared with the Meizu will work... 19.38.40 Quit Grahack ("Leaving.") 19.38.56 # I should be able to spend some time on that over the next few days, and get an lcd driver working... 19.39.10 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 19.39.37 # linuxstb: I can try sending a bootloader to the nano2g using iBugger and see what it does. Hopefully we get something. 19.39.39 # I tried to take care to append -s5l8700 to any source file strictly related to the s5l8700, and -meizu to source files that do something meizu-specific 19.39.55 # LambdaCalculus37: You won't see anything... 19.40.02 # linuxstb: Ahh, right, right. 19.40.17 # bertrik: First thing will be to add a s5l8701 define - as registers look to be in different places... 19.40.22 # linuxstb: You also added a tool to the trunk for working with the nano2g, didn't you? 19.40.44 # Yes, it's "bin2note" - the same as my "bin2htm" included with iBuggerLoader. 19.41.01 Join mc2739 [0] (n=mc2739@cpe-72-181-28-23.satx.res.rr.com) 19.41.05 # You can use that (and the Makefile) to turn "loader.asm" into "loader.htm" if you so desire. 19.41.25 Join QncfOpO [0] (n=michi@e181138232.adsl.alicedsl.de) 19.41.26 # linuxstb, yes, it would be cool if we could share drivers even if they are at different addresses 19.41.59 # bertrik: Maybe it will be as simple as defining things like "LCD_BASE", and specifying the registers relative to that. 19.42.14 # But I guess we'll find out... 19.42.28 # I expect we can even share the M3's lcd driver... 19.42.52 # funman: should http://pastie.org/547043 line 133 be mutex_unlock(&sd_mtx); instad of mutex_lock? 19.43.13 # Although there are two LCD variants on the Meizus? 19.43.30 Join evilnick_7 [0] (i=0c140464@gateway/web/freenode/x-cf574c5f9e7b90cc) 19.43.31 # there are indeed 19.43.46 # Lovely #ifdef hell... 19.44.09 # mc2739: right.. 19.44.22 # Do you wish to discuss the user-list here, Llorean? 19.44.49 # funman: You said earlier that it was known that the Nano2g had the same LCD as the Meizu? 19.44.51 # What is the objection to having a moderated (user) mailling list? 19.45.12 # moderated as in how? 19.45.31 # linuxstb: i remember reading that someone had replaced a nano2g screen with a meizu screen (or the reverse) 19.45.32 # evilnick_7: If a new list needs started, its an unofficial one to be unmoderated. 19.45.34 # evilnick_7: I would guess the objection would be that someone would have to modify it... 19.45.42 # s/modify/moderate/.... 19.45.48 # linuxstb, the m3 comes with either a wolfson or a philips codec, the OF supports both by what seems to be an if-statement for each time the codec has to do something 19.45.59 # saratoga any ideas? (I think you commited the IAP patch) 19.46.02 # funman: Ah, interesting. 19.46.07 # Good question; I guess moderated as in a certain group of people can approve messages as they are sent in?? 19.46.11 # soap: So the suggestion is "if you're having difficulty solving the problem, give up" 19.46.12 # For I go back to my primary point: Repeating a behavior expecting different results is insane. So long as you narrowly define the possibilities so as to justify the behavior you repeatedly engage in you are guaranteeing the same (I would argue harmful) results. 19.46.14 # i can't find it again on google though 19.46.24 # soap: OFFER POSSIBILITIES. 19.46.31 # I have offered three 19.46.35 # stop shouting, please. 19.46.39 # List them again, I've missed them clearly. 19.46.46 # 1 - Moderate the list. 19.46.49 # I acn't do that. 19.46.53 # why not? 19.47.09 # Because that's not something I have access to do? 19.47.19 # delete the list, use the forums instead 19.47.35 # I never said "Llorean, you make the list moderated" 19.47.43 # itcheg: I committed it but I didn't write it and I don't have an ipod 19.47.57 # The only Rockbox user mailing list run by rockbox.org CAN be moderated. 19.48.00 # soap: Well, we were discussing what *I* should or should not be doing, or at least you kept directing a lot of "you" at "me" 19.48.38 # It appears to me you would be unwilling to accept your powerlessness over the problem. 19.49.12 # According to what? 19.49.17 # Clearly the "need" for these long emotional threads has not diminished over time. I therefore would say the success rate of current policy to be a big fat zero. 19.49.25 Quit funman ("free(random());") 19.49.25 # itcheg: I think the usual response though to devices that don't work with the IAP is to either investigate whats missing and implement support for whatever your device needs from it, or wait for someone else to take an interest in the problem and do it for you 19.49.25 # soap: that's dumb, honestly 19.49.36 # Have you seen me respond to any of the half dozen top posters since I left? 19.49.48 # No, I'm only responding to the people who've responded to this one thread I created upon leaving. 19.49.53 # itcheg: do you mean the text is wrong on the player? 19.49.54 # Go ahead - continue to piss off the masses in your self-righteous crusade. 19.50.00 # And that's because they are already engaged in a conversation with me. 19.50.14 # you didn't have to respond. You could leave their sick behavior to be their own problem. 19.50.34 # soap: You honestly think I feel *superior* because of this? 19.50.42 # did I suggest you did? 19.50.48 # *do 19.50.49 # You called me "self righteous" 19.50.56 # gevaerts: the issue is that for next song it works under normal circumstance but if I use an fm transmitter via the dock is shows gargles text 19.51.04 # So, yes, you said so at least. I guess you may have mis-used it. 19.51.07 # what is your motivation? 19.51.10 # itcheg: on the player? 19.51.14 # yes 19.51.26 # ipod video 64 (5.5 gen) 19.51.31 # soap: Well, prior to leaving, it was "nobody else enforces them, we need to either remove them or do so" 19.51.49 # hm, that really shouldn't happen, regardless of whether the transmitter works or not... 19.52.00 Join M [0] (n=7bf3fc5d@gateway/web/cgi-irc/labb.contactor.se/x-7f86ba2519005807) 19.52.17 # the interesting thing is that I had used the patch with my own build before it was committed and it worked fine 19.52.35 # soap: The easiest solution is to simply remove the rule about top-posting. 19.52.40 # what you just said in quotes is the sort of black-and-white thinking which leads, IMHO, to these threads. 19.52.46 Join n1s [0] (n=n1s@rockbox/developer/n1s) 19.53.16 # soap: So what, we should pick and choose who's allowed to top post to maintain a nice healthy shade of gray? 19.53.33 # You're using hyperbole again, rather than suggesting changes. 19.53.39 # itcheg: I can't really test this (I don't have the needed toys). Can you submit a bug report? 19.53.39 # If by correcting every single misstatement in the thread under question you believe you accomplish anything except perpetuating the sick discourse, you are mistaken. 19.54.13 # I call it self-righteous as there appears to be no error, no matter how small, you are willing to let go uncorrected. 19.54.13 # sure, but need to make an account... 19.54.29 # let me try with latest build first 19.54.55 # There seems to be an amazing inability to simply walk away from a conversation until the other side has either left or submissively appeared to agree to your points. 19.54.57 # soap: That would be something else, since self-righteous contains a rather different meaning that that. 19.55.33 # I'll also walk away when the other side says "I disagree, but have no new points to offer on this" or when I personally feel I've run out of new points to offer. 19.55.36 # gevaerts: is there anything wrong with this: %s%alNext: %Ia;%t4%s%alNext: %?It<%It|%Fn> that could be causing something like that 19.56.05 # itcheg: IIRC you cant put scrolling in sublines? 19.56.06 # itcheg: I'm not too familiar with wps syntax, but I wouldn't think so 19.56.19 # really? What new facts did you bring to the table in your most recent post to the user mailing list? 19.56.31 # (the reply to DavidD) 19.56.40 # At least, whatever you do wrong there (if any) it shouldn't cause the behaviour you're seeing 19.57.17 # soap: Well, the fact that I've never banned anyone from the list for one. 19.57.29 # Valuable information there. 19.57.29 Quit M ("CGI:IRC (Ping timeout)") 19.57.40 # Worth continuing a public argument I'd say~ 19.57.52 # Oh, yes, I should instead let someone spread a lie about what's actually happened? 19.57.53 # Cure is worse than the disease. 19.58.00 # "spread a lie" - 19.58.01 # lol 19.58.08 # You think it's truth that I've banned people? 19.58.09 # That, in a nutshell, is the problem again. 19.58.47 # You honestly believe that DavidD was spreading lies that you kick people? 19.59.01 # I honestly believe that DavidD posted to our public list with information that was wrong. 19.59.10 # And that if other people didn't know better, they could believe it was true. 19.59.15 # There isn't a _chance_ that the line of his you quote could not be taken something less than 100% literally? 19.59.28 # I don't think arguing about people's arguments is productive 19.59.37 # soap: What's it supposed to be taken as, exactly? 19.59.40 # either propose a solution to whatever problem you percieve or let it go 19.59.49 # "He said I've banned people, but he really meant I've asked them politely not to top post"? 19.59.50 Quit n1s (Read error: 104 (Connection reset by peer)) 19.59.51 # Self-righteous: Your responsibility to correct every little factual error. 20.00.01 # That's not what self-righteous means. 20.00.08 # saratoga, I have proposed three solutions. 20.00.14 # 1 - make the list moderated. 20.00.21 # And frankly, the idea that I've been banning people from the list is not a *little* error 20.00.27 # 2 - try someone other than Llorean dealing with problem users. 20.00.28 # "Being a dick to people then kicking out anybody that complains is not an acceptable way to interact with a community." Is not explicitly saying that anyone is doing/has done this. 20.00.38 # soap: I've stopped dealing with problem users anyway. 20.00.45 # 3 - take the discussions of, and handling of, problem users off-list. 20.01.31 # all of those presume that the list is kind of useless as a way to discuss things 20.01.47 # and I think a strong case can be made that it is. 20.01.48 # in that they discourage people from using the list to discuss things 20.01.59 # take this logic to its conclusion 20.02.00 # saratoga: It pretty much is, the way things are right now. 20.02.21 # As these threads continue, and continue to be a sizable percentage of the total list. If they were "useful" or "functional" the need for them would cease. 20.02.22 Join M [0] (n=7bf3fc5d@gateway/web/cgi-irc/labb.contactor.se/x-b2305642db67ab01) 20.02.41 # soap: As to #3, have you actually tried that? 20.02.53 # yes, I email about two people a week. 20.03.16 # I have no powers to remove anyone from the list - so I simply point out the rules, do not threaten. 20.03.34 # I've never threatened. 20.03.36 # i don't think any of those are likely to work, but I like #1 best since in practice it would mean that most people wouldn't use the list 20.03.41 # didn't suggest you had. 20.04.32 # saratoga, perhaps they won't work. I think it is reasonable, though, to say what is currently being done isn't working. 20.04.33 # #3 has never worked for me. Even a simple "We've asked that you please not top post to the list. If you're having difficulty, let me know what client you're using and I'll see if I can help" has gotten me extremely rude responses. 20.04.36 # Hey, could anyone tell me how I might add a virtual led toggle to the ui simulator? 20.04.46 # Llorean, I have NEVER gotten a rude response. 20.04.46 # And by never I mean, literally, never. 20.04.58 # no response? Often. 20.05.21 # I've gotten no response from people who've also not changed their behaviour. 20.05.36 # soap: Maybe you could let us know what you put in an example off-list message? 20.05.38 Nick M is now known as MHael (n=7bf3fc5d@gateway/web/cgi-irc/labb.contactor.se/x-b2305642db67ab01) 20.05.42 # and justifying current behavior, if we take it as broken, as the only option when "no behavior" is always an option is also false. 20.06.01 # soap: The option "no behaviour" should be rewritten as "drop the rule" then 20.06.11 # If you aren't enforcing the rule, it doesn't really exist. 20.06.17 # lol, here we go again with taking it to extremes. 20.06.27 # How is it not the case? 20.06.41 # If you say "we've written this rule down, but will never enforce it" you're saying "this rule isn't really there" 20.06.42 # A holiday from an "enforcement" policy which doesn't work is hardly a suggestion to "drop the rule". 20.06.53 # How is it a holiday? 20.07.14 # Why *can't* we just drop the rule, exactly? 20.07.34 # If nobody's willing to try to enforce it, why do we have it? 20.07.35 # You are the one defining your current enforcement policy as the only possibility. A comfortable definition for it pretty much ensures the answer is "continue as before". 20.07.56 # soap: Elaborate, please. 20.07.56 # Regardless of the utter failure of current enforcement tactics. 20.09.10 # Your suggestions for better policies are 1) Make the list moderated (but nobody has stepped up to do this in the last several years), 2- someone else do it (nobody has stepped up to do this, and I've left the job anyway so 2 is currently inaction) and 3- take it off list 20.09.12 # Elaborate? Half of what you have said to me in this channel the last 20 (?) minutes and all that you have said to me in the mailing list is a narrow definition of the possibilities. All with the self-evident result that current policy = only possible policy = no need to change visibly broken ways. 20.09.31 # I've asked you time and again to offer broader definitions. 20.09.38 # of what? 20.09.46 # you're the one saying I've narrowed them 20.09.47 # Shouldn't you know? 20.09.52 # You dismiss my broader definitions before I even get started. 20.09.59 # Get started on what? 20.10.30 # A holiday from an "enforcement" policy which doesn't work is hardly a suggestion to "drop the rule". 20.10.44 # Again - holiday how 20.10.53 # you let the current thread die. 20.11.03 # You're either not enforcing the rule at all, in which the rule is dropped, or you're replacing it with another enforcement policy. 20.11.05 # regardless of how many "wrong" things are said in it. 20.11.24 # What does the current thread have to do with the enforcement policy, at all? 20.11.58 Join _lifeless [0] (n=lifeless@94.51.196.117) 20.12.04 # no - you act much more pragmatically and realize that sometimes you cause your ultimate goal more harm by continuing to press your point (no matter how valid) in the face of resistance than to let all parties calm down and address it again at a later date. 20.12.15 # What is your goal? 20.12.28 # Now? Fuck all. I'm not talking to top posters. 20.12.56 Quit _lifeless (Client Quit) 20.13.52 Quit MHael ("CGI:IRC (Ping timeout)") 20.13.53 # Seriously, is this a discussion about what *I'm* doing, or about what the list needs to be doing. 20.14.16 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 20.14.44 # If it's about what I'm doing, you can stop now. I've stopped attempting to ask people to follow the rules in anywhere but this one thread, and you can either get it closed when it actually qualifies as no longer about Rockbox or the Rockbox list, or you can leave me alone because it's technically on-topic if those are on topic. 20.14.56 # If it's about the list, do what you want with it. I left that to you guys quite some time ago. 20.18.25 Join MHael [0] (n=7bf3fc5d@gateway/web/cgi-irc/labb.contactor.se/x-db09ba93be0eb7fe) 20.20.05 # as of 40 hours ago you were still carrying on a conversation in defense of your handling of top-posters. 20.21.41 # And I didn't deny I was doing that. 20.23.41 Quit MHael ("CGI:IRC (Ping timeout)") 20.23.44 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.30.53 Join MHael [0] (n=chatzill@123-243-252-93.static.tpgi.com.au) 20.31.23 Join funman [0] (n=fun@rockbox/developer/funman) 20.32.35 # Hey, could anyone tell me how I might add a HDD activity virtual LED toggle switch to the UI Simulator? 20.32.40 Join efyx [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 20.33.24 # amiconn: what's the point of declaring a const char testbasedir[] in test_disk.c when TESTBASEDIR could be used? 20.33.56 # i want to extend test_disk to test multiple drives 20.34.54 Quit BCM43 (Remote closed the connection) 20.35.18 # MHael: uisimulator/* 20.35.30 # cant really be more specific atm though :p 20.35.56 # I figured that much. :P 20.36.57 # umm... its not like the hold or usb faking which is pretty easy 20.37.15 # * JdGordon| isnt sure the best way to do it 20.40.54 Quit stoffel (Remote closed the connection) 20.44.59 Join stoffel [0] (n=quassel@p57B4C1FA.dip.t-dialin.net) 20.45.01 # I figure it's controlled by ata_idle_notify so if I could modify that to toggle on and off? 20.47.10 # its not, but you could toggle it there.. 20.47.22 # but I assume you would actually want to control it somehow? 20.47.47 # Yes 20.47.57 Quit stoffel (Remote closed the connection) 20.48.56 # you want this to make sure your WPs is good yeah? 20.49.33 # Yeah 20.50.22 # so my suggestino would be to use the %mh tag (hold button) instead of the diosk activity tag while you are testing 20.51.11 # lol 20.51.20 # I never would've thought of that 20.51.25 # Thanks 20.51.28 # :) 20.51.41 # or... work on the wps editor app :) 20.52.55 # I haven't even made a wps yet, this is my first. I haven't even put rockbox on my iPod. 20.58.12 *** Saving seen data "./dancer.seen" 20.58.43 Nick n00b81 is now known as rabbit (n=n00b81@unaffiliated/n00b81) 20.59.05 Nick funman is now known as something (n=fun@rockbox/developer/funman) 20.59.28 Nick rabbit is now known as n00b81 (n=n00b81@unaffiliated/n00b81) 21.00.25 Nick something is now known as funman (n=fun@rockbox/developer/funman) 21.01.10 Nick n00b81 is now known as n00b81_ (n=n00b81@unaffiliated/n00b81) 21.03.26 Nick n00b81_ is now known as n00b81 (n=n00b81@unaffiliated/n00b81) 21.04.01 Nick aditya is now known as adi|away (n=aditya@59.95.46.133) 21.06.28 Quit funman ("kick kick kick") 21.07.52 Quit antil33t () 21.08.24 # linuxstb: I build a nano2g bootloader. Going to try it out. 21.10.56 # bin2note is complaining "Payload too big!" whenever I point it to the bootloader.bin file I just built for the nano2g bootloader. 21.11.31 # its not trying to add a bootloader splash image is it? 21.11.49 # LambdaCalculus37: Yes, you don't upload it directly with bin2note - you use iBuggerLoader to load it. 21.12.17 # LambdaCalculus37: But I'm not sure yet how to do that... 21.12.41 # There's at least one change in crt0.S that should be removed - switching the CPU into big-endian mode. It's four lines ending with the comment "// set big-endian" 21.13.16 Quit timc (Remote closed the connection) 21.17.11 Quit jfc (Read error: 54 (Connection reset by peer)) 21.17.17 Join timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) 21.17.33 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 21.18.03 Quit jfc (Read error: 104 (Connection reset by peer)) 21.18.24 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 21.18.55 Quit jfc (Read error: 104 (Connection reset by peer)) 21.19.16 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 21.19.47 Quit jfc (Read error: 104 (Connection reset by peer)) 21.20.07 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 21.21.14 Join petur [0] (n=peter@d54C6F267.access.telenet.be) 21.25.09 # Thanks for your help JdGordon| 21.25.12 Quit MHael ("ChatZilla 0.9.85 [Firefox 3.0.10/2009042316]") 21.28.19 Join BdN3504 [0] (n=5ce2257e@gateway/web/cgi-irc/labb.contactor.se/x-2f796cb1c5ab4c76) 21.31.41 # OK guys i have to bother you one last time about the gigabeat flashwriter plugin. i was now able to compile a build conatining that plugin and now the only question i have is to how it works: do simply execute it on target? do i have to put any of the bins provided on the patch tracker to the device as well, or will this plugin write to the flash autonomously without me providing any further files?also, i didn't 21.36.04 Quit robin0800 ("Don't follow me") 21.36.41 # BdN3504: I think you got cut off. That line ends with "also, i didn't" 21.39.35 Join webguest93 [0] (n=5628a84d@gateway/web/cgi-irc/labb.contactor.se/x-37d5efecdc2f7b07) 21.41.42 Quit saratoga ("Page closed") 21.41.45 Quit itcheg (Ping timeout: 180 seconds) 21.42.43 Quit webguest93 (Client Quit) 21.42.53 Join stephen_ [0] (n=stephen@86-40-168-77-dynamic.b-ras2.srl.dublin.eircom.net) 21.45.14 # enable rtc in the config-gigabeat.h, will the plugin not work properly now? 21.49.41 Join freetripleg [0] (n=44122fbd@gateway/web/cgi-irc/labb.contactor.se/x-4f6b986afef53ad5) 21.50.08 # hey anyone know how to tell if a fuze is v1 or v2? forum search function is fail. 21.50.43 # afaik, there are fuze v1 and v2s 21.50.58 # freetripleg, only with the firmware version 21.51.16 # ok... 21.52.33 Quit QncfOpO (Remote closed the connection) 21.52.46 # ahhh, updater says v2 nuts, that means I must wait much longer for rockbox 21.53.43 # thanks for the quick answer 21.53.46 Quit freetripleg (Client Quit) 21.53.49 # erm, how do i use this plugin again? i try install/update bl but i get ABORT: this is an untested etc. but people have reported they flashed anyway, how did they do that? 21.56.24 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 21.59.31 Quit LambdaCalculus37 () 22.04.53 # ok, i have to copy the bootloader from the patchtracker to the root directory and then try again right? that's why i asked... 22.05.49 Join kugel [0] (n=kugel@rockbox/developer/kugel) 22.05.53 # has anyone ever seen a reference to (or a datasheet of) a WM1800 codec? 22.06.05 # I assume it's a wolfson 22.06.41 # Or a touch key controller from a manufacturer called Melfas? 22.10.56 Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) 22.11.16 # hmm... if e.g. the Pegbox menu isn't using custom bitmaps anymore, those could be removed or am I missing something? 22.12.18 Join dash32 [0] (n=dash32@p54AB41FD.dip.t-dialin.net) 22.12.27 # pixelma: That would seem reasonable... 22.13.01 # bertrik: Never heard of it... Are you sure that's the right model? 22.13.21 # * pixelma looks around for Ubuntuxer... in vain once more 22.13.43 # the WM1800 is mentioned in a disassembly video and I also find it as a string in the firmware upgrade image 22.14.23 # Well, there seem to be 100s of wolfson codecs, and only some are mentioned officially... 22.14.55 # although... I put a bit of work in the adaptation of these bitmaps to different screens... but I understand that custom bitmap menus can cause trouble 22.15.03 Quit HellDragon (Read error: 104 (Connection reset by peer)) 22.15.07 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 22.15.27 # bertrik: Google tells me the PSP uses it though... 22.16.18 Quit BdN3504 ("CGI:IRC") 22.16.19 # I just thought that maybe the background could be kept or so... 22.17.42 # pixelma: nag various people to allow viewport background images so they can be kept :) 22.18.05 # Why would you need a viewport background image? 22.18.13 Quit HellDragon (Read error: 104 (Connection reset by peer)) 22.18.25 # just set a backdrop I thought 22.19.47 # sure if you want to do it the boring way.... 22.19.48 # linuxstb, thanks, didn't know that yet 22.20.17 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 22.20.27 # bertrik: Odd that there's no mention at all on wolfson's website though... 22.20.54 # what does that have to do with boring? 22.25.01 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 22.31.01 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.33.19 Quit stephen_ ("Leaving") 22.36.37 # New commit by 03amiconn (r21884): Further ARMv6 imdct optimisation, ~5.5% speedup. 22.39.49 # That is overall decoding speedup 22.42.19 # Hmm, new build table still has no progress indicator... 22.43.01 # amiconn: that's to motivate you to run a build client, so you get the countdown messages 22.44.14 Join stephen_ [0] (n=stephen@86-40-168-77-dynamic.b-ras2.srl.dublin.eircom.net) 22.45.02 # I don't get to see those when running it in teh background 22.46.05 # we clearly need to be able to run a user-contributed script on certain events 22.49.35 Quit wincent (Read error: 110 (Connection timed out)) 22.51.28 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 22.51.58 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-9b73980ae5d89280) 22.52.09 # faster iMdct for mpegplayer ;) 22.53.07 Quit robin0800 ("Don't follow me") 22.54.58 # saratoga: By-product of learning how to use armv6 extensions... 22.58.17 *** Saving seen data "./dancer.seen" 22.59.13 # bertrik: Are interrupts enabled in the bootloader on the Meizu/ 23.01.29 Quit _zic (Remote closed the connection) 23.07.17 Quit Grahack ("Leaving.") 23.09.24 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 23.14.13 Quit dash32 (Read error: 110 (Connection timed out)) 23.18.55 # anyone seeing data aborts on pp (ipod 5g) usb happening when windows mounts the device? seems to have started with a recent (local) build, where it's 100% reproducible and I don't *think* anything usb-related is patched, but i'll test an official build too 23.19.09 Quit jfc (Read error: 104 (Connection reset by peer)) 23.19.09 Join pingosimon [0] (n=pingosim@adsl-71-154-208-214.dsl.sndg02.sbcglobal.net) 23.19.31 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.19.50 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 23.20.07 # Hey guys, I'm on Mac OS X and my newly Rockbox'd ipod won't show up on the desktop or disk utility when I plug it in 23.20.34 # the iPod screen shows the USB icon 23.21.04 # Which version are you using? Current build or release? 23.21.09 Quit jfc (Read error: 104 (Connection reset by peer)) 23.21.30 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.21.30 # the current build, I did a manual install 23.22.00 # ok. Which version of OS X is this? 23.22.01 Quit jfc (Read error: 104 (Connection reset by peer)) 23.22.11 # 10.4 23.22.22 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.22.51 Quit jfc (Read error: 104 (Connection reset by peer)) 23.23.13 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.23.31 # New commit by 03zagor (r21885): Removed use of bogomips. Changed uname -o to uname -s. 23.23.50 # hm, it looks like os x 10.4 has a bug with USB composite devices... 23.24.17 Quit jfc (Read error: 104 (Connection reset by peer)) 23.24.38 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.25.09 Quit jfc (Read error: 104 (Connection reset by peer)) 23.25.29 # hmm 23.25.30 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.25.34 Quit J-23 (Read error: 110 (Connection timed out)) 23.25.37 # do you know of a way to fix that? 23.25.41 # This is the second report I've seen about this sort of thing. You basically have three options : boot to the original firmware manually when you need USB, install the latest release (3.3) (that one boots to the emergency disk mode on connect), or compile your own build 23.25.59 Quit jfc (Read error: 104 (Connection reset by peer)) 23.26.20 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.26.45 Quit jfc (Read error: 104 (Connection reset by peer)) 23.26.59 # yeah I tried to install the latest release using Rockbox Utility, but I got the "could not open iPod" error that nobody has seemed to be able to fix 23.27.06 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.27.14 # you can install that one manually as well 23.30.41 # where can I find the version number within rockbox? 23.30.53 # JdGordon|: I think we need something like FS#10198 to handle this case as well (i.e. disable HID while using a storage connection) 23.31.00 # pingosimon: System->rockbox info 23.31.06 # JdGordon: can you try the latest rbclient on mac osx? 23.31.10 Quit DarkDefender ("Leaving") 23.31.14 # gevaerts: ? 23.31.33 Quit stephen_ ("Leaving") 23.31.40 # Zagor: yeah sure, but unfortunalty that configure issue means i cant participate uin the builds for a while 23.31.40 # hmm I think this is the latest, r21869-090714 23.32.26 # JdGordon|: oh right, the path thing 23.32.51 # JdGordon|: apparently older versions of OS X can't handle composite devices with both usb storage and HID. Either we disable HID totally, or we make it optional. I don't think os x 10.4 users will like us if we don't make things work for them 23.33.16 # * JdGordon| has no idea what you're talking about... but ok 23.33.27 # pingosimon: that's a "current build" from yesterday. The release is something different (currently 3.3) 23.33.44 # ah ok, thanks a lot! I'm gonna try 3.3 right now 23.33.52 # Zagor: should be version 27? 23.33.54 # JdGordon|: FS#10198 is the "USB charge only setting" patch 23.34.04 # OH... ok 23.34.33 # * gevaerts thought that JdGordon| knew all FS numbers by heart! 23.34.34 # New commit by 03dave (r21886): Introduce S5L8701 CONFIG_CPU definition for Nano2G and a new CPU_S5L870X "family" define - the 8700 and 8701 are proving to be different. Also move ... 23.34.52 # gevaerts: it did sound familiar :) 23.35.07 # JdGordon|: oh, I didn't bump the client version yet. I'll do that after this build round. 23.35.44 # linuxstb, yes, interrupts are enabled in the meizu m3 bootloader 23.36.01 # I think sleep even works 23.36.50 # old build system: disabled 23.36.54 # \☺/ 23.37.24 # RIP :p 23.37.49 Quit bmbl ("Bye!") 23.39.59 Quit jfc (Read error: 104 (Connection reset by peer)) 23.40.04 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.40.20 Join jfc [0] (n=john@dpc6682208002.direcpc.com) 23.40.28 # Regarding installing 3.3 on an ipod that already had a daily build: can I just replace the old .rockbox folder with the new one? 23.40.35 # or do I need to run ipodpatcher again? 23.40.54 # just replace .rockbox 23.40.57 # cool 23.41.12 # except now even witht he ipod firmware loaded,, it won't show up on the computer 23.41.25 # not cool 23.41.35 # do you have itunes running? Maybe that hides it 23.41.41 # nope, itunes is off 23.41.47 # But installed? 23.41.59 # oh wait there it is 23.42.13 # You need to enable the "use ipod as a disk" option in itunes. 23.42.16 # yes I do have itunes installed, but the auto sync feature is disabled 23.42.20 # yeah that's enabled too 23.42.28 # so it was just a bit slow? 23.42.33 # anyway, it's here on the desktop now! 23.42.42 # yeah it took about 2 minutes 23.42.47 # New commit by 03bagder (r21887): Added Philips SA9200 sim and bootloader builds 23.43.24 # stop adding builds! arnt we trying to get under 5 min :p 23.43.37 # Do any of you guys use rockbox to play NSF SPC or SID files? 23.44.02 # B4gder: Did you disable the old build system half-way through it building my commit? ;) 23.44.36 # yes 23.44.52 # not exactly intended, but hey 23.44.54 # * linuxstb tries not to be offended ;) 23.45.28 # linuxstb: you got it built faster this way! :) 23.45.41 # Yes, if I wasn't staring at the old page... ;) 23.46.12 # * Zagor renames new.cgi to dev.cgi 23.48.43 # so no chance of having to go back? We can clear the old setups? 23.50.33 # what setups? 23.51.13 # the rbclient login and corresponding checkout 23.51.24 Join DerPapst [0] (n=DerPapst@p4FE8EFFD.dip.t-dialin.net) 23.51.53 # ah yes those can be wiped, but you could possibly wait a day or two before you proceed with that 23.52.04 # Ok with Rockbox 3.3, the ipod does show up on the desktop, after leaving it plugged in for 2-3 minutes. Maybe I just wasn't patient enough when trying with the daily build 23.52.10 # ok. No problem with that 23.52.42 # pingosimon: you could try. If you do, please report back 23.53.02 # will do 23.53.29 # this seems to have the same USB speed problem as the nano did 23.53.34 # pixelma: about the pegbox background, you could viewportify the menu and shift it down so that it is not drawn on top of the pegbox "logo" 23.53.38 Quit robin0800 ("Don't follow me") 23.54.14 # i've done something similar for battleships (which is still not tracker ready. darn real life :P) 23.55.59 # pingosimon: yes. You're now in the apple emergency disk mode, which is slower than the normal USB code. The native rockbox code (which you get with a current build) is a bit faster, but not as fast as the original firmware (we know how to make it faster, but that's still not in shape for the official builds) 23.56.04 # which is the slowest build client yet? did someone run an arm machine? 23.56.26 # Zagor: monster is a 1.2GHz armv5 (sheevaplug) 23.56.42 # It seems to be faster than rasher's cygwin client though 23.56.57 Quit flydutch ("/* empty */") 23.57.41 # I'm about to add a 800 MHz Via C3 23.58.06 # we'll see. hal is a 900 MHz Celeron M 23.58.17 # celeron is a monster compared to c3 23.58.36 # celeron M is really not very impressive :) 23.58.51 # * Zagor dramatically throws a glove on the floor