--- Log for 24.01.113 Server: pratchett.freenode.net Channel: #rockbox --- Nick: Guest87001 Version: Dancer V4.16 Started: 7 days and 4 hours ago 00.01.09 # Ok i'm recompiling but it might take while because I'm also recompiling my kernel 00.01.16 # pamaury: http://pastebin.com/yt2HSJiP 00.01.45 # that's a nasty 00.02.27 # indeed 00.02.52 # oh wait I did not #include 00.03.14 # just asm/signal 00.03.32 Join dynion [0] (~52a896aa@www.haxx.se) 00.03.40 # try sigaction and remove asm/signal 00.05.49 Quit Strife89 (Ping timeout: 245 seconds) 00.07.14 # pamaury: http://pastebin.com/5eK4TeY2 00.08.55 Quit nomada (Ping timeout: 255 seconds) 00.09.17 # ok, don't mind, if it works with this that's fine, we'll see this tomorrow 00.10.11 Quit dynion (Quit: CGI:IRC) 00.10.13 # no it doesn't but obvouisly it's just about to find which file to include 00.10.16 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) 00.10.31 # well at least it does with the parameter remplace 00.10.36 # manually 00.10.51 # Anyway I'm going to bed to 00.11.10 Quit jlbiasini (Quit: jlbiasini) 00.12.34 Quit mt_ (Ping timeout: 248 seconds) 00.18.13 Quit Rower (Quit: Hmmm...) 00.18.18 Quit Tim_Elliott (Quit: Leaving) 00.20.15 Join mt [0] (~quassel@41.233.134.80) 00.20.16 Quit mt (Changing host) 00.20.16 Join mt [0] (~quassel@rockbox/developer/mt) 00.27.52 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 19.0/20130116072953]) 00.36.50 Join [Saint] [0] (~quassel@101.98.158.103) 00.37.11 Nick [Saint] is now known as Guest78563 (~quassel@101.98.158.103) 00.40.04 Quit Edsansaclipplus (Quit: CGI:IRC) 00.42.17 # <[Saint_]> I got some totally unexpected results with test_codec and the 10 band eq. 00.42.29 # <[Saint_]> I'll put them up on the gerrit page now. 00.43.04 # <[Saint_]> long story short, it turns out that when compared to the 5 band eq, the 10 band eq made decoding slightly faster. 00.43.34 # <[Saint_]> possibly because it actually needed to boost occasionally? (a classic)...dunno. 00.44.10 # I don't think test_codec output goes through the eq 00.44.41 # <[Saint_]> Ahhhhhh...right. 00.44.58 # <[Saint_]> I thought "with dsp" used the eq. 00.45.24 # Ah, is there a "with dsp" option? 00.45.33 # <[Saint_]> Ok, well...that's entirely disinteresting then ;) 00.45.33 # * gevaerts isn't sure then 00.46.04 # <[Saint_]> there's a few test_codec options, speed test, and speed test with dsp is what I used. 00.46.19 # <[Saint_]> you can also restrict boosting iirc. 00.47.10 # * gevaerts recommends waiting for someone knowledgeable to wander in 00.51.12 Part zaphee 00.52.38 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 00.53.28 Quit Guest38472 (Read error: Connection reset by peer) 00.54.50 Join TheSphinX_ [0] (~briehl@p5B321F9C.dip.t-dialin.net) 00.57.20 Quit TheSphinX^ (Ping timeout: 240 seconds) 01.07.35 # * [Saint_] is fairly willing to assume that the 'with dsp' option is actually using the eq. 01.07.45 # <[Saint_]> the code got me lost, though. 01.08.03 Quit pamaury (Ping timeout: 256 seconds) 01.14.57 Quit funman (Ping timeout: 252 seconds) 01.16.04 Join funman [0] (~fun@rockbox/developer/funman) 01.18.33 Quit ParkerR (Excess Flood) 01.19.51 Join TheSphinX^ [0] (~briehl@p579CCF09.dip.t-dialin.net) 01.20.39 Quit bluebrother (Disconnected by services) 01.20.42 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 01.21.29 Join ParkerR [0] (ParkerR@unaffiliated/parkerr) 01.21.51 Quit fs-bluebot (Ping timeout: 248 seconds) 01.22.55 Quit TheSphinX_ (Ping timeout: 245 seconds) 01.23.08 Join fs-bluebot [0] (~fs-bluebo@g224236060.adsl.alicedsl.de) 01.25.23 Join funman_ [0] (~fun@rockbox/developer/funman) 01.25.38 Quit ParkerR (Excess Flood) 01.27.34 # <[Saint_]> nicely formatted test_codec results of 10 band eq documented at g386 now: 01.27.36 # Gerrit review #386 at http://gerrit.rockbox.org/r/386 : 10 Band EQ w/Presets adapted from VLC by Hayden Pearce (changes/86/386/4) 01.29.08 Quit funman (Ping timeout: 276 seconds) 01.29.12 # <[Saint_]> the classic is a bit of a beast. flac_8 in ~9MHz, lame_320 and vorbis_500 in ~30MHz 01.30.01 # [Saint_]: are you going to deal with the inline comments? 01.30.45 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 01.31.11 # <[Saint_]> I didn't quite understand your comment. I'm not reinventing the wheel...it's exactly the same as it's done in git HEAD, just...more of it. 01.32.05 # <[Saint_]> Comments on the task I adapted it from said it would be accepted as is if it was proven to run on all targets. 01.32.22 # <[Saint_]> Basically all I did was change the frequency stepping and add presets. 01.32.48 # <[Saint_]> and sync an ancient patch to HEAD 01.33.59 Join ParkerR [0] (ParkerR@unaffiliated/parkerr) 01.34.25 # replacing those magic values with a #define would make it much nicer 01.34.38 # easier to change how many bands are available 01.34.52 # i.e the low ram targets may only want 5 bands 01.35.24 # <[Saint_]> from what I can see, it _should_ run on all targets that have the eq already. there's a 1~2MHz increase or less in CPU usage, and the small screen targets already scroll to accommodatethe gui eq screen so I thought it was pretty much good to go. 01.36.56 # <[Saint_]> sorry, that is poorly worded. that cpu usage increase is caused by using the dsp anyway...the increase from the extra bands is very trivial. 01.37.02 # <[Saint_]> ~1MHz or less. 01.40.22 # 1Mhz smells way too low. 01.40.37 # <[Saint_]> soap: since you seem to know about these things, do you think I should be using 32, 64, 125, 250, ... or 30, 60, 120, 250, ... 01.41.12 # I'm searching now as I can't believe saratoga or buschel hasn't already profiled this, but for a long time the video just about died on Senab's build with more bands turned on. 01.41.26 # <[Saint_]> and, I thought about that...but maybe it causes boosting more often? the classic can do all the codecs I tested fine without boosting in theory but I didn't disable boosting for the test_codec runs I did. 01.41.27 # and that's after MP3 was already below 30Mhz. 01.41.55 # my memory may be faulty as shit, so don't hold the boat on my account. 01.42.07 Quit prof_wolfff (Ping timeout: 248 seconds) 01.42.28 # <[Saint_]> do you have a suggestion about the frequency stepping? 32, 64, ... vs 30, 60, ...? 01.44.11 Quit Raptors (Read error: Connection reset by peer) 01.44.40 # My headphones / truck can't do 30 and my ears can't hear 16 in music, so put them where you like! ;) The center points will be changeable, no? 01.45.16 # <[Saint_]> correct. 01.45.50 # <[Saint_]> It confuses me, if ISO 266 is indeed a preferred standard, then why does virtually nothing seem to use it? :-S 01.47.16 # what do you mean? 01.47.16 # http://www.gearhounds.com/ProductImages/MXR_10_BAND_EQ_M108_Lg.jpg 01.47.25 # http://www.dak.com/reviews/imagesR4/3211_EQ_Slidersss.jpg 01.48.27 # 10-bands on even octaves starting at 30 has long been standard. Isn't that what ISO 266 is asking for? 01.48.42 # <[Saint_]> well, according the the patch I was reading from ISO 266 standard is 30, 60, 120, 250 01.48.53 Nick funman_ is now known as funman (~fun@rockbox/developer/funman) 01.49.01 # <[Saint_]> but lots of stuff is at 32, 64, 125, 250, ... 01.49.28 # you see a 15 band hardware EQ it's most likely 2/3rds of an octave, again with the same range 01.50.07 # the real number is 31.25 01.50.16 # 1000/16 01.50.26 # excuse me - 32 01.50.53 # different people have rounded the text on hardware eqs differently. 01.52.21 # <[Saint_]> I don't think we can do decimals, the accepted values is just in Hz, so 32, ~, 16000. 01.52.55 # <[Saint_]> I wasn't sure what to do with the rounding, as its clearly closer to 31, but it seems to be common to use 32 and double from there. 01.53.48 # <[Saint_]> double from 16 or 32, then round to 125 and double from there. 01.55.46 *** Saving seen data "./dancer.seen" 01.55.49 Nick [Saint_] is now known as [Saint] (~saint@rockbox/user/saint) 01.56.05 Quit mt (Read error: Connection reset by peer) 01.57.42 # <[Saint]> if anyone else wants to do the same/similar test with other targets, I would appreciate it. 01.57.48 Join froggymana [0] (~me@dhcp-155-92-103-232.nebula.msoe.edu) 01.57.48 Quit froggymana (Changing host) 01.57.48 Join froggymana [0] (~me@unaffiliated/froggyman) 01.58.00 # <[Saint]> I will test on an iPod Color this evening. 01.58.02 Join mt [0] (~quassel@41.233.134.80) 01.58.02 Quit mt (Changing host) 01.58.02 Join mt [0] (~quassel@rockbox/developer/mt) 01.58.13 Quit froggymana (Remote host closed the connection) 01.58.49 Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) 02.00.17 # <[Saint]> The way I did it was three runs of test_codec for each case: speed test HEAD w/oDSP, speed test HEAD w/DSP, speed test 10 Band EQ patch w/DSP; average the results. 02.00.20 # the ipod color should answer the PP question once and for all 02.01.14 # <[Saint]> One run is probably enough, I did three and averaged just to try to get a clearer picture and hopefully eliminate the possibility of a 'miracle run'. 02.02.32 # <[Saint]> I don't have any AMS players I can get to easily, so if someone got bored and had a Clip/Fuze/etc laying around, go nuts. 02.03.51 # <[Saint]> I've been trying out the presets today, and although they're kinda kludged they're really not too bad. 02.06.11 Quit ParkerR (Excess Flood) 02.06.20 # <[Saint]> One thing this made me think of, as well, is that Rockbox really needs a "first run script". Something capable of inclusion into a build that runs once after boot and then wipes itself out. SO that one can easily remove depricated files. 02.07.09 # <[Saint]> For example, were this committed, there would be several 5 band EQ presets leftover in the users eqs folder that would be useless. 02.08.56 # <[Saint]> could probably do it with LUA and the rockboot feature or whatever it's called. 02.09.09 # <[Saint]> 02.09.28 Quit ender| (Read error: Operation timed out) 02.09.45 # the worst that could happen is they load an old .cfg and only the first 5 bands get set, right? You didn't change the .cfg format did you? 02.10.39 # <[Saint]> no. 02.11.39 # <[Saint]> I just thought it might be nice to have a way to guarantee we could wipe out depricated files without user intervention. 02.12.09 # what if the user created their own files i the /.rockbox/eqs? 02.12.14 # would you wipe those too? 02.12.24 # or just the rockbox-issued ones? 02.12.41 # <[Saint]> Only known files, ones that came with a previous binary. 02.12.47 # <[Saint]> SHouldn't ever wipe user files. 02.12.49 # own files IN /.rockbox/eqs 02.12.53 # right 02.13.04 # so just ship new preset replacements for all 02.13.24 Join TheSphinX_ [0] (~briehl@91.50.35.246) 02.13.27 # only use 5 bands of the possible 10 of the ones you don't feel up to reworking. define the other five bands as off. 02.14.02 # <[Saint]> Ah, right, yes. good point. 02.14.09 # <[Saint]> I can do that, genius. 02.14.39 # <[Saint]> Another is caused by me renaming Default to Flat to be more obvious, but I can undo that I guess. 02.14.59 Join ParkerR [0] (ParkerR@unaffiliated/parkerr) 02.15.01 Quit TheSphinX^ (Read error: Operation timed out) 02.15.18 # or just ship two opies 02.15.21 # they rae tiny 02.15.23 # nobody cares 02.15.49 # <[Saint]> have Default (the previous, 5 band eq), and Flat (the new, 10 band eq)? 02.16.02 # no, i mean, just ship two copies of exactly the same flat 10 band preset 02.16.06 # with both names 02.16.10 # <[Saint]> Ah. 02.16.14 # because it's a tiny textfile and who cares 02.16.29 # user confusion. "I had selected default and found rockbox so warm and balanced. I then tried flat and all the subtle foot tapping goodness went away and the soundstage collapsed" 02.16.38 # lol 02.17.02 # <[Saint]> audiophile trap for patrick82 wannabes 02.17.03 # <[Saint]> ;) 02.17.28 # then ship one called "Apple.cfg" and another "Cowon.cfg" and make them both flat. 02.17.34 # if you /really/ want to troll. 02.18.58 # <[Saint]> But, anyway, ok...yeah, I'll convert the existing 5 band presets to 10 band and and just leave the new frequency steps with 0 values. 02.19.37 # <[Saint]> but...hum...no, I don't really like that idea. 02.19.46 # <[Saint]> maybe I should try and guestimate the gaps. 02.21.00 # <[Saint]> it would be nice if there was a way to wipe them out... 02.22.44 # <[Saint]> yeah, I might try and fill the blanks instead of leaving the values blank. 02.25.47 Join ender| [0] (whatever@2a01:260:4094:1:42:42:42:42) 02.28.56 # <[Saint]> Ok, I'll do that when I get back home from my pending missions out and about, then as far as I'm concerned it should be able to be committed unless anyone comes up with a target that it completely destroys runtime/realtime playback on. 02.30.24 # <[Saint]> I'll bench the iPod Color and a Nano2G as well, and maybe a Fuze if I can find it. I could probably also do RaaA but I'm not sure if that really matters. 02.33.05 # <[Saint]> Do you think it might help if I provided test binaries and put them on the forum? 02.35.27 # i have found generally that if i do that i get maybe one or two people testing half a dozen common players 02.35.31 # which is better than nothing 02.35.43 # it depends how much you have scripted making the test builds :) 02.35.58 # if you have a sinlge command to do it and can jut leave it for a couple hours and get a dir of zips then it's worth it ;) 02.36.04 # i think our release script will do it in fact no? 02.41.04 # [Saint]: something is wrong with those benchmarks 02.41.16 # its probably about 1-2 MHz per EQ band on ARMv5 02.42.06 # <[Saint]> Well, I can only go by what test_codec gave me...is test_codec actually using the EQ with the "speed test with DSP" option? 02.42.29 # <[Saint]> As near as I can figure it is. 02.42.58 # it should 02.43.07 # are all 10 bands actually enabled though? 02.43.18 # <[Saint]> The other thing I thought of is that perhaps I should do the test with boosting disabled. 02.43.20 # <[Saint]> yes. 02.43.52 # <[Saint]> I thought perhaps this actually caused more boosting during decoding and thats why there was a very trivial difference. 02.44.25 # the codec results are done at constant clock speed 02.44.36 # <[Saint]> but, anyway, yeah...that's the average of three runs on test_codec. 02.44.47 # <[Saint]> besides doing them again, not sure what else I can do. 02.44.51 # basically what those results probably indicate is that the EQ isn't enabled in test_codec for some reason 02.45.01 # <[Saint]> I'll be testing other targets tonight as well. 02.45.33 # <[Saint]> well the with/without DSP runs are clearly different... 02.45.48 # <[Saint]> There just doesn't seem to be much difference in adding 5 more bands. 02.46.10 # <[Saint]> But there is a clear difference with speed test with and without DSP. 02.46.32 # <[Saint]> +~2MHz on the Classic 02.49.22 # the difference is due to the normal DSP code 02.49.27 # the EQ isn't being called though 02.49.51 # looking at the code i don't see how it wouldn't be called 02.50.01 # are you sure you actually have all 10 bands configured in settings? 02.51.00 # you know i keep getting tempted to make a little thing for our website thta just asks you a series of questions to determine if your ipod is supported or not 02.51.04 # well not just ipod, player 02.51.41 # people do not read our list, and even when they do there are things not on the list (like early wip ports), and then they constantly get their model wrong 02.51.50 # "Is it listed on the front page" "No? 02.51.54 # "Go away" 02.51.58 # saratoga: right but that doesn't help if they don't know what it is 02.52.01 # which lots of people don't 02.52.08 # e.g. all the ipodvideo/classic confused folks 02.52.44 # are there still ports on TargetStatus that aren't listed on the front page at all? 02.52.49 # or did someone fix that 02.53.11 # yeah, there are 02.53.12 # e.g. xfi 02.53.28 # <[Saint]> [14:50:03] are you sure you actually have all 10 bands configured in settings? <-- quite 02.54.41 # <[Saint]> perhaps I should do the tests with a very aggressive and unrealistic amount of gain/precut on each band? 02.55.15 # <[Saint]> At the moment I'm using a quite sane "Pop" preset. 02.55.48 # <[Saint]> But, iiuc, it shouldn't matter even if I have "Flat/Default enabled. 02.56.47 # <[Saint]> By my understanding it shouldn't matter if the EQ is on, but all values are set flat, it should still consume additional CPU cycles...correct? 02.57.12 # i would hope not 02.57.18 # iwould hope we skip processing for bands that are on 0db 02.58.10 # <[Saint]> I got lost quite quickly in the code. 02.58.14 # <[Saint]> quite quickly. 02.58.31 # well set every band to 1db an dsee :) 02.59.58 # <[Saint]> I'll re-test when I get back from my missions, I'll do the same test, but this time with very aggressive gain/precut, basically creating an artificial 'worst case scenario'. 03.00.09 # just looking at the code its about 5 multiplies, loads and stores per sample, and you do 88200 samples per second 03.00.10 # <[Saint]> See if that makes a considerable difference. 03.00.43 # so figure 2 cycles per op times ~10 ops times 100k samples = 2MHz per band 03.02.05 # <[Saint]> but, anyway, yeah...I'm procrastinating. I need to get on with my missions. Leave a comment on the tracker if you test on other targets before I get a chance to, or leave a message in the logs for me. o/ 03.03.10 # (for armv5, figure about double that on armv4 due to half speed multiplier and load unit) 03.07.38 Quit Guest78563 (Ping timeout: 276 seconds) 03.38.58 Quit user890104 (Read error: Operation timed out) 03.39.24 Join Xerion_ [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) 03.39.27 Join user890104 [0] (Venci@unaffiliated/user890104) 03.40.00 Quit Xerion (Read error: Connection reset by peer) 03.40.01 Nick Xerion_ is now known as Xerion (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) 03.55.47 *** Saving seen data "./dancer.seen" 03.57.11 # " Assume a band is disabled if the gain is zero " 03.57.18 # looks like they're skipped if there is no gain 04.04.27 Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) 04.08.01 Join TheSphinX^ [0] (~briehl@p579CCA5E.dip.t-dialin.net) 04.11.47 Quit TheSphinX_ (Ping timeout: 245 seconds) 04.12.55 Join [Saint_] [0] (~quassel@101.98.158.103) 04.13.19 Nick [Saint_] is now known as Guest62018 (~quassel@101.98.158.103) 04.27.13 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.27.14 Quit amiconn (Disconnected by services) 04.27.16 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.27.19 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 04.27.45 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.27.45 Quit pixelma (Disconnected by services) 04.27.47 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 05.17.53 Join thegeek_ [0] (~thegeek@110.36.34.95.customer.cdi.no) 05.18.55 Quit TheSeven (Disconnected by services) 05.19.05 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.20.50 Quit thegeek (Ping timeout: 240 seconds) 05.22.43 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 05.26.37 Quit jhMikeS (Ping timeout: 256 seconds) 05.32.05 Join TheSphinX_ [0] (~briehl@p5B321DFB.dip.t-dialin.net) 05.34.27 Quit TheSphinX^ (Ping timeout: 248 seconds) 05.55.51 *** Saving seen data "./dancer.seen" 05.56.36 Join TheSphinX^ [0] (~briehl@p579CC972.dip.t-dialin.net) 05.56.47 Quit [Saint] (Remote host closed the connection) 06.00.11 Quit TheSphinX_ (Ping timeout: 264 seconds) 06.03.49 Join [Saint] [0] (~saint@rockbox/user/saint) 06.12.57 Quit saratoga (Ping timeout: 245 seconds) 07.10.48 Quit SuperBrainAK (Quit: pbly going to sleep /_\) 07.12.28 Quit Buglouse (Read error: Operation timed out) 07.14.33 Join webguest59 [0] (~6378e8b5@www.haxx.se) 07.17.04 Join scorche [0] (~scorche@rockbox/administrator/scorche) 07.19.25 Quit scorche` (Ping timeout: 256 seconds) 07.21.17 Quit webguest59 (Quit: CGI:IRC (EOF)) 07.26.09 Join Roboturner913 [0] (6378e8b5@gateway/web/freenode/ip.99.120.232.181) 07.27.29 # Who knows stuff about the Fuze+? 07.28.12 # Specifically, I am trying to figure out a nasty screen flicker.... 07.29.38 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 07.36.18 Quit Roboturner913 (Quit: Page closed) 07.39.49 Quit Buglouse (Ping timeout: 255 seconds) 07.40.29 Join enriched [0] (~quassel@101.98.163.139) 07.53.07 Join jhMikeS [0] (~jethead71@50.4.240.19) 07.53.07 Quit jhMikeS (Changing host) 07.53.07 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 07.55.53 *** Saving seen data "./dancer.seen" 07.58.41 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 07.59.50 Quit jhMikeS (Ping timeout: 240 seconds) 08.00.56 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 08.01.54 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 08.19.58 Join ender` [0] (~ender@foo.eternallybored.org) 08.22.27 Quit Buglouse (Ping timeout: 248 seconds) 08.33.25 Join Zagor [0] (~bjst@sestofw01.enea.se) 08.33.25 Quit Zagor (Changing host) 08.33.25 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.37.43 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 09.00.32 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.01.57 Quit Buglouse (Ping timeout: 246 seconds) 09.05.51 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.10.59 Join petur [0] (~petur@rockbox/developer/petur) 09.18.03 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 09.20.23 Join LinusN [0] (~linus@giant.haxx.se) 09.26.53 Quit bertrik (Ping timeout: 276 seconds) 09.38.28 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 09.44.23 Join pystar89 [0] (~pystar89@ip-37-24-1-174.unitymediagroup.de) 09.52.35 Quit Buglouse (Ping timeout: 276 seconds) 09.55.54 *** Saving seen data "./dancer.seen" 10.00.48 Quit Guest62018 (Ping timeout: 248 seconds) 10.02.53 Join jlbiasini [0] (~metaphysi@109.103.46.91) 10.25.30 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 10.27.41 # pamaury: kugel: I found the missing include it's and not 10.42.05 Quit Buglouse (Ping timeout: 252 seconds) 10.46.11 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.46.49 Join bebna [0] (~a.fasold@94.101.33.114) 10.52.27 # jlbiasini: pamaury said the thread-unix.c includes it already 10.54.10 # kugel: no it doesn't 10.56.15 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 10.57.18 # kugel so here we go http://gerrit.rockbox.org/r/#/c/387/ 11.02.32 # how it is possible that other sims (as well as our buildfarm) does not signal problem? 11.16.03 # jlbiasini: it's includedd a few lines above 11.16.04 # no idea or perhaps I'm missing a dev package on my debian? 11.16.23 # stupid me 11.16.25 # the third include is 11.16.46 # you just added it a second time. but perhaps the order is important 11.16.48 # How is it possible that it doesn't work if not double??? 11.16.59 # ah right ! 11.17.17 # I will try 11.17.49 # sigcation needs _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE. I guess one of the header after define one of them 11.24.58 # What about pushing g#339 and g#340? The only reason this is not merged yet is that dreamlayers is not active anymore. The patch is widely tested and closes quite serious problem on many targets advertised as stable. 11.25.01 # Gerrit review #339 at http://gerrit.rockbox.org/r/339 : Fix FS#12391 : Memory corruption on PP502x after commit_discard_idcache() by Boris Gjenero (changes/39/339/1) 11.25.21 # so push it 11.26.33 # done 11.27.02 # kugel: ok I don't understand anything now it's working 11.27.15 # I reinstall the git tree 11.27.55 # I didn't had any unstashed change reported and everything up to date... quite a mystery... 11.36.11 Join [Saint_] [0] (~quassel@101.98.158.103) 11.36.35 Nick [Saint_] is now known as Guest25974 (~quassel@101.98.158.103) 11.48.34 Quit efyx (Ping timeout: 248 seconds) 11.50.46 Quit TheSphinX^ (Read error: Operation timed out) 11.53.13 # <[Saint]> new results at g386 11.53.36 Quit fs-bluebot (Read error: Connection reset by peer) 11.53.59 # <[Saint]> I must've accidentally reset the EQ to 0 during the initial testing. 11.54.00 # hmm, magically bootloaders can't find commit_discard_dcache() when linking 11.54.14 # <[Saint]> New results show a clear increase in CPU usage. 11.54.27 # <[Saint]> But, not as much as I had been lead to believe it would be. 11.54.59 # <[Saint]> Except for flac...which got crippled by it. 11.55.54 Join TheSphinX^ [0] (~briehl@87.156.195.228) 11.55.56 *** Saving seen data "./dancer.seen" 11.56.37 # <[Saint]> lame 320 and vorbis 500 saw a ~5MHz gain for realtime decoding (~30MHz vs ~36MHz), but flac 8 /almost/ doubled in CPU usage from ~9MHz to ~15MHz. 11.57.36 # ah right it doesn't build quite big part of system-pp502x.c for bootloader 11.58.30 # 15 is still not much - below boost threshold 12.01.51 Join efyx [0] (~efyx@91.179.16.102) 12.04.35 Quit Buglouse (Ping timeout: 245 seconds) 12.06.09 # Hmm, I think I'll revert last commit. I don't have time now to dive into code how this should be arranged. For bootloaders cache_init() is not called so I think using cache functions is not safe there. Comments are a bit scary. 12.07.14 # [Saint]: cpu increase should be constant, regardless of the codec 12.08.04 # [Saint]: are you forcing boost during testcodec runs? 12.08.14 # <[Saint]> No. 12.08.41 # I'd consider doing that to reduce variables 12.09.05 # test_codec boost by itself 12.09.12 # *boosts 12.09.41 # you have to *force unboost* to test unboosted performance 12.09.56 # <[Saint]> Aha, right. Ok. Good to know. 12.11.52 Quit jlbiasini (Quit: jlbiasini) 12.12.17 # gevaerts: testcodec always boosts 12.12.33 # kugel: [Saint] told me it doesn't :) 12.12.41 # * gevaerts learns never to believe [Saint]! 12.12.44 # he's wrong then :) 12.13.58 # [Saint]: by the way, could you run a set of APE benchmarks on the classic one of these days? 12.14.17 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.17.50 # <[Saint]> APE crashes and burns. 12.17.56 # <[Saint]> And I don't know why. 12.18.03 # <[Saint]> So does wmapro 12.18.11 # <[Saint]> All I get is high pitched noise. 12.18.31 # I meant in test_codec 12.18.37 # <[Saint]> It either outputs a terrible noise, or skips the file completely. 12.18.43 # Still, if it's buggy, not worth trying :) 12.19.02 # <[Saint]> I don't know what the problem with it is... 12.19.17 # <[Saint]> I thought it was my test_files library became corrupt...but, nope. 12.19.56 # <[Saint]> I first noticed it when I saw test_codec claiming 16000000% realtime for APE 12.22.58 # I don't understand it. HAVE_ATA_DMA for PP was disabled in 55fab77 so before it had to build cleanly. Now enabling it again spits errors for bootloaders. In the meantime I don't see any significant changes. 12.23.10 # any clues? 12.30.36 # wodz: missing include when in bootloader ? 12.30.56 # previously it did not use commit_discard perhaps ? 12.32.40 # it did previously (aka when HAVE_ATA_DMA) cpucache_invalidate() but since then names have changed 12.33.46 Join redhot [0] (~kvirc@195.238.92.36) 12.34.00 # but it should not compile cpucache_invalidate() at all then 12.47.05 Quit Poodlemastah (Ping timeout: 245 seconds) 12.48.50 # Ok, in ancient version cpucache_invalidate() was empty stub in bootloader build. I wonder how it was supposed to work with dma transfers. 12.49.38 Part redhot ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") 12.49.52 Join Poodlemastah [0] (~Poodlemas@109-124-180-122.customer.t3.se) 12.49.52 Quit mt (Read error: Connection reset by peer) 12.50.44 Quit petur (Quit: *plop*) 12.51.04 Join mt [0] (~quassel@rockbox/developer/mt) 12.51.36 # is it possible to define HAVE_ATA_DMA only for non bootloader builds? 12.52.18 Quit mt (Read error: Connection reset by peer) 12.53.27 # wodz: Probably, depends on where it is defined 12.53.32 Join mt [0] (~quassel@rockbox/developer/mt) 12.53.56 # HAVE_ATA_DMA is defined in firmware/export/config/xxx.h files 12.55.39 # yea it works but looks ugly 12.57.01 Join mt_ [0] (~quassel@41.233.134.80) 12.57.02 Quit mt (Read error: Connection reset by peer) 12.57.05 # oh, we stub out some lcd functions this way so this is not new technique :-) 12.58.00 Quit Poodlemastah (Read error: Connection reset by peer) 12.58.00 Quit mt_ (Read error: Connection reset by peer) 12.58.40 Join mt [0] (~quassel@41.233.134.80) 12.58.41 Quit mt (Changing host) 12.58.41 Join mt [0] (~quassel@rockbox/developer/mt) 12.59.36 # we already do that for many things 13.00.19 # pamaury: sure in many places but not so much in config/xxx.h 13.00.42 # nearly all config files do it ! 13.01.13 # wodz: sure it's possible 13.01.23 Join Poodlemastah [0] (~Poodlemas@109-124-180-122.customer.t3.se) 13.01.31 # just define it within #ifndef BOOTLOADER 13.04.47 Quit Guest25974 (Ping timeout: 248 seconds) 13.07.15 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 13.19.34 Quit Buglouse (Ping timeout: 255 seconds) 13.31.50 Join jlbiasini [0] (~metaphysi@109.103.46.91) 13.35.09 Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) 13.39.10 # jlbiasini: I don't understand your gerrit patch ?! 13.39.56 # nothing to understand it's abandonned 13.40.18 # You did experienced the same errors as I was yesteday didn't you ? 13.40.40 # no 13.40.52 # I reinstalled my tree and now I can't reproduce it anymore 13.42.15 # stange because I didn't had any thing unstaged. In fact I had this signal.h include so I didn't so there was already one, but kugel was suspecting perhaps the order ofthe include matters 13.42.59 # but after it worked once, it was always working even after reseting the file... mystery... 13.44.14 # just like our 'lib/libtlsf.a: could not read symbols: Archive has no index; run ranlib to add one' random error :-) 13.44.54 # I'd love to hit it locally and inspect intermediate files to understand whats going on 13.47.16 # is it always the same bot ? 13.51.14 # no 13.51.31 # are we building with make -j ? 13.51.55 # with -jn where n is num of cores AFAIK 13.54.00 # sometimes it can yield very strange results 13.55.07 # pamaury: -j can give strange results if you don't take care of your dependencies. we take rather good care of ours. 13.55.21 # apparently not good enough 13.55.58 *** Saving seen data "./dancer.seen" 13.56.05 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 13.56.06 # I can tell you for sure that even in Makefiles with perfect dependencies I've hit some weird errors, usually only happen once, of course 13.56.23 # wodz: that's entirely possible, of course. bugs happen. 13.56.40 # pamaury: you talk like -j is black magic. it's just parallell compilation. 13.56.40 # I'm not blaming make though, that could be a bug in the compilers 13.56.44 # what makes you think it's a make -j error? just because it's strange? 13.56.47 # yes 13.57.11 # because you get it only with make -j and not with make ? 13.57.36 # how do you know? 13.58.39 # With limited number of builds on our farm this days we could switch to -j1 for a week or so and see if strange problems go away. 13.59.22 # Sight, I'm not saying "this is make's fault", I said (please read) 1) i'm not blaming make 2) i've got errors only with make -j 3) which I don't have with make 13.59.22 # That's all, conclude what ever you want 13.59.57 # Correlation is not implication, as one says 14.00.19 # libtlsf certainly look suspicious 14.01.22 # Zagor: In which way? 14.02.32 # wodz: in that it's very often failing there. 14.03.27 # actually this is the only static lib we produce which seems to trigger this error 14.04.28 # could it be that codecs for example do not depend on libtlsf.a ? 14.04.43 # I'll take a peek 14.05.00 Join amee2woof [0] (~thomas@ve504.cugnet.net) 14.05.17 # in plugins IMO we explicitly compile tlsf.c file 14.05.53 # :q 14.07.23 Quit Buglouse (Ping timeout: 276 seconds) 14.07.27 # ok, mikmod and pdbox do use libtlsf but do not compile a copy and I recall seeing failures there 14.08.00 Quit __jae__ (Read error: Operation timed out) 14.09.21 Join __jae__ [0] (~jae@dedicated.jaerhard.com) 14.10.22 Join amayer_ [0] (~amayer@mail.weberadvertising.com) 14.12.57 # aac codec for instance does not specify dependency on libtlsf.a, so it is linked before libtlsf is completed 14.13.29 # ouch 14.15.24 # maybe make libplugin.a depended on libflsf.a 14.16.27 # but only a few codecs use tlsf, right? 14.16.35 # yes 14.16.43 # I mean libcodec 14.17.06 # then adding it as a depencency for all would affect build performance. all codecs would have to wait for tlsf to complete before linking. 14.17.32 # we specify in codecs.make which codecs use which libs. it feels to me like tlsf should be specified there. 14.17.44 # could be 14.17.54 # though I'm a bit confused because I don't even see tlsf specified there at all 14.18.24 # It quite new move to have it compiled as separate lib 14.18.52 # the dependency bit has been omitted apparently 14.22.06 # but where is it even linked? that's supposed to be handled in that file too 14.23.39 # ahh, libtlsf.make adds it to EXTRA_LIBS 14.24.02 # hmm, so it should propagate down to all codecs 14.25.26 # I think that's a bad idea. all codecs should not be linked with tlsf 14.25.49 # those using it should list it in codecs.make 14.26.27 # thats another matter, but if libtlsf.a is added to EXTRA_LIBS why it fails? 14.27.11 # currently the very first codec should compile and link libtlsf.a 14.27.27 # you're thinking serially. don't. :-) 14.27.34 # they are all build at the same time 14.27.42 # (potentially) 14.27.44 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 14.28.05 # that's nasty, it starts building the codec before having the dependency ?! 14.28.50 # pamaury: yes, since we haven't said the lib is a dependency 14.28.52 # ah, you mean one codec started producing libtlsf.a but didn't write file completely while the second tried to link with this incomplete .a ? 14.29.01 # wodz: yes 14.30.04 # I don't see how individual dependency could solve this 14.31.10 Quit wodz (Quit: Leaving) 14.43.44 Quit einhirn (Ping timeout: 245 seconds) 14.53.38 Quit AlexP (Ping timeout: 248 seconds) 14.55.43 Join AlexP [0] (~alex@rockbox/staff/AlexP) 14.55.45 Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) 14.57.39 Quit jlbiasini (Ping timeout: 256 seconds) 14.58.37 Join jlbiasini [0] (~metaphysi@109.103.46.91) 15.00.42 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 15.08.01 Quit einhirn (Ping timeout: 255 seconds) 15.19.50 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 15.19.50 Quit n1s (Changing host) 15.19.50 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.33.48 # Hmmm, the Clip Zip port is still marked "unstable" on the homepage 15.35.00 Quit pamaury (Ping timeout: 245 seconds) 15.36.32 # as a matter of fact, *only* vorbis uses tlsf 15.37.03 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 15.37.17 Quit AlexP (Remote host closed the connection) 15.37.33 Join AlexP [0] (~alex@rockbox/staff/AlexP) 15.37.35 # I can't remembed the purpose of EXTRA_LIBS. the name is too generic. 15.38.51 # and when I remove libtlsf from it, only libsetjmp remains 15.39.18 Quit mortalis (Quit: Leaving) 15.45.55 Quit Poodlemastah (Quit: ZNC - http://znc.in) 15.51.22 Join eckoit [0] (~ryan@50.65.10.24) 15.56.00 *** Saving seen data "./dancer.seen" 15.56.43 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 16.07.37 # that should fix the tlsf dependency problems 16.07.49 Join dfkt [0] (dfkt@unaffiliated/dfkt) 16.09.47 Quit kevku (Ping timeout: 264 seconds) 16.12.36 # ...except it didn't. hmm. 16.25.02 Part LinusN 16.26.01 Join Poodlemastah [0] (~Poodlemas@109-124-180-122.customer.t3.se) 16.26.13 Quit Poodlemastah (Client Quit) 16.31.45 Quit jlbiasini (Quit: jlbiasini) 16.48.48 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 17.07.07 Join PurlingNayuki [0] (~PurlingNa@121.35.227.58) 17.08.34 # There're still several major bugs with RaaA... but really works fine with me. 17.12.01 # Zagor: some plugins too, no? 17.12.30 Quit PurlingNayuki (Quit: Leaving.) 17.12.41 # kugel: yes, I fixed both codecs and plugins 17.12.52 # though the tlsf dependency issue remains. not sure why. 17.13.38 # copper: unstable means incomplete manual and maybe broken graphics for a couple of games in this case 17.14.04 # there was a lot of talk about promoting it to stable, I thought it was a done deal 17.14.34 # no idea sorry 17.15.54 # copper: IIRC (but it's a bit vague) that this discussion was after 3.12, and promoting to stable at random times between releases has some awkward side effects 17.16.12 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.16.43 Quit the-kyle (Remote host closed the connection) 17.17.07 Join WalkGood [0] (~4@unaffiliated/walkgood) 17.18.02 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 17.21.44 Join Ward [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 17.22.08 Nick Ward is now known as Guest54714 (~Mirandaha@176-120-190-109.dsl.ovh.fr) 17.39.27 Quit Zagor (Quit: Clint excited) 17.40.55 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 17.42.18 Quit the-kyle (Remote host closed the connection) 17.43.33 Quit bebna (Quit: Leaving.) 17.43.55 Join dynion [0] (~52a896aa@www.haxx.se) 17.44.16 # hey guys! think i might have found a bug... or it's just a human error...] 17.44.52 # the video 5th gen goes into ipod after every reboot 17.45.01 # instead of rockbox 17.45.26 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 17.46.05 # [saint] ? 17.46.10 # you are probably leaving the hold switch on 17.46.12 # read the manual 17.46.47 # nope 17.46.59 # even without hold it doesnt go into rockbox 17.47.27 # or you are holding menu to turn it on, which also dualboots the original firmware 17.47.44 # or is the rockboc installation gone after one time 17.47.47 # ah... ok:) 17.47.56 # press the select button one time to turn it on normally 17.48.52 # well first i have to get it out completely 17.48.56 # instead of the sleep mode 17.49.27 # god this is a frustrating os... now i know why i hated apple 17.50.09 # should i re-rockbox it before doing it again? cause i can't get it offline properly 17.51.08 # the manual explains how dualbooting works 17.51.17 # oh you didnt mean the apple manual 17.51.19 # to ge tback out of the apple OS you have to hard reset 17.51.27 # you guys made your own... awesome:D 17.53.34 Join Bug2000 [0] (~bug2000@unaffiliated/bug2000) 17.56.01 *** Saving seen data "./dancer.seen" 17.57.21 # Thanks torne! 17.57.29 # Human error it is:D 17.58.08 # so from now on... if i want to start it just use the big round button:D sounds idiot-proof enough 17.59.20 Quit dynion (Quit: CGI:IRC (EOF)) 18.00.17 Join pretty_function [0] (~sigBART@123.252.212.119) 18.00.45 Quit pretty_function (Client Quit) 18.26.38 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 18.26.48 Quit preglow (Ping timeout: 240 seconds) 18.27.34 Join preglow [0] (thomj@skrotnisse.pvv.ntnu.no) 18.27.35 Quit preglow (Changing host) 18.27.35 Join preglow [0] (thomj@rockbox/developer/preglow) 18.27.40 Quit aevin_ (Ping timeout: 264 seconds) 18.27.57 Join aevin [0] (eivindsy@unaffiliated/aevin) 18.30.46 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.39.20 Join lorenzo92 [0] (~chatzilla@95.237.104.74) 18.45.12 Join TheSphinX_ [0] (~briehl@p5B321E02.dip.t-dialin.net) 18.46.26 Quit melmothX (Remote host closed the connection) 18.46.55 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 18.47.33 Quit TheSphinX^ (Ping timeout: 252 seconds) 18.48.42 Join TheSphinX^ [0] (~briehl@p579CC7C8.dip.t-dialin.net) 18.49.02 # * lorenzo92 implementing backlight controller for R1 in rb 18.52.13 Quit TheSphinX_ (Ping timeout: 260 seconds) 18.54.12 Join TheSphinX_ [0] (~briehl@p5B3229FD.dip.t-dialin.net) 18.57.04 Quit Bug2000 (Read error: Connection reset by peer) 18.57.19 Quit TheSphinX^ (Ping timeout: 248 seconds) 18.58.13 Quit melmothX (Quit: #) 18.59.43 Join TheSphinX^ [0] (~briehl@p579CC32C.dip.t-dialin.net) 19.00.24 Quit TheSphinX_ (Read error: Operation timed out) 19.06.00 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) 19.06.37 Quit pamaury (Ping timeout: 255 seconds) 19.07.02 Quit lorenzo92 (Ping timeout: 276 seconds) 19.07.59 Quit Rower (Quit: sover) 19.08.09 Join Strife89 [0] (~Strife89@adsl-98-80-214-204.mcn.bellsouth.net) 19.13.10 Part eckoit 19.14.48 Join mt_ [0] (~quassel@41.233.134.80) 19.14.48 Quit mt (Read error: Connection reset by peer) 19.27.06 # <[Saint]> [03:33:49] Hmmm, the Clip Zip port is still marked "unstable" on the homepage <-- you expect otherwise? 19.27.28 # there was a lot of talk about promoting it to stable, I thought it was a done deal 19.27.51 Join xela [0] (~xela@i59F7927D.versanet.de) 19.28.36 # hey all. i managed to get a 240gb toshiba to work in a ipod video. problem now is replay "stutters" a couple of times when playing a song. 19.30.09 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.32.15 Join lorenzo92 [0] (~chatzilla@95.237.104.74) 19.32.17 # does this ring a bell for somebody? 19.34.02 Quit lorenzo92 (Client Quit) 19.34.22 Join lorenzo92 [0] (~chatzilla@95.237.104.74) 19.34.28 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.35.49 Quit lebellium (Ping timeout: 245 seconds) 19.36.15 # <[Saint]> copper: "stable" has less to do with the stability of the port, and more to do with meeting a set of requirements: complete manual, all applicable plugins, rbutil support, etc. 19.36.36 # yeah I know, I thought those requirements were met 19.36.40 # <[Saint]> Apparently it's lacking in at least one of those areas, which doesn't entirely surprise me. 19.36.44 # <[Saint]> It's a very new port. 19.37.57 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.38.03 # <[Saint]> Changing the port classifications to something a little more obvious has been discussed quite a few times, but no one ever seems to come up with anything better than unusable, unstable, and stable. 19.38.32 # <[Saint]> but it is often amusing, and confusing, that unusable and unstable rarely actually mean that literally. 19.38.34 Quit lebellium (Read error: Connection reset by peer) 19.39.02 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.39.34 Quit lebellium_ (Ping timeout: 245 seconds) 19.43.56 Quit lebellium (Read error: Network is unreachable) 19.44.27 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.44.49 Quit zoktar (Quit: -) 19.46.15 Quit akaWolf (Ping timeout: 245 seconds) 19.53.17 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 19.53.58 Quit lebellium (Read error: Connection reset by peer) 19.54.29 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.56.03 *** Saving seen data "./dancer.seen" 19.57.36 Quit xela (Ping timeout: 256 seconds) 20.01.46 Join xela [0] (~xela@i59F7927D.versanet.de) 20.05.14 # xela: does it stutter only when rebuffering? 20.09.08 Quit amayer_ (Quit: amayer_) 20.11.44 Join amayer_ [0] (~amayer@mail.weberadvertising.com) 20.12.09 Quit WalkGood (Ping timeout: 256 seconds) 20.17.17 Join nomada [0] (~nomada@irc.consciente.de) 20.18.02 Quit Strife89 (Quit: ------->) 20.19.40 # nls: when does rebuffering take place 20.20.41 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) 20.21.19 # just before the buffer is empty or when skipping out of what's buffered, the disk will spin up then and if it takes too long for some reason that will cause a dropout. You can also see the buffer state in the "buffering thread" screen in the debug menu 20.27.47 Join Strife89 [0] (~Strife89@adsl-98-80-214-204.mcn.bellsouth.net) 20.29.50 # nls hard to see it happen 20.31.41 # <[Saint]> It's quite easy to see it happen, actually. 20.32.34 # <[Saint]> System - Debug - View buffering thread 20.32.39 # <[Saint]> xela: ^ 20.32.49 # <[Saint]> You can see the buffer empty and fill in realtime. 20.32.59 # <[Saint]> (with playback, of course) 20.33.07 # i know but to start a replay and then do it in time 20.33.36 # <[Saint]> You don't need to, it will refill the buffer again fairly quickly. 20.33.47 # <[Saint]> It isn't as it it only happenes once. 20.34.24 # and if you use lossy music it should take a half hour or more for it to empty if you playlist is long enough 20.34.53 # <[Saint]> s/lossy/really hideously lossy/ 20.35.45 # it could be the 64MB model! 20.37.12 # <[Saint]> Oh...guess you're right, actually. A rough guess with my classic suggests it will take about ~30 mins to deplete the buffer with lame 320 20.37.29 # <[Saint]> (64MB ~59MB available buffer) 20.38.38 # <[Saint]> Allowing playback control in the view buffering thread screen might be a good idea. 20.38.53 # <[Saint]> The you could actually cause a rebuffer and watch it happen. 20.39.19 # <[Saint]> afaik the keys (on at least a few targets) are free to allow play/pause and seeking. 20.41.12 # i thought you could skip from that screen 20.41.17 Join TheSphinX_ [0] (~briehl@p5B323AA1.dip.t-dialin.net) 20.41.44 # i will try 20.42.09 # it stutter doesnt happen when the playback continues from track to track 20.42.15 # only when i start the playback 20.42.18 # and not always 20.43.56 # <[Saint]> n1s: apparently not on the Classic? 20.44.11 # <[Saint]> Unless for the keys are no longer << and >> 20.44.16 # nls/Saint: skipping doesnt work there 20.44.29 # <[Saint]> I seem to recall it used to, as n1s said. 20.44.32 # <[Saint]> It likely broke. 20.44.49 Quit TheSphinX^ (Ping timeout: 276 seconds) 20.46.10 # i can do it on my c200 with the down/menu button but it has a rather old build 20.46.16 # * lorenzo92 backlight and charger detection working on R1! 20.46.45 # nls seems like i can skip with the wheel 20.48.09 # xela: skip untill the number on the left of the slash after "usfl" drops to 0 and it should rebuffer 20.49.53 # tried it 20.50.13 # nls it takes a little while until playback starts because the disk spins up 20.50.18 # but it doesnt stutter 20.50.24 # so the effect is different 20.50.46 # hmm, yeah a small dropout is expected when skipping like this 20.52.49 # and not every song stutters 20.53.42 # xela: in the buffer thread screen, is pcm almost full most of the time? 20.55.00 # yes 20.58.08 # nls: yes 20.58.37 # hmm, i'm out of ideas then 20.59.12 # i am not quite sure whether or not it happens only with vbr files 20.59.55 # what codec? 21.00.34 # xela: and is this with a very recent build? 21.01.15 # 3.12 21.01.29 # (Buffer: 59.3MB) 21.01.35 Quit dv_ (Read error: Connection reset by peer) 21.02.41 Join dv_ [0] (~quassel@chello080108009040.14.11.vie.surfer.at) 21.03.27 # perhaps it's worth it to test with a current build, there were changes to enable ata dma for the ipod video among others today so that might help but it's just a wild guess 21.03.51 # nls: and to describe the stuttering: the playback starts for about 1-2 seconds, then a gap of maybe 0.5-1 second and then conitnues. sometimes up to three "stutters" 21.04.36 # nls: it used to work like a charm before i replaced the hd (but was an older build on the old hd). so my guess would have been a different timing/whatnot of the new hd 21.05.37 # so only when starting playback? 21.05.51 # yes 21.06.15 # <[Saint]> Hum, yes...seems skipping int eh buffering thread view is broken. 21.07.12 # kugel: pff we will need to find a clean way to select the right io pin to start the radio, I mean, R0 and R1 have the same chip but different RST pin ^^ 21.07.13 # perhaps the new disk is slower and rockbox doesn't wait enough before starting but this would surprise me, might be worth trying current build still 21.07.39 # [Saint] I am able to skip using the wheel. but behaviour seems to be slightly different (since it doesnt stutter then) 21.08.00 # nls are there nightlies somewhere? 21.08.31 # <[Saint]> Ohhhhhhhhhhhhhhhh! 21.08.47 # <[Saint]> << and >> are irrlevant, and skipping is done with the scrollwheel... 21.08.48 # xela: http://build.rockbox.org/ apparently we call the current builds dev builds now, they are the very latest rev 21.08.54 # <[Saint]> how, ...obvious. :-S 21.09.12 Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) 21.09.20 # [Saint]: yeah it's on various unexpected buttons on all targets it seems :) 21.09.27 # [Saint]: well, this menu is for people who know what they do... it even says "keep out" ;) 21.10.02 # <[Saint]> skipping tracks with the volume control seems /very/ non-obvious to me ;) 21.10.17 # <[Saint]> Especially considering the fact that the << and >> buttons are free. 21.10.33 # [Saint] << is used to leave the view 21.10.44 # <[Saint]> Apparently I'll be looking at key maps today, yay...my favourite thing. 21.10.52 # [Saint]: you have git access, don't you? :P 21.10.59 # <[Saint]> xela: menu+select is more consistent, imo. 21.11.10 # <[Saint]> n1s: Not direct, no. 21.11.39 Quit y4n (Quit: PÆNTS ØLF!) 21.11.43 # I've been told that it was put on non-obvios buttons in this menu on purpose (long time ago though) 21.11.48 # <[Saint]> Although this isn't a plugin, the keymap could be greatly improved by allowing full playback control and using menu+select to exit the screen. 21.11.52 # ah, well left leaves the view on most targets it seems so perhaps that's why as this feature was probably added in later 21.11.56 # non-obvious too 21.12.37 # <[Saint]> I say treat it like a plugin on the devices we can. 21.12.52 # <[Saint]> all scrollwheel targets should be able to have full playback control in this screen. 21.13.18 # i think there are even debug screens that can't be left at all on some targets :) 21.13.28 # <[Saint]> Heh. 21.18.04 # nls: checked with latest dev build stuttering still there 21.20.46 Join eckoit [0] (~ryan@96.53.108.182) 21.22.25 # [Saint]: menu+select is ok, especiall if there is a hint in the view 21.22.38 # <[Saint]> There wouldn't be. 21.22.51 # <[Saint]> But you'll notice that many plugins on iPod exit this way. 21.22.59 # <[Saint]> its jsut that this screen isn't a plugin. 21.23.11 # <[Saint]> We can treat it as such, though. 21.28.40 # nls: i wonder how else i could debug/hunt down the stutter thing 21.29.09 # nls: is there something like an error log like if some ata stuff timed out of such? 21.29.30 # Hi 21.29.41 # anyone can help me with a STMP3780/MX233 junker ? 21.30.03 # is it possible to dump the memory map of that device somehow ? pinmux and DRAM config would be probably emough 21.30.28 # I want to give u-boot a stab on these, since we now have u-boot ported to mx233 as well 21.31.44 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 21.32.13 # Marex: what you mean by 'dump memory map of the device'? 21.33.39 # I mean dump the registers of the DRAM controller and the PINMUX controller 21.33.44 # sorry 21.34.11 # you mean the values or what? 21.34.14 # yep 21.34.34 # Marex: ask pamaury ;) there is also the hwtool for that :) 21.34.44 # now that's the nick Im looking for ;-) 21.34.55 # pamaury_: poke ? 21.34.58 # lorenzo92: thanks 21.35.16 # anyway there is the thing called hwemul in utils/imxtools 21.35.22 # Marex: you're welcome 21.35.42 # Marex: yes ? 21.35.53 Nick pamaury_ is now known as pamaury (~quassel@rockbox/developer/pamaury) 21.36.07 # pamaury: can I dump the DRAM controller and PINMUX controller register values somehow ? 21.36.28 # pamaury: from the running firmware that is, I'd like to give u-boot a stab at this XFi3 device now that we have it ported to mx233 21.36.39 # it'd give me a portable hacking rig 21.37.29 # I don't quite understand for what you want to use u-boot but hey. You could write a plugin to dump all the values but I'm not sure of the use of it 21.37.37 # pamaury: the thing is, we have our own HW init altogether, so I need to dump the values from the running firmware, to be able to process them and put them into our HW init code 21.38.11 # pamaury: actually -- is the bootloader in that device locked with some key? Or is the CPU pristine (with no signing key) ? 21.39.50 Join einhirn [0] (~Miranda@p4FC74D02.dip0.t-ipconnect.de) 21.39.52 # ok, so for the dram value: we keep the OF init code (original firmware) does the low-level init of dram and then we only change them to change the frequency (I took them from linux). For the pinmux, well, it's the same thing: the OF init does the init pinmux cfg and we change it. On the X-Fi3 the device is locked with key "0" 21.39.53 # pamaury: the plan here is I want to turn this device into portable hacking rig to be able to test at least some Linux drivers if I have no EVK around ... 21.40.14 # pamaury: ah ok .. key 0 is stock key, right ? 21.40.25 # pamaury: I ordered also fuze+, that one is locked or not ? 21.40.46 # same thing, locked with key only containing zeroes 21.40.51 # ah, super :) 21.41.06 Join anxt [0] (~user@64.141.19.175) 21.41.14 Join einhirn_ [0] (Miranda@bsod.vpn.tu-clausthal.de) 21.41.15 # pamaury: ok, so is it possible somehow to dump the registers from the running firmware then ? 21.41.30 # pamaury: I dont care if I have to reflash the device or whatever ;-) 21.41.56 # if you can run rockbox on it that's trivial yes 21.42.21 # there is a simpler way however 21.42.23 # pamaury: I didnt manage to compile one from latest git with emdebian 4.7.2-4 toolchain 21.42.34 # pamaury: oh, please educate me :) 21.43.32 # we use our own toolchain. I wrote a tool which allows one to poke at the registers remotely (from the PC). If you first run the OF init code and then that code, you can read the DRAM and PINMUX registers easily 21.43.51 # pamaury: hm .. you mean the USB loader ? 21.44.14 # yes, you put the device in recovery mode send code by usb 21.44.16 # funny thing -- I wrote one as well by reverse engineering the USB protocol between MFGtool and MX28 :/ 21.44.31 Quit einhirn (Ping timeout: 256 seconds) 21.44.33 # were I to know you had the same thing going, I'd just stick with yours :) 21.44.51 # I think the mx28 and mx233 use the same protocol 21.45.02 # <[Saint]> Nothing wrong with occasionally reinventing the wheel ;) 21.45.03 # pamaury: I'm able to jumpstart mx233 chip as well, yep 21.45.05 Part eckoit 21.45.40 # pamaury: ok ... so I need the init code (.sb ? bootstream?), load it into the device via USB ? 21.45.41 # anyway, this piece of code is in our repository, in utils/imxtools/hwemul. It would be better if you manage to compile it yourself. Otherwise I can send you a built one 21.45.52 # lemme try 21.46.15 # you might have to build the other directories under utils/imxtools/ before 21.47.02 # ok, hwemul_tool ready 21.47.37 # you need to build the code in dev/, did you ? 21.47.54 # (utils/imxtools/hwemul/dev) 21.48.19 # ah dang 21.48.25 # /usr/lib/gcc/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: error: no memory region specified for loadable section `.note.gnu.build-id' 21.48.48 # this is my LD generating --build-id ... it's some new stuff in recent binutils 21.49.02 # hum, ok, you'll need to modify the linker script file to drop it, you know how do to this ? 21.49.27 # in your case that's hwemul.lds 21.49.49 # yea ... I fought this before 21.50.04 # is there any way to actually configure the cross toolchain prefix ? 21.50.36 # I might just use tools/configure and use a different toolchain I have sitting around (might just be fastest) 21.50.55 # for the main binary of rockbox I think so, for this little tool no, you'll have to edit the Makefile: the first lines 21.50.59 # I have this arm-linux-gnueabi- toolchain here which has linker that doesn't generate this junk 21.51.13 # pamaury: ok then, hang on a bit 21.51.53 # ../lib/hwemul.h:26:24: fatal error: hwemul_soc.h: No such file or directory 21.51.58 # is this intended ? ;-) 21.52.06 # I think you missed some file when commiting this stuff 21.52.49 # you need to generate a register map 21.53.11 # I'm in the process of changing this but hey, you'll have to do it, let me remember how do to this ^^ 21.53.54 # you need to compile the lib/ before 21.54.06 # and before this the imxtools/regtools/ ^^ 21.54.56 # ok, compiled, hwemul_tool ready 21.55.31 # so you have successfully compiled hwemul_tool and the dev/ dir ? 21.56.04 *** Saving seen data "./dancer.seen" 21.57.16 # nls, [Saint] thanks a lot so far, maybe more another time 21.57.45 # yep 21.58.03 # pamaury: yes 21.58.08 # Real key: 467cc254f81be8e78d765a2e63339fc9 21.58.10 # is this right ? 21.58.28 # ah ... it's AES'd 0x00 key 21.58.30 # nevermind 21.58.50 # the real key is random ^^ If you want i'll explain you the firmware format...later :) 21.58.58 # there's a document on that 21.59.01 # so first, we'll do a little test 21.59.06 Quit xela (Quit: Verlassend) 21.59.18 # http://elk.informatik.fh-augsburg.de/gnublin-cdrom/Datasheets/imx28/iMX28_SB_Description.pdf 21.59.23 # Marex: yeah, at the time I first wrote the tools there was none ^^ 21.59.53 # so, in dev/ you should have hwemul.sb, can you send it to the device in recovery mode ? 21.59.54 # heh :) 22.00.00 # pamaury: let's try 22.00.04 # our loader is imxtools/sbloader 22.00.27 # (sbloader 0 hwemul.sb) 22.00.35 # hi, i just installed rockbox via the gui tool, I have some dir ##MUSIC## and ##PORT# is this same to rm -rf ? 22.00.52 # the device should appear as fee1:dead in lsusb in case of success 22.02.06 # I have to hold vol-up, right ? 22.02.20 # on which device ? 22.02.24 # xfi3 22.02.52 # it's power 22.03.21 # a reliable way to trigger it: plug usb, hold power, reset the device 22.05.36 # ok, loaded 22.05.54 # does it appaear as feel1:dead in lsusb ? 22.05.58 # yep 22.06.06 # cool :) 22.06.10 # now run hwemul_tool 22.06.43 # running 22.06.51 # now you have a kind of shell 22.07.02 # (type help) 22.07.16 # you can read by address (read 0x10) or by name if you load a soc description 22.07.28 # oh, so read32 is what I want to do now 22.07.30 # nice :) 22.08.06 # the STMP3780 is about the same thing as MX23, right ? 22.08.33 # to do this do: 22.08.35 # soc imx233 22.08.35 # read HW_PINCTRL_CTRL 22.08.40 # STMP3780=MX233, same chip 22.09.14 # pamaury: I'm ok with memory addresses 22.09.54 # now I should warn you: the tool runs out of iram so currently the dram is not initialised 22.09.58 # pamaury: is there not some kind of a difference between STMP3780 and MX233 ? I mean, the bootrom recovery code identifies as 066f:3780 on mx23 too, but I recall the bootrom on STMP3780 is older 22.10.21 # pamaury: you mean SRAM ? ( stuff at 0x0 ) 22.10.27 # yes 22.10.33 # there are several versions of the bootrom mostly to fix bugs 22.10.41 # pamaury: ok, how do I go about initing it with the original bootloader ? 22.10.44 # pamaury: heh :) 22.11.01 # first download a firmware upgrade for the zen x-fi3 from creative 22.11.19 # pamaury: FYI have you ever seen the bootrom sources ? 22.11.41 # no 22.11.54 # but i've disassembled it :) 22.12.19 # disassembly might just have been way easier to read 22.12.23 # did you ? 22.12.52 # pamaury: no 22.13.11 # it has a terrible architecture anyway, and has bugs 22.13.29 # mx28 is good in that it's industrial design 22.13.40 # and the bugs there were mostly ironed out by FSL guys 22.13.55 # all right, firmware update downloaded 22.14.09 # you'll need to run cabextract on it 22.14.10 Quit thomasjfox (Ping timeout: 245 seconds) 22.14.28 # ah good, it's this 22.14.50 # you should get a file called firmware.sb it in, right ? 22.14.56 # firmware.sb :) 22.15.21 # so zenfwupdater is some sbloader with a pretty face ? 22.15.34 # now, run imxtools/sbtoelf -z firmware.sb -o ZENXFI3 22.15.38 # all right, I have firmware.sb 22.15.38 # ok 22.16.25 # ok, got it 22.16.47 # we have some zen* code but it's for older zens, this one is completely different. You should get files called ZENXFI3*. You want to keep the ZENXFI3.____.* ones, remove the others 22.17.11 # ok, I have it in /tmp anyway 22.17.27 # 14 megs of junk, nice 22.17.33 # you should copy them in hwemul/dev/ 22.17.58 # ok ? 22.18.00 # let's assume you put them in hwemul/dev/tmp/ 22.18.12 # now edit hwemul.db (in hwemul/dev) 22.18.42 # in the sources section, add an entry for all the ZENXFI3.____. files except the last one (number 3 iirc) 22.19.00 # for example: boot0 = "tmp/ZENXFI3.____.0.elf"; 22.19.43 # yep 22.19.47 # #4 is the last one 22.19.51 # done 22.20.17 # now load them and jump them one after another ? 22.20.33 # call them 22.20.48 # not jump :) 22.20.50 # ok 22.20.51 # so load boot0; call boot0; load boot1; call boot1; 22.20.56 # yep 22.21.01 Join sakax [0] (~sakax@d8D862D2D.access.telenet.be) 22.21.40 # and then you should be able to "make" again and get a brand new hwemul.sb file which init the dram 22.22.08 # yea ... you should add hwemul.db into Makefile dep list 22.22.25 # transfer error at send step 30 22.22.27 # ah, I was unsure it was, i'll do it then ^^ 22.22.32 # ;-) 22.22.35 # hum, try again ? 22.23.02 # then maybe I made an error, you should only load the first 3 ___.x.elf files instead of 4, 22.23.09 # let me check 22.23.13 # [Saint]: if i hold menu on a classic while plugging into pc and the headphones output constant buzz and player freezes would that be related to g#379 22.23.43 # yeah, only load the 0, 1 and 2, not the 3 22.23.54 # good 22.23.54 # got it 22.24.01 # bluebrother^: is fsbluebot down? 22.24.29 # Marex: and then run everything again: go into recovery mode, run sbloader, hwemul_tool and you're done ! 22.24.59 # yep, done ... and RAM seems to be online 22.25.06 # at least reading it doesn't crash the chip 22.25.17 # readline support would be nice ;-) 22.25.19 # reading never crashes 22.25.39 # pamaury: really ? if you read RAM which is dead, it'll jump into DABT handler 22.25.41 # yeah I know, that's really just a dev tool, I didn't put too much effort in it 22.25.58 # no prob, I can relate to that at times 22.26.01 # Marex: my experience is that only a few memory ranges trigger an abort 22.26.05 # very strange 22.26.17 # pamaury: we use that in U-Boot to detect the DRAM size at runtime ;-) 22.26.36 # hum, then the dram is part of this region :) 22.26.56 # are you a uboot dev or just hacking uboot ? 22.27.28 # hello guys - how is the nano2g usb thingy going? :) 22.29.06 # sakax: stalled 22.29.55 # :( 22.33.33 # so on arm forth plugin takes 92560 bytes in mem + stacks (~8k I think) 22.38.55 Quit pamaury (Ping timeout: 256 seconds) 22.39.29 # * lorenzo92 nice 58v battery, seems I'm wrong with a variable type :D 22.52.04 # where do I configure battery ADC reading precision? right now I have 5mV but R1 fuel gauge is more precise 1.25... 22.52.30 Quit n1s (Quit: Ex-Chat) 22.52.39 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.54.47 # wodz: is that the size of the entire forth kernel ? 22.55.45 # yes but this number is when compiled with -Os 22.55.57 # -Os build on x86 doesn't run correctly 22.58.05 # I also implemented just a few hooks to our pluginapi just to see if it is working 22.59.35 Join [Saint_] [0] (~quassel@101.98.158.103) 22.59.36 # 133352 is for arm with -O0 (-O0 works as simulator plugin) 22.59.54 # tomorrow I'll test on actual target 22.59.59 Nick [Saint_] is now known as Guest33140 (~quassel@101.98.158.103) 23.00.25 # <[Saint]> amayer_: I highly doubt it, but that patch is really quite aggressive...it would't surprise me if it caused any number of errors. 23.00.30 Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130117041235]) 23.01.35 Quit amayer_ (Quit: amayer_) 23.02.23 # <[Saint]> amayer_: you might want to try (if you haven't already) verifying it only happens with the patch applied, and if so, comment on the gerrit thread, and if so, filing a bug report. 23.02.46 # <[Saint]> errr...bum, I messed that up. 23.03.38 # <[Saint]> Check if it happens without the patch applied; if it does - file a bug report; if it doesn't - mention your findings in the gerrit thread for the task. 23.04.00 # <[Saint]> Aaaaaaaaaaaaannnnnnnd, he's gone. 23.04.04 # <[Saint]> Double bums. 23.04.57 # <[Saint]> Can someone please assist me with a simple pass/fail test regarding EQ presets? 23.05.05 # <[Saint]> Test procedure: 23.05.30 # <[Saint]> Verify EQ is enabled; apply an EQ preset, check if EQ is still enabled. 23.05.39 # <[Saint]> Expected result: 23.05.44 # <[Saint]> EQ remains enabled 23.12.27 # g#388 23.15.49 Quit kevku (Ping timeout: 245 seconds) 23.16.24 # <[Saint]> wodz: nice :) 23.16.46 # <[Saint]> (unfortunately, bluebot is on holiday though? :)) 23.19.33 # someone on the fuze+ forums reported 29 hours of playback with eq and mp3 at 320Kbps, I didn't know that was *that* power consuming 23.33.12 Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 23.34.41 Quit Strife89 (Quit: Heading home.) 23.35.26 Join TheSphinX^ [0] (~briehl@p5B321E8C.dip.t-dialin.net) 23.38.36 Quit TheSphinX_ (Ping timeout: 252 seconds) 23.38.49 Quit wodz (Quit: Leaving) 23.42.31 # pamaury: with rockbox? 23.42.36 # is 29h good or bad? 23.43.03 # better than the OF (~20h) and worse than mine with basic mp3 (~39h) 23.43.17 # (~35 sorry) 23.43.32 # yes with rockbox 23.44.56 Join Tim_Elliott [0] (~Tim@68.179.137.177) 23.45.58 Quit Tim_Elliott (Client Quit) 23.46.19 # the OF is really this bad? 23.46.28 # yeah 23.47.06 Quit SuperBrainAK (Ping timeout: 256 seconds) 23.48.30 Join TheSphin- [0] (~briehl@p5B322E7D.dip.t-dialin.net) 23.51.07 Quit TheSphinX^ (Ping timeout: 252 seconds) 23.56.07 *** Saving seen data "./dancer.seen" 23.57.52 Quit prof_wolfff (Ping timeout: 256 seconds) 23.58.27 # nice