--- Log for 13.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 10 days ago 00.00.08 # kugel: that e200v2 failed install on the forums looks like it could be using mtp 00.01.36 Quit krazykit ("Connection reset by beer") 00.01.57 # interesting 00.02.05 # New commit by 03jdgordon (r21825): Fix the shipped themes statusbar config line 00.02.12 # New commit by 03unhelpful (r21826): Rework addtargetdir.pl to also fix prefix generated-file depedencies with the target directory, and simplify the sed expression for mkdepfile. 00.06.09 # New commit by 03peter (r21827): Update Dutch langfile 00.06.23 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) 00.08.16 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 00.14.48 Quit tvelocity (Read error: 110 (Connection timed out)) 00.15.39 Quit dys (Connection timed out) 00.15.51 Join dys` [0] (n=andreas@p5B310D08.dip0.t-ipconnect.de) 00.16.30 Nick dys` is now known as dys (n=andreas@p5B310D08.dip0.t-ipconnect.de) 00.16.54 # New commit by 03dave (r21828): Basic changes to add nano 2g to the build system, based on the Meizu M3 port. The bootloader builds, but does nothing due to lack of any drivers. 00.17.14 Join tvelocity [0] (n=tony@athedsl-4470332.home.otenet.gr) 00.18.02 # uhh 00.18.03 # nice! 00.18.28 # JdGordon: the recording screen bug is a blocker :( 00.18.40 # arg 00.18.49 # whats the issue there? 00.18.59 # Zagor: "Duplicate name" on stalled client connection still exists 00.19.29 # 22:17:36 Joined: client nereid-amiconn 00.19.32 # Not always, but it just happened when fixing the system time in my VM 00.19.36 # -22:18:25 HELLO dupe name: nereid-amiconn 00.20.26 # * gevaerts also fixed the time on his VM and saw the same symptom 00.20.33 # JdGordon: when you leave it, the main menu is in the viewport of the recscreen list 00.20.51 # the peakmeter shows above (not moving) 00.20.56 # cool! 00.23.10 # Zagor: Unrecognized command '_UPLOADING 00.23.29 # gevaerts: indeed, he was in mtp 00.23.35 # gevaerts: a single time? 00.23.45 # no. For every upload 00.23.48 # I have that too 00.24.04 # command '_UPLOADING 00.24.04 # ' 00.24.04 Quit thegeek (Read error: 110 (Connection timed out)) 00.24.12 # notice the newline 00.24.16 # oh right, I committed that but didn't bump the required version 00.28.03 Quit dmb (No route to host) 00.29.07 Quit bubsy (Read error: 60 (Operation timed out)) 00.29.13 Join kugel_ [0] (n=kugel@e178126043.adsl.alicedsl.de) 00.29.23 Quit kugel (Nick collision from services.) 00.29.29 Nick kugel_ is now known as kugel (n=kugel@e178126043.adsl.alicedsl.de) 00.30.00 Join JdGordon| [0] (i=43a02c5a@gateway/web/freenode/x-c60bd0e27785ea80) 00.30.05 # New commit by 03zagor (r21829): Allow param-less commands. 00.30.39 Join funman [0] (n=fun@rockbox/developer/funman) 00.33.14 # kugel: the rec screen isnt juts missing some really obvious "fix viewports" call on exit is it? 00.33.14 Quit Zagor ("Leaving") 00.33.30 # no, it's a bug in my list code 00.35.24 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 00.37.05 # kugel might i ask why bindings on the sansa players are odd 00.37.28 # atleast for Doom 00.37.47 Join GreatBeaver [0] (n=chatzill@c-71-59-18-236.hsd1.ga.comcast.net) 00.37.51 # which sansa players ? (there are quite a few) 00.38.09 # well for the E250's 00.38.17 # errr E200's 00.39.58 # are meizus big endian ARM ? 00.40.09 Quit petur ("Zzzzz") 00.42.20 Join AndyIL [0] (i=AndyI@212.14.205.32) 00.42.25 # funman: Yes 00.43.26 # New commit by 03amiconn (r21830): * Fix overlooked r12 usage possibility in mpegplayer ARM idct ... 00.47.23 Quit dash32 (Remote closed the connection) 00.48.20 Quit notlistening ("Leaving") 00.49.25 # JdGordon|: found it 00.51.00 # :) 00.51.30 # I can modify/delete post of other users on some forum sections, but not on "Official Test Builds", is that normal ? 00.52.22 Quit ej0rge ("leaving") 00.52.48 # funman: whack scorche|sh 00.53.18 Quit AndyI (Read error: 110 (Connection timed out)) 00.56.51 *** Saving seen data "./dancer.seen" 00.57.22 # scorche|sh: do developers have permission to remove/edit forum posts in "Official Test Builds" section? 00.57.39 # let me check 00.57.55 # they do, unless i have special permission.. which i doubt :p 00.58.48 # yea, that's hardly imaginable :) 00.58.54 # the new patch is up, btw 00.59.17 # ok, ill have a look later... any obvious reasons to not commit it? 00.59.25 # want to get some test builds going for the forums? 00.59.28 # I added some comments to viewport.h, to discribe a bit what the new functions do 00.59.59 # uhm, not really. for me, the best test build is the current build :) 01.02.47 # 800K binsize only 01.03.17 # funman: well, i guess if JdGordon| can....can you not? 01.03.49 # ata-sd-pp.c was moved 3 times since it was created .. 01.04.06 # scorche|sh: no 01.04.49 # kugel: 800K? 01.04.49 # funman: I seem to be able 01.05.04 # delete at least, I don't see an edit button 01.05.18 # funman: you should be able to now... 01.05.19 # kugel: the name is "modify" 01.05.34 # scorche|sh: thanks, now I can ;) 01.05.41 # I know, I don't see this button though 01.05.46 # JdGordon|: yes 01.05.50 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.06.05 # lol 01.06.08 # scorche|sh: was I blacklisted or something ? o: 01.06.12 # no, 800bytes of course :D 01.06.13 Join mt [0] (n=mt@41.233.138.250) 01.06.24 # funman: no...you should be the same as all other devs 01.07.42 # JdGordon|: have a look, I think I'm going to use the GUI_EVENT_REFRESH event for doing cleanup and the likes. It can take a redraw function as parameter 01.08.30 # I dont really agre that that event is needed, but ok 01.09.00 # Why? it does a wasteful clear, update and possibly another redraw function 01.09.07 # that all isn't needed when no viewport is needed 01.09.25 # is used* 01.11.06 Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.11.42 Quit robin0800_ (Client Quit) 01.11.50 Quit robin0800 (Remote closed the connection) 01.12.09 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.12.25 # feel free to come up with something better. I think the event is good, but I'm not overly obsessed of it 01.17.51 # my thinking is once background wps is enblaed it wont be needed 01.22.19 # we can just remove_event() then 01.22.56 # linuxstb: ping 01.23.01 # mt: pong 01.23.30 # r0b-: feel free to fix, but at least for doom you can actually change the keymap 01.24.01 # linuxstb: Any comments on the last commit ? 01.24.38 Quit bertrik (Read error: 113 (No route to host)) 01.25.19 # mt: I havent' really looked at it... The main commit was r21806? http://svn.rockbox.org/viewvc.cgi?view=rev;revision=21806 01.25.53 # yep. 01.26.26 # by the way why doesn't wincent have SVN commit access for his work on puredata ? 01.27.10 # I had that same question too ^ 01.27.35 # funman: There's a mailing list for that question... 01.27.35 # * kugel isn't sure whether this is a topic to be discussed in public irc 01.28.43 Quit DarkDefender ("Leaving") 01.29.09 # linuxstb: btw, here's a brief description on what I did : http://www.rockbox.org/twiki/bin/view/Main/RealMediaSupport#Milestone_3 01.29.21 # I remember all gsoc students would be given access but perhaps i'm wrong here, sorry 01.29.24 # (last point) 01.30.42 # funman: Students are treated the same as other patch authors. But as kugel said, this isn't the place to discuss individuals. 01.30.49 Quit martian67_ (Remote closed the connection) 01.31.07 # kugel if i had the build enviroment i would 01.31.16 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 01.31.29 # as i cant get the tools for CYGWIN 01.31.52 Quit Thundercloud (Remote closed the connection) 01.36.52 Quit robin0800 (Remote closed the connection) 01.37.01 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 01.38.37 Quit kugel (Remote closed the connection) 01.39.52 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.41.11 Quit GreatBeaver (Read error: 104 (Connection reset by peer)) 01.43.55 Quit robin0800 (Remote closed the connection) 01.44.14 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.44.33 Quit gregzx ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 01.45.25 # Hm, clix keymappings seem messed up. I can't go 'up' on ipod target. 01.48.02 # mt: I don't really understand your code, but it looks nice and short ;) Have you tested it with large files? 01.48.02 # hm, and online ipod video html manual only goes up to section 4? The Manual builds seems borked. 01.48.23 # pdf looks fine, just ipod video html online manual 01.48.51 Quit robin0800 (Remote closed the connection) 01.49.21 # stripwax: Yes, I think fml broke the manuals last night - pixelma pointed it out to him. 01.49.21 # linuxstb: yes, tested it on all the samples I have (2 seconds to 30 minutes long) 01.49.34 # How big (in MB) is your 30 minute file? 01.49.40 # linuxstb - ah.. :( 01.49.54 # linuxstb: about 13 MB 01.50.05 Quit stripwax ("http://miranda-im.org") 01.50.19 # mt: Hmm, so it might still be completely buffered. I was curious about a file larger than the audio buffer. 01.51.00 # How large is the audio buffer ? 01.53.14 # about 26-28MB on most targets. 01.53.42 # about 60kB on c200v2 01.53.45 # i think mine is 30MB 01.53.48 # linuxstb: Also, is it possible to have seek_time > duration so that this case should be explicitly handled ? 01.53.52 # on the e200c1 01.53.55 # v1* 01.54.13 # mt: I don't know. I would hope not (the core playback code should prevent that). 01.54.38 # funman: ;) 01.54.55 # funman : KB ? and is it around that for the c200v1 ? 01.55.35 # mt: no, the c200v1 has 32MB of SDRAM, while the c200v2 only has 2MB 01.55.52 # why would they cut the RAM? 01.56.06 # $$$$ 01.56.38 # this is why i use older players :) 01.56.42 # linuxstb: if I kept seeking beyond the end of the file I get a codec failure (control reaches the seeking code) unless I make it ( goto done; ) . 01.57.37 # This happens in cook. I don't think it happens for other codecs ? 01.57.58 # mt: I'm not sure. You should look at other codecs, and see how they behave. 01.59.57 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 02.00.01 Quit JdGordon| (Ping timeout: 180 seconds) 02.00.05 # what does the M after the version number on the C200 mean? 02.00.05 # * FlynDice wonders if "SD Expert" funman could shed some light on sdhc determination in ata_sd_as3525.c if he's got some time.... 02.02.24 # linuxstb: ok, fixed. ;) 02.02.26 # * funman was just notified by his secretary that he has got some free time right now 02.02.50 # it seems right now it gets checked for with SD_SEND_IF_COND and I thought this just checks voltages if I'm reading correctly? 02.03.03 Join dmb [0] (n=Dmb@unaffiliated/dmb) 02.03.47 # cmd8that would be.. 02.04.54 # around line 257 02.07.00 # FlynDice: I understand that CMD8 (SEND_IF_COND) was added in SD Specification 2.00 which adds SDHC support, and that non SDHC cards would just ignore this command 02.07.45 # with a quick look I can't find this explicited in the specification itself, but I find this explanation in ata-sd-pp.c and various webpages/forums after a google search 02.08.29 # funman: The way I'm reading it is that if the card supports the voltage range it will echo back the voltage bits and the check pattern 02.09.22 # funman: and it says that bit 30 will be set to 1 if you have a hc card after it has inited 02.09.45 # It is 02.09.49 # mandatory to issue CMD8 prior to first ACMD41 for initialization of High Capacity SD Memory Card 02.10.24 # linuxstb: Do you know of any place where I could find such large samples ? 02.10.26 # FlynDice: bit 30 of the argument must be set to 1 (by you, not by the card), when sending ACMD41 02.10.43 # yes, but you can issue it to a non hc cardI think 02.11.03 Quit martian67_ (Connection timed out) 02.11.29 # mt: Possibly on the BBC's website - www.bbc.co.uk - they archive a large number of radio shows in realaudio (or at least, used to...) I'm looking now. 02.11.52 # FlynDice: ACMD41 yes, but not CMD8 afaiu 02.12.12 # bit 30 , card capacity status, has this note : 1) This bit is valid only when the card power up status bit is set. 02.13.09 # I'll go read it again and see if I can make sense of it.... 02.14.13 # I remember 0x1AA is a documented value, but don't remember where I saw that .. 02.14.27 # linuxstb, markun: I just realized that the S5L8701 (nano2) seems to only have 176 instead of 256 KB of SRAM! 02.14.36 # you'll need to adjust that. 02.15.08 # DarkSpectrum: the M means modified build 02.15.12 # TheSeven: OK, thanks. But it has 32MB RAM? 02.15.19 # FlynDice: anyway, this matches the OF code as far as i remember 02.15.22 # yep 02.16.35 # * TheSeven is gonna go to bed now... 02.17.05 Part TheSeven 02.17.31 # funman: yes, I can make sense of the 0x1AA, it suggests using AA as the check pattern 02.18.02 # FlynDice: right, bits 7:0 are the check pattern, and bits 11:8 are the supply voltage (lsb surely means lowest voltage) 02.18.42 # FlynDice: where is this suggestion in the spec? 02.19.37 # funman: lemme look 02.20.47 # p 40 on my sheet last line in a box below 4.3.13 Send Interface Condition Command (CMD8) 02.20.51 # 4.3.13 : "it is recommended to use '10101010b' for the 'check pattern'" (10101010b = 0xAA) 02.21.33 # hum it's page 51 here (out of 129) : "Part 1 Physical Layer Simplified Specification Ver2.00 060925.doc" 02.22.54 # pg 52 of the pdf but page 40 at the bottom of the page 02.23.11 # mt: Here are some "listen again" links to radio programmes from the BBC - they should all be at least an hour long. http://beebotron.org/public2/sixmusic.html 02.23.32 # mt: I use "mplayer" to download them - "mplayer -dumpstream -dumpfile myfile.ra rtsp:///...." 02.23.34 # FlynDice: Ok, it's page 40 here as well 02.26.12 # linuxstb: thanks a lot ! 02.26.23 # mt: Lots of nice samples ;) 02.27.26 # Yeah. :) 02.29.27 Quit funman ("free(random());") 02.30.12 Quit QncOPFGl ("Ex-Chat") 02.36.17 # it seems to me that we can remove the @echo, and also move the bmpdepfile call up one and have it write to the temp file? http://pastie.org/543660 02.40.40 # New commit by 03unhelpful (r21831): Add new asmdefs mechanism for exporting information only available to the C compiler for use in asm files, and use it in arm jpeg idct. See ... 02.42.06 Quit mt (Remote closed the connection) 02.53.36 Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 02.54.11 # Unhelpful: I think you have red 02.55.01 # WE HAVE A EWN RECORD HOLDER! 02.55.06 # new even! 02.55.42 # completly destorying the old record by 400K! 02.56.52 *** Saving seen data "./dancer.seen" 02.57.07 Quit bzed (Remote closed the connection) 02.57.10 Join bzed [0] (n=bzed@devel.recluse.de) 02.57.10 # The first million-point commit! 02.57.40 # mc2739: You "think" ? ;) 03.00.11 # well, it is not completely red - player boot is green 03.02.47 Join cr08 [0] (n=Vchat20@cpe-174-100-36-23.neo.res.rr.com) 03.04.40 Join timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) 03.13.43 Quit BHSPitLappy (Remote closed the connection) 03.14.33 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 03.15.42 # New commit by 03unhelpful (r21832): Fix red: broken tools/addtargetdir.pl 03.19.31 # mt: (for the logs) 48.24MHz needed for 64kbps cook on my Sansa 03.20.39 # saratoga: That doesn't seem too bad, considering there's been no real optimisation. 03.20.54 # linuxstb: yeah just looking at it now 03.21.54 # hmm mt told me he was using the IMDCT library today, but looking at the code it doesn't seem so to me 03.25.16 # nevermind was just confused by the various wrapper functions 03.34.49 Quit efyx_ (Remote closed the connection) 03.38.54 # hmm putting COOKContext's buffers into IRAM has a surprisingly small impact on performance 03.40.02 # it only gives me 42.46MHz 03.45.49 Join karma [0] (i=amg@host193-123-47-78-dhcp.bshellz.net) 03.46.10 # Guys! I have shred the whole sansa drive 03.46.22 # Connecting it to the usb will not mount anything 03.46.24 # mt: (for the logs) the gain_table variable in COOKContext looks unused to me 03.46.26 # What can I do? 03.46.46 # which sansa? 03.46.46 # karma: have you seen the e200UnbrickGuide in the wiki? 03.46.56 # saratoga, no.. let me see 03.47.04 # ye, sansa e200 something 03.47.11 # assuming you have a V1 sansa, thats what you need to do 03.47.35 # good 03.47.40 # and i thin i do have a v1 03.49.40 # saratoga: the codeclib mdct... it's all ints and arrays of ints? 03.50.03 # Unhelpful: its all integer, but I'd have to double check to see if theres any structs 03.50.10 # i didn't write it, just borrowed from Tremor 03.51.06 # yes, structs passed to asm are precisely what i'm hunting. :) 03.51.22 # the c version of the fixed point maths use unions 03.51.56 # but that shouldn't ever interact with any ASM code 03.52.23 # right... it's only structured data passed to asm code that i'm looking for, to add more asmdefs files :) 03.52.35 # Unhelpful: no it looks clean 03.52.55 # Unhelpful: do WMA files crash with your changes? 03.54.37 # so far i've only tested things that i happened to have on my e200... curiously, the long-call stubs without the rest of EABI break vorbis. 03.55.52 # i built a toolchain that ought to be generating the same asm, as it's gcc-4.0.3 with the same patches we use except for passing a flag to the assembler to tell it to generate EABI objects. since the compiler doesn't know it's doing anything differently, structs and such ought to be exactly the same... but vorbis files end instantly :/ 03.57.27 # vorbis stalls at the start of playback with gcc-4.3.3 and full EABI. MP3 crashes with an undefined instruction at an address beyond its icode section if i use gcc-4.3.3, even without EABI... but there might still be some oddball ABI change there. 03.57.49 # Unhelpful: vorbis has a lot of ASM 03.58.02 # I suggested WMA since it has very little ASM beyond the IMDCT library 03.58.06 # um... the IDCT lib uses either 8-bit or 31-bit constants? 03.58.19 # should be all 32 bit 03.58.28 # what are you looking at? 03.58.47 # anyway I would try out WMA and/or AAC since they're not as well optimized but use IMDCT, so if they play you know the library is fine 03.59.35 # New commit by 03saratoga (r21833): Put COOKContext struct into IRAM. Speeds up decoding by 6MHz on PP5024 at the cost of 30.5 kbytes of IRAM. 03.59.39 # i'm looking at the constants in the mdct2.h 04.00.38 # we don't use LOW ACCURACY so they should be 32 bits 04.02.03 Join alienseer23 [0] (n=joshp@75-151-15-29-Michigan.hfc.comcastbusiness.net) 04.03.19 # mt: (for the logs) I put COOKContext into IRAM for a nice little speed up, but that puts quite a few buffers into IRAM 04.03.38 # all look important but its possible one or two of them should be removed in favor of more important buffers elsewhere in the codec 04.03.43 # on ubuntu 9.04 i downloaded the ipodpatcher, chmod to allow execution, and execute as root, but only gives me permission denied. what did i miss? 04.05.03 # linuxstb: I just realized the fixed point operations are done in c 04.05.10 # no wonder its slower then I expected! 04.05.31 # alienseer23: have you tried rbutil 04.06.20 # same issue 04.06.25 # permission denied 04.08.39 # the "high-precision" ones are used in the asm version as well... armv5 has some very nice multiply goodies if you're doing 16x16 or 16x32. but i guess that we can't use 16-bit constants for 16-bit audio... 04.09.16 # Unhelpful: we can in a lot of places since rounding error gets distributed through out all the time domain samples when you do it in the frequency domain 04.09.34 # but we've never had ARMv5 targets before so it hasn't been done 04.10.42 # i am certain the MDCT (and also MP3 synthesis filter) are much slower then they ought to be on ARM5/6 04.12.48 # these cook fixed point ops seem silly, who puts a branch in a fixed point multiply function 04.12.53 # saratoga: i'd rather keep rounding errors below the range of the final output if possible :) 04.13.12 # Unhelpful: we've got a lot of accuracy to play with right now 04.13.39 # when i was testing WMA we'd do better then the Windows floating point decoder 04.13.41 # right, but you can't go to 16x16 multiplies without getting rounding errors into the intermediates. 04.14.05 # is there a savings for 32x16 multiplies? 04.14.25 # you could probably truncate a lot of the trig constants without meaningful loss of accuracy 04.15.27 # for the armv5+ 16x16 and 16x32 multiplies, 1) they all come in a multiply and a multiply-accumulate flavor 2) the 16-bit inputs can be selected from either the low or high half-word 04.16.32 # but they're probably not any faster then just doing a 32x32->64 mul 04.16.50 # hmm cook seems to use mostly 16 bit fixed point multiplies 04.16.54 # i wonder why they did it this way 04.16.56 # the jpeg IDCT gets a rather large boost from smulxy/smlaxy, as it can load two inputs per register, and two constants per register, and if a constant is never needed in an add, you will never need to sign-extned it. 04.21.49 # also 5e lets you load two register at once with pc-relative addressing (though limited in range) and timing the same as a 2-register ldm 04.22.41 Quit daurnimator (Read error: 104 (Connection reset by peer)) 04.23.47 Quit Zarggg () 04.24.11 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 04.31.33 Quit tvelocity (Remote closed the connection) 04.34.45 # saratoga: i've found the tables for the smulxy timing on arm9e... i'm not really understanding what they say at all. :/ 04.35.17 # Unhelpful: the multiplier is fully pipelined right? so unless you can save register loads, I don't think theres any savings 04.36.36 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 04.36.49 # saratoga: if i'm understanding correctly, these multiplies are all one-cycle operations in terms of the pipeline, with an extra one-cycle stall if the next instruction uses the result. if that's the case, they're really making it rather confusing. :) 04.37.16 # that would make sense 04.37.38 # so basically you can save IRAM (which doesn't really help much for ARM5/6) and you can perhaps save some register loads 04.37.40 # but yes, you can save register loads with the 16b parts of the 16x16 and 16x32 multiplies. 04.38.29 # well the trig tables just sample points along a sin/cos function, so in theory you could take the larger amplitude parts, shrink them to 16 bit and probably not have any more rounding error then you would the lower amplitude parts anyway 04.38.43 # but I'm not sure how much time you'd really save 04.39.05 # actually I think we should probably look more carefully at the ffmpeg IMDCT again before putting too much work into the Tremor one 04.39.13 # also, if you have 16-bit input data, you can save sign extension... whether it's on load via ldrsh, or later with sxth for armv6 or shift pairs for earlier. 04.39.45 # you're helped rather a lot here compared to the image/video domain... the MDCT seems to be a bit more standard in its implementation? 04.40.28 # yes its basically entirely standard 04.40.50 # aside from MP3, all MDCT codecs we have and even some we don't (wma pro) use exactly the same IMDCT formula 04.41.18 # "the" DCT and IDCT seem to have various tweaks to normalize values. 04.42.39 # anyway cook seems to use rather slow fixed point math, which is surprisingly to me that its still as fast as AAC, so with proper fixed point routines I expect it will be extremely fast 04.42.53 # probably wouldn't take much effort to make it much faster then all the other MDCT codecs 04.44.44 Part alienseer23 04.46.15 # saratoga: um, the arm9e manual shows mul as taking 3 cycles, 4 with interlock, on arm9e. so, on our armv5 targets (thought i think none of those are supported), it might save a bit? 04.47.16 # Unhelpful: I'm not sure what the break down is for actual arm targets, but I think all ARM9E and above have 1 mul/clock throughput 04.47.37 # perhaps there are ARM5 targets without the fast multiplier? or maybe thats latency and not throughput 04.48.11 # i think it might be. these tables are really quite confusing to me... but the "table" seems to actually be listing what's happening each cycle. 04.52.06 # i see smull with an output register used in the next instruction, though... so perhaps this could be made to go a bit faster. :) 04.53.39 # also, on arm7 targets i think you may see a speed gain if you put the constant in the first input operand, since the constants are full-precision. 04.54.06 # Unhelpful: I was looking at the old ARM docs, and they refer to the ARM7 multiplier as the "fast" version, apparently they used to have a 2 bit multiplier unit, so the 8 bit one is "fast"! 04.55.16 # hah! the "fast" multiplier is 32x8... the idea of a 32x2 multiplier just sounds funny to me :P 04.55.31 # also funny, on the ARM922, the MMU that we don't use is almsot as large as the entire CPU 04.55.45 # it's the *tdmi targets that have the 32x8 multiplier, right? 04.55.51 # yes 04.55.59 # and I think some StrongARM 04.56.45 # i don't *think* we have any arm9tdmi? but we have many arm7tdmi targets, don't we? 04.56.54 *** Saving seen data "./dancer.seen" 04.57.01 # Unhelpful: I think AMS is basically ARM9TDMI 04.58.09 # ah yes Wikipedia says all non-E ARM9 cores are TDMI 04.58.10 # if i recall how this works properly, you should see a gain in speed from putting those 32-bit constants in the first input operand, and the variable input, which at least *might* be 16 bits, in the second. 04.58.24 # yes because it can do early termination 04.58.48 # I never really looked into it though 04.59.10 # theres probably some savings possible 04.59.47 # please feel free to look into our MDCT if you need a new project 05.00.05 # i can send you my half completed splilt radix IMDCT too 05.00.23 # well, it looks to me like mdct_arm.S has a couple of spots for small optimizations of this sort... it's putting the constants second everywhere, and i also see smull instructions followed immediately by shifting the high part of the output 05.00.45 # those occur in pairs, so you could save some interlock pain by changing mul shift mul shift to mul mul shift shift 05.01.08 # i'd be very interested to know if that gives any significant speed up 05.01.20 Quit n00b81 ("Leaving") 05.02.07 # well, how hard would it be for me to find a chunk of "typical" input data to these functions? would we maybe be able to rig one of the codecs to dump MDCT inputs with DEBUGF? 05.02.53 # the TDMI multiplier's early termination makes me think you ought to use real-world input to bench it, and not just zeroes, or whatever was on stack before you allocated an array :) 05.02.56 # Unhelpful: i always just tested by doing test_codec on a short WMA file 05.03.35 # WMA uses almost exactly 50% of its time in the IMDCT so its easy to figure out how much it speeds up 05.04.22 # will i find a set of short sample files on the wiki? 05.04.27 # but otherwise, yes you can just dump the contents, or make up any input thats doesn't have too many zeros 05.04.56 # Unhelpful: http://www.mp3-tech.org/tests/wma9/g_128k.wma 05.04.58 # yes, but too few zeroes can cause your benchmarks to look much *worse* than they should. 05.05.09 # that is my standard file 05.05.15 Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) 05.06.01 # i actually don't think i ever checked if its common to have a lot of zeros in the input 05.06.06 # i can do that right now though 05.08.29 # they don't even need to be zeroes, though, TDMI can terminate early on each whole byte worth of zero/sign bits 05.10.38 # what about values that have been multiplied by one of the smaller constants in a prior stage, since those are hi32 multiplies? 05.13.21 # Unhelpful: quite blocks are almost all zeros, so they should be fast, let me check a louder one now . . . 05.13.25 # quiet 05.14.08 # Unhelpful: I don't follow that question 05.16.06 # saratoga: a non-zero input to a multiply can still save cycles on TDMI when the top 8, 16, or 24 bits are all 0 or all 1 05.16.22 # but about hi32? 05.16.38 # Unhelpful: I've got a couple MB worth of MDCT inputs, you want them? 05.16.59 # and i see smull that only keep the top 32 bits - so if outputs of those with small constants are fed to later multiplies, they might also be "small" inputs. 05.17.10 # the composition seems to very considerably though, with lots of values that are less then 24 bits, a few that are nearly all zero blocks, and some that are all 32 bit blocks 05.17.49 # by "hi32" i mean 32x32->64 multiplies that discard the bottom half 05.19.01 # heres the MDCT for a typical WMA file if your'e curious: http://www.duke.edu/~mgg6/rockbox/mdct.7z 05.19.11 # theres actually a lot more variety then I expected 05.19.39 # wait that can't be right 05.20.26 # well, i've got the first round of wma/vorbis/mp3 speed tests done - i happen to have ~1min mp3 and vorbis tracks on my e200 anyway. :) 05.20.33 # crap had the pointer wrong 05.20.57 # MP3 uses its own MDCT by the way, not the library one 05.22.56 # but anyway, the input the the IMDCT have lots of values that will early terminate, so I'm not sure it'd be much better to flip the constants around 05.23.15 # the actual coefficients may be zero more often 05.23.31 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 05.24.12 Quit Horscht ("Verlassend") 05.24.28 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 05.25.05 # saratoga: but if i recall the order correctly, mdct_arm.S has the constants in the slot that can early-terminate. 05.25.15 # oh 05.25.25 # i misunderstood you before then 05.25.45 # at least for 128k files, theres a lot of zero coefficients 05.26.33 # looking at the jpeg IDCT source that i wrote after i benched the multiplies both ways on e200, yes, the first input is the 32-bit input, the second is the one that is chunked. 05.29.28 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 05.29.31 # Unhelpful: would you like me to send you my profiling data for the MDCT functions? 05.30.55 Quit cr08 () 05.30.58 Quit martian67 (SendQ exceeded) 05.31.00 Quit martian67_ (SendQ exceeded) 05.31.59 # actually looking at it i can summarize easily: mdctbutterflies uses 50% of the MDCT time, post rotation, pre rotation and bitreverse each use about 1/6th 05.33.51 # i also think that some constant loads could move up to somewhere much earlier than their use 05.33.59 Join dash32 [0] (n=dash32@p54AB5496.dip.t-dialin.net) 05.34.46 # i see a couple of places where constants are loaded immediately before use, but where that register is untouched for a very long time before 05.35.55 # are x1/x2 pointers to constants in mdct_butterfly_generic_loop? 05.37.29 # Unhelpful: looks like they're the mdct coefficients 05.39.49 # looking at the C version T0 is declared const, and sincos_lookup is passed in that parameter... so those are the inputs i should probably assume to be large 05.40.03 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 05.41.10 # ok i have to get back to work tonight, good luck 05.42.04 Quit saratoga ("Page closed") 05.46.21 Join kinetic [0] (n=matt@c-24-9-130-229.hsd1.co.comcast.net) 06.27.10 Quit dash32 (Remote closed the connection) 06.33.14 # hrm... ~2% speedup on vorbis and mp3... 06.35.30 Nick karma is now known as ayahuasca (i=amg@host193-123-47-78-dhcp.bshellz.net) 06.39.55 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 06.40.45 Quit daurnimator (Read error: 113 (No route to host)) 06.50.04 # New commit by 03unhelpful (r21834): Reorder some operands to increase frequency of multiply early termination on TDMI targets, reorder some operations to try to reduce stalls. 06.56.57 *** Saving seen data "./dancer.seen" 06.59.33 # if i got a MicroSD card can i also load games for Rockboy or no? 07.14.08 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.15.55 # it doesn't matter where the files are located 07.16.30 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-3e3200ddca1a7062) 07.17.17 # Unhelpful: you were looking at synth_full? 07.18.00 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 07.19.57 Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) 07.33.10 # ok i think i figured out how to modify the doom buttons 07.33.13 # but i have no way to test it 07.33.33 Quit kinetic (Read error: 113 (No route to host)) 07.57.55 Quit safetydan ("Leaving.") 07.59.30 Part toffe82 08.11.33 Quit r0b- (Read error: 104 (Connection reset by peer)) 08.14.57 Join petur [50] (n=petur@rockbox/developer/petur) 08.29.04 Quit saratoga ("CGI:IRC (Ping timeout)") 08.30.01 Join n1s [0] (n=n1s@rockbox/developer/n1s) 08.34.44 Quit dmb (Read error: 113 (No route to host)) 08.45.05 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 08.48.39 # New commit by 03zagor (r21835): Slow clients (avg build score <= 5000) get easier builds. 08.49.26 # yay \o/ 08.49.44 # is that revision 23? 08.49.48 Join Rob2223 [0] (n=Miranda@p4FDCD702.dip.t-dialin.net) 08.50.50 # (Zagor ^^^^) 08.51.23 # * petur sees he isn't here and shuts up 08.51.45 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.53.14 # the 5000 value is too low though... looks like under 9000 would be better 08.53.43 # 5000 would mean next round petur's ts439 will get a full build which it cant handle 08.54.05 # I'm reliably getting my Fuze to freeze by pressing Prev while on the FM Radio screen with the radio muted 08.54.49 # tried in both preset and scan modes 08.55.18 # forward too 08.55.18 Join __lifeless [0] (n=lifeless@188.16.126.19) 08.56.14 # recent svn 08.56.58 *** Saving seen data "./dancer.seen" 08.57.23 # * Dhraakellian guesses that there are probably other venues that would be better for reporting such information, but it's almost 3am, and he should've been in bed long ago 08.59.39 # JdGordon: it did get a lot of builds last time... 09.00.27 # I hope that didn't influence the score... could make it an oscillating system :) 09.01.46 # Dhraakellian, that's a known bug (at least known to me ...) 09.02.00 # okay 09.02.05 # if you want, you can open a bug report on it 09.02.11 # heh 09.02.16 # not right at the moment 09.02.32 # someone can feel free to poke me to look into bug reporting tomorrow though 09.07.50 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.10.20 Quit _lifeless (Read error: 101 (Network is unreachable)) 09.12.14 Quit BHSPitMonkey ("Ex-Chat") 09.17.49 # Unhelpful: Did you test whether this asmdefs mechanism also works for other archs than arm? 09.19.00 # This would be nice, even if we don't switch abi versions or similar on these in the near future 09.26.10 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.31.44 Join mt [0] (n=mt@41.233.138.250) 09.33.10 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.34.21 # Can I give negative values to advance_buffer(), so that it returns the buffer to a previous location ? 09.36.43 # linuxstb: I have tested a 2-hour long (38 MB) sample, everything works fine .. seeking becomes slow though when around the end of the file, so I'll try to speed it up. 09.43.44 Quit bertrik (Read error: 113 (No route to host)) 09.44.17 Quit petur (Read error: 104 (Connection reset by peer)) 09.44.23 Join petur [50] (n=petur@rockbox/developer/petur) 09.45.18 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 09.48.49 # mt: Are cook files constant or variable bitrate, or can they be both? 09.50.03 Quit Thundercloud (Remote closed the connection) 09.53.39 Quit martian67_ (Connection timed out) 09.55.10 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.55.11 # amiconn: constant 09.56.03 # amiconn: It's said on ffmpeg's wiki that all codecs in RM are CBR. 10.03.50 # Unhelpful: ping 10.04.55 Join stoffel [0] (n=quassel@p57B4D0B3.dip.t-dialin.net) 10.11.59 # mt: Does each packet have a timestamp? 10.13.20 # If so, you should be able to speed up seeking by first calculating a rough position in the file from the time to seek to and the bitrate, subtract a few KB, lseek there, sync to the stream, and only go packet-to-packet for the last few seconds of precision 10.13.41 # amiconn: No, each group of packets which form a block/scrambling unit have the same timestamp 10.14.38 # Those should also work iiuc 10.14.42 # amiconn: but using the same idea, I could seek to a rough keyframe (the packet determining the beginning of a new block). 10.14.46 # yes. 10.15.46 # CBR should make seeking easy. In fact if all scrambling blocks in a file are equally sized, you wouldn't need to fine tune at all 10.16.19 # Just calculate the number of scrambling blocks to skip, multiply by scambling block size, and lseek 10.18.29 Quit DataGhost (Nick collision from services.) 10.18.37 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 10.19.00 # amiconn : They should all be the same size yes .. except for the last one, it could be only partially filled .. but that shouldn't be a problem. Thanks for yout help :) 10.21.46 # Llorean: ping 10.28.41 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 10.57.00 *** Saving seen data "./dancer.seen" 11.17.51 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 11.19.11 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 11.37.27 Join Ubuntuxer [0] (n=johannes@dslb-094-221-083-220.pools.arcor-ip.net) 11.37.45 # linuxstb: You rang earlier? 11.38.08 # Llorean: you have a survey to do... 11.39.01 # scorche: I kinda thought I wouldn't be involved with that any more. I can do so if necessary, though I've been more or less completely out of touch. 11.39.37 # Llorean: it would have been nice to know...i think all of us were thinking you were going to keep doing that at least 11.40.02 # Bagder: did you want to be the main mentor then? 11.40.28 # Well, I tried to make it clear I was stepping out of all of my positions. I didn't mean to mislead, sorry. I can do it if necessary, as I said. 11.40.47 # alright 11.41.18 # i guess it was just a bit unclear that you were stepping away from that as well 11.41.38 # did you want to continue to be his mentor then or just do the survey? 11.42.05 # Well, I can do the survey now, and we can discuss if Bagder can manage to take over later, maybe? 11.42.27 # I didn't want to force it on anyone, but nobody said "can you still mentor?" to me after I 'quit' so I thought it was okay. 11.43.32 Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) 11.43.47 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 11.46.42 # hmm.. turns out the slow down when seeking in a large file was due to the need to rebuffer 11.49.08 # linuxstb: Is there a way around that ? I've modified the seeking code to speed it up, but the small slow down due to rebuffering is still persistent. 11.53.12 # Or is that normal for files larger than the audio buffer ?? 12.02.14 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.06.23 # New commit by 03mt (r21836): Modified the code for seeking to speed it up a bit. Instead of searching ... 12.07.21 # mt: Yes, I can't see how you can avoid that - if the data isn't buffered, it isn't buffered... 12.10.50 Quit Ubuntuxer ("Leaving.") 12.10.51 # linuxstb: I don't really know how the buffering thread works, doesn't it keep buffering more data during playback ? 12.11.38 # mt: It fills up the buffer with compressed audio, and then when the buffer is almost empty, fills it again. 12.11.58 # obo: ping 12.16.36 # mt: Does the slowdown happen in a sort of "user holds button until the time indicator says what they want, user releases button, user waits for spinup then once buffer catches up, hears audio"? 12.18.10 # Llorean: The latter. 12.18.14 # But now I'm not sure the buffering problem I described is the actual issue ; I keep getting "rebuffer_handle: space is needed". 12.18.59 # till it rebuffers and then playback resumes. 12.20.32 # wincent: I hear some 'crackling' noise when playing pdpod_test.pd in the simulator, which doesn't appear when I use pd (0.41-4); is this normal? 12.21.27 # This seems to be because I provide data chunks of less than 32k. I do so to minimize delay. 12.21.43 # But on the device it works without crackling. 12.22.06 Join TheSeven [0] (n=theseven@dslb-084-056-129-005.pools.arcor-ip.net) 12.23.26 # wincent: perhaps you could use #ifdef SIMULATOR to avoid this? 12.24.51 # mcuelenaere: I did so already, but it seems that I have to change the size of the buffer. 12.30.09 # wincent: Couldn't you change the size of the buffer for the sim ? 12.30.45 # wincent: I seem to hear the same distortion (well not exactly the same) on my target (Onda VX747) 12.30.56 # it also reboots after a while, but that's probably due to the buggy PCM driver 12.33.17 # why were the USB_ENABLE_* defines moved to config.h? Now I need to do a full rebuild whenever I want to change the usb drivers 12.33.25 # I changed the value of AUDIOBUFSIZE for simulator in pdbox.h to 32x of the normal instead of 4x. This removed the crackling. 12.35.08 # But again, it multiplied the latency and the amount of calculations needed to fill a chunk of audio buffer. 12.35.31 # gevaerts: Do you know why this line is needed in the Meizu crt0.S? (svn blame attributes it to you) - "mcr 15, 0, r0, c1, c0, 0 // set bigendian" 12.35.53 # By that time, your (big-endian) code is already running, so I would have thought the SoC would be in big-endian mode... 12.37.09 Join daurnimator_ [0] (n=daurnima@ppp121-44-209-97.lns10.mel4.internode.on.net) 12.37.26 # mt: Do you know which codec is more common in RealMedia - ac3 or mp3? mp3 could be quite interesting to do, if it's used anywhere... 12.37.34 Quit daurnimator (Read error: 60 (Operation timed out)) 12.38.44 # linuxstb: crt0.S was moved a few times, and I did the last move apparently. I didn't actually write any of it 12.39.59 Quit robin0800 (Remote closed the connection) 12.40.17 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.44.48 # wincent: I think the crackling is due to pcm_apply_settings() getting called multiple times 12.45.02 # perhaps I should just check whether the asked frequency isn't already set 12.45.22 # mcuelenaere: Where??! 12.45.45 # wincent: I don't know where, but I enabled all logf() calls and it seems there are calls to pcm_apply_settings().. 12.46.44 # linuxstb: IIRC only one mp3-in-rm sample is known to exist. :) 12.46.54 # (the one in mplayer's samples) 12.47.14 # mcuelenaere: You gave me some chill :-) pcm_apply_settings is called exactly two times: The first one when audio device is "opened" by Pure Data and the second time when the same device is "closed". 12.47.44 # mt: Then I guess it's not useful at all... 12.47.49 # mt: What about ac3-in-rm? 12.48.33 # mt: Are you interested in ATRAC? That's a completely new codec to Rockbox, and one where you (I think) will actually need to do the fixed-point conversion yourself... 12.48.35 # I'm seeing lots of this: http://pastebin.org/1319 (the 80* lines are in my PCM driver, they mean ) 12.48.46 # * linuxstb wishes he could find his ATRAC-in-rm file... 12.51.04 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 12.51.24 # linuxstb: I'm not sure which one is more common, I'll look around. But if it's a matter of what's more interesting to work on, I'd be interested to work on ATRAC yes. I want to try doing fixed point conversion, but given that I haven't actually tried it before, I'm not sure the codec could be ready by the end of the program ? 12.51.48 # I hope you won't abandon us at the end of the summer... ;) 12.52.18 # But yes, ac3 is probably a good second codec - the codec itself should be easy, and it gives you the chance to make sure your RM code is generic. 12.53.14 # linuxstb: I'm not planning on running away. :) 12.54.13 # Aren't there also some very old realaudio codecs as well (earlier than cook)?/ 12.55.16 # I think ac3 will not take much time at all so I could do it then start working on ATRAC, this way even if the program ends and I haven't yet finished we would have something better. 12.55.23 # yes. 12.56.42 # linuxstb : RealAudio 1.0 & 2.0. 12.57.01 *** Saving seen data "./dancer.seen" 12.59.17 # The other area of work is optimising cook, but it seems saratoga is interested in doing that as well... 13.01.11 # TheSeven: I added the Nano2G to the Rockbox build system last night - you can now compile a "bootloader" build for the Nano2G, which uses the core S5L8700 code wirtten for the Meizu port. I doubt it will run yet, but it's a start of something I think could be helpful for hacking... 13.01.45 # By the way, how could I measure the speed-up gain on-target ? 13.02.23 # test_codec 13.02.45 Nick daurnimator_ is now known as daurnimator (n=daurnima@ppp121-44-209-97.lns10.mel4.internode.on.net) 13.02.55 # You need to enable it in apps/plugins/SOURCES, then use "open with" on an rm file 13.04.23 # ah ok. Thanks. 13.20.16 # imdct library is > 4 MHz faster than cook's imdct (the one from tremor) ! 13.22.13 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 13.28.59 Join dmb [0] (n=Dmb@unaffiliated/dmb) 13.31.53 # mt: What target do you test on? 13.32.05 # amiconn: e200 (arm) 13.32.08 # v1 13.32.10 # ? 13.32.33 # yes 13.32.57 # Ok, so PP502x (ARM7TDMI with a properly working cache) 13.33.07 # Is there a cook test file somewhere? 13.34.22 # * amiconn would be interested in performance figures on coldfire (no data cache at all, i.e. IRAM is very important) and PP5002 (broken cache, so iram is important too) 13.35.49 Quit __lifeless ("suck my blood") 13.38.18 # amiconn: https://rm-wavconverter.svn.sourceforge.net/svnroot/rm-wavconverter/ - I was testing the vetenskap one. 13.38.36 # I was trying to get you the mplayer samples website but it seems to be down. 13.40.24 # linuxstb: Seems like aac is the next most common codec after cook. (I asked in ffmpeg's channel) 13.44.31 # amiconn: http://samples.mplayerhq.hu/real/AC-cook/ 13.44.38 # amiconn: If you want to do the same tests I did on the imdct library, you'll have to modify two #ifdef's 13.45.04 # Yep, that's the one :) .. it isn't working for me currently though, I don' know why. 13.45.36 # http://samples.mplayerhq.hu/real/AC-cook/ seems to have rm cook samples 13.45.48 # * n1s slow 13.46.30 # mt: Ah, OK. AAC would be nice to do then. 13.47.49 # * amiconn first builds r21830, i.e. without the IRAM change, and will test on iPod G2 and iriver H180 13.52.46 Join graey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 13.53.09 # hi all 13.53.22 # anyone inhere knows anything about the beatbox plugin/app? 13.53.52 Quit flydutch (Remote closed the connection) 14.01.11 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 14.07.54 Join mt_ [0] (n=mt@41.233.138.250) 14.09.02 Quit mt (Read error: 113 (No route to host)) 14.09.33 Quit jfc^2 (Read error: 104 (Connection reset by peer)) 14.10.57 Quit mrkiko ("Lost terminal") 14.16.09 # New commit by 03mcuelenaere (r21837): Make clix more usable on touchscreen targets 14.22.15 Quit dys (Connection timed out) 14.29.40 Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-17963c3e75eddc50) 14.33.14 # graey: adding it to SUBDIRS doesn't work? 14.33.23 # mcuelenaere: Let him ask the question! ;) 14.33.31 # cheers 14.33.34 # ok 14.33.35 # * mcuelenaere couldn't wait ;) 14.33.39 # * linuxstb predicts some top-posting in IRC... 14.33.56 # Or no-posting... 14.34.13 # so the question is: how can I get rockbox to compile beatbox? adding it to the makefile like normal plugins doesn't work since it's in a subfolder. and yes, I've googled :P 14.35.30 Quit DarkDefender ("Leaving") 14.35.32 # gonna try adding it to SUBDIRS I guess :) 14.36.01 # also, a completely different question, but is it impossible to roll a cross-compiler for windows without doing 'linux on windows'? 14.36.23 # graey: cygwin is not linux :) 14.36.40 # yeah, but it's still not fully native either, if you catch my drift :P 14.37.13 # graey: Most of the tools are from the Unix world, so the answer is no... 14.37.20 # ok :) 14.37.48 # Any Unix will work though, even OS X... 14.37.56 # yeah, I know 14.38.03 # amiconn: i didn't test it on other targets, but shouldn't code like that produce label: .word value on pretty much everything? 14.38.04 # graey: well there is something like Interix, but it's not a recommended compiling environment 14.38.14 # but it's for my crappy exotic laptop, it doesn't run UNIX decently 14.38.28 # mcuelenaere: Isn't that a Unix-like thing for Windows as well though? 14.38.30 # mt: you rang? :) 14.38.48 # Unhelpful: I have to check that. One detail is that e.g. on SH1 all C symbols are prefixed with _ 14.38.56 # linuxstb: yeah, but it's more 'integrated' into the kernel then the other solutions :) 14.39.00 # mcuelenaere: I'll give vbox a go, and if that won't work I'll reinstall windows and go for cygwin instead :) thanks 14.39.14 # * amiconn would use it in libdemac though, where SH1 is not an issue 14.39.19 # graey: I would strongly recommend any VM over cygwin, cygwin is sloow.. 14.40.56 # amiconn: is that done by the compiler or the linker? even if it's like that in the asm, we could just add a _? in the perl to handle it. 14.41.14 # Unhelpful: Yep :) .. I can't find apps/core_asmdefs.h did you commit it ? 14.41.29 Nick mt_ is now known as mt (n=mt@41.233.138.250) 14.42.08 Quit daurnimator (Read error: 104 (Connection reset by peer)) 14.42.14 Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) 14.42.29 # mt: apps/core_asmdefs.h is generated in the build directory from apps/core_asmdefs.c 14.43.04 # mcuelenaere: is there anything faster than either of those? it's an old celeron system, from 2003-2004, so it's not too fast :P 14.43.20 # graey: fastest is native Linux/Unix of course ;) 14.43.32 # yeah, but if I do that I can't get a graphical desktop... 14.43.36 # or wifi. 14.43.44 # I could live without X, but not without wifi... 14.43.45 Join dys [0] (n=andreas@krlh-5f706a1d.pool.einsundeins.de) 14.44.04 # Unhelpful : ah ok. I didn't compile a clean build so that's why.. :) 14.45.19 # mt: did it fail to generate it? 14.47.03 # it might have done if your make.dep was out of date... 14.47.15 # Unhelpful: Yes, but let me recheck. 14.48.46 # mt: Umm, elapsed time display is totally borked on coldfire 14.49.58 # amiconn: Is it viewable in a sim ? 14.50.02 # Huge numbers (in the order of thousands of hours) jumping erratically etween positive and negative... 14.50.25 # I doubt it, as I do think it's an endianess problem 14.50.40 # I'm setting up a xubuntu VM in vbox, for rockbox development, maybe it'd be nice to host that somewhere as a click-n-go solution? 14.50.47 # I would expect it to show up in a sim e.g. on a PowerMac (PPC is big endian too iirc) 14.52.06 # Unhelpful: Yeah, just needed to update the dependencies. 14.54.11 # * Unhelpful thinks that we could perhaps have a second, and somewhat more complicated, deps scanner that could be run to generate deps for files in SRC that don't appear in make.dep, or when make.dep is older than source files... 14.54.24 # graey: there's one; http://www.rockbox.org/twiki/bin/view/Main/VMwareDevelopmentPlatform 14.55.47 # amiconn: elapsed time update is corrupted even with no seeking ? 14.55.58 # Yes, just when playing the file 14.56.00 Join Tomcat_ha [0] (n=F14_fana@82-148-214-99.fiber.unet.nl) 14.56.26 # Total playtime display is correct, elapsed time jumps around (far outside the possible range) 14.56.30 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 14.56.46 # even that would fail if a dependency of an unchanged source file changes 14.57.02 *** Saving seen data "./dancer.seen" 14.57.11 # can someone help me with setting up the ipod 240 gb monster build? 14.57.38 # Tomcat_ha: Ask on the forum thread for support for that build. 14.57.46 # That's an unsupported build. 14.57.59 # i know but i thought i could get support quicker if i joined the chat :B 14.58.23 # Tomcat_ha: Do you have the standard Rockbox development environment installed, and can you compile an unmodified Rockbox build? 14.58.44 # i have done nothing except installing standard rockbox in the past 14.58.57 # im looking at this: http://64.151.69.236/rockbox/Readme.txt 14.59.12 # mcuelenaere: yes, but that's for vmware, and vmware is not fully 'free' :) 14.59.18 # the part i dont entirely get is Then you 14.59.18 # will need to run ipodpatcher -a bootloader-ipodvideo.ipod with your ipod 14.59.18 # connected. 14.59.41 # graey: ah, and I suppose vbox isn't able to load vmware images? 14.59.41 # i dont understand where to put the -a bootloader-ipodvideo.ipod with the ipodpatcher 15.00.07 # mcuelenaere: it just might, never thought of that! 15.00.28 # Tomcat_ha: Ah, I misunderstood... You need to open a command prompt, and then type that command (after "cd"-ing into the directory containing ipodpatcher.exe and that bootloader). 15.00.34 # * mcuelenaere remembers some free alternatives to VMWare being able to load VMWare images 15.02.18 # mcuelenaere: the vbox released last week can indeed read vmware images, my bad. 15.02.28 # hmh 15.02.39 # says that the command isnt recognized as an internal or external command 15.03.00 # im typing in -add-bootloader bootloader-ioidvideo.ipod 15.03.52 # mcuelenaere: ofcourse, the vmware-image on rockbox.org hasn't got the guest additions necessary for ease of use, such as mouse pointer integration and/or swapping around files with the host os easily... 15.03.56 # Tomcat_ha: You type "ipodpatcher -a bootloader-ipodvideo.ipod" 15.04.20 # amiconn: Negative values too ? 15.04.26 # graey: yes, I can imagine that. Also, that image was going to get an update IIRC 15.04.27 # yeah i just figured that out myself 15.04.31 # :P 15.04.35 # im slow today 15.04.40 # mt: yes 15.04.59 # mt: Btw, saratoga's IRAM change, despite the rather moderate speedup on PP502x, works wonders on coldfire 15.05.23 # 244% realtime -> 575% realtime on my H180, using the file you first linked to. That's a factor of 2.35 15.05.25 # amiconn: Could you try changing the type of 'i' to uint8 and see what happens ? 15.05.28 # mcuelenaere: well, I've nearly got a xubuntu setup ready, I could just as well compile all cross-compilers instead of just the one for my sansa, and then it'd be good enough to use for everybody I guess :) 15.05.52 # amiconn: How much of MHz is it faster ? 15.06.15 # * amiconn only noted down the percentages, not the MHz. 15.06.20 # anyone know how i can check if i have the 32 or 64m versions? 15.06.23 # The percentages are much easier to compare imo 15.06.31 # of the ipod video? 15.06.43 # Tomcat_ha: What capacity§ 15.06.45 # Tomcat_ha: What disk size was it originally? 15.07.17 # 80 15.07.21 # It dropped from roughly 50MHz to 21.5MHz 15.07.27 # and apparently its not cleanly spread between 32 and 64 for that 15.07.28 # Tomcat_ha: 64 MB then 15.07.34 # wow 15.07.50 # Tomcat_ha: Or if strange things happen with the 64MB build, then 32MB... 15.07.53 # Speedup on PP5002 is 15% (288% -> 331% realtime) 15.08.37 # markun: Did you write crt0.S for the Meizus? 15.08.40 # mt: As mentioned earlier - the coldfires used in our coldfire targets have no data cache, and sdram is slooow compared to a cpu... 15.08.50 # graey: sure, you can put a link in the wiki somewhere I think 15.08.54 # i see 15.08.58 # ill just try this then 15.09.12 # markun: I was wondering about the line that sets the CPU to big-endian mode - isn't it already in big-endian mode (as it's running your code)? 15.09.22 # amiconn: Ah .. I see. 15.09.46 # mcuelenaere: yeah, I'll find a host first and put a link up somewhere. Any things I specifically should or shouldn't do? 15.10.07 # linuxstb: I think it was basically a copy-paste job 15.10.29 # can't remember setting it to big-endian 15.10.38 # markun: No-one seems to accept responsibility for that code ;) 15.10.46 # ;) 15.11.05 # yes, I noticed my name in the logs when you asked other people about it 15.11.16 # linuxstb: It was me! :) 15.11.18 # graey: you could install roughly the same packages as VMwareDevelopmentPlatform does; also try adding an easy way for users to move files between host & VM (samba is installed in the VMWare image for that) 15.11.19 # i assume i dont need to run rockbox utillity now 15.11.25 # linuxstb: do you have a way to run code on the nano2g now? 15.12.05 # markun: Yes, the linux4nano people have worked out an exploit in the notes viewer which lets them start some code which then listens on usb for a file upload, which it then accepts and executes. 15.12.26 # So no way to permanently install new code, but that's probably a good thing... 15.12.45 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 15.13.28 # mcuelenaere: yes, virtualbox has it's own guest additions for that, basically you select a folder that is shared between the host and guest OS, and it's automagically configured right. I think it uses samba, too 15.13.36 Quit Sajber^ (Read error: 110 (Connection timed out)) 15.15.00 # uh 15.15.04 # i get: 15.15.19 # *panic* unsupported physical sector size: 4096 15.15.23 Join Sajber^ [0] (n=Sajber@h-142-120.A213.priv.bahnhof.se) 15.15.30 # mcuelenaere: do you know a place where I can get it hosted? I mean, I can get it on rapidshare or something, but I find those annoying, needing to wait and a low download-speed... is it possible to get it on the rockbox-server itself? 15.15.30 # New commit by 03amiconn (r21838): Fix another file for r12 being a scratch register. Overlooked earlier because this file used ... 15.15.59 # pixelma: ping 15.16.21 # graey: You'd need to offer some significant improvement over the current option, probably, if you wanted yours to be hosted instead. 15.16.53 # graey: you'll need to ask Bagder to put it on the Rockbox server, if you want it on a place with no waiting time I can recommend mediafire.com 15.17.05 # i love mediafire 15.18.17 Join Lear [0] (i=chatzill@rockbox/developer/lear) 15.18.32 # Llorean, mcuelenaere: ok, so the way to go seems to be: put it on mediafire.com, and if it is enough of an improvement ask Badger :) 15.19.13 # personally I think any option that gets rid of proprietary products (be they 'freeware' or not) is a big improvement already :P 15.19.16 # graey: Remember that the current one is rather optimized to be a small download, too. 15.19.33 # how can i change the physical sector size now? 15.19.35 # graey: Also, make sure that it can build all of the various architectures, and sims and manuals (I think the current one does that) 15.19.39 # Just being "freer" but not being as good elsewhere probably isn't going to do it. 15.20.28 # AlexP: yes, I'm going to build all cross-compilers rockbox has to offer, if that's what you mean :) 15.20.35 # graey: How big is your vm? The existing ones are designed to be relatively small... 15.20.54 # well, my current VM is quite big, but that's ubuntu-based and also has some mono-development stuff installe 15.21.35 # Hm, the improved seeking in tremor appears to have been a fairly easy merge. Works in the sim at least. :) 15.21.35 # I'm gonna do one on xubuntu or just debian, with a dynamicly expanding disk of about 8GB. 15.21.51 # download size I'm targetting is 250-300MB max. 15.21.52 # Maybe we could simply provide instructions for setting up Rockbox in a "standard" vm, if they exist (i.e. ones hosted elsewhere...). 15.22.35 # Llorean: it's not just freeer, it also provides an easier way of sharing files with host os, and virtualbox is less limited than the free vmware player in many ways :) 15.22.35 # linuxstb: Well, setting up Rockbox development is pretty simplified already (rockboxdev.sh could be extended to manuals, I guess?) 15.22.43 # graey: That, plus the packages needed to build the sims and manuals 15.22.54 # AlexP: yes, ofcourse, forgot to mention that. 15.23.26 # graey: Yes, but as I said, it needs to actually meet all of the needs already met by the current one, without drawbacks. Being less limited than vmware player hardly matters if none of vmware player's limitations prevent it from being used for the purpose the VM we provide is designed for. 15.24.04 # Llorean: I'll make it so that it meets the needs the current one does, and where possible more, without making it bigger in size. 15.24.08 # Llorean: Yes, I was thinking more along the lines of some step-by-step instructions (including downloading and installing the VM), designed for Linux novices. Maybe rockboxdev.sh (or a new script) could do most things for the user, like making sure all required packages are installed. 15.24.27 Join mrkiko [0] (n=mrkiko@79.24.107.232) 15.24.40 # linuxstb: I'll make a guide of how I built my VM. should be applicable to both debian and ubuntu installs. 15.24.44 # Or maybe we should simply recognise that people now have more bandwidth, and increase the image size... 15.24.59 # linuxstb: Something as far as checking for the package, and if not present, offering to manually download it or providing them a list of package names different distros use (or even specific to their distro)? 15.25.18 # I think anything less than CD sized is "small enough" probably 15.26.30 # True, lots of people download full distro's these days, not to mention the torrenting and stuff. 15.29.05 # Is virtualbox itself as easy, or easier, to use than VMWare? Less technical knowledge expected/necessary? 15.29.48 # Llorean: when using prepared OS images like you do with VMWare player, yes 15.30.34 # and you actually have the ability to create your own VMs with virtualbox, something which player hasn't. that could save people bandwidth, by letting them set up an environment with only the stuff they need :) 15.31.44 # And I'll be writing a guide on how to setup a VM in virtualbox yourself, mostly it'll be the same as the existing guide for Linux setup, with some additions about virtualbox 15.31.45 # VMWare is more or less for the people who *can't* do things for themselves 15.31.50 # Or rather, any VM we host 15.32.01 # People who can do things for themselves could use the VM of their choice. 15.32.08 # yes, I know, and virtualbox is just as good at that 15.32.31 # and by the way, if you can develop C, surely you can start a prepared VM from virtualbox :P 15.33.10 # Many of these people can't develop C 15.33.18 # They're just trying to apply a single patch, or a few, and compile 15.33.24 # yeah, fair enough. 15.33.26 # well 15.33.30 # I think it's easy enough 15.33.34 # let me show 15.33.39 Join daurnimator_ [0] (n=daurnima@ppp118-208-150-78.lns10.mel4.internode.on.net) 15.33.40 # I'll take your word for it, honestly 15.34.05 # Just wanted to make sure it's clear that a major goal here is "ease of setup for the less-technical" rather than "offering a flexible, powerful, free tool that can be expanded to other purposes" 15.34.20 # The latter's nice, but not if we have to sacrifice the first (in my opinion) 15.35.08 # yes, I understand :) 15.35.27 Part Tomcat_ha 15.36.38 # Llorean: http://i25.tinypic.com/16jh6ja.jpg 15.37.11 Quit gevaerts (Nick collision from services.) 15.37.20 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 15.38.11 # Llorean: when you start virtualbox, if you only have one VM installed, it's automatically selected. so novice users would start vbox, click start and be done 15.38.47 # now I'll stop talking about how much I like vbox and finish the VM ^^ 15.39.15 Quit daurnimator (Read error: 60 (Operation timed out)) 15.40.23 # graey: Will installing it in windows automatically associate the extensions? 15.41.21 # I think it does, yes 15.41.30 # let me check 15.44.20 # it does not! 15.44.24 # mt: Changing the type of 'i' doesn't change anything. Btw, it is recommended to use 'int' or 'unsigned int' for plain variables like 'i'. Using data types of specific sizes often causes gcc to emit extra code, i.e. it's larger and slower 15.44.59 # (sign or zero extension in various ways depending on the architecture) 15.45.13 # graey: That's a little bit disappointing. It would be nice to be able to say "install virtualbox, download this file, and double click on it to use our VM" 15.45.15 # Llorean: you can export vm settings and hard disk to a .ovf, open virtualisation format, but you have to click File -> Import appliance, then you have to browse to it, and only then you can use it. 15.45.17 # But not the worst thing ever. 15.45.53 # Llorean: I'll update to the latest version, and check virtualbox SVN. if it isn't a feature yet, I'll file a bug report/feature request and it'll probably be in the next version, as it's only a minor fix. 15.47.51 # Llorean: also, does vmware player support USB forwarding? 15.48.05 # amiconn: Could you log the values of rmctx.audiotimestamp and i ? (Though I'm guessing the problem is with audiotimestamp) 15.48.29 # graey: I'm not sure what you mean by "usb forwarding", if you mean "can it preempt USB in some manner so the devices appear to connect to the VM rather than to windows" I believe the answer is "yes" 15.48.31 # I'm not 100% sure though 15.48.58 # Well, "rather than to the host OS" I suppose. I only use "windows" there since that's what I was asking about earlier. 15.49.36 # Llorean: ah, ok. virtualbox does that too, on all host OSes it supports. 15.50.07 # As a side point, VM Server is free and lets you make VMs 15.50.19 # You don't have to use the player 15.50.46 # And only the none open source Vbox does USB passthrough as far as I'm aware 15.50.51 # * gevaerts thinks that as long as the free virtualbox can't do USB forwarding, there's no point in preferring it over vmware 15.51.20 # AlexP: vmware server is only partially free, but I see your point 15.51.36 # graey: same goes for virtualbox 15.51.44 # graey: It is free as in price 15.52.09 # graey: And if we are arguing about free as in libre, then the same is true for the version of virtual box with all the features (such as USB) 15.52.31 # alexp: yes, I just noticed, I thought that had changed already, but it hasnt, yet. 15.52.47 # Do we consider USB forwarding essential? 15.52.54 # Probably not 15.53.23 # I don't care which we use, VM or VBox, I was just pointing out that neither are completely "free" 15.53.26 # Even if it would be essential, the non-open source Virtualbox does it, and virtualbox virtual machines work equally well with both the open-source and the non-open source. 15.53.28 # depends. You need it for e200tool, tcctool, meizu_dfu, e200rpatcher,... 15.53.30 # Though it does make installation easier 15.53.39 # With USB forwarding you don't need access to the files from the host in many cases. 15.53.48 # gevaerts: I thought e200rpatcher didn't actually work in the VM 15.53.57 # Or some e200R related tool 15.54.11 # ah, possibly. I never tried 15.54.14 # with virtualbox, there is an option for open-source, and only if you need specific features you have to use the closed-source version :) 15.54.45 # Is virtualbox equally fast in compile times? 15.54.53 # * gevaerts doesn't consider this GPL-as-shareware-crippling to be proper open source 15.55.02 # I wouldn't know. 15.55.24 # I mean, the main reason we recommend the VM, rather than Cygwin or similar alternatives, is that it compiles much faster on Windows 15.55.28 # gevaerts: e200rpatcher and tcctool work on windows with libusb. 15.56.00 # I'll make the VM and try. 15.56.49 # * Llorean would expect it to perform equally well, but you never know 16.00.10 # linuxstb: yes, but you need precompiled versions of them, or cygwin or mingw, or a VM that has mingw. It gets complicated 16.00.34 # We have binaries, don't we? 16.00.45 # Llorean: yeah, I've seen multiple times that vbox is equal to vmware in performance, or that it outperforms it but I've never tried myself 16.00.57 # just switching pc's now though, be back in a second 16.01.15 # * dz needs to get rid of vmware on account of vmware-modules not wanting to play well with 2.6.29 and above 16.01.19 # linuxstb: sure, but this is about development. Maybe the binaries are stable enough not to worry about them though 16.02.09 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 16.02.36 Join thegraey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 16.02.42 # back 16.03.58 # as to localisation, should I stick with debian standard values like USA and stuff? 16.06.58 Quit r0b- (Read error: 104 (Connection reset by peer)) 16.07.42 Quit graey (Read error: 60 (Operation timed out)) 16.09.51 Join r0b- [0] (n=rob@76.235.217.188) 16.10.56 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.13.59 Join Strife89 [0] (n=Michael@168.16.239.71) 16.14.35 Quit gevaerts (Nick collision from services.) 16.14.44 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 16.15.05 # linuxstb: pong - Mornin! 16.17.20 Join AndyI [0] (i=AndyI@212.14.205.32) 16.20.41 # New commit by 03alle (r21839): Correctly compute the array size regardless of the element type 16.21.08 # obo: Hi. I was wondering how things were going with the View? 16.22.05 # Slowly, as ever. I seem to have hit a bit of a wall trying to communicate with the LCD 16.22.29 # Is there anything else you can work on? Do you have any form of feedback (backlight, LEDs, ...) ? 16.22.45 # I have backlight and button lights 16.23.44 Quit mrkiko ("sorry") 16.24.26 # the View appears to have the same USB controller as earlier generation PP devices, so I could try to track down the GPIO used for that... 16.26.12 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.26.36 # apart from that I'm open to suggestions 16.26.42 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-a34949799583decc) 16.27.33 Quit crwl (simmons.freenode.net irc.freenode.net) 16.27.33 NSplit simmons.freenode.net irc.freenode.net 16.27.33 Quit feisar-- (simmons.freenode.net irc.freenode.net) 16.27.58 NHeal simmons.freenode.net irc.freenode.net 16.27.58 NJoin feisar-- [0] (i=jljhook@irkki.fi) 16.27.58 NJoin crwl [0] (n=crawlie@a91-156-100-168.elisa-laajakaista.fi) 16.29.09 Quit AndyIL (Read error: 110 (Connection timed out)) 16.30.43 # obo: Working on USB for some days might be sensible, it's probably a good idea to take a short break from the lcd wall 16.31.12 Join schrottplatz [0] (n=max@78.53.227.28) 16.31.15 # hi 16.31.18 # (also you'll have a bit more to show off [if that's needed] for the mid-term evaluation) 16.31.31 # has anybody running rockbox on a sansa fuze? 16.31.34 # kugel: mid-term evaluation ends today :) 16.31.53 # today already? A bit late then 16.32.06 # schrottplatz: yes 16.32.58 # and can you listen to music etc? 16.33.05 # yes 16.33.10 # great :) 16.33.25 # the lcd of my e200 broke and now i need a new player 16.33.25 # I've also seen pictures of people playing pokemon on it 16.33.37 # obo: What about ATA/NAND? Do you know if that's similar to the e200? 16.34.37 Nick daurnimator_ is now known as daurnimator (n=daurnima@ppp118-208-150-78.lns10.mel4.internode.on.net) 16.36.15 # where can i see the fiffrence between fuze v1 and v2? 16.37.00 # linuxstb: it has a similar SD<->NAND controller to the e200. 16.37.37 # obo: So that could be interesting to work on as well. My main suggestion was simply to be to try something else, and go back to the lcd later. 16.39.13 # obo: Also, do you have anything to commit? I don't see a View in the build system... 16.39.20 # schrottplatz: I don't think you can before turning it on and looking for the firmware version 16.39.42 # linuxstb: kugel: okay, thanks. I'll try looking into these new areas. 16.39.43 Join jfc^2 [0] (n=john@dpc6682208002.direcpc.com) 16.39.46 # kk 16.39.50 # i will buy one 16.39.51 # :D 16.40.38 # linuxstb: no. I was thinking along the lines that since I didn't have any code that produced any output, it wasn't worth adding the target to the build system 16.40.55 # thx and bb 16.40.59 # obo: That hasn't stopped me in the past... 16.40.59 Part schrottplatz ("o.O") 16.41.34 Join _zic [0] (n=user@83-156-252-126.rev.libertysurf.net) 16.42.07 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.43.50 # linuxstb: okay, I can add it in. To begin with I was thinking of adding the PP6100 like the PP5024 - it just includes the PP5020 header. But for main builds some defines will need to be changed to make sure the COP isn't used on the View 16.46.09 Quit bmbl (Connection timed out) 16.48.05 # New commit by 03alle (r21840): Slightly reduce the bin size by using ushort instead of int in arrays 16.49.23 Join Strife1989 [0] (n=Michael@168.16.239.71) 16.50.12 Quit Strife89 (Nick collision from services.) 16.50.51 Nick Strife1989 is now known as Strife89 (n=Michael@168.16.239.71) 16.53.38 Join funman [0] (n=fun@rockbox/developer/funman) 16.55.02 # obo: So there's no COP? 16.55.37 # linuxstb: AFAIK the COP is the Nvidia GPU/media accelerator 16.57.04 *** Saving seen data "./dancer.seen" 16.57.14 # obo: OK, that should be easy to disable in config.h I think 16.59.40 Quit kugel (Nick collision from services.) 16.59.44 Join kugel [0] (n=kugel@85.178.106.203) 17.02.44 Join fml [0] (n=4fd3cb07@gateway/web/cgi-irc/labb.contactor.se/x-71ad39def403d27c) 17.03.03 Quit teru ("Quit") 17.03.38 # What do the errors for the two last commits mean? Are they caused by the commit or by the build infrastructure? 17.04.14 # fml: I wonder if 50bytes are really worth added complexity through not using int 17.04.47 # what was the binsize hit anyway? Maybe you're worrying a bit to much 17.05.14 # kugel: what complexity? Nothing has changed code wise. 17.05.16 # fml: "No space left on device" is clearly a problem with one particular build server. 17.05.33 # not in the C code, yes .) 17.06.20 # I wonder a bit if the pitchscreen needs yet another fixpoint implementation anyway 17.07.21 # kugel: I don't think it needs 17.09.22 # there's some in fixedpoint.c 17.10.15 # I don't quite understand all the changes, I thought only the UI was questionable? 17.10.46 # obo: have you seen some code ran by the COP, or you only have informations from documents? 17.22.09 # obo: since you can control the button light / backlight you can get back binary numbers from the sansa view. 17.22.42 # For example check the content of a lcd status register to see if commands are being transmitted at all 17.23.10 # New commit by 03learman (r21841): Import Vorbis seeking improvements from Tremor SVN. 17.23.53 # funman: there are checks/branches in the OF testing if a COP is present. The only docs I have are the nvidia sales info, which describes an ARM1176JZ with a "hardwired media co-processor" 17.24.37 # If i'm not mistaken, "media" co-processors have a special instruction set dedicated for multimedia processing 17.24.41 # just got back home, and I forgot how to include beatbox in my build. its a plugin, but in a subdirectory, so the normal plugin-adding routine doesn't apply? 17.26.02 # funman: that what I assumed, some kind of DSP? There is an extra chunk/mi4 in the firmware partition titled mediaproc.mi4 I'd be happy not to touch it 17.26.30 # btw, I have googled, but not found. and I've tried to add beatbox to SUBDIRS, but that yields an error about no beatbox.make being there... 17.26.57 # obo: you better shouldn't ;) there is a reason the DSP on some ipods is not used 17.27.06 Quit n00b81 ("Leaving") 17.27.16 Quit Strife89 ("Gotta run some errands. Thanks again, Lambda. :)") 17.27.33 # thegraey: just look at .make files in other subdirectories 17.28.26 # funman: I didn't think the ipods had a DSP? But I have a 250MHz arm to play with, that should be more than enough. 17.29.24 # funman: I will, thanks 17.30.53 Join daurnimator_ [0] (n=daurnima@ppp118-208-196-178.lns10.mel6.internode.on.net) 17.35.26 Nick daurnimator_ is now known as daurn (n=daurnima@ppp118-208-196-178.lns10.mel6.internode.on.net) 17.39.36 # fyi, it looks like ipod classic (6g) is extremely similar to the nano 2g 17.39.47 # somebody just reported that ibuggerloader would run on it 17.42.13 Quit daurnimator (Read error: 101 (Network is unreachable)) 17.42.26 # TheSeven: You mean it runs fully? i.e. enumerates as a USB device running your code? 17.42.49 # that's what someone reported 17.43.34 # That would be good news. The Classic is far more interesting (IMO) than the Nanos - very few companies make hard-disk DAPs any more... 17.44.12 # and it's a currently-sold model 17.44.37 # we really need to get usb fully working 17.46.23 # Isn't there two revisions of the "6g" though? 17.46.28 # funman: it's building now, thank you :) 17.49.01 Nick thegraey is now known as graey (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 17.50.43 # linuxstb: Are there really? I thought the 120gb one was just a larger single-platter drive? 17.51.15 # Llorean: Well, http://www.felixbruns.de/iPod/firmware/ lists "Classic" and "Classic 2G". That's my only source for that info. 17.51.23 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 17.51.24 # funman: now it's complaining about beatbox.map missing, did I do something wrong again? ^^ 17.51.30 # I don't think the hw is different though 17.51.54 # JdGordon: Better check your build server... 17.51.58 Quit robin0800 (Remote closed the connection) 17.52.11 # yeap, done, fixed 17.54.14 # linuxstb: Ah, interesting, because I don't think apple distinguishes them on the "identify your iPod" page like they do the 5G and the later 5.5G 17.54.49 # or anyone else for that matter ^^ 17.56.00 Quit petur ("work->home") 17.56.05 # graey: paste the log on some pastebin 17.56.18 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 17.59.08 Join saratogalab [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-9ab345e4068a789d) 17.59.37 # amiconn: you cook test file is way faster then mine, I only got ~190% realtime with my 64k file on PP5024 17.59.48 # funman: it's all hapiness, until this: http://pastebin.com/d653b87e5 17.59.54 # funman: all out of the blue, too 18.01.17 # graey: ld is (I think) writing that file - do you perhaps have another file already there with that name, but with odd permissions/ownership? 18.01.45 # linuxstb: in the build-directory? 18.01.48 # * linuxstb realises that probably doesn't make sense, re-reading the error message... 18.01.51 # Yes 18.02.09 # Do you even have apps/plugins/beatbox/ in your build dir? 18.02.31 # nope, I clean up my build dir every time, so it's empty to start with. is that wrong? 18.02.43 # I mean, it builds perfectly without beatbox 18.03.44 # nvm 18.03.47 # just noticed a typo 18.04.03 # $(SBEATBOXBUILDDIR)/beatbox.rock: $(BEATBOX_OBJ) should be $(BEATBOXBUILDDIR)/beatbox.rock: $(BEATBOX_OBJ) 18.04.13 # sorry ^^ 18.05.32 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 18.06.41 # saratogalab: It's a 32kbps file, that's why it's faster. But it doesn't change the fact that your iram change works wonders on coldfire 18.08.41 # yeah 18.09.08 # how nice of them to put all buffers in one struct that could be easily moved to IRAM 18.09.10 # Putting some code into iram would help on PP5002 18.09.33 # ASM'ed fixed point functions would help a lot 18.09.47 # the fixed multiply function they use looks like a mess 18.09.47 # There are also some arrays of constants of which I don't know how often they're used 18.10.19 # If they're used heavily, they should go into iram as well 18.10.38 Quit AlexP ("No Ping reply in 90 seconds.") 18.10.54 # * amiconn still wonders about the jumping elapsed time on coldfire 18.10.55 Join AlexP [0] (n=alex@rockbox/staff/AlexP) 18.11.09 # * amiconn has no real idea how he could help debugging that 18.11.20 # I tried some things which didn't work 18.12.16 Quit dz (Remote closed the connection) 18.12.20 Join dz [0] (n=dz@alt.dissonance.nl) 18.14.02 # amiconn: So it plays fine, but the elapsed time is wrong? What about seeking? 18.15.24 Join Ubuntuxer [0] (n=johannes@dslb-094-221-083-198.pools.arcor-ip.net) 18.23.26 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.31.05 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.31.21 Join dash32 [0] (n=dash32@p54AB5496.dip.t-dialin.net) 18.32.03 # aaron424: i can use mkamsboot fine on my m200v4 firmware "4.01.08-A", md5sum fc9dd6116001b3e6a150b898f1b091f0 18.32.03 # has midi changed a lot lately? I get far less buffering issues now on my sansa e250. 18.32.18 # with latest revision that is, btw 18.32.33 Join JdGordon| [0] (i=ad804a17@gateway/web/freenode/x-ee4d069c3d8f625d) 18.32.56 # funman: the .bin I am using was originally named m200p.bin. (I got it from badgers website) 18.34.47 # aaron424: I used this same file, please check that it downloaded correctly (using md5sum for example) 18.35.24 # aaron424: Also are you using the most recent mkamsboot? 18.35.42 # just downloaded it today 18.35.53 # from svn I believe 18.36.24 # aaron424: can you paste the full output of mkamsboot on a pastebin, with a md5sum of your m200p.bin if possible 18.36.36 # brb 18.36.39 Quit graey () 18.37.02 # what is a pastebin 18.37.03 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 18.37.16 Quit DarkSpectrum (Client Quit) 18.37.29 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 18.37.33 # aaron424: http://pastie.org/ for example 18.38.01 # paste the output of mkamsboot in it, click paste, and give us the url you obtained so we can see what you pasted 18.38.55 # aaron424: I've just tried (downloading m200p.bin from Bagder's site), and it works fine for me as well... 18.39.30 # 18:29 < aaron424> [ERR] Whole file checksum failed 18.39.40 # hm 18.39.43 # I suspect an incorrect download? 18.39.51 # I just had a "sd bank error: -1" 18.40.04 # ? 18.40.21 # dont know how to use it 18.40.28 # no, http://pastie.org/544338 18.40.41 # after clicking paste just post the url from the addressbar here 18.40.55 # okay 18.41.03 # the error is explicit (and it is not the one you had mentioned), you have to build a m200v4 bootloader first 18.41.05 # aaron424: That's a different error to the one you pasted before... 18.41.09 Nick thegeek_ is now known as thegeek (n=nnscript@s243b.studby.ntnu.no) 18.41.21 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 18.41.25 Quit thegeek ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") 18.41.27 # amiconn: ping 18.41.31 # linuxstb: I ran the command again 18.41.37 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 18.41.38 # with a fresh .bin 18.42.18 # You now need a bootloader-m200v4.sansa file in the same directory as mkamsboot and m200a.bin 18.42.54 # where/how do I get that 18.43.32 # You need to compile it yourself. 18.43.54 # * linuxstb doesn't even know the status of Rockbox on the m200v4... 18.44.06 # * aaron424 is trying to find out 18.45.36 # linuxstb: sporadic (volume related) shutdowns, and playback stopping (like on clip and c200v2) 18.48.21 # mt: guess you wanted a coldfire tester, so problem solved? 18.51.08 Join graey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 18.52.02 # pixelma: umm .. I'm not sure it's going to make any difference, but it's a very small modification so we might as well try. :) 18.52.15 Quit dmb (No route to host) 18.52.17 # I also remember LCD problems (probably due to too fast delay loops) resulting in the display data to be shifted down 18.53.26 # the m200v4 runs on an AA battery (or was it AAA) so it is different from the other ams sansas (that uses a lithium battery) with respect to power 18.53.32 # pixelma: in apps/codecs/librm/rm.c - line ~553 (pkt->flags & 2) .. change the 2 to 2000 and see if that makes a difference in the elapsed time update ? 18.54.04 # there are some settings that determine how the power is regulated that we haven't explored yet as far as I know 18.54.45 # I also noticed that the audio volume on the m200v4 was quite low compared to the other ams sansas 18.57.05 *** Saving seen data "./dancer.seen" 19.02.42 Quit Ubuntuxer ("Leaving.") 19.03.34 Quit r0b- (Read error: 104 (Connection reset by peer)) 19.04.41 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 19.09.35 Quit saratogalab ("CGI:IRC (EOF)") 19.13.36 Quit JdGordon| (Ping timeout: 180 seconds) 19.18.43 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-a9011f40c0660390) 19.20.43 Join _lifeless [0] (n=lifeless@188.16.126.19) 19.22.41 Join Ubuntuxer [0] (n=johannes@dslb-094-220-230-039.pools.arcor-ip.net) 19.24.55 # I'm trying to make the metronome tick every first beat of the measure, basically meaning you'll have a 'tick' and a 'tock' sound. However I don't fully understand the sound array, I suppose it's raw sound data like in a wav file, but then as an array of chars? if so, what's the second sound array doing? 19.28.45 # graey: there's a patch for that in the tracker somewhere IIRC 19.28.56 Nick efyx_ is now known as efyx (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 19.29.06 # graey: One is wav (for swcodec targets), one is mp3 (for hwcodec targets). 19.29.15 # linuxstb: thanks :) 19.29.41 # n1s: does it also allow you to set different types of measures too? like 3/4, 4/4, 6/8 and so on? 19.29.59 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.30.02 # graey: i don't know 19.30.08 # k 19.30.49 # fs#6255 19.32.06 # thanks :) 19.33.12 Quit DarkSpectrum () 19.34.41 Join benanne [0] (n=rijdier@208.133-246-81.adsl-dyn.isp.belgacom.be) 19.34.48 # I cannot make my m250 update the firmware. 19.34.56 # * n1s wonders why fml reinvented the ARRAYLEN macro in r21839... 19.35.15 # I wondered that also 19.36.31 # I was finally able to make the bootloader with mkamsboot but copying the file over and renaming it and then removing the m200 from the computer. It just refreshes database and goes back to the of 19.38.04 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 19.39.48 # I know this isn't an iPod support channel, but I've been running rockbox on my iPod nano 1st gen all its life and now it seems to have died... it's not responding to the reset button combination, and when I attach it to my PC it seems to go into a reboot loop (showing the apple logo for a few seconds, then powering down, etc. ad nauseam) 19.40.02 # I'm having a hard time identifying the problem, but I'm affraid the battery might have died... anybody else ever seen this? 19.41.30 # benanne: Leave it charging for 24hrs or so, and try to hard reset it again 19.42.25 # evilnick: the problem is that when I attach it to my PC for charging, it goes into this reboot loop... it doesn't seem very healthy to let it do that for 24 hours on end, I even doubt that it actually charges at all in that process. Or should I just go ahead and try that :) 19.42.28 # pixelma: Any luck ? 19.42.43 # benanne: Don't you have a wall-charger? 19.42.48 # nope 19.43.33 # if I could find an externally powered USB hub somewhere, would that work? 19.44.04 # benanne: You could also try turning on the hold switch, to try and get it to start the Apple firmware. Or force it into disk mode (hold SELECT+PLAY immediately when it comes on) 19.44.28 # benanne: I'm not sure. I was thinking of the kind of adaptor that you plug into the wall that you then plug the USB end of the iPod cable into. 19.44.29 # those sound like viable ideas, thanks :) 19.44.42 # evilnick: yeah, I know what you're talking about, don't have one of those unfortunately :( 19.45.05 # benanne: Get an iPhone and you get one for free (!) 19.45.14 # hehe :p 19.45.16 # * gevaerts slaps evilnick 19.45.50 # entering disk mode seems to have worked :) 19.46.06 # couldn't boot into the apple firmware either though, I guess rockbox isn't to blame 19.46.06 Quit antil33t () 19.46.11 # although I didn't expect it would be 19.46.13 Join gkahla [0] (n=gerall@adsl-64-219-115-135.dsl.bumttx.swbell.net) 19.48.38 # did JdGordon already fix his server? 19.48.49 # yes 19.48.59 # its still complaining? 19.49.31 # probably not, just catching up with what happened today :) 19.50.29 # mt: sorry, phone call. Going to try soonish, build is already complete 19.50.48 # Bagder: something to make the new system more complicated... errors like out of disk and missing compilers and stuff will be hidden in the new system.. any chance of having it email the client owner if it happens? 19.51.38 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 19.52.09 # pixelma: Great.. Thanks :) 19.52.10 Part gkahla ("Leaving") 19.52.18 # funman: Got any remarks on this: http://pastie.org/544392? I think the 1<< 23 is covered by 0x00FF8000 19.54.37 # FlynDice: but for non sdv2 cards, only the bit 23 is set, not all the bits of supported voltage 19.55.17 # aren't we just telling it what our hardware supports? 19.57.52 # I'll go find a version 1 sd spec... 19.57.56 # mt: hmm, the time looks sensible now (though I think it's wrong, need to compare with vlc). But playback is broken - starts playing ok for a bit less than a second, I guess and the it's stuck playing one sample, sometimes outburst into more noise, or so and current playing time doesn't advance (stays at 0:00) 19.58.12 # haven't tried plain svn though 19.58.14 # FlynDice: i think version 2 covers all cases 19.59.04 # i think 1<<23 is what the of uses, lemme check 19.59.38 # funman: so do we only support 3.5-3.6 on a v1 sd card, is that the issue? 20.00.39 # right, I'll leave it charging for a while and then see if I can get it to boot rockbox again 20.00.40 # pixelma: Does your source copy have any modifications related to RM ? 20.00.45 # evilnick, linuxstb, thanks for your help :) bye 20.00.54 Part benanne ("kbai") 20.01.32 # FlynDice: i don't know 20.02.02 # I just get the supported voltages from the OF since we don't have the details of how the SD controler is powered 20.02.20 # * linuxstb wants to create a subdir in utils/ for tools for hacking new ipods, and wonders what to call that directory... 20.02.44 Join antil33t [0] (n=Mudkips@119.224.12.185) 20.03.21 # mt: it had the one change you told me, kugel's pluginlib actions patch and a few changes to the manual by me 20.03.25 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 20.03.29 Quit DarkDefender (Read error: 104 (Connection reset by peer)) 20.04.16 # 0x5806 in my fuze firmware (v1.1.11 i think) 20.04.35 Part Ubuntuxer 20.04.40 # pixelma: Fine. Nothing of those could be affecting playback .. I'll go back and think. :/ 20.04.41 Quit flydutch ("/* empty */") 20.05.31 # linuxstb: I didn't try seeking. test_codec has the same display problem - the number of decoded milliseconds is jumping around wildly. But apart from that it's working properly 20.05.35 # mt: pong 20.05.48 # linuxstb: new_ipods ? :) 20.05.52 # mt: I just tried without that one line change in apps/codecs/librm/rm.c and it plays fine but playing times are junpy 20.06.21 # mt: I may end up just using that... Or maybe simply "ipod".. 20.06.58 # amiconn: nevermind, I just had a stupid idea that doesn't work ! 20.07.47 # amiconn: Do you have a WPS that shows the bitrate? 20.08.07 # I do 20.08.20 # No - I used the track info screen 20.08.23 # 32kbps 20.08.23 # pixelma: You mean jumpy like giving out-of-range values ? 20.08.34 # amiconn: OK, so that's being read correctly? 20.08.43 # yes 20.09.33 # yes, really bogus times jumping from -345464:-23 to 567:34 etc 20.10.15 # bogotimes 20.10.30 Join mitk [0] (n=594df737@gateway/web/cgi-irc/labb.contactor.se/x-293b11667a5b9b6f) 20.10.50 # only seems to be the current playing time. This thing makes the progressbar jump from being completely full to completely empty and vice versa 20.10.51 # linuxstb: I was going to suggest just 'ipods', but thought 'new_ipods' is better since it clearly states that those tools are just for the new ipods. 20.11.34 # the track length seems to be displayed correctly 20.12.05 # The problem has to be with rmctx.audiotimestamp. It can't be with rmctx.bit_rate since it's displayed correctly and if there were a problem with 'i' there would have been seg faults.. :/ 20.13.25 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 20.13.54 # #rockbox 20.14.22 # the mentioned times were just examples, it's completely different all the time 20.14.33 Quit funman ("free(random());") 20.14.50 Join itcheg [0] (i=4117734b@gateway/web/freenode/x-6f8dd8e38c172de8) 20.14.56 # I am having trouble installing rockbox on my m250. I have put the rockbox dir in the root and compiled the bootloader (m200a.bin) 20.15.19 # but when I put the .bin on my device, it does not update 20.15.32 # pixelma: Yeah I know. Thanks for the clarification. 20.16.55 # Hi. Is there anyone who have some time to take a look and enough power to commit FS#10235? It is pacbox patch for Fuze. 20.17.51 # mt: I've remembered I also have one utility for old ipods, which I could commit there, so I'll just use "ipods" as the top-level dirname... 20.18.21 Nick JdGordon| is now known as JdGordon|| (n=Miranda@nat/microsoft/x-a9011f40c0660390) 20.18.44 Nick JdGordon|| is now known as JdGordon| (n=Miranda@nat/microsoft/x-a9011f40c0660390) 20.19.09 # mitk: what's the HOME button change? 20.19.18 # amiconn: Is it possible to log the values of some parameters on-target ? 20.19.30 Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060308]") 20.20.01 # It changes menu access method. 20.20.32 # yea, but why? long home is used in all other plugins 20.23.05 # If I understand correctly originally it was combo BUTTON_HOME|BUTTON_REPEAT. I can change t to long HOME but pacbox do not need many buttons so simple HOME can be used. 20.23.21 # s/t/it/ 20.24.53 # mt: Probably, using logf(). But I didn't use that for ages, and I'm not sure whether I could use it from codecs 20.25.02 Quit stoffel (Read error: 104 (Connection reset by peer)) 20.25.22 # Also, what would I find? A jumping value... but why does it jump 20.25.59 # amiconn: It could be used from codecs, I was just asking because I wasn't sure it worked with your targets. 20.26.18 # logf() works for all targets 20.27.16 # amiconn: No, I'm almost pretty sure the problem is with rmctx.audiotimestamp, which makes the possibility of an error in reading the value of pkt->flags high. 20.28.39 # amiconn: So if you have the time, could you help me by displaying this value ? 20.31.44 # New commit by 03dave (r21842): First commit of "bin2note" utility for exploiting the Notes buffer overflow on the 2nd generation Nano. 20.34.13 # New commit by 03kugel (r21843): FS#10235 - "(fuze) pacbox keymap change" by Ralph Soto. ... 20.34.59 # mitk: alright, done 20.35.02 # kugel: Thank you. Bye 20.36.37 Quit mitk ("CGI:IRC") 20.37.13 # mt: There is a difference in the test function rm_get_packet_fd() and rm_get_packet(). The former only gets packet_group and flags if version == 0, the latter always does 20.37.24 # Is this correct? 20.39.09 # amiconn: Yes .. it's not exactly the same but that is no problem. (I should modify _fd later though) 20.39.13 # New commit by 03dave (r21844): Add flashsplit utility, previously hosted on the wiki at http://www.rockbox.org/wiki/IpodFlash 20.39.49 # Also, I wonder why you're reading 'unknown' at all if it's not used 20.40.03 Join einhirn [0] (n=Miranda@p5DCC1995.dip0.t-ipconnect.de) 20.40.18 # In the fd case you need to advance the file pointer of course, but in the in-memory case this is unnecessary 20.46.19 # This should be removed yes. 20.47.35 Quit einhirn (Read error: 104 (Connection reset by peer)) 20.48.54 Quit flydutch (Read error: 60 (Operation timed out)) 20.48.56 # I'm considering using midi sounds for the metronome, is this OK or doesn't MIDI work on all targets the way PCM/MP3 playback does? 20.49.02 # * kugel thinks statusbar should be a theme setting 20.50.01 # graey: midi takes a lot of CPU time, plus a lot of RAM. It's not an efficient choice... 20.50.19 # Plus it's not easy to use codecs from plugins 20.50.27 # kugel: it is 20.50.54 # actually... they are 20.50.56 # linuxstb: I thought it'd be nicely doable since it's also what beatbox seems to do 20.51.23 # but if it's not efficient it's not the right choice indeed 20.51.33 # graey: beatbox actually uses the midi code, or does it just have it's own samples that it plays back? 20.51.43 # graey: How does the current Metronome do it? 20.52.00 # evilnick: Just a single PCM sample (or mp3 for Archos) 20.52.05 # linuxstb: it does reference them in it's sources-file, so I assume it uses midi yes 20.52.22 # JdGordon|: they're not under the theme settings menu though 20.52.33 # so move them 20.52.39 # doesnt mean they arnt theme settings :) 20.52.44 Join bubsy [0] (i=Bubsy@94.139.72.137) 20.54.18 Quit bmbl ("Bye!") 20.54.22 # linuxstb: how exactly do I 'convert' a wave/mp3 file to char/short array like used in the metronome? 20.54.52 # slick_letitblue looks nice with customlist 20.55.59 # graey: You would need to write a program to do it 20.56.28 # linuxstb: a hex-editor wouldn't do? 20.56.58 # graey: Maybe. But basically you'll need to use your initiative - there are no existing tools in Rockbox to do it. 20.57.10 *** Saving seen data "./dancer.seen" 20.57.34 # graey: have a look at tools/bin2c 20.57.36 # linuxstb: yeah, I thought so. I was hoping the original writer was on irc and reading along :P 20.57.45 # gevaerts: thanks, I will :) 20.58.11 # You'll need a raw audio file of course, not a wav file 20.58.32 # amiconn: Could you change line 160 in apps/codecs/cook.c to : ci->set_elapsed((rmctx.frame_number-2)*(1000*8*sps/rmctx.bit_rate)); and try again ? 20.58.33 # what targets have a built-in speak for keyclicks? 20.58.39 # *speaker 21.00.20 # JdGordon|: do you have an idea why the list in the playlist viewer is so slow? 21.00.53 # I wonder how to drive the piezo speaker in the meizu, should i just put a DC voltage on it to produce a click? or maybe some kind of square wave? should I try to drive it at its resonant frequency? 21.01.19 # gevaerts: raw audio file, I think sox converts waves to raw audio files. then I use bin2c and start coding? 21.01.21 # unfortunately it's not connected to a timer PWM output 21.01.28 # graey: yes 21.01.49 # ok, thanks! 21.03.19 # mt: The flags are obviously read correctly (mostly 0 and sometimes 2), but the timestamp is jumping erratically 21.03.39 # This is in rm.c: rm_get_packet() 21.05.22 # kugel: slow how? 21.05.29 # amiconn: I see, thanks a lot. Is this also with the last modification in cook.c ? 21.05.42 # I didn't try that 21.05.51 # * amiconn has a suspicion 21.06.02 # JdGordon|: scrolling it is noticeably slower than a normal list (possibly only really noticeably with a scrollwheel) 21.06.25 # just had a quick look on the clip and it seems fine 21.06.44 # amiconn: of what ? 21.06.45 Quit martian67 (Connection timed out) 21.08.30 # i haven't actually noticed it before i used the fuze 21.08.44 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 21.09.53 # mt: I found the bug. It was indeed an endianess problem, in rm.c 21.10.06 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 21.10.41 # get_uint16be() and get_uint32be() are inherently endian agnostic due to the way they work. But there are two versions - the one used for big endian was broken 21.11.37 # * mt slaps forehead :/ 21.11.48 # * linuxstb slaps mt ;) 21.12.01 # mt: I'll commit the fix in a few minutes 21.12.17 # Don't we have those functions in a central place? 21.12.22 # amiconn: Thanks a lot ! 21.12.39 # linuxstb: They are a bit different iirc .. I'll check. 21.12.47 # beware of forehead 21.13.05 # * linuxstb just remembers implementing them 100s of times... 21.13.22 # On coldfire we could in fact use an optimisation. Since coldfire is able to do unaligned accesses, we could simply cast pointers and read 16 or 32 bits at once. The fact that RM is obviously big endian helps here 21.14.12 # mt: are you interested in further optimization for cook? 21.14.22 # i have some ideas 21.14.45 # although i understand if you have other priorities 21.17.24 # saratoga: If it's more important than implementing aac-in-rm for now then I have no problem. 21.17.44 # New commit by 03dave (r21845): Add some Makefile rules to demonstrate assembling, linking, converting to binary file and finally converting to a notes .htm file. 21.17.54 # mt: both are worth having, I would work on whatever is most interesting to you first 21.19.09 # New commit by 03amiconn (r21846): Fix cook on big endian targets. get_uint*be() is already endian agnostic due to reading ... 21.19.53 # linuxstb: alac also defines those functions. 21.20.49 # saratoga: Optimising cook would probably take less time than adding support for aac, right ? 21.21.31 # Can't we have multiline commit messages here ? 21.23.23 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 21.24.12 # Zagor: there's a slight bug in the build script : if it kills some gcc processes, the gcc tempfiles stay. Probably best solved by using our own $TMPDIR 21.24.50 # mt: yes I think it would be fairly easy, I'll probably have a go at it one of these days once I have some more tiem 21.25.01 # Also, I think the scores are unbalanced : bootloaders are seriously overvalued. I'm now generating a set of new and improved scores 21.25.08 # gevaerts: we should probably use normal kill instead of -9, to allow cleanup code to run 21.25.19 # excellent 21.25.24 # kill and then kill -2 if it's still running 21.25.30 # saratoga: Let's work on that first then. 21.26.17 # Unable to get setup-2.ini from 21.26.37 # * linuxstb would prefer to see more codecs - optimisation can be done by anyone at any time, but few people will add a completely new codec... 21.27.43 Quit timc (Remote closed the connection) 21.28.19 # Zagor: I'm measuring total used CPU time (using /usr/bin/time) for non-ccache builds. If those aren't good enough, nothing is 21.29.08 # gevaerts: sounds good. feel free to add the new values to the builds file when you are done 21.29.10 # linuxstb: Isn't aac already supported? (i.e, it's not completely new ;) ) 21.29.21 # OK. Give me a few hours :) 21.29.26 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 21.29.32 Join tomcat_ha [0] (n=aksit@82-148-214-99.fiber.unet.nl) 21.30.45 # mt: True... ATRAC then! ;) 21.31.10 # mt, linuxstb: Using the suggested get_uint*be() optimisation works. Coldfire cook.codec becomes 60 bytes smaller. No measurable speedup (probably because these functions aren't used often) 21.31.30 # AAC in rm would be nice, our current AAC in MP4 support is buggy due to bad parser 21.31.34 Quit advcomp2019 (Nick collision from services.) 21.31.36 # so the rm version wouldn't be redudant 21.31.41 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 21.31.42 # and of course aac in rm isn't entirely uncommon 21.32.41 # saratoga: that sounds like a call for separate "codecs" for the containers. :) 21.33.42 # linuxstb: Do you think such a change is worth being committed? It's an additional #ifdef with little effect... 21.34.39 # * mt still wishes we could have multi-line CIA commit messages. 21.34.58 # Unhelpful: i think the plan is to just link the codec more then once: aac-in-mp4.codec, aac-in-rm.codec, etc 21.35.25 # mt: they're still multiline on the website and in svn, so its not a big loss i think 21.35.38 Quit FOAD ("I'll be back") 21.35.43 # saratoga: that at *least* suggests we want to have a somewhat standard interface between codec and container handler 21.35.51 # amiconn: I've no real view either way. As you say, it's an additional #ifdef (bad), for a tiny improvement... 21.35.54 # saratoga: Still, it would be nice. :) 21.36.23 # mt: Not when someone commits a 20-line message... 21.36.37 # Ah, good point. 21.36.44 # A url would be nice though... 21.37.11 # * gevaerts does get a URL, thanks to some magic :) 21.37.13 # a 20-line message in the logs would be fine i think, they're so rare 21.37.21 # question: how can i do whats described in the last post of this thread: http://forums.rockbox.org/index.php?topic=20960.15 ? 21.37.35 # do i need to edit the bootloader? 21.38.18 # tomcat_ha: You need to edit the Rockbox source code (text files), and then compile a bootloader (and Rockbox itself) from that modified source code. 21.38.38 Join FOAD [0] (n=dok@dinah.blub.net) 21.38.54 # linuxstb: my ruby script appends the url :) 21.39.27 # although it would be nice if it came from the bot in the first place indeed 21.40.13 # where can i find the source code? 21.40.14 # saratoga: What about working on both the optimisation and the new codec in parallel, with main focus being on the new codec ? 21.40.58 # tomcat_ha: Start here - http://www.rockbox.org/twiki/bin/view/Main/DocsIndex#For_Developers - specifically the "HowToCompile" or "SimpleGuideToCompiling" pages. 21.41.06 # ty 21.41.57 # we have a tag for the wps for when the volume is being changed yeah? 21.42.07 # mt: that sounds fine 21.42.14 # JdGordon|: Weren't you the one who added it? 21.42.24 # cant remember 21.42.46 # I want to change the clips cabbie to show the volume as a number when its changing in the wps... any objections? 21.42.54 # mt: which new codec? Are you going to add AC3 support? 21.43.07 # (as a real audio codec I mean) 21.43.13 # regarding optimization, the two fixed point mulitply functions in cook_fixpoint.h look ugly to me 21.43.22 # JdGordon|: We don't do that on any other cabbie, do we? 21.43.28 # It really shouldn't behave uniquely. 21.43.34 # and the call to av_clip in output_math isn't needed since rockbox can take 32 bit output from the codec 21.43.43 # no, but because on the clip its so small it would be a great addition 21.43.51 # markun: No, aac since it's the next most common codec after cook. (according to the ffmpeg devs) 21.43.53 # JdGordon|: I don't understand what its size has to do with it. 21.43.53 Join timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) 21.44.05 # oh stop being difficult :) 21.44.08 # There's no numeric volume indicator in the WPS on the Gigabeat and that's the largest screen we've got. 21.44.12 # Llorean: I don't think we should try and make Cabbie look exactly the same on every target if the targets are fairly different 21.44.14 # Well, largest supported. 21.44.20 # saratoga: It's an issue of behaviour, not looks. 21.44.25 # mt: I only have cook and ac3 files 21.44.37 # IMO cabbie should look good and be functional on all targets, but maybe not the same on each 21.44.41 # but that can come laer 21.44.42 # later 21.44.47 # the difference is the size of the bar thing is so small its hard to tell if its moved much or at all 21.44.49 # saratoga: If we want it to show numeric volume when volume is changing, there's no reason not to do it on all targets. And no reason *to* do it on the clip if we're not doing it elsewhere. 21.44.52 # actually I always wanted cabbie on the ipods to have a different color scheme then on black targets . . . 21.45.02 # JdGordon: I have no objection to it displaying numeric values when changing on all targets :) 21.45.21 # saratoga: What do you mean by "black targets"? ipods come in black... 21.45.23 # saratoga: This isn't an optimizing it to a specific target issue though. 21.45.38 # markun: Are the ac3 files old ? 21.45.38 # do we support any black ipods? 21.45.44 # AlexP: Agreed, I like seeing numeric values. I just think it'd be rather wrong to just change it on the clip 21.45.47 # saratoga: Nano, 5g, 5.5g 21.45.52 # * JdGordon| changes his suggestion to showing the number on any targets that people can be bothered fixing... 21.45.57 # ah ok 21.45.58 # saratoga: One of the first iPods to hear music in Rockbox was black. 21.46.05 # that'd be hard to detect at runtime 21.46.06 # mt: yes, quite old 21.46.12 # saratoga: Actually, no. 21.46.21 # saratoga: If the OF is there, at least, you can find out from its data what color the iPod is. 21.46.37 # the OF reports it in the inquiry to iTunes, so it must know somewhere 21.46.50 # Ah yes, so itunes can show the correct icon ;) 21.47.02 # * Llorean thinks it'd actually be rather interesting to have Cabbie default to matching the iPod's color, with two versions available to switch between manually later. 21.47.38 # markun: That's why then. Recently it's been rarely used as a codec in rm. (again, according to ffmpeg devs :) ) 21.47.53 # neat idea 21.48.00 Join thegraey [0] (n=geertvan@cc412026-a.zwoll1.ov.home.nl) 21.48.07 # mt: BTW, did you ever get a copy of "realproducer" so you can create your own test files? 21.48.22 # changing cabbie subtlely on different targets to make it blend in with the hardware more has been on my TODO list for ages but I never got around to it 21.48.36 # linuxstb: Yes. 21.50.05 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.50.36 # just got back at my dev machine. is there any documentation on what keymaps apply to what devices? 21.50.38 # One thing I find slightly weird is that in the default theme cabbiev2 the icons are on the bottom, while they are on top in the main menu 21.50.47 # the manual says i have to type in ../tools/configure in my new made folder to see all possible devices 21.50.59 # bertrik: you mean the statusbar? 21.51.01 # however my terminal says it cant find those folders 21.51.19 # yes 21.51.29 # it can be put on the bottom now 21.51.38 # takes a bit of getting used to though 21.53.16 # linuxstb, saratoga: Since aac has already been ported, should it go through the same stages cook went through ? more specifically is a standalone test program for aac-in-rm needed at first ? 21.54.00 # mt: That's up to you - the standalone test programs are just to help you develop it. 21.54.27 # JdGordon|: I already use it at the bottom for cabbie since it's committed 21.54.38 Join mortti [0] (i=mortti@beer.modeemi.cs.tut.fi) 21.55.25 # oh 21.55.26 # mt: do you know how AAC is stored in RM? if its pretty simple to decoder I think a stand alone test program might be unneeded 21.55.40 # simpleguidetocompiling is made with windows users in mind? 21.55.42 # "pretty simple to decode" 21.55.48 # i am running ubuntu here atm :B 21.56.03 # do we have audible keyclicks for any rockbox targets yet? 21.56.18 # tomcat_ha: NOTE: This guide is for Windows users only! Linux users can read LinuxSimpleGuideToCompiling. 21.56.47 # im smart am i not 8) 21.56.53 # but the steps should be the same aside from the parts about setting up cgywin/vmware so it probably doesn't matter 21.57.06 # bertrik: There is the button click on (some?) ipods, but I seem to remember it causing issues at some point 21.57.20 # Did that use the ipod piezo? 21.57.38 # there is a very old patch for the piezo which never got in 21.57.42 # saratoga: Yes I know, that's why I asked. :) 21.59.07 Join petur [50] (n=petur@rockbox/developer/petur) 21.59.09 Quit LambdaCalculus37 () 21.59.52 # is there a function to check if an array contains a value or should I just loop through it? 22.00.16 # depends. If it's sorted, there's bsearch() 22.00.21 # (or there should be) 22.00.40 Join Ubuntuxer [0] (n=johannes@dslb-094-221-091-125.pools.arcor-ip.net) 22.02.49 # thegraey: Also, what kind of array? 22.03.59 # array of ints 22.04.01 # mt: If you try and write a standalone program, you'll also need to make Rockbox's aac decoder compile standalone... 22.04.46 # AlexP, JdGordon I'll see if I can find that patch 22.06.28 # linuxstb: don't we have that patch that compiles any codec stand alone now? 22.06.50 # saratoga: I'm not sure if it's any codec, but yes, that should help. 22.07.17 # also have you looked at Yoshihisa Uchida's recent storm of codec patches? 22.07.31 # linuxstb: would you be able to give FS#10436 a quick sanity check if you have a few moments? 22.07.51 # * linuxstb heads off to flyspray... 22.08.43 # saratoga: Not yet, I'll have a look now... 22.08.56 # i think hes nearly doubled the number of formats we can play, provided you put them in .WAV or .AIFF 22.09.05 # obo: Yet another ARM variant? :( rockboxdev.sh will never finish... 22.09.21 # I'm afraid so... 22.10.43 # Is the View's keypad also different to all the others? 22.11.05 # linuxstb: I think thats the same arm core as the beast, sans some of the addons . . . 22.11.41 # linuxstb: I think it's pretty much the same as an e200, but I don't actually have one of those... I'll check the e200 manual 22.12.05 # obo: You would save a lot of work if you could pretend to have the e200 keypad... 22.12.27 # There are also images in uisimulator/sdl/ 22.12.48 # yeah wikipedia says its the same core as the imx31 except with added DRM hardware, so they should be able to use the same arm compiler i think 22.13.37 # linuxstb: it's different. the view has a combined power/hold button on the side, a home button, and 4-way clickwheel. 22.13.39 # That could save people needing to re-run rockboxdev.sh... 22.14.11 # So this nvidia is a massively souped-up PortalPlayer? 22.15.33 # I'm not sure how massive the increase is... 22.15.56 # Well, it seems at least to be armv6 compared to armv4... 22.16.39 # yes. I may not have changed enough defines to handle that yet. 22.16.41 # But yes, it looks like you could simply use the gigabeat S's compiler. 22.16.54 # but the S has the floating point unit? 22.17.22 # so does the View apparently 22.17.43 # it's a jz not a jfz? 22.18.41 # both have vfp 22.18.49 # i don't know which it is though 22.18.56 # Although what does the "KZ" mean in "ARMv6KZ" ? 22.19.39 # K is "a few extra bits" 22.19.46 # oh perhaps not 22.19.52 # everything except ARM1136 is v6K 22.20.03 # things liek CLREX and other useful bits that they totally forgot in arm1136 22.20.09 # the Z is TrustZone 22.20.14 # "The only functional difference between the ARM1176JZ-S and ARM1176JZF-S processor is that the ARM1176JZF-S processor includes a Vector Floating-Point (VFP) coprocessor." 22.20.28 # Torne: Ah, so that would mean that there are extra instructions on the 1176 vs the 1136? 22.20.31 # yes 22.20.35 # only a few though 22.20.42 # the 1136 is a dud 22.21.08 # so it doesn't have vfp afterall 22.21.11 Quit Ubuntuxer ("Leaving.") 22.21.50 # if you can run code on it, just check 22.22.06 # turn on cp10 and cp11 in CAR and read FPSID 22.22.12 # if you die with an undef abort then it doesn't :) 22.23.23 # we don't actually emit vfp ops anyway on the beast, correct? 22.23.49 # no idea 22.24.15 # New commit by 03gevaerts (r21847): Replace scores by more carefully calculated ones. Now the user+system CPU time (as reported by /usr/bin/time) on an Intel L5410 are used, as opposed ... 22.25.16 # obo: The other "unsupported" targets don't have that echo in configure do they? 22.25.23 # (it's a nice idea though...) 22.25.31 Quit bertrik (Read error: 54 (Connection reset by peer)) 22.25.36 # linuxstb: the Clipv2 does 22.25.44 # Zagor: the heaviest build now has score 26825. Maybe 30000 is a good value for the slow client cutoff now? 22.26.12 # obo: You forgot to change "e200" in your config-view.h file 22.26.22 # That's about 47 times heavier than the lightest build 22.26.23 # oops :) 22.27.17 Quit mt (Remote closed the connection) 22.27.39 # obo: But it looks fine to me (including the change to the multilibs patch - it seems it needs a new gcc) 22.28.11 # gevaerts: thats too high... that means it could still try doing a single massive build 22.28.25 # got a listing of all the builds and their scores? 22.28.42 # linuxstb: I've updated the config file locally. Thanks for the review. 22.28.51 # Not yet. But I think the beast does have vfp, as it's an ARM1136JF-S 22.29.02 # JdGordon|: no. Lower than the cutoff and it will get bootloaders preferably 22.29.36 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 22.30.33 # so the cutoff needs to be higher than the heaviest build 22.30.44 # saratoga: Hmm, looking at FS#10422, Uchida's actively removed comments saying what codecs are supported... 22.31.07 # Zagor: could you copy the multilibs patch from FS#10436 to www.rockbox.org/gcc please? 22.31.51 # JdGordon|: http://svn.rockbox.org/viewvc.cgi/www/buildserver/builds 22.32.03 Join matsl [0] (n=matsl@host-90-233-209-189.mobileonline.telia.com) 22.32.52 # saratoga: Hmm, it looks nice on first glance... 22.33.25 # * JdGordon| is getting confused 22.33.30 # * linuxstb is now confused by the subsequent patches... 22.34.34 # gevaerts: I diN't understand the logic 22.34.38 # don't* 22.35.15 Quit bertrik (Read error: 104 (Connection reset by peer)) 22.35.16 # any specific bit? 22.35.22 # the heaviest build is 27K. And slow clients are those with <30K. Doesn't that mean slow clients are qualified for the heaviest build? 22.35.42 # obo: does it replace a file or is it a new one? 22.35.56 # Zagor: it's new 22.36.18 # I thought maybe 2x the heaviest bootloader would be a good cutoff 22.36.19 Quit matsl (Remote closed the connection) 22.36.24 # kugel: all clients are qualified for all builds. What "slow" means is you start of with light builds and get heavier builds as the round progresses instead of starting of with heavy builds 22.36.43 # 2x the heaviest bootloader would mean we get no slow clients 22.36.58 # why? 22.37.09 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 22.37.24 # if a client can only manage bootloaders, it will never have an avarage score of 2x the heaviest bootloader 22.37.25 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 22.37.53 # kugel: yes it will. average score is _per round_, not per target 22.38.13 # gcc says we need to build for the "softfp" float ABI for VFP support - the "hard" float ABI is not supported on it 22.38.27 # I thought the score is "avarage of the sum of the build-scores" 22.38.43 # obo: can you suggest a name for it? specifically how does it differ from "rockbox-multilibs-arm-elf-gcc-4.0.3.diff"? 22.38.53 # Unhelpful: On eabi? That's at least how I understand it 22.38.56 # kugel: it is. The sum of the build-scores is the round-score 22.39.03 # Old abi doesn't seem to support vfp at all 22.39.16 # Zagor: the current file has a _2 suffix, this one has a _3? 22.39.35 # amiconn: the gcc manual says that for the -mfloat-abi option without any mention of EABI. 22.39.44 # obo: ok 22.39.50 # Wasn't there talk about putting that patch in svn, and changing rockboxdev.sh to get it via viewvc? 22.39.58 # obo: done 22.40.03 # Zagor: thanks 22.40.07 # Although I guess it updates rarely, so.... 22.40.17 # gevaerts: I mean the client score 22.40.34 # linuxstb: or simply just have the patches in a subdir for rockboxdev.sh... 22.40.34 # kugel: yes 22.40.41 # Unhelpful: Well, as I understand it, old abi would support soft float (subroutines) and hard float using hardcoded fpa instructions, but not vfp 22.40.56 # B4gder: D'oh... Of course, rockboxdev.sh lives in a SVN checkout... 22.41.05 # gevaerts: and if we avarage this over the number of builds done? 22.41.07 # And eabi *should* use vfp if it's compiled as soft-float 22.41.17 # kugel: the server keeps the score each client manages for each round. then the average score per round is used to see if it is a fast or a slow client. 22.41.23 # basically there's a different calling convention for floats with the soft float-abi. softfp == "use soft float calling convention, but allow hardware fp instructions" 22.41.31 # kugel: then you get the average build weight, unrelated to client performance 22.42.01 # Zagor: is it the total average, or the average of say the last 15 rounds that client participated in? 22.42.21 # gevaerts: currently it is the total average 22.42.21 Quit pixelma (Nick collision from services.) 22.42.22 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 22.42.39 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 22.42.46 # B4gder: Are you #rockbox-gsoc? 22.42.49 # Zagor: maybe clear the numbers when you get the new score values in service? 22.42.51 # Zagor: And if a client did no builds for that round, it gets 0? 22.42.57 # gevaerts: yes 22.43.01 # AlexP: yes 22.43.06 # gevaerts: ah yes, it won't work then 22.43.18 # AlexP: which means it is more likely to get easy builds the next round 22.43.26 # yep 22.43.34 Quit amiconn (Nick collision from services.) 22.43.37 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 22.43.56 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 22.44.09 # amiconn: i also did get a working toolchain for long-call stubs without EABI. oddly that still breaks one or two things, somehow, like vorbis. 22.44.32 # Zagor: I guess a total average is OK, as long as people pick new names if they switch to different hardware, or if they ping you about it 22.45.20 # Unhelpful: I thought ogg has many assembly, it probably breaks there 22.45.51 # kugel: this was without the struct changes, though - basically gcc 4.0.3 and the relocation changes. 22.47.23 # Unhelpful: can't it still break there? codecs have a mix-up of IRAM and DRAM stuff, I'm thinking only the long-call stuff might affect it already 22.48.22 Join BdN3504 [0] (n=5ce22528@gateway/web/cgi-irc/labb.contactor.se/x-dbe5e15ff6b8158b) 22.48.22 # kugel: i don't really see how... the long-call stuff amounts to it emitting short-call instructions everywhere, and if it finds one of them out of range at link time, it generates a one-instruction stub that jumps to the proper address. 22.48.37 # there's no calling convention or structure packing change involved. 22.48.54 # which codecs fail? just vorbis or others too? 22.49.27 # saratoga: vorbis was all that i found. it silently skipped tracks. 22.49.52 # full eabi breaks more things in a rather more dramatic fashion, but that's not surprising. 22.49.59 # Unhelpful: undef arm for that codec and see if it starts working 22.50.11 # so that it reverts to plain c code 22.50.12 # We definitely need a ring-like album list in PF 22.50.19 # hey, i just got myself a 16 gb microsd card for my sansa and must say this is really awessome. Is the sansa going to work with any card you throw at it, or has anyone encountered some incompatibilities over time? 22.50.21 # Unhelpful: Why are there two different relocation types, btw? 22.50.24 # i.e. going from the beginning to the end 22.51.28 # i thought to maybe set up a wiki page like the one for the support cf cards for modded players. but if you guys tell me that the sansa will accept any card, then that page would be obsolete. 22.51.50 # Unhelpful: would it be hard to do? 22.51.56 # BdN3504: It should be fine 22.52.12 # to set up a wiki page? 22.52.31 # amiconn: i'm not really completely sure, i believe the eabi objects have relocation types that specify exactly what is done with the address reference, while the pre-eabi R_ARM_PC24 reloc can represent several things, so that the linker needs to decode the instruction to figure out what happens 22.52.33 # i don't think anyone has ever found a card that it didn't work with 22.52.40 # OMG. We should delete the users ML. 22.52.44 # ok 22.52.45 # tthanks 22.52.57 Quit BdN3504 (Client Quit) 22.53.14 Join BdN3504 [0] (n=5ce22528@gateway/web/cgi-irc/labb.contactor.se/x-ac821baa185c7b26) 22.53.15 # PS: 22.53.26 # Unhelpful: did you wipe the entire build dir? I was having problems with not doing that 22.53.32 # hooray for rockbox! 22.53.36 # BdN3504: No, I meant all cards should be fine 22.53.37 Quit BdN3504 (Client Quit) 22.53.55 Join ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) 22.53.57 # I.e. my code was perfectly fine, but codecs didn't work because I didn't think of rm -rf'ing the build dir 22.54.06 # i'll try again, but i can't this very moment :) 22.54.07 # (some sort of linker problem, I don't know) 22.54.28 # bluebrother: haha yes we should.. what is it this time though? 22.54.41 Quit bubsy (Read error: 60 (Operation timed out)) 22.54.46 # Don't, they'll come on the -dev list then 22.54.51 # JdGordon|: The same as always... 22.54.52 # JdGordon|: same as last time. Someone revived it 22.55.06 Quit B4gder ("It is time to say moo") 22.55.22 # JdGordon|: yet another top-posting thread. And even in a completely unrelated thread. 22.55.23 # what the FUCK!? 22.56.02 # close it temporarily is enough 22.56.04 # I get the impression that users simply aren't worth something like Rockbox and our support channels :/ 22.56.42 # and those users whining about an etiquette won't come back? 22.57.04 # well... we could just abandon the ml and leave it to rot... closing it would mean more of them in here and the forums 22.57.12 *** Saving seen data "./dancer.seen" 22.57.16 # JdGordon|: That pretty much happens anyway 22.57.25 # well, I've left the list quite a while ago for exactly that reason 22.57.40 # Hands up how many people ever read it except for when someone points out a stupid thread? 22.58.02 # linuxstb: on further digging the keypad seems to be the same as the sansa fuze, so I'll change the CONFIG_KEYPAD to match 22.58.06 # I need to take a weekend and read the whole thread, lol'ing all the time 22.58.07 # I looked at it once, and decided I'd rather do many many many unpleasant things than join it 22.58.21 # * gevaerts thinks that we should send an announcement on the user ML stating that the list will be closed on the next top posting or netiquette rules complaint, and then actually follow up on that 22.58.22 # obo: Congratulations! ;) 22.58.31 # AlexP: I only read it when someone points to a stupid thread :p 22.58.57 # i've said before that i think the mailing lists are an absolute mess 22.59.44 # they are. Unfortunately. But the users ML is the worst, -dev is bearable 22.59.51 # I reckon its all Llorean's fault for letting the rabble get away with blue bloody murder! thats what happens when you dont lay down the law occasionally! 22.59.58 # committers is lovely :D 23.00.19 # SSSSHHH!H!! 23.00.36 # i do like committers 23.00.54 # what are the arguments in favor the users list exactly? seems like those people should really just be on the forums 23.01.07 # saratoga: You git, don't send them there! 23.01.28 # * amiconn still prefers the ml over the forums by far, regardless of top posting 23.01.30 # AlexP: on the forums, deleting posts is easy :) 23.01.37 # gevaerts: true :) 23.01.39 # I mean theres the equivilent of maybe 5-10 real threads a month in the mailing list, and half are just arguing about nothing 23.01.47 # * JdGordon| wonders why AlexP is calling saratoga a version control system? 23.02.14 # * bluebrother still likes MLs too but only if they are useable 23.02.15 # I mean on the users list that is, the dev list is nice for annoucements 23.03.14 # we have our fair share of arguments ont eh dev ml also 23.03.19 # kugel: i'm rebuilding a fresh long-call-stubs-only toolchain, and will try a completely fresh build, but if that works where make clean doesn't i'm inclined to think we do something wrong 23.03.44 # true, but the users list is worse, especially when it comes to ignorants 23.04.02 # Unhelpful: I don't know what wrong, but sometimes make clean just isn't enough 23.04.36 # I like to think many of the arguments on the dev list are ultimately productive in that they lead to some sort of agreement on how things ought to be 23.04.44 # though to be honest I rarely read them 23.05.52 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 23.05.53 # often threads also are discussed so endlessly so that minor things lead to people getting tired and no agreement being reached 23.06.25 # Regularly that are the ones I start ;) 23.06.29 # kugel: That may e.g. happen if source files get renamed and their related objects are located in the build root 23.06.45 # i usually read them if i care about the subject or if they are < 20 mails 23.07.13 # Sinec 'make' clean' only cleans objects an earlier 'make' created, they will stay there. And depending on the order the linker picks up objects, and outdated object may get linked 23.07.57 # Similar things happen if an arbitrary source file gets renamed (or a different source file gets used for a target, e.g. an asm version) and you don't 'make clean' 23.08.05 # amiconn: but that's the sort of thing that could happen over time *without* toolchain changes, and *can't* happen because of toolchain changes alon. 23.08.41 # This often leads to both objects residing in an .a, and the linker usually picks the first one it finds, which is the old one 23.09.43 # New commit by 03robert (r21848): FS#10436 - add the Sansa View to the build system. The bootloader builds but doesn't do anything useful yet. 23.10.18 # On cygwin I often tried to delete only the affected subdir in the build dir, because a full rebuild is so slow. On linux with ccache enabled this is much less of an issue 23.11.43 # Unhelpful: Right, but 'make clean' is mandatory when switching toolchains 23.12.19 # also in this case it would lead to link failure - gnu ld will not link objects of different eabi versions. this is why you can't just try adding -Wa,meabi=4, unless you manage to completely avoid any use of toolchain libraries 23.13.01 # libgcc must be built with -meabi=4 passed to gas, and then your other binaries likewise, for them to correctly link with stub generation 23.13.03 Quit dash32 (Read error: 110 (Connection timed out)) 23.13.14 # mt: what is the meaning of samples per channel? is it derivived from the imdct block size? 23.13.27 # and obviously letting such objects meet "true" eabi objects is a very very bad idea 23.13.34 Join dash32 [0] (n=dash32@p54AB5527.dip.t-dialin.net) 23.15.41 # hmm, with the View and PP6100 in the target tree, could we eventually get around fixing the mess there? 23.16.06 # ls 23.17.23 # i've not found any struct-passing-to-asm in libmad yet 23.17.38 Quit _zic (Read error: 101 (Network is unreachable)) 23.17.53 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.18.11 # kugel: Which mess in particular? And who is "we" ? ;) 23.18.15 # it may be that the *only* breakage in mp3 was that of using gcc-4.3.3 23.18.38 # linuxstb: We is MrSomeone :P And I mean the manufacturer vs soc mess 23.18.43 Quit martian67 (SendQ exceeded) 23.19.29 # kugel: Yes, he should. 23.19.37 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.21.52 # * JdGordon| volanteers kugel for the job 23.22.05 # Mr Someone is pretty useless for getting things actually done 23.23.52 # well, I thought about it 23.24.14 # but the problem is to decide which subdir structure PP needs 23.24.17 # question I have an Ipod 5.5 with a build from about a month ago that the settings get reset on relatively ofter, what would be the best way to troubleshoot this 23.24.34 # s/ofter/often 23.24.53 # a generic PP will need a dir extra which our target tree doesn't handle, PPXXXX in arm/ will lead to many PP-files in arm/ still 23.25.32 # I should mention I use it with an FM transmitter via the recently implemented iap 23.26.31 Join __lifeless [0] (n=lifeless@188.16.125.117) 23.27.44 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 23.28.37 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 23.29.17 Quit advcomp2019 (Nick collision from services.) 23.29.18 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 23.29.41 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.30.34 Quit martian67 (SendQ exceeded) 23.30.40 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 23.31.17 # hm, simply changing the DC level on the meizu m3 piezo when keys are pressed or when sliding over the touch strip is hardly audible 23.31.19 Join dmb [0] (n=Dmb@unaffiliated/dmb) 23.32.25 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 23.34.17 # Zagor: Setting LC_ALL=C when building seems like it'd be rather useful 23.34.27 # rasher: yes, I'll add that 23.34.49 Quit n1s ("Lämnar") 23.35.44 Join bubsy [0] (i=Bubsy@94.139.72.137) 23.37.25 # bertrik: you need to apply a tone to a PZ 23.40.02 Quit evilnick ("Page closed") 23.42.08 Quit _lifeless (Read error: 110 (Connection timed out)) 23.42.14 Quit itcheg (Ping timeout: 180 seconds) 23.44.15 Quit stripwax ("http://miranda-im.org") 23.44.35 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.45.40 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.46.23 Quit thegraey () 23.46.23 Quit TheSeven (Read error: 54 (Connection reset by peer)) 23.46.50 Join TheSeven|Zzz [0] (n=theseven@dslb-084-056-129-005.pools.arcor-ip.net) 23.46.53 Nick TheSeven|Zzz is now known as TheSeven (n=theseven@dslb-084-056-129-005.pools.arcor-ip.net) 23.48.39 Quit Horscht (Read error: 110 (Connection timed out)) 23.50.28 # New commit by 03kugel (r21849): Try to make configure respect the TMPDIR environment variable. 23.50.50 # I don't think it will help :( 23.53.53 # why is the new build system not running? 23.54.02 # it is 23.54.11 # Build: build mrobe100sim rev 21849 client kugel-x-kugel 23.54.31 # ah, I was tricked 23.54.45 # there's still no progressbar/indicator on new.cgi 23.54.50 # no 23.55.10 # looking for my client takes a few keystrokes so I didn't bother :( 23.55.11 # saratoga, I think the OF doesn't use a tone, I hear just a click (maybe a very short tone) 23.55.48 # bertrik: if you just change a voltage, you're sending it one cycle of a square wave, which means you get just a very little bit of sound out 23.55.54 # I'l try driving it with opposite polarity for the two piezo outputs 23.56.01 # maybe they turn it on and off a couple times in a row? 23.56.39 # indeed, it didn't help 23.57.38 # the clips batt hasnt been calibrated yet has it? 23.57.48 # 29h remainig with 42%? 23.58.12 # hours remaining is not related to calibration 23.58.54 # the calibration just maps voltage to percent charge, not to absolute hours remaining