--- Log for 20.11.110 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 17 hours ago 00.03.31 Quit ender` (Quit: A computer program will always do what you tell it to, and seldom what you want it to.) 00.06.50 # grml, I can't use apache v2 code in rockbox (?) 00.07.41 Quit LambdaCalculus37 (Quit: Fwump) 00.08.20 # google says its GPLv3, not v2, so you probably shouldn't 00.10.25 Quit user890104 (Read error: Connection reset by peer) 00.10.33 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 00.10.56 Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) 00.10.57 # this is xml, I can't just re-implement it without ending up with the exact same (besides indentation maybe) 00.11.16 Quit freddyb (Client Quit) 00.13.53 # assuming you re-implement it without copying from the old to the new you're ok 00.14.25 # so i guess make a note of the fields and then construct an XML file to store them using your knowledge of XML file structure 00.18.26 Quit Buschel (Ping timeout: 255 seconds) 00.25.44 Join Buschel [0] (~chatzilla@p54B67603.dip.t-dialin.net) 00.27.24 Join user890104_ [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 00.27.57 Quit user890104 (Read error: Connection reset by peer) 00.27.59 Quit user890104_ (Read error: Connection reset by peer) 00.28.06 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 00.30.30 Quit bertrik (Quit: :tiuQ) 00.33.18 # imho it is a good assumption that FS#11627 is a duplicate of FS11608. any objections to close FS#11627? 00.40.27 Quit user890104 (Ping timeout: 272 seconds) 00.44.20 Quit sideral (Quit: Leaving.) 00.49.10 Part toffe82_ 00.51.27 Quit krazykit (Quit: brb locally) 00.51.50 Join krazykit [0] (~kkit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 00.53.21 *** Saving seen data "./dancer.seen" 01.02.19 Quit Buschel (Ping timeout: 240 seconds) 01.02.59 Quit {phoenix} (Remote host closed the connection) 01.16.17 Quit BlakeJohnson86 (Quit: Leaving.) 01.23.17 Quit ReimuHakurei_ (Quit: Leaving) 01.24.15 Join ReimuHakurei [0] (~reimu@74.112.212.15) 01.25.57 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 01.26.23 Quit factor (Ping timeout: 255 seconds) 01.29.35 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 01.31.05 Quit DerPapst (Quit: Leaving.) 01.31.17 Quit Kupop (Ping timeout: 264 seconds) 01.46.31 Quit kugel (Ping timeout: 252 seconds) 01.46.51 Quit S00row (Read error: Connection reset by peer) 01.49.24 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 01.55.09 Join Boldfilter [0] (~Boldfilte@99-120-142-250.lightspeed.jcvlfl.sbcglobal.net) 02.00.59 Quit domonoky1 (Read error: Connection reset by peer) 02.01.09 Quit GeekShadow (Quit: The cake is a lie !) 02.15.20 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 02.20.08 Join Loto_ [0] (~Loto@S01060012171a84e3.no.shawcable.net) 02.22.46 Quit Loto (Ping timeout: 240 seconds) 02.33.48 Quit InsDel (Read error: Connection reset by peer) 02.40.34 Quit xxcv () 02.45.51 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 02.45.52 Quit S00row (Read error: Connection reset by peer) 02.47.19 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 02.53.23 *** Saving seen data "./dancer.seen" 03.22.34 Quit BHSPitMonkey (Read error: Connection reset by peer) 03.33.01 Quit liar (Quit: Leaving) 03.38.24 Quit madalu (Remote host closed the connection) 03.48.14 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 03.54.10 Join anewuser [0] (anewuser@unaffiliated/anewuser) 03.56.14 Join InsDel [0] (~haqr.net@c-98-231-87-43.hsd1.fl.comcast.net) 03.57.56 Quit S00row (Read error: Connection reset by peer) 04.00.31 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 04.03.02 Quit bluebrother (Disconnected by services) 04.03.03 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 04.15.36 Join Barahir [0] (~jonathan@frnk-590f4199.pool.mediaWays.net) 04.19.41 Quit Barahir_ (Ping timeout: 276 seconds) 04.24.07 Quit anewuser (Ping timeout: 240 seconds) 04.34.58 Join anewuser [0] (anewuser@unaffiliated/anewuser) 04.37.00 Quit ReimuHakurei (Quit: Leaving) 04.37.12 Join ReimuHakurei [0] (~reimu@74.112.212.15) 04.46.20 Quit dys (Ping timeout: 276 seconds) 04.46.28 Join dys [0] (~andreas@krlh-5f721792.pool.mediaWays.net) 04.51.32 Quit TheSeven (Ping timeout: 276 seconds) 04.53.27 *** Saving seen data "./dancer.seen" 04.54.29 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.14) 04.54.44 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.54.45 # oh hell i just converted a filter to ASM that isn't actually used 04.57.38 Quit amiconn (Disconnected by services) 04.57.38 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.57.39 Quit pixelma (Disconnected by services) 04.57.41 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.57.43 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.57.58 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.58.11 Quit LambdaCalculus37 (Quit: Zzzzzzz) 05.01.31 Quit S_a_i_n_t (Ping timeout: 240 seconds) 05.34.08 Quit ps-auxw (Ping timeout: 255 seconds) 05.41.20 Quit clone4crw (Ping timeout: 245 seconds) 05.43.32 Join clone4crw [0] (~Calvin@96-42-80-202.dhcp.roch.mn.charter.com) 05.44.07 Quit anewuser (Ping timeout: 240 seconds) 05.45.29 Join ps-auxw [0] (~arneb@p4FF7FF8A.dip.t-dialin.net) 05.45.40 Quit clone4crw (Client Quit) 05.48.28 Join froggyman [0] (~seth@unaffiliated/froggyman) 05.52.45 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 06.07.36 Quit InsDel (Read error: Connection reset by peer) 06.25.07 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 06.25.09 Quit ReimuHakurei_ (Client Quit) 06.53.28 *** Saving seen data "./dancer.seen" 06.57.26 Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 07.01.55 Quit froggyman (Read error: Connection reset by peer) 07.04.04 Join froggyman [0] (~seth@unaffiliated/froggyman) 07.10.52 Join Horschti [0] (~Horschti@xbmc/user/horscht) 07.11.48 Join mordocai [0] (~mordocai@66.119.9.243) 07.14.06 Quit Horscht (Ping timeout: 265 seconds) 07.23.07 # Just dobule checking, but it looks like rockbox does not support iRiver e200's? 07.23.10 # double* 07.25.53 # correct 07.25.58 # i've never even heard of that player 07.27.56 # http://www.iriver.com/product/view.asp?pCode=001&pNo=69 :P. It looks pretty nice to me. Luckily it already plays .ogg, so I wouldn't -have- to use rockbox to get ogg to work. (I assume rockbox makes ogg work?). [I'm looking into what portable music player to buy] 07.29.53 # iriver was making pretty neat players 07.30.30 # Sundiver: Was? 07.30.48 # Well, I meant flash players 07.31.01 # if you guys want to talk about iriver, go over to rockbox-community 07.31.10 # sorry 07.31.39 # I just finished theme for RB for my clip+ 07.32.23 Part mordocai ("Leaving") 07.32.27 # does anyone understand pipeline scheduling on arm11 particularly well? 07.32.32 # i'm confused by their diagrams 07.32.44 # I'm not 07.33.14 # arm has awful datasheet 07.34.57 # BTW, can I just delete unused plugins, themes from my player? 07.36.28 # sure 07.36.59 # Thanks saratoga! 07.46.22 Quit Boldfilter (Quit: Boldfilter) 08.09.33 Quit xavieran (Remote host closed the connection) 08.12.04 Join xavieran [0] (~xavieran@ppp118-209-137-192.lns20.mel6.internode.on.net) 08.13.39 Join stoffel [0] (~quassel@p57B4C0EB.dip.t-dialin.net) 08.14.18 Quit JesusFreak316 (Ping timeout: 245 seconds) 08.39.08 Quit xxcv () 08.53.31 *** Saving seen data "./dancer.seen" 08.54.24 Join Buschel [0] (~chatzilla@p54B67BC7.dip.t-dialin.net) 08.57.44 Quit stoffel (Remote host closed the connection) 08.59.08 Quit Buschel (Ping timeout: 240 seconds) 09.20.43 Quit amiconn (Remote host closed the connection) 09.20.43 Quit pixelma (Remote host closed the connection) 09.25.23 Join amiconn [0] (quassel@rockbox/developer/amiconn) 09.25.26 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 09.25.28 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 09.26.57 Join Rob2223 [0] (~Miranda@p4FFF2E04.dip.t-dialin.net) 09.30.24 Quit Rob2222 (Ping timeout: 276 seconds) 09.30.27 Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) 09.33.29 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.33.29 Quit bertrik (Changing host) 09.33.29 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.51.08 Quit Horschti (Read error: Connection reset by peer) 09.51.30 Join Horscht [0] (~Horschti@p4FD4F242.dip.t-dialin.net) 09.51.30 Quit Horscht (Changing host) 09.51.30 Join Horscht [0] (~Horschti@xbmc/user/horscht) 09.52.08 Quit S00row (Read error: Connection reset by peer) 09.54.23 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 09.59.03 Quit sasquatch (Quit: WeeChat 0.3.2) 09.59.29 Join sasquatch [0] (~username@p4FF2D67F.dip.t-dialin.net) 10.08.32 Join Buschel [0] (~chatzilla@p54A3A669.dip.t-dialin.net) 10.15.37 Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) 10.21.27 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 10.23.22 # are there any thoughts, comments or ideas regarding FS#11753 (alignment definition/usage)? 10.30.20 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.30.42 Quit Buschel (Ping timeout: 276 seconds) 10.30.44 Join TheLemonMan [0] (~lemonboy@ppp-249-212.32-151.iol.it) 10.37.09 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 10.39.19 Join ender` [0] (krneki@foo.eternallybored.org) 10.47.36 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 10.53.34 *** Saving seen data "./dancer.seen" 11.03.54 Quit feisar- (Ping timeout: 250 seconds) 11.05.16 Join {phoenix} [0] (~dirk@p57AA6C2C.dip.t-dialin.net) 11.18.56 Join Gnea [0] (~gnea@unaffiliated/gnea) 11.22.33 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.29.44 Join GeekShadow [0] (~Antoine@44.181.204-77.rev.gaoland.net) 11.29.44 Quit GeekShadow (Changing host) 11.29.44 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.39.02 Part dodddummy ("Leaving") 11.54.19 Join Jaykay [0] (~chatzilla@p5DC57B57.dip.t-dialin.net) 11.55.39 # what is the behavior of "idle poweroff" in rockbox-on-android? does it just stop the service? 12.03.44 Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) 12.29.47 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 12.33.33 Quit dfkt (Ping timeout: 255 seconds) 12.42.03 Quit Keripo (Ping timeout: 240 seconds) 12.45.33 Join Keripo [0] (~Keripo@eng239.wireless-resnet.upenn.edu) 12.53.35 *** Saving seen data "./dancer.seen" 12.57.28 Quit Gnea (Ping timeout: 245 seconds) 13.03.05 Join DerPapst [0] (~Alexander@p4FE8F803.dip.t-dialin.net) 13.10.31 Join stoffel [0] (~quassel@p57B4C5E1.dip.t-dialin.net) 13.14.06 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) 13.16.19 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 13.18.32 Quit mystica555_ (Ping timeout: 272 seconds) 13.26.32 Quit stoffel (Remote host closed the connection) 13.31.15 Join Gnea [0] (~gnea@unaffiliated/gnea) 13.44.48 Quit xxcv (Ping timeout: 255 seconds) 13.57.33 Join Buschel [0] (~chatzilla@p54A3A1E7.dip.t-dialin.net) 13.58.39 Quit S00row (Read error: Connection reset by peer) 13.59.31 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 14.05.20 Join piggz [0] (~piggz@78.151.53.160) 14.06.54 # lo, i was wondering if there was a sleep mode in rockbox for my ipod video, as i noticed my daughters ipod video lasts a lot longer when not in use, and its faster than power cycling 14.11.43 # n17ikh: idle poweroff doesnt do anything on android (yet) 14.11.56 # piggz: rockbox doesnt sleep the ipod, it turns it off 14.17.39 # JdGordon: shame, sleep would be cool 14.18.11 # not really... it just uses up battery life doing nothing and rockbox boots to playing music in 3s or so anyway 14.23.04 Quit Buschel (Ping timeout: 240 seconds) 14.29.04 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.32.31 Join Topy [0] (~Topy44@f048110248.adsl.alicedsl.de) 14.34.46 Quit GeekShadow (Read error: Connection reset by peer) 14.36.25 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 14.36.29 Join Buschel [0] (~chatzilla@p54A3A1E7.dip.t-dialin.net) 14.36.30 Quit T44 (Ping timeout: 252 seconds) 14.37.53 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.43.36 Quit Buschel (Ping timeout: 255 seconds) 14.53.36 *** Saving seen data "./dancer.seen" 14.57.15 Join hkmix [0] (~8e9dc124@giant.haxx.se) 14.58.24 Quit hkmix (Client Quit) 15.02.06 Join Lear [0] (chatzilla@rockbox/developer/lear) 15.07.10 Join Buschel [0] (~chatzilla@p54A3A1E7.dip.t-dialin.net) 15.17.34 Join feisar- [0] (jljhook@sienikerho.com) 15.39.13 Quit guymann (Quit: BYE!) 16.00.13 Quit teru (Quit: Quit) 16.10.33 Join panni_ [0] (hannes@ip-178-203-101-205.unitymediagroup.de) 16.10.56 Quit S00row (Read error: Connection reset by peer) 16.13.14 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 16.15.52 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 4.0b8pre/20101119031701]) 16.18.06 Join InsDel [0] (~haqr.net@c-98-231-87-43.hsd1.fl.comcast.net) 16.28.16 Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) 16.28.37 Quit freddyb (Client Quit) 16.32.43 # If your daughter's iPod video with the Apple Original Firmware has a longer shelf life than your iPod video with Rockbox something is seriously wrong. 16.35.21 # For, piggz, as JdGordo n said her Video is actually consuming power while sitting on the shelf, and yours is not. In general your iPod should achieve a longer battery life than hers, all things being equal, and if you turn on some of Rockbox's optional power-savings tricks you should be able to smoke her runtime. I am referring to the turning off of the Accessory Power Supply if/when you are not using dock connector accessories and setting the screen it 16.35.21 # self to turn off when the backlight is off. 16.37.09 # soap: i understand that, its just nice that, with the stock firmware, although it is using power while alseep, it lasts for days anyway, and instantly comes on when needed 16.38.41 Join Dreamxtreme [0] (~Dre@92.30.31.119) 16.39.13 # I understand the "responsiveness" point, as it is one of those subtle things which add up, but 3s boot in the grand scheme of things is not really problematic. But more importantly last I saw nobody actually knew how to put the iPod to sleep, much less expressed terrible interest in doing so. :( 16.40.01 # i should probably configure my ipod to turn off when not used, as opposed to me always forgetting and it being constantly flat ;) 16.41.00 # Yes, I have mine set to turn off the screen when backlight is off, and power down after an hour at idle. That is a quite generous idle time and doesn't affect my music playback time significantly. 16.42.00 Join mc2739_ [0] (~mc2739@rockbox/developer/mc2739) 16.42.13 Quit mc2739_ (Client Quit) 16.42.57 # figuring out how to "sleep" the ipod probably comes down to RE'ing the various device inits required to bring devices up again after shutting them down 16.43.36 # power off everyting but the cpu and amybe ram and clock the cpu the lowest possible 16.43.36 # whats the highest bitrate and sample freq that rockbox supports 16.44.14 # Dreamxtreme: rockbox resamples everything that isn't 44.1kHz to 44.1kHz and >16 bps is truncated or dithered to 16bps 16.44.33 # Dreamxtreme, do you mean the highest bitdepth of files, or of hardware playback? 16.44.42 # (as long as we are talking about music playback) 16.44.57 # hardware playback really 16.44.59 # i think 16.45.12 # then it differs from player to player 16.45.18 # i have a DVD of Foo Fighters that ive converted to FLAC 88200 24bit 16.45.40 # bit_rate_ would depend on how fast your storage is. And as n1s mentioned everything is taken brutally to 44.1/16, though some of the target hardware could support higher. 16.45.47 # Th 88200 will work, not sure about the 24bit 16.45.47 # so the bit rate is around 3000kbps 16.46.10 # But I suspect it should play fine on most players 16.46.18 # Not to get off topic, but 88.2 is an odd sample rate from a DVD. 16.46.20 # yes, we support 24 bit flac 16.46.35 # o good 16.46.36 # :D 16.46.39 # and saratoga just mentioned fixing insane samplerates in the forums. 16.46.40 # yes i know 16.46.53 # although there's a bug report about stupidly huge flac files not playing 16.46.57 # If you care at all about battery life, I'd suggest reencoding to 44.1/16 16.47.34 # with a Classic 3G (when its cracked) it shouldnt be a problem 16.53.38 *** Saving seen data "./dancer.seen" 17.04.16 # * kugel has track info in the notification area of android working 17.25.18 Quit TheLemonMan (Quit: Help me, i got shot! *DIES*) 17.28.21 Quit crwl (Ping timeout: 240 seconds) 17.35.47 Join kreislauf [0] (~4e334c0a@giant.haxx.se) 17.37.27 # hi guys. does anybody know, what vorbis decoder rockbox uses? 17.37.41 # i read i review of libvorbis vs. ffvorbis 17.37.48 # regarding battery life 17.39.16 Quit froggyman (Quit: Bye) 17.39.33 # I think it's based on libtremor 17.39.57 # * gevaerts doesn't know much about the codec side of rockbox though 17.40.37 # didn't find any docs 17.40.42 # but thanks 17.41.25 # apps/codecs/libtremor in our sources 17.44.08 # it is based on libtremor, yes 17.44.29 # with quite a bit of our own optimizations by now 17.46.19 # kreislauf: both libvorbis and the ffmpeg vorbis decoders are floating point and would need to be converted to fixed point to be usable in rockbox, also the ffmpeg one requires several MB of memory which makes it a bad fit on rockbox (mostly due to it always allocating worst-case sizes) 17.46.38 Quit S00row (Read error: Connection reset by peer) 17.49.43 Quit avacore (Ping timeout: 265 seconds) 17.50.23 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 17.50.41 Quit InsDel (Read error: Connection reset by peer) 17.51.10 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 18.03.20 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.03.46 # n1s: if you should have any free time left -> could you measure, if there is any difference in decoding speed with introduction of r28561 on your CF target? 18.04.03 # sure 18.04.46 # cool :) 18.04.56 Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) 18.05.44 Join Daeken [0] (~Daeken@cpe-66-108-56-142.nyc.res.rr.com) 18.06.38 # hello all. does anyone happen to be working on ipod nano 6g support? i'm considering getting one to hack on, but i don't want to replicate work if possible. 18.07.18 # Daeken: ask TheSeven 18.07.47 # Daeken: don't think anyone's working on it around here at least, AFAIK noone has found a working exploit for it yet 18.08.24 # ah, fun -- a challenge ;) 18.08.43 # hrm, think i'll walk over to the apple store in a bit and grab one. 18.11.01 # I think you're underestimating the challenge 18.11.39 # bertrik: i've spent the last 5 years reverse-engineering apple products :) 18.12.55 # usually very difficult, always a blast. well worth it 18.14.09 # Buschel: seems to slow down 0.1MHz decoding the 128kbps test file 18.15.29 Quit mc2739 (Quit: leaving) 18.16.06 # hmm, then it would be interesting to introduce target dependent defines... 18.16.54 Quit bmbl (Read error: Connection reset by peer) 18.17.03 # which are set to CACHEALIGN_ATTR for ARM and maybe left empty for Coldfire... 18.17.04 # Daeken: well, good luck with it :) 18.17.09 # (at least for mpc) 18.17.35 # gevaerts: thanks :) 18.18.25 # step one is getting access to a decrypted firmware... then, well, probably a file format vuln. quicktime's file format handling is insanely insecure -- can't be much (if any) better on the nano. 18.18.30 # Buschel: well, the only thing that cares about alignment > the size of the members is movem in dram, the only place in mpc that uses movem is mpc_decoder_windowing_D and i thought that always worked on iram so this is probably just different code layout causing the icache to miss a little more 18.18.32 # Daeken: what products have you previously been working on? 18.18.41 # are you coming from the iphone scene? 18.19.44 # TheSeven: back in 2005, the itunes music store (dunno if you ever heard of pymusique, but it allowed you to purchase drm-free music from itms on linux); in recent-ish history, fairplay DRM a couple years back, and i worked on the dev team up through the initial unlock 18.19.44 Quit kreislauf (Quit: CGI:IRC (EOF)) 18.19.46 # n1s: ok, only movem in dram would benefit on CF? 18.20.29 # Daeken: the problem here is that you probably have to find an exploit blindly, because there is probably no way to get your hands on unencrypted main firmware code. 18.20.31 # TheSeven: i guess it's been a good 2 years since i've worked on anything apple-wise. been working on some odd things, like reversing a consumer EEG 18.20.44 # TheSeven: hmm, interesting. why is that? 18.20.49 # yes, movem in dram does burst acces when alignment is 16bytes nothing else cares about large alignments 18.20.56 # if you're incredibly lucky, there's an unencrypted (only signed) DFU image or bootloader on phobos, the main firmware is certainly encrypted 18.21.37 # and if you have no way to run code on the device, you probably have no way to decrypt that 18.22.08 # it might be worth to try one of those recently found bootrom exploits though 18.22.25 # TheSeven: do you have reason to believe that they're storing keys anywhere other than the flash? e.g. on the app cpu somewhere? 18.22.42 # (i think there were at least two USB control message handling bugs in apple bootloader code recently, which may or may not have been fixed in that SoC) 18.22.56 # from what we know, the nano6g uses an S5L8723 SoC 18.23.19 Join Kitr88 [0] (~Kitarist@109.182.143.0) 18.23.41 # on the previous devices, not even code on the CPU in privileged mode can access the keys, they can only be used by a hardware AES coprocessor 18.24.00 # so you can only use the keys, but not read them out, and only if you can run code on it. 18.24.11 # Buschel: also i don't think 0.1MHz is worth introducing more complexity ;) 18.24.21 # oh nice. they're starting to get this right :) 18.24.24 # also they seem to be using asymmetric cryptography nowadays 18.24.37 # ok, so, are the keys actually /on/ the cpu, or are they stored somewhere in flash that's inaccessible? 18.24.50 # Daeken: the hardware key thingy started with the ipod nano2g and the initial iphone i think 18.25.18 # on the early iphones they were only using encrypted nonces to generate keys they use at runtime, while on the nano2g they used the hardware key directly 18.25.51 # starting with the 3g, they introduced PKI for DFU images, starting with the 4g they seem to be using it for almost everything 18.26.00 # nah, the original iphone barely used the hardware aes accelerator -- at least i know that much on the baseband, not sure on the app cpu (i ran a good bit of baseband code in an emulator while reversing it, and the AES stuff was minimally used) 18.26.12 # hmm, interesting 18.26.22 Quit Kitar|st (Ping timeout: 255 seconds) 18.27.09 # i haven't paid attention to apple's stuff in a few years now, so i have a lot to learn, history-wise. 18.27.24 Quit Kitr88 (Ping timeout: 240 seconds) 18.28.47 # i just saw http://www.kickstarter.com/projects/1104350651/tiktok-lunatik-multi-touch-watch-kits earlier and decided that not only must i get one of those, but i have to be able to run my own code on it, so here i am ;) 18.29.25 Join CaptainKewl [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 18.30.11 # Does one need a special patch to get at the ipod accessory protocol debug info? 18.30.30 # gevaerts, I think so, I haven't seen anything like that in SVN code 18.30.58 # Daeken: to get back to your original question, I don't know of anyone working on it 18.30.59 # if it's not too intrusive, I'd say we add the debug info and enable it with a define 18.31.19 Join toffe82 [0] (~chatzilla@adsl-71-154-234-239.dsl.frs2ca.sbcglobal.net) 18.31.34 # and I myself am not planning to do anything with that one in the next couple of months unless maybe we accidentally discover a possible exploit 18.31.53 # TheSeven: alright, well, i appreciate your help. i'll idle here and if i discover anything fun, i'll let you guys know :) 18.32.00 # feel free to try it, but this is going to be really hard 18.32.12 # in case you find a working exploit, we would be glad to re-use it on the nano5g :) 18.32.18 # bertrik: any idea about the task number? 18.32.32 # TheSeven: i sincerely hope so. i haven't had a good challenge in a long time. 18.32.45 # apple doesn't tend to let me down in that regard, so i'm looking forward to it ;) 18.32.46 # Daeken: you might want to idle in #freemyipod :) 18.33.02 Join Kitar|st [0] (Kitarist@BSN-142-102-198.dial-up.dsl.siol.net) 18.33.04 # that's where we're currently poking at the ipod nano 3g/4g and classic 18.33.14 # great, thanks. 18.33.21 # gevaerts, http://www.rockbox.org/tracker/task/9951 18.33.28 # not sure if it still applies 18.34.09 # hm, do I need the logging patch, or both, or only the last one? 18.34.42 # TheSeven: do you know if it's possible to get the unencrypted bootloader/dfu image for the 6g? 18.35.12 # check the files on phobos, i haven't looked at them yet 18.35.18 # I guess the aug 23th patch is the relevant one 18.35.24 # http://www.trejan.com/projects/ipod/phobos.html 18.35.34 Join Boldfilter [0] (~Boldfilte@99-120-142-250.lightspeed.jcvlfl.sbcglobal.net) 18.35.44 # ok, cool. thanks again :) 18.35.52 # Yes, that one seems to apply at least 18.35.52 # http://appldnld.apple.com/iPod/SBML/osx/bundles/061-9054.20100907.VKPt5/x12320000_Recovery.ipsw 18.35.56 # http://appldnld.apple.com/iPod/SBML/osx/bundles/061-9054.20100907.VKPt5/x12480000_Recovery.ipsw 18.36.12 # http://appldnld.apple.com/iPod/SBML/osx/bundles/061-9054.20100907.VKPt5/iPod_1.0_36A00403.ipsw 18.36.29 # there might be something unencrypted in one of them, but i rather doubt it 18.36.50 # same. 18.37.39 Join domonoky1 [0] (~Domonoky@agsb-4d055ffd.pool.mediaWays.net) 18.38.30 # yea, the dfu image is encrypted, from 0x400 on 18.38.30 Quit domonoky (Ping timeout: 245 seconds) 18.39.13 # hrm... they use CBC mode, right? 18.40.23 # n1s: it's not worth to introduce them for this 0.1 MHz, true. but if we should use alignment mactos for ARM we need to find a solution to cope with CF. see FS#11753. (might be interesting to make measurements on arm11) 18.40.44 # ah shit, need to get to the bank... back shortly. 18.41.14 # n1s: saratoga introduced 32 byte aligment in atrac3 to optimize for arm11 18.42.38 # Buschel: well, since large alignment doesn't really hurt anywhere i don't see why not just always align to 32 bytes (it would waste some space but that's usually very little9 18.43.59 # as an example in mpc, 5 arrays aligned to 32 bytes would waste a max of 31*5=155 bytes 18.44.11 # n1s: tha's the easiest way :) but I don't think such solution would be accepted in general 18.45.46 # Daeken: they used CBC on the older platforms at least 18.48.28 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 18.48.39 # Buschel: maybe we can use something global like FAST_ALIGN where we just align for the sake of speed and not something else which would then be 16 bytes on CF 18.49.07 # i don't really like abusing CACHE_ALIGN for this on CF 18.53.40 *** Saving seen data "./dancer.seen" 18.54.14 # yes, that's why I proposed to have something else. e.g. MEM_ALIGN_ATTR or FAST_ALIGN_ATTR. this can be same as CACHEALIGN_ATTR for ARM an something else for other CPUs. 18.54.44 # it could be simply defined in system.h as well 18.54.58 # sounds good to me if you don't want to do unconditional 32byte alignment :) 18.55.20 # depends on what we want to use as default ;) 18.56.47 Quit Rob2223 (Remote host closed the connection) 18.57.23 Join Rob2222 [0] (~Miranda@p4FFF2E04.dip.t-dialin.net) 18.57.24 # e.g. it might be ok to use 32 byte alignment on unknown ARM CPUs. the newer ones have this alignment. so, the probability that it fits for a new port is high 18.58.03 Join dfkt [0] (dfkt@unaffiliated/dfkt) 18.58.22 # i think the cores that use the cache from ARM have 32b cache lines but that the PP cores have custom caches 18.58.45 # Anyone with IAP knowledge around who understands what http://pastie.org/1313231 means? 18.58.46 # so, yes 32 bytes is very likely for newer ARM's 19.00.58 Quit rvvs89 (Remote host closed the connection) 19.01.02 # gevaerts, 1st is length, 2nd is mode. Mode 0 is used for negotiation into other modes IIRC 19.01.50 # I'm with n1s 19.01.58 # Which presumably fails here since we have no idea how to deal with the thing 19.02.10 Quit dfkt_ (Ping timeout: 252 seconds) 19.05.37 Quit Gnea (Ping timeout: 272 seconds) 19.05.45 Join guymann [0] (~charles@69.182.43.9) 19.07.06 Quit piggz (Ping timeout: 250 seconds) 19.11.25 Join T44 [0] (~Topy44@f054217089.adsl.alicedsl.de) 19.14.21 Quit Topy (Ping timeout: 245 seconds) 19.14.31 # FS#11766 19.19.41 Quit guymann (Quit: brb lol) 19.25.13 Join guymann [0] (~charles@69.182.43.9) 19.25.13 Quit S00row (Read error: Connection reset by peer) 19.25.59 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 19.30.58 Quit n1s (Quit: Lämnar) 19.35.22 # TheSeven: any idea how they handle/have handled padding in the past? 19.36.07 # they usually pad data to 16 byte blocks with 0xff 19.36.13 # ah, ok 19.37.13 # ... huh, the bootloader in the firmware update (the main one) isn't encrypted. 19.40.40 Join Topy [0] (~Topy44@g228209202.adsl.alicedsl.de) 19.43.31 Quit T44 (Ping timeout: 245 seconds) 19.43.55 Join anewuser [0] (anewuser@unaffiliated/anewuser) 19.43.56 Quit Boldfilter (Quit: Boldfilter) 19.44.38 # Buschel: do you mind if I commit FS#11235? 19.45.06 Quit dfkt (Read error: Connection reset by peer) 19.45.06 # i want to look at arm9 scheduling in more detail for libmad, so getting that patch in first would be nice 19.45.07 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 19.45.45 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-109-252.tampfl.fios.verizon.net) 19.46.07 # can this still be applied to svn? 19.46.57 # if so, I do not mind if you would submit 19.46.58 Quit dfkt_ (Read error: Connection reset by peer) 19.47.00 Join dfkt [0] (dfkt@unaffiliated/dfkt) 19.48.19 Quit dfkt (Read error: Connection reset by peer) 19.48.20 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 19.48.23 # it doesn't apply, but it should be easy enough to fix 19.48.53 # also, i got the c version of libmad working with 32x16 muls and no "SSO" optimization 19.48.57 # i've started on the asm code 19.50.14 # scheduling this for arm11 is . . . interesting 19.50.39 # i didn't realize on arm11 doing two multiply accumulates into the same register on sequential cycles was a stall 19.51.24 # the optimal arm11 code should run with no speed hit on arm9e, but i'm thinking of splitting them up anyway just because the arm9e version is comprehensible while the arm11 version is going to be a mess 19.51.24 Quit S00row (Read error: Connection reset by peer) 19.53.34 Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) 19.53.46 # Buschel: hmm i don't see why this patch is failing exactly, you wouldn't happen to have your synth.c for you last version of that patch handy? 19.57.29 # ah nevermind, got it 20.01.59 Quit iq (Ping timeout: 240 seconds) 20.03.18 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 20.05.58 Quit GeekShadow (Quit: The cake is a lie !) 20.06.13 # New commit by 03saratoga (r28624): Commit first part of FS#11235 by Buschel and I. Improves scheduling on arm9 for two filter macros in libmad that are almost never called. A larger ... 20.06.29 # Buschel: I'm going to leave that task open for now, I want to play around with arm < 9E scheduling some more 20.08.28 # r28624 build result: All green 20.11.36 Quit dfkt_ (Read error: Connection reset by peer) 20.11.38 Join dfkt [0] (dfkt@unaffiliated/dfkt) 20.25.51 Join pamaury [0] (~quassel@dhcp-128-203.residence.ens-lyon.fr) 20.25.51 Quit pamaury (Changing host) 20.25.51 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.38.16 # gah 20.38.32 # using the layout values for the inbuilt media player doesn't work for htc sense 20.39.59 Quit user890104 (Ping timeout: 272 seconds) 20.52.17 Quit Buschel (Ping timeout: 264 seconds) 20.52.20 Quit liar (Ping timeout: 255 seconds) 20.53.43 *** Saving seen data "./dancer.seen" 20.53.52 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.00.18 Join u42p [0] (~u42p@d085196.adsl.hansenet.de) 21.00.43 # (how) can i use http://www.rockbox.org/tracker/task/11664?show_task= in combinaton with RockboxUtility on linux? 21.01.38 # i mean, my clip+ boots sansa firmware if i connect it to the pc and since it then hangs i'd like it to boot rockbox instead 21.01.39 # u42p, there is no need to use RockboxUtility in combination with that patch. 21.01.58 # oh i dont know how to install anything without that tool :) 21.02.38 # What you want to do is build your own rockbox (starting with http://www.rockbox.org/wiki/CrossCompiler ) using those patches and test. 21.03.11 # u42p, one would simply copy the compiled .rockbox folder to their player overwriting the old one in the process. 21.05.10 # oh, now that you say it, i think i looked at that page before and got scared. 21.06.44 # it is step by step. Lots of steps, but little left to the imagination. If soap can do it you can! 21.08.40 # ok, gonna try it. :) 21.10.44 # if you're on Windows using the VMWare image is likely easier than cgywin 21.11.08 # nope, archlinux 21.11.16 # then you're set. 21.22.19 # ok, i have run rockboxdev.sh . how do i apply those patches? 21.24.11 # Daeken: you mean the whatever.bootloader.rb3 file? 21.24.28 # have fun disassembling that :) 21.25.38 # yea 21.25.41 # "patch -p0 so they're still not encrypting that. nice. 21.26.17 # no, cant find the file 21.26.31 # Daeken: prepare yourself for a disassembling odyssey :) 21.28.15 # seccore/peicore will be rather easy, but the rest will be rather evil. 21.28.20 # :) 21.28.40 # in case you haven't noticed yet what's in there: 21.28.57 # it's an EFI volume. yes, they're using EFI on those players. no idea why. 21.29.10 # ok, did it manually 21.29.15 Join mc2739 [0] (~mc2739@71.20.73.59) 21.29.16 # it contains a shitload of compressed PE executables 21.29.18 Quit mc2739 (Changing host) 21.29.18 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 21.29.32 # if i want the complete makeover i need to build the Bbootloader and Normal, correct? 21.29.35 # looks like I can save 1-2MHz on arm9 (non-E) decoding mp3 21.29.38 # those are relocated at runtime, lots of dynamic memory allocation involved 21.29.49 # unless you're changing the bootloader you shouldn't touch it 21.30.14 # TheSeven: how much of the bootloader code depends on weird hardware features? e.g. does it use the aes accel? 21.30.24 # and the worst is probably that they call each other through those runtime-registered guid to function table mappings 21.30.36 # even some of the function tables are generated at runtime 21.30.57 # it does, but the individual modules are nicely separated 21.31.15 # the ugly thing are the cross-module calls/callbacks/events/triggers/whatever 21.31.23 # hmm... so running this in emulation might be a feasible approach. 21.31.34 # possibly 21.31.35 # (that's how i did a lot of baseband reversing for the original iphone) 21.32.34 # finding a vuln there will be hard, it's hardly doing any user interaction 21.33.10 # i'm mainly interested in it to understand the boot process better 21.33.29 # the only possible route of exploitation that i can see is cracking the firmware update protocol, corrupting the firmware partition somehow, and exploiting the firmware file system reading code 21.34.00 # aaargh, build failed: http://pastebin.com/iZAFkADu 21.34.47 # or maybe some signature validation code 21.35.18 # the boot logo will probably still be a bitmap, so it's not very likely that there will be a vuln in the decoder 21.35.24 # u42p: as I said before you dno't want to build a bootloader 21.35.45 # sorry, i missed that line 21.36.12 # although since you haven't changed the bootloader, and its failing to build, you're probably still doing something else wrong 21.36.25 # * TheSeven asks for a general opinion: should we move this discussion to #freemyipod or stay here? 21.36.27 # i don't know what exactly i am changing. but since it is related to the bootloader i suspect it might be it. it is this patch i want to try http://www.rockbox.org/tracker/task/11664?show_task= 21.37.52 # TheSeven: I don't think it's wrong to have it here 21.42.03 # TheSeven: i hate having to read two sets of logs, so i say keep it here 21.42.46 # TheSeven: during the bootloader, what is active? is there a way to do anything usb-wise from the bootloader level, or does that come later? 21.43.21 # i imagine there's /something/ usb-wise there, to start the flashing process... 21.44.02 # there are three points where USB is used: 21.44.06 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 21.44.06 # - bootrom DFU (too early) 21.44.13 # - USB mass storage device (too late) 21.44.18 # - Disk mode (too late) 21.45.16 # there's also a USB EFI module, but I'm not sure what this one is doing 21.45.28 # might only be used to determine if there is voltage on the bus 21.45.34 # hmm... 21.45.38 # or maybe in diagmode (which in integrated into this efi hell) 21.48.18 # stupid arm and its lack of registers, even storing the stack pointer so I can use it, I still have 1.5 cycles of stall per PCM sample produced in libmad on arm9 (non-E) 21.50.19 # you know, i wonder if it'd be possible to employ a timing attack against the signature check for the bootloader update process. 21.50.36 # i find it doubtful that they're doing it in constant time, unless someone's employed the same attack against them in the past... 21.51.30 # the timing would be precise enough to do it pretty damn quickly, especially if the update procedure works anything like bbupdate did. 21.52.34 # you mean trying to figure out the hardware AES key by analyzing the time decryption takes? 21.52.51 # 16 hr, 20 min using freddyb's patch 21.52.56 # on fuzev1 21.53.33 # no -- that'd pretty much require having code running on the device in the first place (might be feasible from there, though i think a power measurement attack would be more likely to succeed) ... i mean measuring the time it takes to check the signature during the update process. 21.54.15 # the bootloader code isn't encrypted, so modifying it would be easy (for some value of easy) ... if you can measure the time it takes to check the signature and they're not doing it in constant time, it'd be possible to find a matching signature... in theory. 21.54.19 # depends on how they're doing it, really 21.54.26 # the only place where such an attack could be mounted is bootrom DFU IIUC 21.55.15 # that may well be the best way to get code running on it initially... as soon as one tiny bit of code runs on it, it's game over. 21.55.16 # I still think that jitter introduced by USB will be way too big to do this 21.55.48 Quit factor (Read error: Connection reset by peer) 21.56.31 # nah, noise is a nonissue in this regard. you can achieve nanosecond resolution over the internet with a timing attack... very practical on anything local. the only concern i have is that they're doing the check in constant time. 21.56.38 # but that's easy enough to figure out 21.56.55 # well, try it :) 21.57.26 Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 21.57.36 # yea, think i'm going to... probably gonna go pick up a nano this week. 21.57.46 # was going to do it today, but didn't feel like walking over there after i hit the bank :P 21.57.58 # are the DFU images encrypted? 21.58.03 # yea 21.58.11 # hm, that's not good 21.58.16 # why so? 21.58.30 # because it means we would have to encrypt the code 21.59.06 # why? if you're patching the bootloader, it should take it no problem as long as the signature matches. 21.59.35 # how would you get feedback on the time it takes for the bootloader signature to be verified? 22.00.02 # (assuming they let you flash whatever you want, and will just fail on the next reboot) 22.00.22 # depends on how they're doing the updates. is it a situation where you simply ship the data off to the nano and it hands back an error or somesuch, or does it allow you some semblance of control? 22.00.41 # i imagine it won't flash the bootloader unless it validates the signature first, right? 22.01.18 # i'm not sure about that 22.01.47 # why should they check it? 22.02.01 Join froggyman [0] (~seth@unaffiliated/froggyman) 22.02.08 # because if there's an error on the line, the user gets a brick. 22.02.13 # nope 22.02.17 # how so? 22.02.34 # if the bootloader isn't signed correctly, the bootrom will enter DFU, itunes will pick it up, upload WTF and disk mode, and flash it again 22.02.43 # ah, good point... 22.02.49 # hrm. 22.03.32 # and "errors on the line" would have to pass USB CRCs 22.04.11 # the one big thing that makes me think this could work is that bytes 0x40-0x54 of the bootloader look to me like an sha1, most likely hmac. 22.04.35 # if they verify that in a non-constant-time way at flashtime, it'd be easy. 22.04.36 # * TheSeven bets it's plain sha1 of bytes 0-0x3f 22.04.39 # otherwise... not so much. 22.05.01 # and bytes 0x10-0x14 will probably be plain sha1 of the payload 22.05.22 # you mean 0x10-0x24? 22.05.29 # yes, of course 22.05.40 # nope, not in this case... this is the only thing that looks like an sha1. 22.05.42 # at all 22.05.50 # hm, interesting 22.05.58 # on the nano2g those were HMACs 22.06.00 # one sec, i'll pastebin the header. 22.06.13 # on the nano3g/classic they switched to SHA1 run through the AES hardware key 22.06.22 # and on the nano4g I've seen plain SHA1s somewhere 22.07.26 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 22.11.38 # http://pastie.org/1313553 <-- header plus first 16 bytes of payload. 22.12.53 # if they were to run sha1 through aes, either they'd truncate the hash first, meaning we'd have 4 bytes less data, or they'd pad it out, meaning we'd have 12 bytes more... i'd put money on that being an hmac 22.15.21 # well, there is one other possibility, but i find this insanely unlikely: SHA1 encrypted then truncated to 20 bytes... they couldn't decrypt it, but they could do the same thing on the hardware, allowing them to verify it. 22.15.26 # but i can't see why they would ever, ever do that :P 22.16.03 # that's why i think it's a plain one 22.16.15 # they seem to have accepted that encrypting those hashes buys them nothing 22.16.15 # how would they verify it? 22.16.27 # that is, how could they verify it wasn't tampered with 22.16.28 # ? 22.17.20 # that's why they have a digital signature of the header (or even the payload?) at the end 22.17.35 Quit alexbobP (Quit: leaving) 22.18.02 # there's none in the header... and i don't see one in the payload, but it could very well be there and simply not have anything to stand out. 22.18.33 # saratoga: how much is 1.5c per sample improved over svn? and why 1.5c? 22.18.35 Join alexbobP [0] (~alex@75.63.1.71) 22.19.03 # kugel: saves about 2 MHz on the Fuze v1 22.19.17 # and in this case, hmacs would be identical to signatures for their purposes. except even more secure, in theory 22.19.32 # (personally disagree with that point, but i'm in the minority there) 22.19.37 # 1.5 cycles * 44100*2 = 132kHz 22.19.59 # so not too bad, but still annoying 22.20.17 # 2MHz is nice 22.20.27 # brb, need a smoke. 22.22.42 # yeah i'm pretty happy with it 22.22.56 # i think we can get a much, much bigger improvement on arm9e and arm11 though 22.23.40 # probably on the order of 3-4 times that 22.23.58 # would make mp3 fast like vorbis 22.24.27 # if i built a new rockbox.zip, should i remove the old .rockbox on my player before unpacking? 22.24.32 Join stoffel [0] (~quassel@p57B4A17B.dip.t-dialin.net) 22.25.28 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 22.25.32 Quit ReimuHakurei (Read error: Connection reset by peer) 22.26.47 # no 22.27.38 # ok 22.28.05 # ok, done. still boots sansa if i plug it in 22.29.01 # ah, i had to launch rockbox and then plug it in 22.30.27 # hooray, works like a charm 22.30.32 # thanks for your help guys! 22.31.13 # pamaury: another satisfied customer here for http://www.rockbox.org/tracker/task/11664?show_task= . sansa clip+ 22.31.16 # saratoga: your work already helps on armv5+, no? 22.32.01 # kugel: yes, same on arm9, but i'm going to replace this code with armv5 optimized versions soonish 22.32.08 # "same on all arm9" 22.32.20 # yes I saw, apparently the patch is working quite well with linux, but windows is still doing crap 22.32.47 # saratoga: can you post the patch? I can test on my phone then 22.33.13 # kugel: sure, give me 5, tracking down a glitch in the audio sometimes 22.36.22 # ok there i think i got it working 22.36.58 Join casainho [0] (~chatzilla@2.81.145.101) 22.38.24 # kugel: http://www.rockbox.org/tracker/task/11235 22.38.45 # awesome 22.39.10 # I'll apply Buschel's alignment patch as well and make a new test codec batch 22.39.12 Quit froggyman (Quit: Bye) 22.39.20 # according to test_codec, libmad has gotten 3.5MHz faster on the fuzev1 since the spring 22.44.55 # saratoga: does your patch hurt PP? 22.45.10 # kugel: shouldn't 22.45.32 # doesn't really matter anyway thanks to the COP patch 22.45.38 # all this code runs on the COP 22.46.18 # TheSeven: my ipod says its blank and the OF wants me to restore it, whats the easiest way to fix this 22.46.33 # (haven't used it in a month or so FWIW) 22.47.35 # saratoga: what kind of ipod? 22.47.44 # sorry, 2g 22.47.46 # naon 22.47.48 # nano 22.47.53 # "use itunes to restore" 22.48.07 # has it ever seen iloader? 22.48.15 # no, just whatever rbutil installed 22.48.22 # that's weird 22.48.33 # i'll go find a machine with itunes 22.48.58 # you could try handcrafting a firmwarefs with a rockbox bootloader inside :) 22.49.12 # but itunes is certainly the easier way 22.49.29 # whats weird is the rockbox bootloader seems gone 22.49.59 # "use itunes to restore" means that it failed to load the rockbox bootloader for whatever reason 22.50.13 # this is displayed by the NOR bootloader 22.51.36 Quit stoffel (Remote host closed the connection) 22.52.16 Part u42p ("Leaving") 22.53.45 *** Saving seen data "./dancer.seen" 22.56.48 Quit benedikt93 (Quit: Bye ;)) 23.00.01 # saratoga: good thing you fixed test codec to work with files larger than ram 23.00.29 # yes thats quite handy 23.00.46 # i'm thinking of next adding options to do boosted, unboosted, and "dynamic" boosted tests 23.00.57 # the last one attempting to boost and unboost as needed like during normal playback 23.01.34 # i.e. testing how much boost happens in realtime decoding? 23.01.47 # good idea generally but tests will take ages this way 23.02.04 # still faster then unboosted :) 23.02.26 # the thing is performance with boosting locked on is often a lot different then when it flips on and off on some players 23.02.34 # not on android :) 23.03.02 # although i guess figuring out the right ratio of boosted to unboosted could be tough if we want to go a lot faster then real time 23.03.59 # loading the file from disk basically takes longer than decoding for some codecs on android 23.04.44 # (that's perhaps exaggerated) 23.05.15 # huh test codec is slightly slower then what the wiki says mp3 should be 23.05.18 # i wonder whats going on 23.05.40 # the async clock mode change? 23.06.23 # sorry, i mean on the nano2g 23.06.27 # fuzev1 is faster 23.11.39 # hmm no its faster, however the nano2g has gotten slower since I tested it over the summer 23.12.27 # the alignment patches already make some difference. most codecs are a good deal faster than in my last test 23.13.29 # hmm well this is TheSeven's problem 23.13.36 # i'll make the codecs faster, he has to figure out the hardware 23.15.03 # saratoga: what exactly is slower now? 23.15.05 # test_codec? 23.15.14 # so decoding without the pcm driver running and always fully boosted? 23.15.25 # TheSeven: correct 23.16.07 # is test_codec loading the complete file to RAM before decoding? 23.16.21 # you got 51.06MHz with r24786, I'm getting about 53MHz now 23.16.35 # it loads as much as fits into RAM, then pauses the timer to rebuffer if needed 23.16.46 # for 128k mp3 it shouldn't be rebuffering 23.16.53 # OK 23.17.01 # so it can't be coming from the FTL/NAND 23.17.03 # have you changed any clocks in the last 3000 revisions 23.17.52 # i have changed the boosting/unboosting operation a bit, but this shouldn't have an effect 23.18.08 # pretty much the only thing that should matter is the bus and memory clocks 23.18.32 # is it possible my ipod is somehow faster then yours? 23.18.41 # they should always have been the same (CPU: 192MHz, AHB: 96MHz, async mode) 23.18.41 Quit xavieran (Ping timeout: 265 seconds) 23.18.55 # i can have a check on mine if you like 23.19.01 Join Gnea [0] (~gnea@unaffiliated/gnea) 23.19.02 # yeah probably a good idea 23.19.24 Join MethoS- [0] (~clemens@134.102.106.250) 23.19.28 Quit MethoS- (Read error: Connection reset by peer) 23.19.34 # which file is that? lame128? 23.20.12 # yeah 23.20.17 Join MethoS- [0] (~clemens@134.102.106.250) 23.20.26 Quit MethoS- (Remote host closed the connection) 23.20.39 # the difference is even more pronounced when you consider that the fuzev1 seems to have gotten faster over that time due to better optimization in libmad 23.20.57 # hm, no test_codec installed :/ 23.22.13 # * TheSeven needs to rebuild first 23.23.14 # I get upto 20% speedups with the alignment patches 23.23.23 # wow 23.23.26 # on which target? 23.23.32 # my phone 23.24.47 # arm11 or cortex? 23.25.05 # i guess alignment will matter a lot on either, since they have the 64 bit bus for aligned transfers 23.25.17 # arm11 23.25.33 Join MethoS- [0] (~clemens@134.102.106.250) 23.26.02 # I'll have new charts up in a few minutes 23.28.14 # saratoga: 53.56MHz on r28602 with aafonts and hw keyclick patch applied, iLike theme 23.28.41 # touched the clickwheel a few times during the process to keep the display awake 23.29.10 # ok same as i then 23.29.10 # weird 23.29.19 # maybe one of Buschel's IRAM changes are related? 23.29.33 # IRAM isn't really fast on this one, but I wouldn't expect it to be slower than DRAM 23.29.39 # that would make sense, ams doesn't use the iram defines 23.30.00 # we'll probably have to bisect that 23.30.37 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 23.31.02 # saratoga: http://pastie.org/1314086 23.31.13 # I'm redoing the svn test with backlight on this time 23.32.25 Join alexxel [0] (flea2008@peer214-29-159-178.ll.magnitogorsk.multinex.ru) 23.32.43 # the left is svn, the right is svn+asm enabled+alignment patches 23.32.48 Quit MethoS- (Remote host closed the connection) 23.32.55 # Hey ? 23.33.30 # wow those are amazing 23.33.35 # is the alignment patch in SVN yet? 23.33.39 # no 23.33.43 Join MethoS- [0] (~clemens@134.102.106.250) 23.34.10 # rockbox for nano 3g ipod is it real ?? 23.34.17 # nope 23.34.23 # I'll prepare a graph that has my last test codec benches in it 23.34.30 # you should get that patch in then 23.34.33 # just need to find the right files 23.34.36 # whats the fs number? 23.34.47 # FS#11753 23.35.42 # does it help with any other CPUs? 23.35.51 # probably not much on arm9 i guess 23.36.53 # i should probably double check that everything in libmad is aligned 23.37.36 # huh it isn't 23.38.36 # what define should I be using to align things? 23.41.05 # alexxel: not yet at least. it might be coming one day, i'm working on it :) 23.43.23 # :( 23.43.31 # funny guy 23.44.41 # saratoga: pretty amazing: http://www.alice-dsl.net/simonemartitz/rockbox/test_codec_stats.pdf 23.45.15 # saratoga: CACHEALIGN_ATTR, or whatever the outcome of fs#11753 is 23.45.17 # kugel: i wonder what those look like if libmad is actually aligned 23.46.20 # wow, look at the mpc numbers 23.46.30 # alignment makes no real difference on arm9 that i can see 23.46.47 # also, mp3 is faster now, and even faster with your patch and asm enabled (in svn C is faster) 23.47.08 # alexxel: who is claiming that rockbox would run on it? 23.48.53 # I'm surprised that cache align makes such a vast difference. or did something else change since a month ago? 23.49.24 # on arm11 aligned loads/stores are basically 2x as fast as unaligned ones 23.49.58 # Why not?? this is open sourse, it may run even on my tv if anybody cares... 23.50.02 # hmm i take back what i said about alignment on arm9, its more complicated to align libmad because of all those packed structs 23.50.17 # alexxel: no one cared until recently 23.50.46 # i'll have to dig into alignment more once buschel's patch is committed, theres probably a lot of room for improvement here 23.51.17 # kugel: also if possible having the raw MHz needed is nice too, since it makes it easier to see the actual magnitude of an improvement 23.51.58 # so very sad 23.53.52 # saratoga: it should be possible, but you need to know the actual clock frequency of the device, luckily my parse_testcodec can do that 23.54.20 # cool 23.54.28 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 23.57.18 # someone should try doing test_codec on the nano2g without boosting 23.57.44 # gah, ape is messing up the chart 23.58.39 Quit advcomp2019 (Quit: There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.)