--- Log for 18.03.110 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 9 hours ago 00.02.18 Part froggyman 00.04.59 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 00.07.23 Quit saratoga (Ping timeout: 252 seconds) 00.08.26 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 00.10.16 Quit ender` (Quit: Consultation, n. Medical term meaning "to share the wealth.") 00.19.24 Join webguest41roko [0] (~9ec3c4fa@giant.haxx.se) 00.19.47 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 00.23.40 Join Strife1989 [0] (~michael@adsl-154-11-187.mcn.bellsouth.net) 00.24.18 Join CaptainKewl [0] (~jason@207-237-107-203.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 00.26.22 Quit Strife89 (Ping timeout: 265 seconds) 00.28.34 *** Saving seen data "./dancer.seen" 00.28.35 Quit Strife1989 (Read error: Connection reset by peer) 00.28.59 Join Strife1989 [0] (~michael@adsl-154-11-187.mcn.bellsouth.net) 00.30.48 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 00.32.34 Quit CaptainKewl (Read error: Connection reset by peer) 00.33.02 Part toffe82 00.34.02 Nick Strife1989 is now known as Strife89 (~michael@adsl-154-11-187.mcn.bellsouth.net) 00.36.29 Quit webguest41roko (Quit: CGI:IRC) 00.48.48 Quit r0b- (Ping timeout: 260 seconds) 00.50.17 Quit xavieran (Ping timeout: 246 seconds) 00.56.14 Quit bertrik (Ping timeout: 246 seconds) 01.10.54 Quit komputes (Read error: Connection reset by peer) 01.11.13 Quit Adubb (Read error: Connection reset by peer) 01.18.20 Quit perfectdrug_ (Quit: perfectdrug_) 01.23.49 Join r0b- [0] (~nnscript@adsl-76-236-178-147.dsl.klmzmi.sbcglobal.net) 01.28.01 Quit hebz0rl (Quit: Ex-Chat) 01.30.15 Quit scorche|sh (Ping timeout: 276 seconds) 01.31.44 Quit DerPapst (Quit: Leaving.) 01.39.17 Join komputes [0] (~komputes@ubuntu/member/komputes) 01.39.19 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-zsqusexkeghgjdzg) 01.40.25 Join Strife1989 [0] (~Strife89@adsl-154-11-187.mcn.bellsouth.net) 01.40.35 Nick Strife1989 is now known as Strife89|Desktop (~Strife89@adsl-154-11-187.mcn.bellsouth.net) 01.49.03 Quit robin0800 (Remote host closed the connection) 02.14.37 Quit MethoS- (Remote host closed the connection) 02.27.49 Join CaptainKewl [0] (~jason@207-237-107-203.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.28.11 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 02.28.36 *** Saving seen data "./dancer.seen" 02.36.37 Join Tomis2 [0] (~Tomis@70.134.88.206) 02.38.47 Quit Tomis (Ping timeout: 265 seconds) 02.38.48 Nick Tomis2 is now known as Tomis (~Tomis@70.134.88.206) 02.48.24 Join MrShlee [0] (Default@122-49-180-61.ip.adam.com.au) 02.48.29 # Hey 02.49.11 # My iPod classic blew up (until the linux4nano team work their magic for a bootloader) I'm looking for a new mp3 player running rockbox. any recommendations? 02.49.17 # 80GB+ wanted. 02.52.59 # MrShlee: It's all subjective my "good" or "best" (or thers) will differ from yours. Have a look at the supported players on the RB mainpage, and pick one :D 02.53.12 # *others rather. 02.56.11 Quit jordan` (Ping timeout: 265 seconds) 02.57.40 Quit adnyxo (Quit: Leaving) 03.04.22 Quit komputes (Ping timeout: 246 seconds) 03.22.41 Join I3uckwheat [0] (~chatzilla@64.68.182.251) 03.23.05 # hello 03.23.37 # has rock box come out for the sansa fuze v2 yet 03.25.00 # * S_a_i_n_t directs I3uckwheat to the Rockbox main page. 03.27.48 # has rock box come out for sansa fuze v2 yet 03.28.40 # I3uckwheat: check the Rockbox main page, it lists all supported devices. 03.28.59 # www.rockbox.org 03.31.40 Quit I3uckwheat (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 03.39.59 Quit Barahir (Ping timeout: 260 seconds) 03.40.24 Quit saratoga (Ping timeout: 252 seconds) 03.41.22 Join Barahir [0] (~jonathan@gssn-5f756868.pool.mediaWays.net) 03.41.24 # Music is I:\Connor's Complete Music Collection 03.41.59 Quit MrShlee (Ping timeout: 240 seconds) 03.48.27 Quit Tomis (Read error: Connection reset by peer) 03.48.40 Join Tomis [0] (~Tomis@70.134.85.82) 03.56.08 Quit kugel (Remote host closed the connection) 04.05.22 Join jordan` [0] (~jordan@78.235.252.137) 04.15.05 Quit mc2739 (Remote host closed the connection) 04.21.15 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 04.28.40 *** Saving seen data "./dancer.seen" 04.31.08 Quit TheSeven (Disconnected by services) 04.31.22 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.31.32 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.42.49 Quit Barahir (Read error: Operation timed out) 04.55.07 Join Rob2222 [0] (~Miranda@p4FDC946C.dip.t-dialin.net) 04.57.36 Quit Rob2223 (Ping timeout: 260 seconds) 04.58.12 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 05.15.19 Quit DV_ (Read error: Connection reset by peer) 05.54.24 Quit Strife89 (Read error: Connection reset by peer) 05.54.52 Join Strife89 [0] (~michael@adsl-220-102-96.mcn.bellsouth.net) 05.58.04 Quit Strife89|Desktop (Ping timeout: 246 seconds) 06.06.28 Quit Strife89 (Quit: Rebooting.) 06.08.12 Join Strife89 [0] (~michael@adsl-220-102-96.mcn.bellsouth.net) 06.19.00 Join FOAD_ [0] (~dok@dinah.blub.net) 06.19.20 Quit soap (*.net *.split) 06.19.20 Quit preglow (*.net *.split) 06.19.20 Quit killan (*.net *.split) 06.19.20 Quit mt (*.net *.split) 06.19.20 Quit scorche (*.net *.split) 06.19.20 Quit yosafbridge (*.net *.split) 06.19.20 Quit jordan` (*.net *.split) 06.19.20 Quit scorche|sh (*.net *.split) 06.19.20 Quit RadicalR (*.net *.split) 06.19.20 Quit chaos (*.net *.split) 06.19.20 Quit GodEater (*.net *.split) 06.19.20 Quit leavittx (*.net *.split) 06.19.20 Quit Battousai (*.net *.split) 06.19.20 Quit stavrob (*.net *.split) 06.19.20 Quit tchan (*.net *.split) 06.19.20 Quit krazykit (*.net *.split) 06.19.20 Quit dionoea (*.net *.split) 06.19.21 Quit avacore (*.net *.split) 06.19.21 Quit ChanServ (*.net *.split) 06.19.21 Quit FOAD (*.net *.split) 06.19.21 Quit FlynDice (*.net *.split) 06.19.21 Quit Llorean (*.net *.split) 06.19.21 Quit lostlogic (*.net *.split) 06.19.21 Quit Tuplis (*.net *.split) 06.19.21 Quit doomcup (*.net *.split) 06.19.21 Quit tipi^ (*.net *.split) 06.19.25 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) 06.23.56 Quit JdGordon (Read error: Connection timed out) 06.24.35 Join JdGordon [0] (~jonno@123-243-140-31.static.tpgi.com.au) 06.27.46 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 06.28.44 *** Saving seen data "./dancer.seen" 06.31.10 Join CGL [0] (~CGL@190.79.141.37) 06.52.45 Join elcan [0] (user36@pr0.us) 07.02.14 Join n1s [0] (~n1s@119.42.73.137) 07.05.55 Quit fyrestorm (Read error: Connection reset by peer) 07.06.14 Quit CaptainKewl (Remote host closed the connection) 07.09.31 Join DV_ [0] (~DV@218.248.65.246) 07.17.47 Quit DV_ (Ping timeout: 264 seconds) 07.20.45 Join xavieran [0] (~xavieran@ppp118-209-22-76.lns20.mel4.internode.on.net) 07.21.02 # * n1s wonders what the point of screenshots of the text viewer is 07.23.32 Quit anewuser () 07.32.57 # is the forum down or is this just a problem in my end? 07.34.13 Quit n1s (Ping timeout: 258 seconds) 07.36.56 # find here 07.41.20 Quit CGL (Quit: Saliendo) 07.42.14 # any suggestions for the tag letters for "track changing?" (so you can know if its about to change or has just changed +/- user timeout) 07.42.21 # %pC was suggested in the forum 07.46.41 Join DV_ [0] (~DV@218.248.65.245) 07.56.46 Join Horscht [0] (~Horscht2@p4FD4FF01.dip.t-dialin.net) 07.58.55 Quit Horschti (Ping timeout: 245 seconds) 08.08.09 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.08.16 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 08.08.56 # New commit by 03jdgordon (r25239): 2 new tags: ... 08.11.26 Quit phanboy4 (Ping timeout: 265 seconds) 08.14.17 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 08.14.17 Join scorche [0] (~scorche@rockbox/administrator/scorche) 08.14.17 Join fyrestorm [0] (~nnscript@cpe-24-90-81-175.nyc.res.rr.com) 08.14.17 Join Barahir [0] (~jonathan@gssn-5f755222.pool.mediaWays.net) 08.14.17 Join jordan` [0] (~jordan@78.235.252.137) 08.14.17 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 08.14.17 Join soap [0] (~soap@rockbox/staff/soap) 08.14.17 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 08.14.17 Join chaos [0] (~chaos@gentoo/user/ch4os) 08.14.17 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 08.14.17 Join killan [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 08.14.17 Join leavittx [0] (~leavittx@89.221.199.187) 08.14.17 Join Battousai [0] (~bryan@gentoo/developer/battousai) 08.14.17 Join mt [0] (~chatzilla@rockbox/developer/mt) 08.14.17 Join stavrob [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 08.14.17 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 08.14.17 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 08.14.17 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 08.14.17 Join krazykit [0] (~kkit@adsl-76-240-216-183.dsl.ipltin.sbcglobal.net) 08.14.17 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 08.14.17 Join dionoea [0] (~dionoea@yop.chewa.net) 08.14.17 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 08.14.17 Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) 08.14.17 Join doomcup [0] (~doomcup@c-24-22-223-47.hsd1.wa.comcast.net) 08.14.17 Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) 08.14.17 Join tipi^ [0] (pihlstro@lehtori.cc.tut.fi) 08.14.17 Join ChanServ [0] (ChanServ@services.) 08.14.17 Mode "#rockbox +o ChanServ " by card.freenode.net 08.14.43 Quit JdGordon (Changing host) 08.14.43 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.15.12 Nick shai is now known as Guest43559 (~Shai@l192-117-110-233.cable.actcom.net.il) 08.15.12 Nick Zagor is now known as Guest13876 (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.16.19 Nick Guest43559 is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il) 08.16.36 Quit shai (Quit: Leaving) 08.16.55 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 08.20.18 # New commit by 03jdgordon (r25240): fix yelllow and add those tags to the debug output 08.21.17 Quit mt (Ping timeout: 245 seconds) 08.21.53 Join ender` [0] (krneki@foo.eternallybored.org) 08.24.14 Join DerPapst [0] (~DerPapst@p4FE8FC99.dip.t-dialin.net) 08.25.06 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.28.07 # what the heck hapened with the 1/2g ipod delta? 08.28.15 # -2k?! with no code change 08.28.48 *** Saving seen data "./dancer.seen" 08.30.24 Join pondlife [0] (~Steve@rockbox/developer/pondlife) 08.30.34 Part pondlife 08.31.03 Join mt [0] (~chatzilla@41.233.153.77) 08.31.14 Quit mt (Changing host) 08.31.14 Join mt [0] (~chatzilla@rockbox/developer/mt) 08.32.16 Quit Guest13876 (Quit: Clint excited) 08.32.35 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.32.35 Quit Zagor (Changing host) 08.32.35 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.36.59 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.5.166) 08.38.26 Quit S_a_i_n_t (Ping timeout: 260 seconds) 08.40.50 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.5.166) 08.53.39 # JdGordon: What is the default time for %pS and %pE ? Also, isn't "elapsed" in ms, not HZ? 08.54.40 Quit DV_ (Ping timeout: 248 seconds) 08.54.57 # JdGordon: Also, what's with the "+ +" in http://svn.rockbox.org/viewvc.cgi/trunk/apps/gui/skin_engine/skin_tokens.c?r1=25238;r2=25239;pathrev=25239 ? 08.55.44 Join liar [0] (~liar@213162066166.public.t-mobile.at) 08.56.00 # wtf? keyboard wierdness, not sure how tha happened 08.56.06 # default time works out to 10s for both 08.56.08 # or should be 08.56.35 # Looking at the code, the default seems to be 0, unless I'm misreading. 08.56.55 # how is that compiling even? ...elapsed++state->... ? 08.58.06 # default is 10, parser.c line 1113 09.00.22 # fixed 09.00.22 # Ah OK, I hadn't updated that file... ;) Can that be documented? 09.00.27 # New commit by 03jdgordon (r25241): woops, elapsed is ms not HZ and how did that extra + get in there? 09.01.18 Join petur [0] (~petur@rockbox/developer/petur) 09.01.33 # Zagor: can you understand how some of the 150-190 speed machines in the build farm never complete builds, while some < 100 completes several? 09.01.59 # there seems to be a discrimination that could need some attention 09.03.07 # there looks to be a bug in the average speed calculation, which causes rbmaster to give a bunch of bootloaders to gevaerts for example 09.03.19 # http://build.rockbox.org/data/25238-clients.html <= this is good example of this 09.03.29 # w1ll14m-w1ll14m did 6 builds 09.03.32 # his average is listed as 128 when in fact it is one of the fastest machines in the cluster 09.03.35 # deepthought-ender did none 09.03.51 # hm 09.11.29 # well, in my case I have my core2 duo laptop that isn't a very slow machine that often ends up not completing a single build 09.11.39 # and it seems wrong to me 09.12.19 # especially the last few days when I've had it hooked up to a 10mbit uplink 09.16.40 # I had the problem at the low end too, with my build client just being slightly faster than the slowest ones. The latter always got the bootloaders and mine a sim which it seldom finished 09.16.52 # yeah, something like that 09.17.30 # it seems the slowest machines get more builds than the ones slightly faster somehow 09.19.17 # the primary problem is the wrong average calculation. it corrupts the whole planning. last time, gevaerts was assigned one very easy build which it completed in ~23 seconds and then started chasing all the slower clients 09.19.40 # until that is fixed, it's very difficult to get a clear view of the other problem 09.19.49 # right, and at least that's an obvious problem that will skew most things 09.20.52 # gevaerts in person? ;) 09.21.36 # yes, I think I saw him come running down the hall here! 09.23.17 Join wodz [0] (~c21d9c6b@giant.haxx.se) 09.24.22 # can buildclient be run on machine behind NAT? 09.24.29 # yes! 09.24.32 # looks like there was a build messup in the previous round again with the 1st gen Nano (looking at the deltas) 09.24.46 # will be P4 1.5GHz helpfull? 09.25.14 # wodz: absolutely. all machines are helpful. 09.25.16 # wodz: it basically cannot hurt, so it's fairly easy to just fire it up and see what it can do 09.25.36 # ok I will setup buildclient then 09.25.46 # my Atom N270 contributes to every build round! 09.27.31 # what about 64bit system? Does it makes any problems as a buildclient? I have some 64bit debians rather unused 09.28.51 # wodz: no problems 09.29.15 # ok I will explore how I can contribute to build farm than 09.29.23 # excellent 09.29.51 # Is the build client aware of multicore? 09.29.54 # yes 09.30.05 # cool 09.30.31 # by default it uses all cores/hyperthreads, but you can limit to a specific number if you want 09.32.16 # AlexP: doesn't matter which backdrop 09.32.51 # if there was no fundamental change recently I missed 09.33.51 # New commit by 03zagor (r25242): Limit number of rows returned. 09.37.34 Join DV_ [0] (~DV@218.248.65.242) 09.52.16 # JdGordon: Do you plan to write a manual entry for the new tags any time soon, or are you just going to follow the trend of ignoring such things? 09.53.21 # found the problem. some boots and especially the wpscheck builds are so small that if you take a full second to complete them you get a very low score 09.53.39 # and the system does not support fractions of a second 09.57.19 # it's exacerbated by the fact that I use a conservative 33% median speed value for planning, rather than the average speed 09.59.32 # JdGordon: The general agreement was that the minimum was an FS entry of a full text description like you'd put in the manual, yours is just a rough description of it. 10.03.48 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 10.04.53 Join anewuser [0] (anewuser@unaffiliated/anewuser) 10.04.58 Join einhirn [0] (~Miranda@p5485A2ED.dip0.t-ipconnect.de) 10.12.27 Quit DV_ (Ping timeout: 252 seconds) 10.13.20 Join DV_ [0] (~DV@218.248.65.242) 10.14.21 Quit DV_ (Read error: Connection reset by peer) 10.14.42 # are there any major objections to upping the skin buffer size radsio skin can go in before the resisable buffer patch get finished? 10.14.57 Join DV_ [0] (~DV@218.248.65.242) 10.17.17 Join merbzt [0] (~benlar@193.13.246.198) 10.18.03 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.20.47 # JdGordon: Shouldn't things be done in the correct order? i.e. implement resizable buffer before things which require a resizable buffer? 10.21.19 # S_a_i_n_t: ping? 10.21.50 # linuxstb: well, the fm skin doesnt depend on the resizing, it does need a slightly larger buffe though 10.23.10 # pamaury: you're doing dircache fiddling yeah? any idea why the init order for dircache in the sim and target are different? 10.23.29 # on sim its setting_load(); init_dircache(true); init_dircache(false); 10.23.39 # on target the settings apply is between them 10.24.35 # JdGordon: yes, I'm always tweaking dircache :) I can't answer you now but iirc, there is difference because one tries to load the cache from the disk and the other not, or perhaps it's about transparent build or not. If you're ready to wait for a few minutes I can answer your question :) 10.24.52 # im not going anywhere :) 10.25.04 # it looks like dircache shouldnt even work on target with that orering! 10.26.32 # When I was fiddling with usb in simulator, I had a deep look at the init functions and there are big difference between targets and sim :) 10.27.11 # :( 10.27.50 # On the other hand, in the sim, much of the initialization part is useless I think 10.28.24 Quit TheSeven (Ping timeout: 252 seconds) 10.28.52 *** Saving seen data "./dancer.seen" 10.29.10 # ok, so init_dircache takes a parameter which tells whether dircache_init should be called. so the first time it's true, then it's false. That's sensible 10.29.40 # global_settings.dircache is I think undefined at that point though 10.29.44 # on target anyway 10.29.48 # It also seems that init_dircache checks whether settings are loaded or not 10.29.51 # on the sim it will be set to the config 10.30.19 # ah no, it will always be false thre 10.30.37 Quit einhirn (Ping timeout: 265 seconds) 10.30.54 # Hum, there is this fucking EEPROM thing that doesn't make any sense to me so if we ignore it, then the first call will be equivalent to dircache_init 10.31.27 # The second one will display a nice screen during rebuild 10.32.20 # I don't understand what the settings have to do with that 10.32.49 # to not init dircache if the user dosnt want it? 10.33.41 # Isn't that EEPROM thing the h120, when Rockbox is flashed to NOR? IIRC, that will cache the dircache, as it can tell whether the device may have been modified between boots. 10.34.41 # yes and no, iirc it was doing strange thing with EEPROM settings that don't seem to have any link with EEPROM 10.36.21 # JdGordon: I think you're right, during the first call, if the settings have never been assigned, then either it's undefined or more probably lobal_settings.dircache is false 10.36.30 # *global_ 10.36.52 # does that actualy change anything though? 10.37.10 # I'm tyring to find out why boot splashes apparently arent using the sysfont, and dircache is one of those 10.37.54 # well, it's just that the first call is equivalent to dircache_init apparently, so it's weird to this function two times, with the first call being trivial 10.38.03 Quit DV_ (Read error: Connection reset by peer) 10.38.16 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 10.38.21 Join DV_ [0] (~DV@218.248.65.242) 10.38.35 # I can't help you with this, I know nothing about that :) But the first call will not trigger a splash, I'm nearly sure 10.39.07 # I you have doubts, replace the init_dircache(true) by dircache_init 10.39.23 # no, looks like it wont 10.40.09 # But perhaps this difference makes sense in the sim ? Sounds strange but we never know 10.45.42 # I have question about iriver h300 bootloader code. charger_inserted() is defined in firmware/powermgmt.c and returns power_thread_inputs & POWER_INPUT_CHARGER; power_thread_inputs is updated in power_thread(). Now examing bootloader.map I can't see power_thread() symbol so how does it work than? 10.46.11 # be very careful with the h300 bootloader.. svn will brick it 10.47.08 # I am not messing with that bootloader I am only using it as a template for my own (MPIO HD200). I do have BDM so I am on the safe side 10.49.36 # on my target charger_inserted() doesn't work and I can't figure out what is the code workflow. Under debugger variable power_thread_inputs seems to be empty so I am wondering how it is updated in bootloader context 10.49.54 # on normal build I assume it is updated by power_thread() 10.54.46 # JdGordon: belated pong. 10.55.15 # are you sure its the sysfont and not just hta your userfont is very similar? 10.56.39 # well, my user font is Helvetica 12, and I'm pretty sure I can tell the difference between the two. 10.57.09 # *maybe* I'm messing it up, but it looks like 8pt sysfont on the splashes to me. 10.59.53 # very wierd.. I just had another look on the h300 sim and it was dfinitly using the correct fonts 11.00.10 # Hmmmm...new development. It's only when I'm using that one font. 11.00.13 # :S 11.00.38 # Not "new" I guess, I just hadn't noticed it until now. 11.02.23 # is that font file corrupt maybe? 11.02.58 # I'm replacing it with a newer version now. 11.05.35 # Hmmm. OK, that task cab closed I guess. I feel slightly sheepish now. Helvetica Bold from the "extras" page works fine. Not sure how the one I compiled is any different, but it is apparently :/ 11.05.45 # s/cab/can/ 11.05.55 # shit...sorry about that. 11.09.43 # no worries 11.13.38 Quit phanboy_iv (Ping timeout: 265 seconds) 11.20.28 # does anyone have any good reasons why we dont immediatly draw images in skins when they show up? instead of (What we do now) drawing all images in a viewport at he end of the vewport loop? 11.23.15 # You basically mean, why don't we have a predictable draw ordering? 11.23.23 # (and controllable) 11.23.27 # yes 11.23.52 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) 11.24.42 # I guess that this just dates back to times when an advanced WPS meant that you showed both metadata *and* a progress bar... 11.25.23 # so its maybe something to think about fixing? 11.26.21 # If nobody can give a good reason, I'd consider it a bug, yes 11.26.33 Join einhirn_ [0] (~Miranda@p5485A2ED.dip0.t-ipconnect.de) 11.29.07 # Is it perhaps to enforce drawing images after any text? So if text clears a "line", the image isn't wiped? 11.29.15 # New commit by 03funman (r25243): sd-as3525v2: sd_get_info() is already in common SD code 11.29.18 # New commit by 03funman (r25244): Clip+: correct usb product id 11.29.50 Quit scorche|sh (Ping timeout: 246 seconds) 11.29.52 Quit einhirn (Ping timeout: 246 seconds) 11.30.09 Quit anewuser () 11.37.27 Quit m3dlg (Ping timeout: 276 seconds) 11.38.44 # is there central page with statistics how buildclients perform? 11.51.37 Join evilnick__ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 11.52.45 Join ender [0] (krneki@foo.eternallybored.org) 11.53.52 Join funman [0] (~fun@28.131.193-77.rev.gaoland.net) 11.53.55 Quit funman (Changing host) 11.53.55 Join funman [0] (~fun@rockbox/developer/funman) 11.55.00 Quit evilnick_ (Ping timeout: 256 seconds) 11.55.02 Quit ender` (Ping timeout: 246 seconds) 11.59.33 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 12.17.17 Nick evilnick__ is now known as evilnick (~evilnick@ool-457bccf5.dyn.optonline.net) 12.17.39 Quit evilnick (Changing host) 12.17.39 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 12.21.07 Quit RadicalR (Quit: Nettalk6 - www.ntalk.de) 12.23.20 Join MethoS- [0] (~clemens@134.102.106.250) 12.28.55 *** Saving seen data "./dancer.seen" 12.30.03 Join webguest47 [0] (~4b4cabd8@giant.haxx.se) 12.31.06 Quit webguest47 (Client Quit) 12.31.27 Join m3dlg [0] (~m3dlg@212.183.140.4) 12.37.11 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 12.37.23 # i get USB interrupts on my fuze but both device & endpoint irq status registers are 0x0 12.48.06 Quit m3dlg (Ping timeout: 276 seconds) 12.53.57 Join watto [0] (~watto@193.203.81.165) 12.59.42 Join DV__ [0] (~DV@218.248.65.243) 13.00.29 Join PaulJam [0] (~Paule@p54BEC8D0.dip.t-dialin.net) 13.03.51 Quit DV_ (Ping timeout: 268 seconds) 13.05.36 # Nobody interested in FS#11118 about the FAT driver ? 13.09.53 # I am, but haven't had time to test it yet 13.11.43 # ok 13.18.25 # funman: Maybe it's the IRQ_ENRD0 usb status change interrupt? 13.19.25 # BTW, if I enable DEBUG build, I get a compile error in apps/gui/skin_engine/skin_parser.c 13.19.36 # (debug_wps undefined) 13.20.38 # ranmachan: should it call the i2c isr? 13.20.42 # shouldn't* 13.20.53 # ranmachan: slap JdGordon for that :) 13.21.54 # * FlynDice has found clip+ uSD and manages to get the card to STBY state but not TRAN yet. The card makes it through init just fine though. 13.22.05 # funman: Good question, that's one of the things I'd like to try, but haven't tried yet. 13.22.26 # Meanwhile I had fun rewriting ascodec to use interrupts :) 13.22.28 # http://pastebin.com/RPvTTMvU 13.22.42 # FlynDice: good! did you look at the FIXME for CGU_BASE+0x3c clock register? 13.23.17 # funman: No have'nt seen that yet 13.24.45 # ranmachan: nice 13.26.29 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 13.28.05 # Is there an easy way to postpone the ascodec_write in system_init()? 13.28.15 # Or is it maybe safe to enable interrupts at that point? 13.28.39 # ATM I have a special polling version of write just for that... 13.29.57 # ranmachan: enabling interrutps should be safe after setup_vic() 13.30.00 Join froggymana [0] (~187b533e@giant.haxx.se) 13.30.22 # (i was wondering why polling was needed and why system_init() used it) 13.30.27 # I just saw "FS#10112 - Rockbox abort: search of title when the database is created by illegal codepage. " which is bug related to the fact that mp3 tags have no preferred code page. There has been a discussion recently about that no ? 13.30.36 # i believe rockbox enable interrupts in kernel_init() 13.32.14 # Hmm, or rather than just interrupts, since I use the wakeup system I think the kernel also has be initialized sufficiently at that poit. 13.35.06 # Would it be acceptible to introduce system_init_late() in main.c and do the ascodec_write from there? 13.37.40 # or move it into power_init() for example since it's realted to power 13.38.43 # and call enable_irq() in system_init() because power_init() is called just before that in main() 13.41.15 # funman: you're a genious! or have supernatural powers... I added the shift for CGU_BASE+0x3c and am now browsing the uSD! 13.42.17 # \o/ 13.42.36 # just wild guessing, i hadn't tried to touch again this register fearing it wouldn't work .. 13.43.29 # Needs a little cleanup first but I'll commit shortly 13.43.34 # * funman waits eagerly 13.43.44 # print business cards: funman, wild guessing genius 13.44.35 # topik: i had guessed you'd do that! 13.44.51 # sure thing. pick them up later 13.45.26 # great job on the newer samsas guys 13.45.28 # FlynDice: hm i wonder if the bootloader still works after this change 13.46.05 # i guess (!) that everything will be clear once we understand how CGU_PERI divider works 13.46.19 # I'll test that before I commit 13.47.21 # i can test if you want, if it doesn't work let's just put a #ifdef BOOTLOADER 13.49.22 # Hmm, the i2c controller sucks. For safety I still have the 'while (i2c_busy())' in there, but I was hoping that since it raised the interrupts it wouldn't be busy anymore when we get around to submit the next command (when another one is queued) 13.50.13 # But: read_ctr=1267 write_ctr=200 busywaits_after_read=1779 busywaits_after_write=13794 13.50.47 # ranmachan: is there a noticeable speed difference with current method? 13.51.08 # i guess if wakeup_wait() schedules another thread we can't compare decently 13.52.16 # Well, in theory the cpu can spend time in another thread while the i2c controller is busy instead of waiting. 13.52.21 # w00t! Symmetry is now multilingual! http://themes.rockbox.org/index.php?themeid=654&target=ipodnano1g 13.52.45 # I haven't cross-checked the above busywait measurement with the unpatched version yet. 13.55.50 # How well does charging work on the e200 these days? As fast as in OF? 14.03.02 Join Connor_ [0] (~Connor@ip72-204-35-60.fv.ks.cox.net) 14.03.08 Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 14.05.09 Join Connor__ [0] (Connor@ip72-204-35-60.fv.ks.cox.net) 14.06.21 Quit Connor1 (Ping timeout: 260 seconds) 14.08.06 Quit Connor_ (Ping timeout: 264 seconds) 14.09.04 # Hmm, if I increase the i2c clock from 400KHz to 4MHz I have less busywaits :) 14.13.33 Quit JdGordon (Quit: Leaving.) 14.21.52 # what exactly mean FIRMWARE_OFFSET_FILE_LENGTH FIRMWARE_OFFSET_FILE_CRC FIRMWARE_OFFSET_FILE_DATA ? 14.22.43 # I am at the point that bootloader loads rockbox image to the memory and complains about bad checksum 14.23.43 Join Schmogel [0] (~Miranda@p3EE21FBA.dip0.t-ipconnect.de) 14.24.32 Join hebz0rl [0] (~hebz0rl@dslb-088-065-221-200.pools.arcor-ip.net) 14.25.17 # New commit by 03FlynDice (r25245): SansaAMSv2: Add support for uSD cards to sd-as3525v2.c and activate hotswap and multidrive. 14.25.20 Join TheSphinX^ [0] (~cold@p54A5CD6E.dip.t-dialin.net) 14.28.56 *** Saving seen data "./dancer.seen" 14.33.13 # green, back later! 14.35.14 Join ichthys [0] (~jaaron@128.224.252.2) 14.39.42 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.40.04 # wodz: rockbox firmware field has 2 fields to check if it loaded correctly from storage: length & a checksum 14.40.26 # length is at position 0 + FIRMWARE_OFFSET_FILE_LENGTH of the file, and data at position 0 + FIRMWARE_OFFSET_FILE_DATA 14.40.36 # ranmachan: isn't 400kHz the maximum authorized for i2c ? 14.41.33 # funman: and where is CRC stored? 14.41.58 # FIRMWARE_OFFSET_FILE_CRC 14.42.11 # have a look at bootloader/common.c: load_firmware() 14.42.53 # funman: from load_firmware() it seems that file length is not stored in firmware 14.43.37 # ah sorry, it stores the model number instead 14.44.11 # length is used in firmware/rolo.c on archoses 14.44.27 # funman: so order is CRC MODEL DATA right? 14.44.43 Join fred_99 [0] (~fred@195.6.173.23) 14.44.57 # hi 14.45.34 # wodz: looks like it (also have a look at tools/scramble.c which add this header) 14.45.46 Join stoffel [0] (~quassel@p57B4AA66.dip.t-dialin.net) 14.45.49 Join n1s [0] (~n1s@rockbox/developer/n1s) 14.48.43 # funman: Yeah, but I thought 'hey, it's both on die, let's try something higher :)' 14.48.43 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 14.49.02 # 4MHz seems to be the upper bound though, with 8MHz it doesn't boot. 14.49.26 # FlynDice: nice, works fine even in bootloader! thanks :) 14.50.12 # battery time left on an X5 : are the CURRENT_something variable the only constant to setup to have a battery time left ? 14.50.29 Join m3dlg [0] (~m3dlg@212.183.140.38) 14.51.00 # funman: does it mean I have to hack scramble.c to add new target also? 14.51.03 # fred_99: should be, try changing them to some value and see if the time changes 14.51.31 # wodz: yep, look at svn log to see when new targets were added, you have to add the same model number than in configure i think 14.52.14 # this make clear why it doesn't boot than 14.52.31 Quit froggymana (Quit: CGI:IRC) 14.52.45 # funman: I set up CURRENT_NORMAL and CURRENT_BACKLIGHT with value like 1100mAh divided by the battery_bench time, and it seems to work. 14.54.11 # funman: I can put a patch if it can help. 14.54.13 # fred_99: that's correct for CURRENT_NORMAL, CURRENT_BACKLIGHT is added to CURRENT_NORMAL to calculate current use when backlight is on 14.55.28 # funman: ah .... I didn't do this exactly ..... 14.58.07 # I can't write to µSD either 14.59.08 Quit Hillshum (Ping timeout: 264 seconds) 14.59.30 # fred_99: CURRENT_NORMAL = 1100/hours_lcd_off, CURRENT_BACKLIGHT = 1100/(hours_lcd_off-hours_lcd_on) 15.01.29 # funman: for exemple (in my case), CURRENT_NORMAL = 1100mAh / 7h15 ~ 150 and CURRENT_BACKLIGHT = (1100mAh / 4h26) - CURRENT_NORMAL ~ 100 15.01.59 # funman: do you agree ? 15.02.30 Quit Rob2222 (Read error: Connection reset by peer) 15.02.33 # i have no opinion, post your runtimes with the patch on flyspray so we can check 15.04.00 # funman: ok .... thanks 15.11.12 Quit DV__ (Ping timeout: 260 seconds) 15.11.14 Quit DerPapst (Quit: Leaving.) 15.12.38 Quit m3dlg (Ping timeout: 258 seconds) 15.13.08 Join Rob2222 [0] (~Miranda@p4FDC946C.dip.t-dialin.net) 15.13.25 Join DerPapst [0] (~DerPapst@p4FE8FC99.dip.t-dialin.net) 15.13.42 # funman: what do You mean by 'the same model number than in configure'? 15.13.46 Quit DerPapst (Client Quit) 15.15.36 Join Farthen [0] (~chatzilla@e179234232.adsl.alicedsl.de) 15.16.12 # clip+ has target_id=66 in tools/configure , and modelnum=66 in tools/scramble.c 15.21.00 # funman: look for irivers iriver h100 has target_id=11 in configure, and modelnum=1 in scramble.c 15.21.16 # the same for iaudios 15.23.23 # ah it's not in configure, it has to be the same MODEL_NUMBER defined in firmware/export/config/xxmodel.h 15.24.10 # ideally target_id should be MODEL_NUMBER 15.24.53 # YUPI!!!! I booted rockbox on mpio hd200 :-) 15.25.08 # good! 15.26.39 # and how should I choose MODEL_NUMBER? 15.27.32 # unique number (grep for it in config/*.h to see if no other defines it) 15.28.37 # All I can say is that adding new target to rockbox is a real pain. 15.29.17 Quit robin0800 (Ping timeout: 265 seconds) 15.29.37 # I am not talking about hardware and so on but on source structure and documentation 15.30.22 # wodz: did you see http://www.rockbox.org/wiki/PortingHowTo ? 15.30.57 # of course 15.32.29 # i agree there is room for improvements but once you've finished adding a target you probably want to work on it instead of on the target tree 15.32.35 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-kyfhztesikadsffz) 15.32.41 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 15.32.49 # does anyone have an actual arm-linux system they can test something on? 15.33.22 # i have arm926-ejs not too far, just need 5 minutes to plug it again 15.34.14 # funman: would you mind trying my latest libtremor patch when you get a chance 15.34.29 # see if it gets correct output and maybe bench mark it if thats not too much trouble 15.34.36 Part LinusN 15.34.47 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.35.33 # http://www.rockbox.org/wiki/FasterMDCT#libtremor_upstream_merge 15.35.50 # it works on QEMU but trying real hardware would be nice, plus it takes 30 minutes to compile in QEMU :) 15.37.46 # saratoga: i'm impressed you do the work to push your improvements upstream 15.37.51 Quit hebz0rl (Read error: Connection reset by peer) 15.39.30 # FlynDice: good work! :) I just noticed the fuzev2 OF sets up GPIOA isr too but didn't think further about it, looks like it was for microsd 15.39.59 # saratoga: I have some. I can try later today 15.41.29 # saratoga: is there a sample program to test output/benchmark in tremor svn ? 15.42.14 # One arm5 and one arm7 15.44.32 # saratoga: ogg_int32_t isn't defined in asm_arm.h (needed for MULT32 proto) 15.46.08 # kugel: you could skip lcd code and enable buttonlight only in rockbox.sansa to see if storage works 15.46.38 # and how does that help? 15.47.05 # power on fuzev2: if buttonlight is on, storage works 15.48.45 # I assume it works, whether it does or not doesn't get me further though 15.49.28 Quit funman (Quit: free(random());) 15.50.08 Join toffe82 [0] (~chatzilla@12.169.218.14) 15.51.14 # I have the strong feeling that the fuzev2 also has slighly different versions, it does something strange with GPIOA 0 and 5 15.51.16 Quit ranmachan (Ping timeout: 256 seconds) 15.51.21 Quit simabeis_ (Ping timeout: 258 seconds) 15.51.26 Quit wodz (Quit: CGI:IRC) 15.51.31 # and I think backlight is also done through sw pwm, but I don't know for sure 15.51.41 Quit bzed (Ping timeout: 248 seconds) 15.52.12 Quit knittl (Ping timeout: 245 seconds) 15.55.03 Join knittl [0] (~knittl@thehappy.de) 15.56.41 Join bzed [0] (~bzed@devel.recluse.de) 15.57.22 Join CGL [0] (~CGL@190.79.141.37) 15.58.22 Join ranmachan [0] (ranma@mx.tdiedrich.de) 15.58.57 Join simabeis [0] (~simabeis@lobmenschen.de) 16.04.16 Join Strife1989 [0] (~Strife89@adsl-220-102-96.mcn.bellsouth.net) 16.09.21 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 16.09.32 Join hebz0rl [0] (~hebz0rl@dslb-088-065-221-200.pools.arcor-ip.net) 16.13.34 # funman: sorry, "make example" then "./ivorbisfile_example < file.ogg > out.raw" 16.14.10 Quit TheSphinX^ (Quit: XChat) 16.15.55 # which linux distro was this tested on? 16.18.43 # funman: could you try commenting out the include to asm_arm.h in fft-ffmpeg.c? 16.18.50 # i think that was added by mistake at some point 16.19.36 # http://www.rockbox.org/wiki/FasterMDCT#libtremor_upstream_merge 16.19.40 # i put the instructions to test here 16.19.47 # if anyone else wants to try 16.24.39 # GPIOA_4 seems to indicate some fuzev2 revision 16.25.03 # saratoga: how much faster is it compared to the tremor mdct ? 16.26.59 # merbzt: about 10% faster verses are well optimized version of the tremor IMDCT 16.27.15 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) 16.27.19 # sorry I mean vorbis gets 10% faster 16.28.02 # overall its probably something like 20-25% faster for just the mdct, verses stock tremor's mdct (no rockbox optimizations) probably something like 50% faster 16.28.07 # no change in memory/code footprint ? 16.28.17 # it uses 2KB more RAM, though that can probably be fixed 16.28.24 # or at least reduced 16.28.52 # impressive 16.28.57 *** Saving seen data "./dancer.seen" 16.29.01 # i don't remember the exact numbers, but I think we saved something like 3MHz over stock mdct, then when we rewrote it we got another 3 or so MHz faster 16.29.10 Quit mikroflops (Remote host closed the connection) 16.29.31 # but i'd love to see some numbers for the patch above, not just extrapolations from rockbox's hacked up version 16.30.07 # cool work anyway 16.31.11 # was the half_mdct way of doing stuff to hard to implement? 16.35.04 Join m3dlg [0] (~m3dlg@212.183.140.6) 16.35.18 Quit Strife1989 (Remote host closed the connection) 16.39.17 # merbzt: not too hard I think, but its not a huge improvement so we haven't gotten around to it 16.39.31 # theres still a lot more places this code could be optimized 16.39.37 # ok 16.39.38 # i expect to squeeze another 2-3 MHz out of it over time 16.39.58 # eventually folding in the windowing code to the last part of the IMDCT would probably help a lot 16.40.09 # liba52 in rockbox already does this 16.40.31 # would save a loop and probably some load/stores 16.57.12 Quit mt (Ping timeout: 240 seconds) 16.57.33 # saratoga: didn't i say that and you said that it's generally accepted the best way is to window separately? :P 16.57.47 # Unhelpful: I don't think so 16.58.04 # folding it in obviously saves you at least some loop overhead, its just much harder to do in a general way 16.58.22 # since different codecs have different blocks 16.58.35 # and some load/store overhead given that at *some* point we may have to deal w/ data that is not in iram? 17.00.02 # you might trigger register starvation also 17.00.19 # register starvation is a forgone conclusion on arm 17.02.06 # rockbox optimization would be a lot more fun if MIPS had won the embedded space 17.02.16 # and i imagine the code in question would be asm, so we can decide carefully how much of what to load, and when 17.02.41 Join funman [0] (~fun@rockbox/developer/funman) 17.03.45 # saratoga: running the tests, example didn't build with the patch because of missing MB declaration (any program using the lib wouldn't link). I moved it to asm_arm.h and added back the memory barrier 17.04.22 Quit m3dlg (Ping timeout: 256 seconds) 17.05.10 # funman: did you have to manually define ARM_ASM? 17.05.24 # it sounds like the make script didn't handle it for me in QEMU because it compiled and ran fine for me 17.05.29 Nick ender is now known as ender` (krneki@foo.eternallybored.org) 17.05.47 # no 17.05.59 # huh probably some QEMU weirdness then 17.06.01 # does it build now? 17.06.22 # yep, i'll paste the patch i used 17.07.24 # thanks! 17.07.28 # funman: sd writes are no longer disabled for sd-as3525v2.c is that correct? 17.07.37 # by the way, did it decode correctly? 17.08.02 # md5 differ 17.08.23 Quit robin0800 (Remote host closed the connection) 17.09.14 # funman: yeah it probably will since the transform uses a different algorithm, mostly i'm curious if it sounds like audio 17.09.17 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.09.43 # the algorithm is correct so mostly i want to make sure I haven't made some horrible mistake porting it 17.10.17 # if i use ffplay -f u32le i got a float exception 17.10.46 Join webguest04 [0] (~59bdbf64@giant.haxx.se) 17.11.04 # funman: does "./ivorbisfile_example < file.ogg > out.raw" work? 17.11.15 Quit webguest04 (Client Quit) 17.11.43 # yes, same output size for both 17.12.21 # sox --rate 44100 -c 2 --bits 16 -s out.raw out.wav 17.12.25 # see if its audio or just crap 17.12.45 # hopefully your distro has sox 17.13.28 # sorry have to run 17.14.37 # works with -t raw 17.15.03 Join mt [0] (~chatzilla@41.233.142.114) 17.17.15 # saratoga: http://pastie.org/875646 results with my diff to your diff 17.17.49 # the patched version spends more time in user time it seems 17.19.53 # listened to a whole file: excellent audio 17.20.52 # FlynDice: writes are still disabled : #if 1 return -1 # else sd_transfer_sectors(...) #endif 17.21.54 # yes, I just worked through that, enabling writes seems to not work at the moment... 17.31.34 # oops i spotted an error 17.32.13 # removing the timeout check (max=0x40000) in send_cmd locks the clip, timeout failing is not detected 17.35.02 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 17.35.09 Quit n1s (Ping timeout: 252 seconds) 17.39.28 # funman: which arm cpu is this anyway? 17.39.48 # arm926-ejs 17.40.23 # New commit by 03funman (r25246): sd-as3525v2: correctly check send_cmd return value (which is boolean) 17.42.15 # hm write is still locking up 17.43.32 # funman: do i need to do something special to apply that patch? 17.43.51 # oh its a diff against the patch not the code 17.44.43 # btw why did you remove memory barrier? 17.45.06 # i didn't realize i did 17.45.15 # probabaly just got lost when syncing the files 17.45.28 # funman: could you diff against the source tree, I can't figure out how to apply this patch 17.45.59 # plus its mostly just changing the patch headers to french :) 17.47.31 # ^^ 17.48.33 # http://pastebin.org/117033 17.50.10 Join B4gder [0] (~daniel@rockbox/developer/bagder) 17.50.24 # write still locks up if i remove CMD_CHECK_CRC_BIT, other threads are still running 17.50.34 Quit pamaury (Quit: Quitte) 17.53.22 # funman: maximum size of that pastebin was exceeded? was there anything changed beside misc.h and asm_arm.h? i can fix those myself 17.53.37 Part knittl 17.53.46 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 17.54.10 # i don't think so 17.55.48 # i moved MB from misc.h to asm_arm.h, commented out include asm_arm.h in fft-ffmpeg.c 17.56.02 # sounds good 17.56.14 # any chance you could try this patch before I send it to the mailing list? 17.56.15 # http://www.duke.edu/~mgg6/rockbox/tremor_ffmpeg_imdctv6.patch 17.58.07 # huh did the patch actually get slower on your system then stock? 37.51s vs. 42.61s 17.59.21 # looks like it but i made only 1 run though 17.59.54 # thats odd, it was faster on x86 18.01.53 Quit petur (Quit: work->home) 18.08.07 Join jfc^2 [0] (~john@dpc6682208002.direcpc.com) 18.08.20 Join __arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) 18.09.38 # saratoga: only user time is significative, right? 18.10.17 # Torne: any chance you could try mkamsboot on last released clipv2 OF ? 18.11.27 # not until the weekend; at work atm and won't be home tonight 18.11.34 # funman: yeah but the patched one took more user time :) 18.11.43 # original, 3 runs: 39.84, 40.82, 40.77 18.11.43 Quit _arbingordon (Ping timeout: 264 seconds) 18.11.43 Quit jfc (Ping timeout: 264 seconds) 18.11.53 # yep :/ 18.12.08 # patched one: 1st run 40.65 18.12.45 # 40.14 18.13.14 Join bertrik [0] (~5a911fc2@giant.haxx.se) 18.13.27 # 40.24 18.14.34 Quit bertrik (Client Quit) 18.14.36 # so it's only marginally faster, not even clearly faster than original 18.15.16 Join bertrik [0] (~5a911fc2@giant.haxx.se) 18.15.43 # funman: I don't understand why, in rockbox is it substantially faster on the CPU 18.15.52 # hm i didn't specify -mcpu flags 18.16.03 # "on that cpu" 18.16.10 # funman, does the as3525v2 really have 1 MB IRAM? 18.16.25 # bertrik: the Clip+ at least, yes 18.16.35 # but it looked a bit slower than DRAM 18.17.17 # funman: did you compile the stock tremor, or use one that came with the OS? 18.17.28 # svn 18.18.26 # ok, there was some joke going around about it having double the clipv1 size (640k) and I thought that maybe an mistake was made thinking that 0x100000 was twice as much as 0x50000 18.19.25 # true i made the mistake, but i also made it when testing so i really tested 0x100000 18.19.42 # ffs 18.19.52 # i really deserve slapping for that :p 18.20.06 # I need assistance ... I can't get this lcd to work 18.20.10 Quit bertrik (Client Quit) 18.20.38 # saratoga: testing with CFLAGS=-O3 -mcpu=arm926ej-s 18.20.47 # I don't even know whether SSP is involved or not. lcd_init_device does messes with ssp, but the other lcd functions look similar to the fuzev1 ones 18.23.40 # kugel: could it be that there are 2 different screens ? 18.23.42 # if someone wants to help me, I can offer my disassembly, my local code and/or a spare fuzev2 18.24.45 # it looks like the OF looks gpio4 for some fuze revision; but I can only see references to the corresponding global variable in the init functions 18.25.01 # lcd_window_*, clear_display() all deal with dbop 18.25.33 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 18.25.42 # saratoga: with -O3 -mcpu=arm926ej-s: original medium time (3 runs) : 37.59s, patched medium time (3 runs) : 34.72s 18.26.28 # funman: ok so its a little faster 18.26.32 # whats the clock speed btw? 18.27.02 # not sure, 250 or 300 18.27.11 # and the track length? 18.27.41 # oh 246 seconds 18.28.21 # http://dm6446.org/ says 256.6-297MHz so I suppose 297MHz 18.28.27 # I should check if the dbop is activated properly 18.28.33 # so you're doing 42Mhz realtime decoding 18.28.50 # i suppose the percentage difference is small since the rest of the decoder is much slower then in rockbox 18.29.00 *** Saving seen data "./dancer.seen" 18.29.14 # kugel: you have 2 fuzev2 ? 18.29.41 # saratoga: you want another test, or can i shut it down? 18.29.47 # funman: thats fine 18.29.54 # i'd really rather you work on the clip anyway :) 18.29.59 # ^^ 18.30.20 # i am looking at usb on the fuze and ranmachan is looking at recordign on c200v2 18.30.43 # funman: yes 18.30.48 # ranmachan: btw i just though perhaps we could use i2c interrupts for headphone plug/unplug detection? 18.31.41 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.32.08 # kugel: i'd be glad if i can help you somehow, i'll give you my address 18.35.50 Join m3dlg [0] (~m3dlg@212.183.140.96) 18.37.11 # I could test which interrupt the headphone detection generates I suppose, it's not necessarily going to be the i2c interrupt. 18.37.43 # Note that "The detection is only working as long as the headphone stage is in power down mode" 18.38.07 # hm so we can detect plug but not unplug 18.38.10 # So I suppose you can't detect unplugging the headphones while music is playing over the headphones 18.38.45 # pixelma: So where is the pink transparent then? 18.40.04 # IRQ 9 is marked "AUDIO IRQ" in the vic interrupt sources, so I'd assume that's the one that'll get triggered 18.40.39 # ranmachan: i see you dumped the CGU_* regs while playing, powered over USB, how hard would it be to dump the regs with battery power, in the case the OF changes its clocking while powered by USB ? 18.41.43 # Hmm, I thought I also did that... 18.42.04 # i believe you had unplugged the battery at that time 18.42.40 # http://forums.rockbox.org/index.php?topic=14064.msg162645#msg162645 < i wanted to compare with what we do 18.42.55 # funman: when you say "CURRENT_BACKLIGHT = 1100/(hours_lcd_off-hours_lcd_on)" are you sure ? looking in the config files it seems that the constant CURRENT_BACKLIGHT is almost all the time smaller than CURRENT_NORMAL, which is not the case in your calcul. Can you confirm ? 18.43.48 # fred_99: you're right, it's (1100/hours_lcd_off) - (1100/hours_lcd_on), i suck at maths :) 18.44.22 # funman: ok thanks ..... so do I ;) 18.45.31 # funman: the opposite should work perfect ;) 18.45.40 # ranmachan: also could you look at MCI_CLOCK : 0xC8000004 and 0xC8020004 ? 18.47.57 # AlexP: in all the other bitmaps (besides backdrops) and not on greyscale 18.48.30 # OK, I've been under a misapprehension for years then :) 18.48.40 # ranmachan: i'll first look at those registers, if there is some significant difference we can assume it'll be the same with battery power 18.48.53 # AlexP: you could have tried ;) 18.49.19 # yeah, could have 18.50.40 Join jgarvey [0] (~jgarvey@cpe-065-190-069-073.nc.res.rr.com) 18.50.55 # ranmachan: ah 0x0-0x40 are mirrored at 0x40-0x80 18.51.20 # Yeah, I know :) 18.51.27 # IIRC the Datasheet was claiming otherwise 18.51.55 # could be sandisk diffs from the original design, they put a pl180 instead of the nand controller at least 18.52.46 # Hmm, or maybe not. Looks like I was just misreading it? 18.52.48 # saratoga: I'll have some more results for you in a few minutes 18.53.02 # gevaerts: thanks 18.53.12 # gevaerts: does your system have IRAM? 18.53.39 # any easy way to find out? 18.53.47 # it's my phone 18.53.50 # they run plla at 216MHz and fclk to half of that: 108MHz 18.55.22 # pclk=extmem_clk=54MHz 18.56.12 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.56.26 # funman: [edit3] added 18.56.39 # MCI_CLOCK is 0x301 18.59.32 # only CGU_IRQ & CGU_INTCTRL change 19.00.20 # saratoga: http://pastie.org/875804 has my results. Numbers are user time in seconds, averaged over 5 runs 19.00.26 # + bit 15 of CGU_PERI = SDMCI (i assume you had no card and it's on with USB mode) 19.00.30 # The output sounds as expected 19.00.47 # I used the rockbox testfiles 19.01.18 # I did similar things as funman to get it to compile, otherwise nothing special 19.01.26 # thanks! 19.01.34 # btw, do you have IRAM on that system? 19.01.40 # funman: I just put a write watchpoint on 0xC80F0014 and it's toggling between 0ef3c38d and 0ef3c3d1 (on battery, playering mp3) 19.02.35 # mciclk means NO widebus, powersaving enabled, pclk/4 == 13.5MHz 19.02.41 # FlynDice: ^ 19.03.12 # interesting 19.03.25 Quit m3dlg (Ping timeout: 246 seconds) 19.04.09 # yes very interesting: it changes extmem_clk 19.05.04 # saratoga: I'm trying to find out. It's an OMAP3430, which has a cortex-a8 19.05.40 # * gevaerts doesn't really know where to find this information 19.05.40 # hm no, extmem_clk stays at 54MHz but pclk changes between 27MHz & 54MHz 19.05.48 # ranmachan: how fast does it toggle? 19.05.57 # funman: sub_1660 is doing the toggling 19.06.08 # well if you don't know its ok, was just curious if enabling it would make any difference 19.06.13 # funman: Good question 19.06.23 # I also wouldn't know how to use it :) 19.06.40 # At 0x1712 and 0x171c are the writes 19.07.42 # there's also calls to code changing pll freqs in there 19.08.15 # it asks for 65MHz but got the closer possible freq (54) 19.10.08 # USB phy is still enabled with usb unplugged 19.11.19 # ide clk at 108MHz 19.12.03 # memstick at 72MHz 19.12.49 # saratoga: http://pastie.org/875804 has the numbers converted to MHz as well 19.12.51 Join perfectdrug [0] (~marko@p5B0ED25F.dip.t-dialin.net) 19.12.59 Quit B4gder (Ping timeout: 256 seconds) 19.13.02 # The toggles look semirandom, if I can trust TIMER2... 19.13.17 # At least not at regular intervals. 19.13.37 Join captainewkl [0] (~2669ecc2@gateway/web/freenode/x-lzdaohivferjdoaj) 19.14.08 # like several time per seconds, or each 10 seconds? 19.14.08 Quit captainewkl (Client Quit) 19.15.26 # Several times per second 19.15.46 # For each resume I'd hear a very short bit of music 19.16.02 Quit kugel (Remote host closed the connection) 19.16.39 # TIMER2_CONTROL: 000000e0 19.17.27 # TIMER2_VALUE between resumes: 00008867 000056f9 00001e8d 0000b5f5 00009993 00000bd2 19.19.07 # Hmm, at 16bit it might just be wrapping around multiple times though... 19.19.16 # Since prescaler is 1 19.19.52 Quit CGL (Ping timeout: 246 seconds) 19.20.21 Join FOAD_ [0] (~dok@dinah.blub.net) 19.21.28 # well anyway it's fast 19.21.34 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 19.22.17 Quit tipi^ (Ping timeout: 246 seconds) 19.24.09 Quit FOAD (Ping timeout: 265 seconds) 19.24.09 Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) 19.25.41 Quit Horscht (Quit: Verlassend) 19.30.51 # gevaerts: wow your system is really fast 19.31.52 Quit DerPapst (Quit: Leaving.) 19.32.23 # sorry ... .I'm really stupid but I don't see how to submit a patch in FlySpray. Can anybody help me 19.32.39 Quit funman (Quit: free(random());) 19.34.11 # fred_99: add new task button on the flyspray page 19.36.41 # saratoga: I don't see this button on my page 19.36.55 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 19.36.57 # fred_99: Are you registered and logged in ? 19.37.27 # saratoga: I'm not sure, I received the mail and confirm, but log or not my page is the same 19.37.58 # figure out if you're logged in or not, then come back here if it still doesn't work 19.38.29 # how do you see if you are logged in ? 19.39.00 # I will try with another browser .... and see what appens 19.41.04 # what are you submitting on flyspray? 19.42.02 # fred_99: Also, look right under the rockbox logo on flyspray, if you see empty text fields you're not logged in. 19.42.27 Quit hebz0rl (Quit: Ex-Chat) 19.43.13 # mt: thanks .....It's ok now 19.44.13 # saratoga: I don't know how to read ..... thats it ...... confirmation code pre-filled with my email ..... but now it's OK 19.44.28 # I have the famous button 19.44.35 Join gill0r [0] (~gill0r@g225219054.adsl.alicedsl.de) 19.45.10 # Good news everyone 19.45.16 # Rockbox accepted for gsoc 19.45.18 # the wiki says it's better to ask here before submitting a patch, so I will 19.46.14 # mt: cool! 19.46.24 Join captainewkl [0] (~2669ecc2@gateway/web/freenode/x-yzkdbowswcwgvhwr) 19.47.00 # my patch only add the CURRENT_NORMAL and CURRENT_BACKLIGHT values to the iaudiox5.h file 19.47.22 # is it OK to submit ? 19.47.32 # sure 19.47.49 # saratoga: OK .... so I try 19.48.31 # mt: Cool - where is that said? 19.49.05 Quit __arbingordon (Quit: `) 19.49.07 # AlexP: I just asked danderson on #gsoc 19.49.25 # I got a notification about it too it seems 19.49.26 # ah right, good stuff. I just noticed that the list hasn't been published yet :) 19.49.38 # excellent :) 19.49.51 # "Your Organization Application for "Rockbox" in Google Summer of Code 2010 has been accepted." 19.50.01 # saratoga: do I have to choose 3.4 when I did it with the SVN ? 19.50.36 # let me rephrase that: I got 7(!) notifications about this 19.50.37 # fred_99: if this is so difficult maybe you could just tell me what the current normal value is and i will type it myself 19.50.39 # all identical 19.50.41 # Bagder: Beware .. you might receive like 6+ more acceptance mails. There's some bug with their automailer. :) 19.52.00 Quit stoffel (Remote host closed the connection) 19.52.31 # mt: So are you thinking of applying by any chance? :) 19.53.11 # saratoga: sorry to bother ..... it was suppose to be the first, and certainly would have been the last ..... as you like CURRENT_NORMAL = 152 and CURRENT_BACKLIGHT = 96 19.53.27 # fred_99: i don't think those values are reasonable 19.53.46 # AlexP: Probably yes :). I'll just have to check some stuff by the end of the month to be able to determine whether I'd have enough time. 19.53.56 # mt: I don't get any mails, I get them in their weirdo gsoc web app 19.54.12 # ah no 19.54.17 # wrong, I get mails too 19.55.24 # :) 19.56.02 # saratoga: reading a bin powermgmt.c .... and listening to funman , and testing it .... OK for not so long to trust it ;) ..... it was my calcul 19.56.44 # i think you're off by at least a factor of 2 19.56.45 # saratoga: I keep it and in fue days when I will know more I will submit the patch 19.57.04 # how did you calculate that value? 19.58.02 # CURRENT_NORMAL = 1100mAh / 7h15 ~ 150 and CURRENT_BACKLIGHT = (1100mAh / 4h26) - CURRENT_NORMAL ~ 100 19.58.50 Join petur [0] (~peter@78-21-207-106.access.telenet.be) 19.58.50 Quit petur (Changing host) 19.58.50 Join petur [0] (~peter@rockbox/developer/petur) 19.59.01 # fred_99: the wiki lists 17+ hours for the X5, why did you use 7 hours? 20.01.00 # fred_99: because it should be for a x5L but mine is x5 , and I have rockbox for several years now and changed the battery once, and never be abble to lissten to music more than 6 or 7 hours 20.01.54 Join DerPapst [0] (~DerPapst@p4FE8FC99.dip.t-dialin.net) 20.01.57 # the battery type doesn't change the amount of power the player uses 20.01.57 # saratoga: so the read on the battery_bench file for me looks good 20.02.09 # I agree 20.02.11 # and if your player is only getting 6 or 7 hours theres obviously something wrong with your battery 20.02.29 # so assuming your broken battery works as well as a new battery is not a very good idea 20.02.50 # I only use rockbox ..... 20.03.05 # I already changed my battery 20.03.15 # soldering and everything 20.03.36 # is your new battery half the capacity of the old one? 20.03.39 # and with the new ol one 20.03.55 # GSOC list is out btw: http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010 20.04.00 # fred_99: maybe you've already said this, but which codecs do you use? 20.04.01 # and the new new one ..... the working time was the same 20.04.05 # looking at the wiki, it looks like maybe 65mA and 25mA for the backlight 20.04.21 # http://www.rockbox.org/wiki/BuyersGuide says 8 to 12 hours for the X5 20.04.22 # let me check 20.04.54 # gevaerts: you mean for the test ? 20.04.57 # yes 20.05.04 # or in general 20.06.32 # the X5Ls should have 35 hours (according to the manufacturer and considering that my M5L got almost 52 hours with fresh batteries...) 20.06.40 # gevaerts: in general it depends a lot 20.07.56 Quit Strife89 (Read error: Connection timed out) 20.08.06 # pixelma: I guess I have a wrong config from the beginning 20.08.30 Join Strife89 [0] (~michael@adsl-220-102-96.mcn.bellsouth.net) 20.08.31 # gevaerts: let me 2 minutes I check wich codec I used 20.08.32 # K5L is a 2200mah battery? 20.08.38 # fred_99: also, do you use EQ? 20.08.41 # nah, the Iaudio batteries seem to degrade relatively quickly 20.08.49 # gevaerts: no 20.09.26 # gevaerts: standard wps a bit modified 20.09.45 # both benches I've seen look to use about 65 mA so i'm going to use that 20.11.34 # saratoga: next time I will change my battery, I will do a bench 20.11.34 Quit Strife89 (Client Quit) 20.11.34 # ok just put it on the wiki or something, no need to tell me about it 20.11.45 # New commit by 03saratoga (r25247): Add runtime estimation for the iaudio X5. 20.12.57 # gevaerts: ogg is OK or you need the codec 20.12.58 # gevaerts: sorry I'm always confusing between container and codec 20.13.20 # in this case it's clear enough :) 20.15.29 # FlynDice: I can confirm that after r25245 reading from an 8GB SDHC card works fine in the Clip+ 8GB 20.16.09 # fred_99: unless you use really high bitrates, vorbis should give reasonably good runtimes. mp3 might give you a bit more though 20.16.14 Quit flydutch (Quit: /* empty */) 20.17.14 # some happy fellow could update /topic 20.17.19 # gevaerts: ffvorbis 20.17.46 # gevaerts: ~240 kbps for the bench 20.18.34 # gevaerts: I suppose it depends of the frequency ..... but MP3 128 it's no way for me 20.18.54 # fred_99: have a look at http://www.rockbox.org/wiki/CodecPerformanceComparison for the full details 20.18.59 # gevaerts: I don't have dog ears but not less than 200 20.19.06 # sure :) 20.19.32 # gevaerts: it was VBR of course 20.20.03 # Basically, with the current rockbox code, on coldfire mp3 needs less CPU than vorbis, for similar quality 20.20.17 Topic "Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community | Rockbox has been accepted for GSOC 2010! Potential students see http://www.rockbox.org/wiki/SummerOfCode2010" by ChanServ (ChanServ@services.) 20.20.41 # gevaerts: thanks I will have a look, but I won't reencode my CD's which are in ogg ..... because I don't think at all I cann double the playing time 20.20.41 # e.g. 320kbps mp3 needs about as much (or even slightly less) as 96kbps vorbis 20.20.54 Quit phanboy_iv (Read error: Connection reset by peer) 20.21.11 # oh, it definitely won't double. Basically anything that's less than 50MHz on that table is reasonable 20.21.30 # gevaerts: not an integrist but mp3 is not free, and quality in lower 20.21.40 # try musepack then :) 20.21.47 # gevaerts: but not the subject 20.22.06 # wavpack or any other lossless codec is even better :-) 20.22.24 # domonoky: not on a hard disk player I'd say 20.22.38 # Also not according to that table :) 20.22.46 # especially on those that only have 16MB RAM 20.22.58 # wavpack needs more CPU than mp3 or mpc 20.23.04 # gevaerts: its better for quality, not for runtime.. you have to make some tradeoff :-) 20.23.19 Join stooo [0] (~sto@e180224104.adsl.alicedsl.de) 20.24.06 # I will have a look ..... thanks 20.24.22 # flac is very efficient to decode but I don't know how much it makes up for the disk spinnimg 20.25.56 Part stooo 20.28.31 # last thing , on the iaudioruntime page there is a battery bench file from PhilipBarton showing something like 7 hours too 20.29.01 *** Saving seen data "./dancer.seen" 20.30.32 # and another showing 17h is with a CF instead of the HDD, and another stops at something like 7 hours and the guy write 17 hours in the table 20.31.06 # I will try my patch for some time and will come back 20.31.17 # goodbye 20.31.17 Quit liar (Quit: partey) 20.31.24 Quit fred_99 (Quit: Ex-Chat) 20.36.49 Quit PaulJam (Ping timeout: 240 seconds) 20.41.05 Join froggyman [0] (~sopgenort@pool-72-69-76-103.chi01.dsl-w.verizon.net) 20.49.51 Quit chaos (Read error: Operation timed out) 20.49.53 Quit Llorean (Quit: Leaving.) 20.50.18 Join chaos [0] (~chaos@gentoo/user/ch4os) 20.50.19 Join Llorean [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) 20.50.19 Quit Llorean (Changing host) 20.50.19 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 20.53.42 Quit parafin (Ping timeout: 260 seconds) 20.56.32 Join parafin [0] (parafin@paraf.in) 20.56.37 Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de) 21.11.25 Part watto 21.12.54 Quit pixelma (Disconnected by services) 21.12.55 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.13.09 Quit amiconn (Disconnected by services) 21.13.11 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.13.14 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.13.18 Join einhirn [0] (~Miranda@p5485A2ED.dip0.t-ipconnect.de) 21.13.37 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.20.57 Join raket2 [0] (~Earworm@99-59-195-147.lightspeed.livnmi.sbcglobal.net) 21.21.53 Join dottedmag [0] (~dottedmag@altlinux/developer/dottedmag) 21.22.06 # whats the file size limit for fat32 in rockbox? 21.22.15 # 2GB? 21.22.40 # hey peoples. strange problem. my battery dies when i run chkdsk on my ipod so I can never complete the scan. What say you? I have an error on the 120gb drive, so I need to fix it. (aside of replacing the battery of course) 21.23.08 Join m3dlg [0] (~m3dlg@212.183.140.102) 21.23.18 # raket2: Can you charge it in the OF first and then try? 21.23.26 # OF ? 21.23.34 # Original Firmware 21.24.11 # sure i could try. so charge it in the OF, but should i revert it to rockbox once done? 21.24.17 # are you running the scan in the OF? 21.24.24 # i ran it under rockbox 21.24.27 # i don't think doing it in rockbox is a good idea 21.24.44 # oh crap. ok 21.24.45 # do the scan in the OF too, or you might get battery problems again 21.25.12 # i thought fat32 had a 4GB limit? 21.25.26 # ok, I shall try soon, and hopefully that will work 21.25.28 # saratoga: Sorry, it is 4GB. My bad 21.25.41 # raket2: Rockbox on your ipod doesn't charge at full speed over USB, so if you are doing disk intensive things the battery can run down while in use 21.26.20 # AlexP: but it does charge at full speed under the OF ? 21.26.23 # And scanning for errors is pretty disk intensive :) 21.26.25 # raket2: yes 21.26.35 # cool! bbl 21.29.22 Quit raket2 (Quit: Leaving.) 21.30.09 Join phanboy4 [0] (~benji@gate-20.spsu.edu) 21.32.39 Join GHF [0] (~meow@unaffiliated/ghf) 21.39.21 Join p3tur [0] (~petur@rockbox/developer/petur) 21.41.29 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 21.50.42 Quit bluebrother (Disconnected by services) 21.50.43 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 21.57.46 Join anewuser [0] (anewuser@unaffiliated/anewuser) 22.02.55 # we could use a new "project news" entry about the successfull gsoc news :-) 22.05.02 # indeed 22.05.14 Join Bug2000 [0] (~bug@unaffiliated/bug2000) 22.05.15 # Hey. 22.05.21 # I just found out rockbox lies. 22.05.59 # I run in on my Sansa Clip v1 and it works perfectly fine. 22.06.26 # Except for the fact that I reduced the volume up to -74db. At which point rockbox change the sound icon to no sound. 22.06.30 Part dottedmag 22.06.46 # Yet, I can still hear the playback of the music. Which in other words, means it's not silent even though rockbox claims it to be. 22.07.09 Quit einhirn (Ping timeout: 246 seconds) 22.07.49 # So mute isn't yet implemented on a port that isn't entirely complete yet? 22.07.54 # Have you filed a proper bug report on this? 22.09.33 # Maybe if you turn it to maximum for a while, your ears will be rockbox compatible and you won't hear anything at -74 22.09.46 # Llorean: I wouldn't care if it's not implanted, heck, even if it wouldn't have mute. I just have problems with it claiming it's mute :P 22.10.07 # Bug2000: Then file a proper bug report. 22.10.11 # gevaerts: lol. That's an interesting idea. 22.10.14 # Llorean: K, sec. 22.11.00 # Uha. >.< I forgot, I'm not using the latest version. Hopefuly I'll remember to upgrade in the morning and see if I can still hear at lowest sound level, if so I'll hopefully report it. 22.11.08 # Right now I'm too tierd to do so. Sorry for bothering. 22.11.49 # gevaerts: Still, it's pretty funny to hear at -74 as it's quieter then other sounds around. Whenever it's the clicks made by clicking the sansa clip buttons or the clock. 22.13.08 Join fred_99 [0] (~fred@bem87-1-88-174-140-49.fbx.proxad.net) 22.14.46 Quit fred_99 (Client Quit) 22.15.02 Join fred_99 [0] (~fred@bem87-1-88-174-140-49.fbx.proxad.net) 22.19.07 Join einhirn [0] (Miranda@vpn10.rz.tu-clausthal.de) 22.26.13 Quit rvvs89 (Ping timeout: 260 seconds) 22.27.26 Join rvvs89 [0] (robotnik@bright-snat.ucc.asn.au) 22.29.02 *** Saving seen data "./dancer.seen" 22.30.59 # Hmm, my third plugin is ready! A game this time: http://img245.imageshack.us/img245/2408/dsc03356m.jpg It's first battleship for rockbox, isn't it? 22.31.57 # leavittx: nice graphics ! 22.33.01 # Nice indeed. :) 22.33.05 # domonoky: thanks! It's hand-made in gimp :) 22.34.05 Join [foo [0] (~Nadia@109.86.186.130) 22.34.50 # <[foo> Hi there 22.36.28 Quit jordan` (Ping timeout: 240 seconds) 22.36.49 # By the way: is there any chance to include it (or/and my other stuff) in official rb? 22.37.40 # Assuming it has no licensing issues, it works, and it has documentation, sure 22.38.27 # <[foo> Could I ask gsoc questions? 22.38.32 # sure 22.38.36 # <[foo> cool 22.39.11 # <[foo> I am interested in making rockbox an outstanding mobile app 22.39.22 # sure 22.39.32 # <[foo> cross-platform (hopefully :) 22.39.42 Part froggyman 22.39.56 # leavittx: to get plugins commited: make sure they work on all platforms where possible, make a manual entry (pure text is enough) and bug us here to commit it :-) 22.40.10 Join jordan` [0] (~jordan@78.235.252.137) 22.40.51 # [foo: on which plattforms are you interessted ? 22.41.05 Quit m3dlg (Ping timeout: 258 seconds) 22.41.23 # <[foo> I already have some iphone knowledge 22.41.39 # <[foo> but if thats an issue I could take android 22.42.10 # iphone is not ideal, because we surely cant get into the appstore, so it would only work on jailbroken devices. 22.42.14 # if the goal is to make things portable, that shouldn't make too much difference 22.42.23 # <[foo> yes 22.42.27 # Remember that Rockbox is GPL and C, meaning that wherever you bring it, it must be able to accommodate the license and language. 22.42.38 # <[foo> thats for sure 22.42.43 # <[foo> idea is that 22.42.43 # domonoky: is it ok to have lots of bitmaps for different screen resolutions? 22.42.47 # so android is better, but there are also other possible targets. (WiMo, Maemo, other linux based phones) :-) 22.43.03 # leavittx: yes. take a look at how other plugins do it. 22.43.08 # <[foo> why not to make a Model layer crossplatform 22.43.10 # Or even just host-based PC apps 22.43.23 # <[foo> while Controller and View - platform specific 22.43.29 # domonoky: #if defined(BLAH) :) 22.43.40 Join Adubb [0] (~aldubuc@67.201.160.144) 22.43.41 # leavittx: there is a system in place to provide images of different resolutions. 22.43.54 Quit fred_99 (Quit: Ex-Chat) 22.44.24 # leavittx: i think the ifdef is only needed in the correct SOURCES file :-) 22.44.44 Quit evilnick_B (Quit: Page closed) 22.44.48 # [foo: a lot will depend on how exactly you see this project. Everyone here probably has his or her own ideas about how this should work. Some think that something like the current sim is fine (i.e. sdl and our GUI code), while others want to integrate it more 22.45.08 Join fred_99 [0] (~fred@80.125.173.117) 22.45.16 # [foo: Rockbox is already fairly split into the apps and firmware layer, where apps is mostly more cross-platform style code while firmware is more device/hardware specific. 22.46.24 # [foo: do you have a rockboxed mp3player ? 22.46.46 # <[foo> unfortunately, no 22.47.04 # <[foo> just iTouch and some not suitable transcend 22.47.37 # <[foo> do I need to have one? 22.47.44 # * domonoky recommends [foo to play a bit with some rockbox UI Simulator, to get a feel how rockbox is.. 22.47.56 # domonoky: ok, though defining different keymaps and bitmaps is quite difficult, I'll try to do that. Thanks (: 22.48.08 Join CGL [0] (~CGL@190.79.141.37) 22.48.23 # no, certainly not for the app project 22.48.41 # <[foo> I`ll play with it anyways 22.48.44 # <[foo> :) 22.48.46 # the rockbox as app project should probably mostly use touch input. 22.48.59 # Depends on the device. 22.49.04 # <[foo> yep 22.49.22 # I know that if it were on my phone, I'd generally prefer to use the hardbuttons so I don't need to constantly take it out of the pocket to adjust things. 22.49.23 # sure, if it has many buttons, we should use it. :-) 22.49.39 # * gevaerts tends to think that all this is not important :) 22.49.48 # That being said, the D2 simulator (or other touchscreen device) would be a good place to start for general functionality, since *most* likely app devices will have a touchscreen and/or mouse input 22.50.03 # Get the lower level infrastructure working right, the UI is a detail! ;) 22.51.01 # yes, the lower level is the important part for this project. But the UI sim is still good to get a feel of rockbox for people whithout rockbox experience and rockboxed dap :-) 22.51.20 # <[foo> so I thing the best path would be like split current APP layer into managable pieces which could be later reused with any external UI framework 22.53.02 # maybe 22.53.04 # essai 22.53.21 # fred_99: Please don't test things here 22.53.52 Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) 22.54.12 Join Soap_Hotel [0] (~434d1a51@giant.haxx.se) 22.54.23 # Woo Wee! Congrats on GSOC 2010! 22.54.30 # AlexP: sorry it's what i was thinking about 22.54.39 # * gevaerts still isn't convinced that redoing the GUI layer using whatever framework the target platform uses is a good idea 22.55.46 # gevaerts: I think in situations where Rockbox is likely to be full screen (many/most mobile devices) our current UI is pretty good / acceptable 22.55.55 # [foo: as a general warning, mentors are by no means decided yet, so even if my name is currently next to this idea, that doesn't mean you have to listen to me 22.56.11 # Nobody else does :) 22.56.12 # On a PC, I'd much rather have something the ability to have something slimmer with a lot of options accessible through standard menus / widgets. 22.56.56 # Llorean: that's part of my thinking. The other part is that we're slowly getting everything to be themable, using native widgets will throw that away 22.57.54 # I don't think they're at all necessary anywhere that Rockbox "takes over" the device as something that's either permanently fullscreen or minimized. 22.58.41 # If I were to do this project, I'd start with the threading model 22.58.46 # Like XBMC on PC has what I'd consider somewhat "Rockbox like" menus in the sense that it's a series of nested lists that can be navigated entirely with keyboard or entirely with mouse, and no native widgets at all. 22.59.21 # yes, it's not as if there's no precedent for media player apps to ignore all common sense and do their own thing :) 23.00.02 # Anyway, I'm also not opposed to make using native widgets possible 23.00.43 # I just think that having an app that plays back audio without dropouts and with minimal CPU usage has slightly higher priority :) 23.00.51 # Indeed. 23.00.58 # Memory usage on such devices is also important. 23.01.21 # ah, yes. The buffering code also could use work 23.01.51 # Well, I mean most devices can manage giving up 4-8MB of RAM that Rockbox can just monopolize, I'd imagine. 23.01.56 # But it's probably not ideal. 23.02.11 # Although, to be honest, there I'd wait for the buflib rework first. That should make it much easier to change things 23.02.23 # the buffering code works fine with atleast ~600kb buffer, so that should be doable on mobile phones :-) 23.02.32 # * gevaerts 's phone could afford to give more than enough to rockbox 23.03.06 # One big thing would probable be the ability to support multiple screen sizes with a single build. 23.03.26 Quit fred_99 (Remote host closed the connection) 23.03.58 # And, I guess, configurable controls for devices with varying buttons or button IDs with a single build. 23.04.09 Join GeekShadow [0] (Antoine@reactos/tester/GeekShadow) 23.04.11 # I guess it's significantly just removing all the dependencies on one build = one hardware. 23.04.23 # Is that really necessary? A full rockbox build is a few megabytes; having one build per common screen size, packaged in one executable, would work just as well I think 23.04.44 # What about devices that can rotate the screen, for example? 23.04.51 # * domonoky thinks that isnt really needed. we already manage 100+ builds, a few more dont hurt :-) 23.05.12 # Llorean: at least for the beginning, we can just not rotate :-) 23.05.22 Join Kitr88 [0] (Kitr88@BSN-182-15-223.dial-up.dsl.siol.net) 23.06.11 # yes, while rotation is nice, I happen to own a device where the media player app doesn't support rotation while the webbrowser does. People seem to survive 23.06.31 Quit Kitar|st (Ping timeout: 240 seconds) 23.06.55 # Would it really be that difficult to support multiple screen sizes now? 23.07.11 # it depends 23.07.26 Quit einhirn (Ping timeout: 264 seconds) 23.07.37 # We've got viewports for most screens already, which basically restricts those screens to an imaginary screen size anyway, right? 23.07.57 # For plugins it wouldn't be straighforward at all I think, but for those we don't have to care much since most of them don't make that much sense in an app anyway 23.08.22 # the list screens should work just fine 23.08.23 # I wouldn't envisage most of the plugins being included here 23.08.42 # Is there anything in rockbox that's not a list or a wps? 23.08.48 # Maybe the odd music related one, and they don't tend to have lots of bitmaps to deal with 23.09.19 # gevaerts: There's a few screens like the quickscreen or equalizer, but in effect they're still lines of text (or text-like bars) 23.09.25 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 23.09.49 Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) 23.10.10 # If you use native widgets the question goes away obviously 23.10.16 Quit MaadMan (Quit: Verlassend) 23.14.13 Join fred_99 [0] (~fred@80.125.173.117) 23.14.59 Quit fred_99 (Client Quit) 23.22.09 # Llorean: a lot of things use defines for the screen size, doing that at runtime rather then compile time will be somewhat less efficient 23.22.28 # IIRC this was discussed in more detail some years ago for another player but i can't remember the details 23.22.30 Join fyre^OS [0] (~nnscript@cpe-24-90-81-175.nyc.res.rr.com) 23.23.00 Join jfc^3 [0] (~john@dpc6682208002.direcpc.com) 23.23.34 Join ender [0] (krneki@foo.eternallybored.org) 23.23.56 Nick ender is now known as ender| (krneki@foo.eternallybored.org) 23.25.09 # saratoga: Won't most of these things need to be adapted to runtime sizing anyway to work with viewports? 23.25.18 # Especially with the themeing trends. 23.25.34 Join GeekShado_ [0] (Antoine@78.251.88.61) 23.25.35 # i don't know the details 23.26.21 Join GeekShad__ [0] (~Antoine@78.251.88.61) 23.26.38 Quit Kitr88 (Ping timeout: 246 seconds) 23.26.38 Quit FlynDice (Read error: Connection reset by peer) 23.27.01 Quit jfc^2 (Read error: Operation timed out) 23.27.02 Quit fyrestorm (Ping timeout: 240 seconds) 23.27.04 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 23.27.08 Quit ender` (Ping timeout: 240 seconds) 23.28.00 Quit DerPapst (Quit: Leaving.) 23.28.41 Quit GeekShadow (Ping timeout: 245 seconds) 23.29.01 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 23.29.23 Quit amiconn (Disconnected by services) 23.29.25 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 23.29.51 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 23.30.08 Quit GeekShado_ (Ping timeout: 260 seconds) 23.30.31 Join bzed_ [0] (~bzed@devel.recluse.de) 23.31.05 Join MethoS-- [0] (~clemens@134.102.106.250) 23.31.09 Quit Soap_Hotel (Quit: CGI:IRC (EOF)) 23.31.24 Quit MethoS- (Write error: Broken pipe) 23.32.20 Quit jgarvey (Quit: Leaving) 23.32.46 Quit rvvs89 (*.net *.split) 23.32.46 Quit p3tur (*.net *.split) 23.32.46 Quit FOAD (*.net *.split) 23.32.46 Quit komputes (*.net *.split) 23.32.46 Quit Schmogel (*.net *.split) 23.32.46 Quit advcomp2019_ (*.net *.split) 23.32.46 Quit Galois (*.net *.split) 23.32.46 Quit Utchybann (*.net *.split) 23.32.46 Quit Hadaka (*.net *.split) 23.32.47 Quit jvd (*.net *.split) 23.32.47 Quit beta2k (*.net *.split) 23.32.54 Join Kitar|st [0] (Kitr88@BSN-182-15-223.dial-up.dsl.siol.net) 23.34.00 Quit bmbl (Quit: Bye!) 23.35.57 Join einhirn [0] (~Miranda@p5485A2ED.dip0.t-ipconnect.de) 23.36.10 Quit einhirn (Client Quit) 23.36.11 Join phanboy_iv [0] (~benji@gate-20.spsu.edu) 23.36.11 Quit bzed (Ping timeout: 260 seconds) 23.36.17 Join rvvs89 [0] (robotnik@bright-snat.ucc.asn.au) 23.36.17 Join p3tur [0] (~petur@rockbox/developer/petur) 23.36.17 Join FOAD [0] (~dok@dinah.blub.net) 23.36.17 Join komputes [0] (~komputes@ubuntu/member/komputes) 23.36.17 Join Schmogel [0] (~Miranda@p3EE21FBA.dip0.t-ipconnect.de) 23.36.17 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 23.36.17 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 23.36.17 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 23.36.17 Join Hadaka [0] (~naked@naked.iki.fi) 23.36.17 Join jvd [0] (~syscrash@poipu/developer/syscrash) 23.36.17 Join beta2k [0] (1000@d24-36-68-97.home1.cgocable.net) 23.36.23 Nick bzed_ is now known as bzed (~bzed@devel.recluse.de) 23.36.43 # <[foo> so the main idea of rockbox app is to make it native on a) x86 b) some portable device 23.36.55 # <[foo> am I right? 23.37.33 # the main idea is to run rockbox as an app, as a guest in another OS 23.38.06 # there are several such OSes 23.38.25 Quit GeekShad__ (Ping timeout: 258 seconds) 23.38.43 Quit phanboy4 (Ping timeout: 256 seconds) 23.38.45 # <[foo> i.e. current UI SIM -> native *nix/Win -> some embedded OS (IphoneOS, Android..( 23.39.08 Nick ender| is now known as ender` (krneki@foo.eternallybored.org) 23.40.02 # I don't think so, no 23.40.13 # if thouse "->" implies an order of work 23.40.16 # those 23.40.22 # <[foo> yes 23.40.40 # <[foo> but this is stated on current gsoc page 23.40.41 # Bagder: That order was my suggestion (and others agreed, or at least didn't object...). 23.40.54 # * Bagder doesn't keep up 23.41.00 # well, that's one way to do it 23.41.13 # <[foo> Suggested goals 23.41.13 # <[foo> A mid-term goal could be to undertake the refactoring of the existing Rockbox code and produce a Rockbox application capable of running in a dexktop environment using SDL 23.41.13 # <[foo> The remaining part of the summer could be spent porting this Rockbox application to a portable device. 23.41.28 Quit domonoky (Read error: Connection reset by peer) 23.41.50 # so if you read that already, what is the question again? 23.42.19 # I think it doesn't make much difference. The first steps are not about the target OS but about the code structure and kernel work anyway I think 23.42.32 # yes I agree 23.42.58 # Yes, that was my intention. i.e. don't get bogged down in the details of a particular target - do the important work (restructuring Rockbox) first. 23.43.21 # <[foo> so, what's the best starting path? 23.43.31 # As soon as the target tree work is done, and it doesn't use the preemptive-multithreading-with-only-one-running-thread style of cooperative multithreading anymore, you can start thinking about the target you like 23.44.25 # <[foo> ok. I think I got your point 23.46.15 # <[foo> thanks for the info. I'll be back after checking the SIM and the code 23.46.24 # good plan :) 23.46.26 Quit rvvs89 (*.net *.split) 23.46.26 Quit p3tur (*.net *.split) 23.46.26 Quit FOAD (*.net *.split) 23.46.26 Quit komputes (*.net *.split) 23.46.26 Quit Schmogel (*.net *.split) 23.46.26 Quit advcomp2019_ (*.net *.split) 23.46.26 Quit Galois (*.net *.split) 23.46.27 Quit Utchybann (*.net *.split) 23.46.27 Quit Hadaka (*.net *.split) 23.46.27 Quit jvd (*.net *.split) 23.46.27 Quit beta2k (*.net *.split) 23.47.01 # <[foo> what time are u here regularily? (gevaerts?) 23.48.27 # Most people are here in euro evening times. I tend to be online during daytime as well, but I'm at work then so I don't always reply quickly 23.49.05 # <[foo> ok. 23.50.13 Join rvvs89 [0] (robotnik@bright-snat.ucc.asn.au) 23.50.13 Join p3tur [0] (~petur@rockbox/developer/petur) 23.50.13 Join FOAD [0] (~dok@dinah.blub.net) 23.50.13 Join komputes [0] (~komputes@ubuntu/member/komputes) 23.50.13 Join Schmogel [0] (~Miranda@p3EE21FBA.dip0.t-ipconnect.de) 23.50.13 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 23.50.13 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 23.50.13 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 23.50.13 Join Hadaka [0] (~naked@naked.iki.fi) 23.50.13 Join jvd [0] (~syscrash@poipu/developer/syscrash) 23.50.13 Join beta2k [0] (1000@d24-36-68-97.home1.cgocable.net) 23.50.20 # <[foo> c u 23.50.21 # but again, don't concentrate on me particularly. I volunteered as a mentor for this project, but other people might still do that as well, or I might end up mentoring another project... 23.50.39 # <[foo> well 23.51.00 # <[foo> whom should I then ask stupid questions? 23.51.02 # <[foo> :) 23.51.15 # No-one in particular - just ask in this channel. 23.51.16 # just ask them here, anyone can answer them :) 23.52.12 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.52.20 Quit robin0800 (Quit: No Ping reply in 180 seconds.) 23.52.27 Join hd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 23.52.27 Quit hd (Changing host) 23.52.28 Join hd [0] (~jd@Wikipedia/HellDragon) 23.52.45 Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) 23.53.18 Join mc2739_ [0] (~mc2739@rockbox/developer/mc2739) 23.53.23 Join AlexP_ [0] (~ap@rockbox/staff/AlexP) 23.53.43 Quit elcan (*.net *.split) 23.53.43 Quit jd (*.net *.split) 23.53.43 Quit SirFunk (*.net *.split) 23.53.43 Quit AlexP (*.net *.split) 23.53.43 Quit rasher (*.net *.split) 23.53.53 Quit mc2739_ (Client Quit) 23.54.04 Quit [foo (Quit: Leaving) 23.54.35 Quit ender` (Quit: Pandas are the least racist animals: they're black, white and asian!) 23.55.22 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 23.56.42 Quit rvvs89 (*.net *.split) 23.56.42 Quit p3tur (*.net *.split) 23.56.42 Quit FOAD (*.net *.split) 23.56.42 Quit komputes (*.net *.split) 23.56.42 Quit Schmogel (*.net *.split) 23.56.42 Quit advcomp2019_ (*.net *.split) 23.56.42 Quit Galois (*.net *.split) 23.56.42 Quit Utchybann (*.net *.split) 23.56.42 Quit Hadaka (*.net *.split) 23.56.42 Quit jvd (*.net *.split) 23.56.42 Quit beta2k (*.net *.split) 23.56.58 Quit pamaury (Quit: Page closed)