--- Log for 14.02.110 Server: wolfe.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 9 hours ago 00.00.09 # for now I was just going to try and use the new fft with it 00.00.17 # since thats really easy and would get most of the speed up 00.00.21 # Oh yes I remember now. I looked at that months ago and forgot about it. (bias) 00.01.19 # #define BIAS(x) ((x) + (bias*0)) 00.01.20 # hmmmmm 00.02.20 # haha 00.02.35 Quit petur (Quit: Zzzz) 00.02.40 # Mhm. I think I found the guy, but not sure ^.^ 00.03.14 # email him and ask 00.03.20 # Thats what I did 00.04.40 # If he turns out to be the original creator and allows me to steal his work I might be able to publish my personalized Brownstowne-Theme under CC-license on the rockbox themes pages. Would be awesome :) 00.05.09 # I wonder what kind of answer that is. Such a post can easily be read as unfriendly though I give you that it could be overlooked. I just wish that people take themselves a little more time to answer and pay some attention 00.05.35 # i'll try to be more careful in the future 00.05.52 # thanks 00.06.53 # liba52 hasn't been updated since 2002 00.07.04 # anyone care if I kill dead code and such in it 00.08.39 # saratoga: I think that bias is just there for floating point. 00.09.00 # yeah looks like it 00.09.05 # i took it out 00.09.24 # i'll commit it to the mdct branch and then when we merge it'll get clean up 00.10.34 # ok. 00.10.49 # whats the easiest way to run the sim remotely on a linux machine over xwindows and ssh? i know longer have direct access to an ubuntu machine 00.11.39 # Also, this : #elif 1 (code that defines MUL(a,b).).... #else ... (Another definition of MUL(a,b)) .. What's that ?? 00.12.53 Quit m3dlg (Ping timeout: 240 seconds) 00.12.56 # saratoga: I used vnc when I needed to work remotely. 00.13.18 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 00.13.47 # saratoga: try ssh -X user@remote 00.14.26 Quit checker (Quit: CGI:IRC (EOF)) 00.16.32 # but I'll still need an xwindows program for windows right? 00.18.23 # Better suited for #rockbox-community 00.18.36 # definitly. I've used Xming before. (For this to work you have to have ssh_server (sshd) installed and running on remote. Which is not default in Ubuntu.) 00.19.32 Join Strife89 [0] (~michael@adsl-154-22-223.mcn.bellsouth.net) 00.20.06 # Currently reading through the FAQ and I must say I really admire how much work was done to make rockbox possible. All this reverse engineering and stuff. Seems like rockbox is a real hackers masterpiece :D 00.22.26 # (by which I mean most of you guys, I suppose) 00.22.47 # waran: Most. :) 00.22.56 # waran: (Not me, I'm just a user. :) ) 00.23.12 Quit tetsuo55 () 00.23.45 Join stooo [0] (~sto@f051065128.adsl.alicedsl.de) 00.24.53 Quit Olof- (Ping timeout: 240 seconds) 00.26.29 # mrsomeone's todo list needs a "compare wav file" function in test_codec so we can more easily check if changes to the codecs introduced glitches 00.26.32 # doing it on pc takes too long 00.29.38 Quit punkt (Quit: Leaving) 00.29.49 # someone deleted a locked thread with an explination of why I locked the thread 00.30.07 # it would be nice if we didn't do that, since the whole point of putting the explanation is to remind people of the rules 00.33.23 # stripwax, mt: do you care if I expose the fft in the codeclib.h header so I can use it in liba52? 00.33.35 # for now its a lot easier to use the fft directly then to figure out how to use the mdct itself 00.34.10 # I don't see a problem. 00.34.28 # do you think its possible to put windowing code in the codeclib as well? 00.34.46 # liba52 should have an ASM optimized version, maybe sharing with another codec is possible 00.37.31 # liba52 also folds the windowing into the MDCT post rotation, which is probably a good idea on other codecs as well since it'll save a load/store per sample 00.37.34 # You mean having separate windowing code/function in codeclib, that liba52 could use ? 00.38.07 # yeah 00.38.25 # or maybe having an imdct_window function 00.38.37 # that computes the IMDCT and then windows the data during post rotations 00.38.45 # using a window function supplied by the codec 00.39.00 # Yes I was just thinking of that too :) 00.39.02 # i think most codecs could use that 00.40.28 # the imdct function itself could be made aware of whether it should window or not, and what window to use. (instead of having 2 separate functions) 00.41.04 # saratoga: "compare wav file" only makes sense for lossless 00.41.24 # having separate functions might be marginallly faster 00.42.11 # amiconn: it would be useful for some changes to lossy as well as a sanity check 00.42.17 Join Schmogel [0] (~Miranda@p3EE21E83.dip0.t-ipconnect.de) 00.42.23 Quit Schmo (Ping timeout: 256 seconds) 00.42.30 # but yeah i suppose having it compute the RMS difference or something would be most useful 00.42.42 # TheSeven: Why ? 00.42.59 Join tetsuo55 [0] (~eteu@82-171-117-177.ip.telfort.nl) 00.43.13 Quit tetsuo55 (Changing host) 00.43.13 Join tetsuo55 [0] (~eteu@unaffiliated/tetsuo55) 00.44.36 # because not having to decide things will save some cycles 00.44.43 # * domonoky wants general support for subtracks. The way its done in nsf is nasty.. 00.45.52 # * domonoky wanted to copy that for subtracks in the asap codec,but the i would loose the ability to seek :-/ 00.47.13 # TheSeven: Missed that ! Thanks. 00.47.33 # it'll just be one branch per call, typically about 200 calls a second, so not a big deal 00.53.37 *** Saving seen data "./dancer.seen" 00.54.17 Quit robin0800 (Ping timeout: 256 seconds) 01.00.13 Part froggyman 01.03.22 Quit utchybann (Read error: Operation timed out) 01.04.13 # heh liba52 doesn't even use IRAM for its imdct 01.04.45 # well the trig stuff is, but now the rest 01.08.23 # switching over to the new FFT gives 21.94MHz decoding for the 192k sample 01.08.26 # not sure what it was before though 01.11.31 Join GeekShado_ [0] (~Antoine@243.234.193-77.rev.gaoland.net) 01.12.26 Quit GeekShadow (Read error: Connection reset by peer) 01.13.20 # saratoga: Wasn't liba52's fft a bit faster ? or is the fft we're using now optimized ? 01.13.32 # mt: the one we're using now has a lot of ASM 01.13.35 # so its probably faster 01.13.43 # and 22.76MHz 01.13.50 # oh ok. 01.13.51 # so we're 800kHz faster 01.14.00 # but i only switched long blocks over, not short 01.14.27 # using IRAM this thing could probably decode at << 20MHz on ARM 01.14.32 # we should really be using it for mpegplayer 01.18.01 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 01.19.13 # oh local variables are on the stack which is IRAM anyway 01.19.14 # duh 01.20.36 # :) 01.22.08 Quit moos (Read error: Connection reset by peer) 01.22.36 Join moos [0] (moos@rockbox/staff/moos) 01.25.35 # " warning: dereferencing type-punned pointer will break strict-aliasing rules" 01.26.08 # i have no idea what that warning means, i'm basically just trying to cast from the liba52 complex type to the ffmpeg complex type which are functionally identical but delcared seperately 01.26.55 Quit piotrekm (Quit: piotrekm) 01.29.23 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 01.29.31 # hmm easy enough to fix i guess 01.30.04 Join checker [0] (~621342a9@giant.haxx.se) 01.30.19 # This can happen when you "type-pun" a pointer, ie you access a variable with a pointer which is not of the same type. Typical with a union 01.31.02 Nick aaron_ is now known as Adnyxo (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 01.31.25 # Merely bad style, but works ;) 01.31.41 # the structures are actually identical, they just have different member names 01.31.42 # %?bl<-1|0|1|2|...|N> using that conditional, |...| can be filled with as many sections "|-|" as desired? 01.31.47 # so i just renamed them 01.32.13 # I'm puzzled. Why isn't there a "title" object property with MTP... 01.32.37 # Isn't the title of an audio file one of its most important property oO 01.32.43 # saratoga, in way old pascal versions this would have been considered an error by the compiler :) 01.33.24 Quit bertrik (Quit: De groeten) 01.34.33 # this is c, a struct is just a funny type of array :) 01.35.02 # converting short blocks makes no measureable difference in performance, probably because my sample doesn't really use them 01.35.08 # Actually there is no array in c. Everything-is-a-pointer(TM) :D 01.35.42 # That's false. 01.36.07 # thats why offset[pointer_var] works just like pointer_var[offset] 01.36.24 # In some cases there is a fundamental difference between an array and a pointer. But these are subtle (and useful !) 01.37.00 # example? 01.38.19 # Hum, that's should happen on community perhaps ? 01.38.56 # just a tab away. Lets take it to community. 01.39.31 # ok liba52 now uses the new codeclib in the mdct branch 01.40.14 # speed up is less then 1 MHz, mostly because the ffmpeg and liba52 ffts are identical, the only difference being the ASM in the ffmpeg one 01.41.06 # liba52 is really interesting because its the only codec that i know of thats actually faster clock per clock on the gigabeat F then on PP 01.41.54 # i'm assuming that means theres not very good IRAM usage in the codec, but looking at the imdct i'm not sure where the problem is 01.47.21 # huh looking at it more closely, it does look like its using IRAM extensively 01.47.28 # i wonder what the gigabeat F does better 01.47.37 # to overcome the IRAM advantage 01.48.31 # waran: it's not *always* only bad style, if two pointers of different types alias each other, but both have been loaded into registers, the compiler may assume that it can keep the value of *b in a register unchanged after you assign to *a. 01.49.16 # Clearly strict aliasing is an optimiazation tool 01.50.23 # what exactly is %bc 01.51.01 # * pamaury has object properties at least partially working for MTP using tagcache 01.51.12 Quit checker (Quit: CGI:IRC) 01.56.03 Quit perfectdrug_ (Quit: perfectdrug_) 02.03.18 # i guess it doesn't make sense to convert too many formats to the new mdct until stripwax finishes with his init changes 02.03.25 # it'll just be a lot of work that'll have to be undone later 02.08.18 # Is there any way to get the sample rate of a file using tagcache tags or not ? iirc, it's related to the frequency in metadata but in tagcache, I'm can't find an equivalent 02.08.56 # pamaury: you could call the metadata parser on it I suppose 02.09.28 # Yes of course but it's slow so if I can avoid it it's better 02.09.38 # although i'm curious why libmtp needs to know what the sample rate of files already on the disk is? 02.09.47 # err mpt 02.09.53 # mtp 02.10.09 # libmtp doesn't it but I'm trying to implement the properties that are usually implemented in MTP 02.10.15 # *doesn't need it 02.10.22 # And sample rate is one of them 02.10.26 # i thought it just checked the files as they came in and then didn't need that once they're on the disk 02.13.40 # hmm .. avoiding the reversal of the spectral coefficients in the imlt in atrac3 only saves 0.11 MHz :/ 02.15.23 # i remember looking at requantization in atrac last summer and thinking we could speed that up a bit 02.15.52 # the tonal component coding thing happens too rarely to make much difference in performance, but the rest of it could be speed up 02.16.10 Quit waran (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 02.16.16 # and of course theres the little issue with it not being real time on coldfire 02.17.50 # Is it still not realtime ? I thought Buschel's optimizations last summer fixed that ? 02.19.02 # i don't think he did anything for coldfire 02.19.07 # IIRC he only has an arm target 02.20.37 # found it : http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22561 .. The amazing +639% ! 02.21.20 # ah 02.21.39 Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo Ï¢INTER ϾHIP 5iVE is OOON!!) 02.23.16 # makes me wonder if that patch was ever upstreamed to ffmpeg 02.23.26 # mt: http://forums.rockbox.org/index.php?topic=22932.0 02.23.32 # thats why i was thinking it wasn't real time 02.23.39 # perhaps some files are slower then others 02.24.37 # tetsuo55: it won't be, its not really applicable to ffmpeg 02.25.06 # its a lossy speedup? 02.25.31 # no its fixed point only 02.25.48 # ah I see .. 02.26.04 # or at least not obviously applicable to ffmpeg 02.27.11 # doesnt look that obvious to me 02.27.19 # Maybe that user was using an old revision . the thread was in october, ~2 months after the optimizations. 02.27.47 # if it increases performance for any random case, without decreasing accuracy or perfoemance elsewhere, i'm sure it will be accepted upstream 02.29.02 Join domonoky1 [0] (~Domonoky@g229163226.adsl.alicedsl.de) 02.29.35 Quit domonoky (Ping timeout: 265 seconds) 02.29.56 # tetsuo55: it optimizes fixed point math 02.30.01 # ffmpeg doesn't even do fixed point math 02.30.23 # it doesnt? 02.30.23 # :P 02.30.25 # so its not really applicable to them 02.31.16 Quit domonoky1 (Read error: Connection reset by peer) 02.32.11 # Should I commit that small optimization to mdctexp and trunk, or just trunk, so that mdctexp would be just for the mdct stuff ? 02.32.29 # i was wondering that 02.32.39 Join perfectdrug [0] (~marko@p5B0ED3E6.dip.t-dialin.net) 02.32.40 # is it in a file we'll need to change to use the new mdct? 02.33.04 # the ARM ltd profiler looks really nice 02.33.15 # i wonder if theres a way we can get them to donate a copy or two 02.33.17 # saratoga > i just checked the ffmpeg site through google, seems like there is a big interest in fixed point math, the devs try to have all codecs have 2 codepaths, fixed and floating 02.33.37 # theres even a fixed point math port from rockbox to ffmpeg on the to-do list 02.34.05 # but not for this particular codecd 02.34.29 # it's in atrac3.c .. it's now using the new mdct in the mdctexp branch, so we'd just have to change those few lines when merging back. 02.35.27 # would make it easier to stay in sync with ffmpeg trunk too (assuming it gets accepted) 02.35.32 # tetsuo55: do you have a link about the fixed point stuff? 02.35.41 # http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008684.html 02.35.49 # http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks#Add_wma_fixed_point_decoder_back_into_libavcodec 02.35.53 # heh 2006 02.36.04 # ignore the dates 02.36.35 # lots more here: http://www.google.nl/search?hl=nl&safe=off&q=fixed+point+ffmpeg&btnG=Zoeken&meta=&aq=f&oq= 02.37.14 # well when they get around to adding a fixed point decoder we should see about giving them optimizations for it 02.37.23 # anything that improves ffmpeg is a win in my book 02.37.33 # saratoga dont expect that 02.37.57 # ffmpeg has a clear policy, that they dont really work on feature requests, and that stuff like this has to be submitted as a patch 02.38.12 # rockbox clearly has a fixed point local version, that could be upstreamed 02.38.12 # yes I know, i've spent a good deal of time over there 02.38.38 # and its probably not just atrac, but many other codecs 02.39.04 # may sound obvious, but ideally all codec updates will occur in the ffmpeg trunk, then get synced into rockbox 02.39.46 # i have a similar problem with my project, unfortunately my patches are really only usefull in my project, as they are api hooks 02.40.08 # tetsuo55: They have a fixed-point cook patch that's been sitting in there (interesting patches) for ages, and we actually used that patch in rockbox - it decodes 200+% realtime btw - and it has yet to be committed. 02.40.09 # but if we find anything like memory leaks, etc.. we quickly submit a patch upstream 02.40.20 # damn 02.40.22 # i want that 02.40.22 # s/in there/in their/ 02.40.22 # :P 02.40.58 # Well, You have it in rockbox already. :) 02.41.02 # i assume you harras tem all the time in #ffmpeg-dev 02.41.04 # i dont 02.41.06 # :( 02.41.11 # * tetsuo55 has a D2 02.41.29 # i only play with rockbox in the sandbox on windows 02.42.04 # i use cook audio ALL the time on the pc though 02.42.19 # and that codec needs a lot of TLC 02.42.31 # Wouldn't trying to keep all of our code in sync with theirs by submitting it to them and updating off of their version just create a ridiculous bottleneck in the rate at which codec improvements could occur unless all Rockbox codec contributors had ffmpeg commit access too? 02.42.56 # only 1 rockbox dev really needs commit access 02.43.19 # This 1 dev being magically available 24/7/365? 02.43.29 # but yes, the bottleneck means you need a local ffmpeg branch that you can keep working on, while you wait for the offical ffmpeg trunk to catch up 02.43.50 # i have to go to bed now, more here http://producingoss.com 02.44.08 # Also doesn't that mean more work for Rockbox devs to fit the code into ffmpeg, rather than ffmpeg devs who know their code doing that work? 02.44.32 # ideally things would go smoothly on irc 02.44.32 Quit pamaury (Quit: abort();) 02.44.43 # and snippets of code would turn into commits swiftly on their side 02.45.05 # instead of slowly in a mailing list that nobody cares about 02.45.27 # i don't think trying to convert all of ffmpeg to fixed point makes much sense 02.45.35 # it'd just make a mess of their codecs 02.45.43 # i agree, just the parts your already doing anyway 02.45.47 # combined fixed/float codecs are ugly and difficult to work with 02.46.03 # i would guess rockbox has a large pile of patches, that get applied to ffmpeg in some way 02.46.14 # we don't actually use ffmpeg itself 02.46.18 # (locally) 02.46.32 # we do adapt [by rewriting] some of their code though 02.46.33 # I'm just not really sure I see the 'benefit' of creating additional work to integrate code to another project that has its own devs perfectly capable of working with us to do that. 02.47.26 # saratoga so you only use small bits of ffmpeg, in your own codebase? 02.47.50 # a few of our codecs started out as ffmpeg codec, and one ffmpeg codec started out as a rockbox codec, but we do very different things 02.48.04 # Llorean > the idea is that you change something, to the default ffmpeg file, and then provide that patch upstream, and the ffmpeg devs take it from there, and ask you for input when needed 02.48.29 # Llorean > i do agree that its hard to swallow, to have to do the whole thing yourself 02.48.39 # tetsuo55: That also doesn't really reflect the real-world situation 02.48.50 # unfortunately it doesnt :( 02.48.52 # As saratoga said, we're not really a port of ffmpeg. They're not really, realistically, "upstream" 02.49.04 # tetsuo55: what is involved in converting a codec to fixed point? 02.49.05 # yeah, i just understood that just now 02.49.22 # It's a good idea to try to learn about the situation before you make suggestions on how to 'improve' it. ;) 02.49.42 # i wrongly assumed it was similar to what my project does, include ffmpeg and wrap around that (with some minor patches to the ffmpeg source) 02.50.09 # saratoga > LOTS of beer 02.50.45 # if thats your answer then maybe you shouldn't be trying to tell people who have some idea what they're talking about how to do things 02.50.48 # Llorean > i based it off the few svn logs :P 02.51.29 Quit toffe82 (Ping timeout: 240 seconds) 02.53.11 # saratoga > i dont claim to have any idea how to do that, my mistake was that i misinterpretid the things i saw as a "local copy" where in fact it seems to be a "fork", and then only for a handfull of codecs 02.53.11 Quit saratoga (Quit: CGI:IRC) 02.53.17 Join saratoga [0] (~9803c6dd@giant.haxx.se) 02.53.27 # damn1 02.53.35 # [02:53] saratoga > i dont claim to have any idea how to do that, my mistake was that i misinterpretid the things i saw as a "local copy" where in fact it seems to be a "fork", and then only for a handfull of codecs 02.53.39 *** Saving seen data "./dancer.seen" 02.54.09 Join toffe82 [0] (~chatzilla@ppp-71-130-76-253.dsl.frs2ca.pacbell.net) 02.54.14 # tetsuo55: if you have no idea what you're looking at its still not a good idea to give advice 02.55.11 # also, if people are using lots of words you don't understand, thats another clue 02.55.18 # hope that helps 02.55.39 # maybe, but the generic idea still stands, it would be nice, if this stuff was available upstream in ffmpeg(with lots of support from that side) 02.56.22 Join Rob2222 [0] (~Miranda@p4FDCB4AE.dip.t-dialin.net) 02.56.37 # A lot of what we've got doesn't even make sense as a patch against their tree. 02.56.48 # yeah 02.56.52 # It really makes more sense to find someone who's familiar with their code and knows where fixed point codecs would fit within it. 02.56.53 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 02.57.29 # yeah 02.58.01 # hence my original comment that most of it isn't applicable to ffmpeg 02.58.46 # didn't most codecs used to be fixed point anyway? 02.58.52 # some time ago 02.59.09 # and now transitioned into all being floating 02.59.30 # no 02.59.59 # The transition from mostly fixed to mostly floating point code happened before compressed audio codecs like MP3 really took off 03.00.11 Quit Rob2223 (Ping timeout: 272 seconds) 03.02.08 # maybe im misunderstanding, but google is giving me fixed point decoders for almost all popular formats 03.03.01 # probably ours 03.03.34 # ouch> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-April/057293.html 03.04.49 # saratoga > that might be the cause yeah 03.04.50 # http://www.google.nl/search?hl=nl&safe=off&q=fixed+point+codec&btnG=Zoeken&meta=&aq=f&oq= 03.05.00 # lots of closed source stuff too 03.05.34 # but i can clearly see the rockbox patches being ignored in those search results too 03.06.15 # so its not for lack of trying from this side! 03.06.37 Quit toffe82 (Ping timeout: 258 seconds) 03.07.30 Join toffe82 [0] (~chatzilla@adsl-71-154-234-168.dsl.frs2ca.sbcglobal.net) 03.07.33 # all the results on that page for open source decoders are in rockbox as far as I can tell 03.08.15 # makes sense 03.08.20 # allright 03.09.19 # thanks for your serious responces 03.09.27 # reponses 03.11.06 # * tetsuo55 sleeps 03.18.11 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 03.20.42 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 03.21.01 Quit TheSphinX^ (Ping timeout: 246 seconds) 03.21.34 Join toffe82_ [0] (~chatzilla@ppp-69-238-92-73.dsl.frs2ca.pacbell.net) 03.22.02 Quit efyx_ (Remote host closed the connection) 03.22.43 Quit toffe82 (Ping timeout: 258 seconds) 03.25.47 # wow the mailing list hates my email formatting 03.26.11 Join toffe82 [0] (~chatzilla@71.142.13.13) 03.29.12 Quit toffe82_ (Ping timeout: 264 seconds) 03.30.08 Quit saratoga (Quit: CGI:IRC (EOF)) 03.30.14 Quit akur (Quit: Leaving.) 03.40.36 Join TheSphinX^ [0] (~cold@p54A5C04A.dip.t-dialin.net) 03.42.22 Join Nimbus [0] (~4b459917@giant.haxx.se) 03.43.26 Join toffe82_ [0] (~chatzilla@ppp-71-140-91-61.dsl.frs2ca.pacbell.net) 03.43.42 Quit Schmogel (Ping timeout: 256 seconds) 03.46.52 Quit toffe82 (Ping timeout: 240 seconds) 03.47.16 # is anyone in here? 03.50.21 # Nimbus: If you want to ask something please do, if someone is able to answer you they will. 03.57.27 Quit Nimbus (Quit: CGI:IRC (Ping timeout)) 03.58.22 Join Nimbus [0] (~4b459917@giant.haxx.se) 04.03.52 Quit Nimbus (Quit: CGI:IRC (Ping timeout)) 04.09.21 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) 04.16.01 Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net) 04.17.29 Quit TheSeven (Disconnected by services) 04.17.43 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.17.55 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.18.14 Quit Tomis (Quit: Tomis) 04.22.53 Quit Sajber^1 (Read error: Connection reset by peer) 04.38.04 Join Tomis [0] (~Tomis@70.134.74.176) 04.39.41 Join Barahir_ [0] (~jonathan@gssn-5f7560d1.pool.mediaWays.net) 04.43.21 Quit Barahir (Ping timeout: 256 seconds) 04.46.41 Quit amiconn (Disconnected by services) 04.46.43 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.47.05 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.47.45 Quit pixelma (Disconnected by services) 04.47.46 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.48.04 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.51.09 Quit Adnyxo (Ping timeout: 256 seconds) 04.52.24 Quit stooo (Ping timeout: 260 seconds) 04.52.57 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 04.53.40 *** Saving seen data "./dancer.seen" 05.04.29 Quit mt (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) 05.06.57 Join stooo [0] (~sto@f050237192.adsl.alicedsl.de) 05.11.23 Quit GeekShado_ (Quit: The cake is a lie !) 05.23.04 Quit Strife89 (Quit: Bed.) 05.26.52 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 05.29.13 Quit kramer3d (Ping timeout: 264 seconds) 05.32.43 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.122) 05.33.00 Quit S_a_i_n_t (Client Quit) 05.33.18 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.122) 05.42.57 Join Riku [0] (~Lss@cm48.omega219.maxonline.com.sg) 05.42.58 Quit Lss (Read error: Connection reset by peer) 05.43.27 Nick Riku is now known as Guest93909 (~Lss@cm48.omega219.maxonline.com.sg) 06.15.12 # arg! 06.15.38 # * S_a_i_n_t is poised for emplanation 06.15.47 # *fail 06.15.53 # explanation rather 06.31.15 Part toffe82_ 06.42.01 Nick kramer3d_ is now known as kramer3d (~kramer@unaffiliated/kramer3d) 06.44.18 # Llorean: mobile computing wasn't huge then though, arm drove back to soft approximations over fp 06.45.16 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 06.45.16 # I would personally love to have fixed point codecs in ffmpeg, gstreamer, etc. for my embedded projects on slow fp arm chips 06.45.23 # embedded linux 06.46.10 # ffmpeg already has multiplr codec variants selectable at runtime 06.47.12 Quit kramer3d (Ping timeout: 264 seconds) 06.53.44 *** Saving seen data "./dancer.seen" 06.56.18 # freddyb: seet, all targets build? 06.56.24 # sweet* 07.02.00 # * S_a_i_n_t wonders how checking out a 'clean' svn revision reports being 24***:24***M 07.02.56 # I did actually build them going through it. But there's a lot of targets and my automagic C checker is broken. 07.06.19 # I wonder what I broke...svn is having a hissy fit at me. 07.07.19 # JdGordon: is there an automatic way to build all the targets? 07.07.41 # there is a script somewhere to do it 07.07.55 # tools/release/sims.pl 07.10.28 # can it mess things up somehow if the connection drops while checking out a souce revision? 07.11.11 # it's all I can think of, I deleted the old folder, checkout out a new revision...but it's al messed up. 07.13.02 Nick kramer3d_ is now known as kramer3d (~kramer@unaffiliated/kramer3d) 07.14.29 # JdGordon: I'll put Samsung models in and then run sims.pl. The only problem I've had building stable targets was if I had a typo in the button_map instance. The last conditional is a catch all emtpy set. 07.16.25 Quit CaptainKewl (Ping timeout: 245 seconds) 07.16.34 # S_a_i_n_t: Are you using real linux, cygwin, or vmware, or something else? 07.16.49 # freddyb: ok, let me know when you are done and I'll commit it 07.17.38 # cygwin...(yeah, yeah :P) 07.18.33 # deleting the old source folder should be sufficient no matter how bad I mess the tree up..no? 07.19.02 # Cygwin can pose line ending problems. Are you using the console SVN command or something like TortoiseSVN? 07.19.19 # console. 07.20.00 # JdGordon: Will do. 07.20.12 # example of weirdness: checking out a brand new revision, and it stopping dead on " svn: Failed to add file 'manual/rockbox_interface/main.tex': an unversioned file of the same name already exists" 07.20.30 # which definately didn;t alredy exist... 07.26.08 # here we go..... 07.26.55 # ... 07.27.25 # * S_a_i_n_t is killed by suspense... 07.27.58 # Transmitting file data .................... 07.28.10 # is svn on the fritz 07.28.55 # that may explain my recent 'piss-offs' with trying to check-out... 07.33.46 # ok wierd, the checkin shows up on the main page.. I wonder whats broken 07.34.29 # wtf? 07.36.45 Quit kaniini (Quit: E.T. go home.) 07.44.03 # oh bloody hell... game over for the ondio sp's rombox 07.44.22 Join kaniini [0] (~kaniini65@dyn75-70.yok.fi) 07.45.07 Quit Horscht (Ping timeout: 256 seconds) 07.45.49 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 08.02.00 # hasn't it been a huge effort to keep the ondio's rombox alive fr as long as you have? 08.07.13 Quit phanboy4 (Ping timeout: 256 seconds) 08.22.05 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 08.25.16 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 08.37.04 Quit robin0800 (Remote host closed the connection) 08.48.35 Quit kramer3d (Ping timeout: 258 seconds) 08.51.59 Quit freddyb (Remote host closed the connection) 08.53.47 *** Saving seen data "./dancer.seen" 09.29.54 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 09.38.58 Join Kitr88 [0] (~Kitr88@BSN-182-122-137.dial-up.dsl.siol.net) 09.41.52 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.42.41 Quit Kitar|st (Ping timeout: 240 seconds) 09.43.13 Quit Kitr88 (Ping timeout: 246 seconds) 09.44.59 Join ender` [0] (krneki@foo.eternallybored.org) 09.49.30 Join Kitar|st [0] (Kitr88@BSN-182-57-57.dial-up.dsl.siol.net) 10.05.26 Join flydutch [0] (~flydutch@host66-209-dynamic.15-87-r.retail.telecomitalia.it) 10.11.23 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 10.13.38 Quit kramer3d (Quit: Leaving) 10.38.15 Quit dude187 (Read error: Operation timed out) 10.53.51 *** Saving seen data "./dancer.seen" 10.58.16 Join utchybann [0] (~papier@ede67-1-81-56-102-26.fbx.proxad.net) 11.01.50 Join xavieran [0] (~xavieran@ppp118-209-153-106.lns20.mel6.internode.on.net) 11.05.20 Join petur [0] (~peter@d54C6F9B2.access.telenet.be) 11.05.20 Quit petur (Changing host) 11.05.20 Join petur [0] (~peter@rockbox/developer/petur) 11.22.39 Join TopyMobile_ [0] (~topy@f049070201.adsl.alicedsl.de) 11.26.11 Quit TopyMobile__ (Ping timeout: 240 seconds) 11.39.45 Join DerPapst [0] (~DerPapst@p5797C11D.dip.t-dialin.net) 11.47.44 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 12.11.06 Join stoffel [0] (~quassel@p57B4C5B8.dip.t-dialin.net) 12.13.52 Join Buschel [0] (~ab@p54A3A9E4.dip.t-dialin.net) 12.14.26 # anyone with a coldfire target willing to test a atrac codec optimization? patch -> http://www.pastebin.org/91504 12.14.43 # I need a short run with svn against the patched version 12.14.51 # maybe pixelma? ;o) 12.20.38 Join Sajber^ [0] (~Sajber@h-143-173.A213.priv.bahnhof.se) 12.21.38 # Buschel: what exactly do you need tested? Also, is there a test file somewhere I can use? 12.24.31 # gevaerts: I need a speed test via the test_codec plugin 12.24.51 # I am a bit puzzld there are no *.rm test files on http://download.rockbox.org/test_files/ 12.24.57 # *puzzled 12.25.17 # no free encoder maybe? 12.30.53 # solved ;) 12.31.36 Join Farthen [0] (~chatzilla@e179233077.adsl.alicedsl.de) 12.31.41 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 12.35.49 # mt once linked me to a few (from some mplayer page or so?). Can't remember exactly unfortunately :\ 12.36.22 # testing on plain svn now (I assume you want to have both) 12.36.46 # pixelma: same for me. I have the files, but no link... 12.36.52 # gevaerts: yep 12.36.55 Quit Adub- (Read error: Connection reset by peer) 12.37.19 Join Adub- [0] (~Rotting@xplr-ts-t11-208-114-159-122.barrettxplore.com) 12.38.31 # Do you want me to listen to them as well, to see if the codec still works properly? 12.39.44 # yes, to be safe. butyou will only need to listen very briefly. if something is going wrong you ears would bleed ;) 12.40.30 Join Schmogel [0] (~Miranda@p3EE21EA7.dip0.t-ipconnect.de) 12.41.23 # too many typos today... :/ 12.41.41 # http://pastie.org/824273 12.41.45 # They seem to play OK 12.41.54 Join pamaury [0] (~pamaury@ALyon-551-1-70-117.w92-137.abo.wanadoo.fr) 12.43.26 # thanks! +8-10%, but still not fully realtime... 12.44.02 # but there is still some room left for tweaking :) 12.44.11 # progress is always good 12.46.02 # gevaerts: what target did you use? 12.46.18 # certainly not h120 :) 12.46.18 # h300 12.47.08 # Buschel - atrac not realtime on coldfire? 12.48.05 # ok. does the codec stil compile for you when changing line 60 in atrac.c (from IBSS_ATTR_LARGE_IRAM to IBSS_ATTR)? 12.48.33 # have you tried the mdctexp mdct ? 12.48.42 # stripwax: it is realtime on coldfire targets with large iram. 12.49.12 # ah, which coldfire targets have 'small' iram? i have an h120 12.49.19 # stripwax: no ,it did not try mdctexp, but i have read it will save another 1.5 MHz on arm. so, let's check it for coldfire as well :o) 12.49.43 # Buschel - I think mt reported an 11% speedup, or something (can't remember if that was for atrac though) 12.50.01 # (that wasn't on coldfire though) 12.50.03 # stripwax: the "large" one is CPU == MCF5250 12.50.19 # Buschel - ok so the h120 has a 'small' one I guess 12.50.26 # Buschel: no 12.50.31 # IRAM full 12.50.44 # gevaerts: too bad 12.51.09 # * gevaerts goes out to buy more IRAM 12.51.26 # hehe :) 12.51.39 # saratoga - (for the logs) - I don't understand why liba52 can't just use codeclib mdct? Why is only the fft bit applicable? 12.52.08 # the easiest way to optimize coldfire targets is to move stuff to iram 12.53.53 *** Saving seen data "./dancer.seen" 12.56.17 Quit S_a_i_n_t (Quit: [St.] has exited mIRC™) 12.56.35 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.122) 13.00.11 Quit Farthen (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 13.05.49 Quit stripwax (Quit: http://miranda-im.org) 13.10.09 Join mt [0] (~mtee@rockbox/developer/mt) 13.15.23 Join perfectdrug_ [0] (~marko@p5B0EC932.dip.t-dialin.net) 13.18.41 Quit perfectdrug (Ping timeout: 240 seconds) 13.26.41 Quit shaggy-h (Ping timeout: 240 seconds) 13.27.23 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 13.33.46 # gevaerts: does this patch compile for your h300? -> http://pastie.org/824320 13.34.35 # yes 13.34.57 # :o) is it faster? 13.36.07 # * gevaerts wonders where he put this usb cable 13.36.54 # gevaerts: You sent it to me, remember ? 13.38.02 # Did I? I thought I sent it to funman! 13.39.21 # Hum, tagcache_fill_tags does not fill the length entry of mp3entry. I think I'll fix that in a second 13.40.24 # Buschel: http://pastie.org/824326 13.41.55 # gevaerts: hmm, same as with first patch 13.47.52 # svn is really slooooooooooooooooooow today 13.49.45 Quit bmbl (Ping timeout: 245 seconds) 13.51.05 # pamaury: Slt, how goes your dircache rework, is it finished? I didn't test yet (not dev env here those last weeks) 13.51.38 # moos: hello 13.52.15 # pamaury: waw it tested enough? 13.52.16 # moos: I have two pendings orthogonal dircache rework: 1) Remove this awful 30kb buffer in dircache (I have a patch in FS) 2) Remove any use of a buffer of size MAX_PATH on the stack. I have some code but not finished. 13.52.45 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 13.53.01 # moos: you mean the one I commited more than one week ago ? 13.53.32 # oh ok, still working on it... If you need testing on big discs (aka big cache) I could 13.54.15 # pamaury: the complete scan rework. I didn't find time yet to fix my laptop problems (ie no dev env) 13.55.12 # Ah. I tested it and got not change. JdGordon also tried it and apparently it is working. I can't seen any reason for this to fail except if my trick with the FAT code is wrong but if think it's ok. 13.55.30 # moos: but yes, if you can try it on a big disc this would be great 13.56.21 # do you get improvements? I mean: is the scan faster now? 13.57.02 # pamaury: I will retry to get e dev env here, sinon, you will have to build me a beast build patched 13.57.22 # On my device I can't see a difference because I haven't got some many files. That's why a test on a big disc would be useful. 13.57.44 # I'm not sure it will scan faster with this because beasically it does the same thing but uses less memory 13.58.17 # okok 13.58.31 # did you get Slasheri's attention about it? 13.58.54 # The only possible improvement is the old code did depth first scan, this one does breadth first search so if the directory is contiguous, perhaps this is faster but it's unlikely. 13.59.09 # I haven't seen Slasheri for more than one week 13.59.43 # pamaury: ok, I will say you how things became here... 14.00.41 # Did someone notice that JdGordon multifont patch broke Ondio SP on the build table ? (region FLASH is full (/home/robert/rb/builds/build-archosondiosp/rombox.elf section .rodata) ) 14.01.15 # yup he advised that the rombox is now out 14.02.49 # "game over" for it to use his words :) 14.03.01 # *tu use 14.03.28 # * moos hides from amiconn's ammo :) 14.03.43 # I wonder if it wouldn't be possible to regain some space by e.g. loading bitmaps from disk after boot 14.03.46 # yes, I believe it was something along the lines of "bugger, its game over for the ondio sp's rombox..." 14.04.34 # I guess ondio sp doesn't use dircache... 14.05.17 # it doesn't 14.06.06 # Hum. Maybe I'll go through a little review of the code to see if I can gain some place. Does it use tagcache or not ? 14.07.05 # apparently, yes 14.09.01 # gevaerts: next try -> http://pastie.org/824345 does it compile and is it any faster? 14.10.41 # could just make multifont a bigmem-only feature :P 14.12.05 # does it even actually work on lowmem? Isn't the skin buffer smaller there as well? 14.13.53 Quit teru (Quit: Quit) 14.13.59 # hm, on ondio, the bitmaps are only 940 bytes, so loading those after boot isn't goint to achieve much 14.14.01 Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) 14.14.11 # are commits not showing in channel for some reason? 14.14.30 # no CIA bot anymore 14.14.41 # ah... 14.15.06 # Buschel: http://pastie.org/824348 14.15.14 # No real change 14.16.06 # gevaerts: yes, a pitty. so, I better leave the iram free for more efficient future options. 14.16.08 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 14.25.20 # pamaury: tagcache uses 27K on the archoses, so yes, there might be room there 14.25.45 # *27K binsize 14.27.18 # moos > CIA is down 14.29.10 # gevaerts: from what I saw, tagcache uses an enormous stack (16Kb !!!) so there is some work to be done in this area perhaps. 14.29.48 # pamaury: improving that will no doubt be good, but that won't fix rombox unfortunately 14.29.55 Quit petur (Quit: real life) 14.30.35 # True. But there perhaps are other areas to optimize. tagcache is kind of a fragile masterpiece so it's not the easiest one to tweak. 14.32.05 # One real long-term solution for rombox could be the ability to load parts of the binary from disk. That's probably not going to be very practical though 14.32.29 Join jeffp [0] (~jeffp@barmen.interhost.no) 14.34.02 # hey guys, i was just wondering whether anyone's working on rb for sansa fuze v2 14.34.02 # gevaerts: Loading bitmaps after boot kinda defeats the purpose of the splash screen 14.34.20 Join Farthen [0] (~chatzilla@e179233077.adsl.alicedsl.de) 14.34.39 # *especially* when running from flash 14.34.54 # amiconn: I was more thinking about the usb logo and the icons, but anyway I think that this sort of thing is not worth it for only a few hundred bytes 14.35.39 # gevaerts: I know a place where there is memory: in dir_uncached using the same FAT trick, one can divide the size of DIR_UNCACHED by two at first sight (if I'm correct) 14.37.50 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.38.45 # surely reducing stack, buffers etc won't help code fit in flash? 14.38.45 Quit robin0800 (Read error: Connection reset by peer) 14.39.47 # Don't know but I'm listing areas where there is some things to take (in a general way) 14.40.14 # Unhelpful: Of course not 14.40.24 # What uses flash memory ? 14.40.46 # In fact the binsize increase for multifont is relatively moderate, given what it adds (unlike some other features...) 14.41.13 # pamaury: code. read-only data. not much else, i'd expect. 14.41.17 # pamaury: Code, read-only data and initial values for data 14.41.40 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 14.43.21 # amiconn: do plugins change between rombox and rambox? 14.43.42 # * gevaerts suspects not 14.43.51 # Ahem, no 14.44.31 # Rombox, standard in-flash rombox and disk-based rockbox (.ajz/.mod) all come in the same package... 14.45.43 Quit Farthen (Ping timeout: 256 seconds) 14.45.57 # We could consider changing rombox builds to be separate builds, without e.g. tagcache. That wouldn't be a very nice solution though 14.48.56 # And it wouldn't work 14.49.24 # If you leave out tagcache (or any other non-trivial feature), language and voice ids change 14.50.33 # yes, they'd have to be fully separate builds. Not good 14.50.35 # That means loading disk-based rockbox (which is required before flashing if rombox is currently running) would mess up the whole ui 14.50.59 # You could have an equivalent disk-based rockbox with it 14.51.47 # Then people would just have to choose when installing: full rockbox with all features, or rockbox light with less features, but longer runtime 14.52.05 # Move the "optional" feature strings to the end? 14.52.19 # that would still break the plugin API 14.52.47 # * gevaerts doesn't like this sort of "solution" at all 14.53.03 # Runtime isn't really different on te Ondios 14.53.18 # there are still two targets that have rombox currently and for others it has been broken for quite some time (different time depending on the target) 14.53.23 # But the larger buffer has other advantages, e.g. being able to view larger jpegs etc 14.53.41 # or using a better quality voice 14.53.54 *** Saving seen data "./dancer.seen" 14.54.20 # In fact runtime might be *slightly* worse with Ondio rombox 14.55.16 # This is because the RAM has a 16 bit data bus, while the ROM only has an 8 bit bus. Hence code execution from ROM is slower, and the cpu gets less sleep 14.55.29 Quit Guest93909 (Ping timeout: 240 seconds) 14.55.58 # On the hdd-based archoses, the savings from having less disk spinups more than make up for this 14.57.14 # Of course, code running from IRAM isn't affected, and is faster than from RAM. IRAM is 32 bit, but there isn't much of it... 15.00.57 # gevaerts: last try -> http://pastie.org/824369 15.03.05 Quit moos (Ping timeout: 276 seconds) 15.04.10 Join moos [0] (moos@rockbox/staff/moos) 15.05.43 Quit tetsuo55 () 15.07.19 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 15.10.37 # Buschel: no change 15.10.43 # hmmm 15.10.47 Quit robin0800 (Client Quit) 15.11.15 Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) 15.14.17 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 15.14.31 # Buschel: I have to go now. If you need more tests, you'll have to look for another victim^Wvolunteer 15.15.02 # gevaerts: thank you for your time! 15.16.35 # btw, found the link to free atrac samples -> http://samples.mplayerhq.hu/real/AC-atrc/ 15.25.11 Join tetsuo55 [0] (~eteu@82-136-192-201.ip.telfort.nl) 15.25.29 Quit tetsuo55 (Changing host) 15.25.29 Join tetsuo55 [0] (~eteu@unaffiliated/tetsuo55) 15.30.01 Join akur [0] (~akur@bl6-144-197.dsl.telepac.pt) 15.32.47 Join Lss [0] (~Lss@cm48.omega219.maxonline.com.sg) 15.36.05 # re pamaury, tested your dircache patch. Working as plain svn (RAS). 15.37.05 # And what about dircache thread usage ? 15.37.22 # all is working as excepted, same scan time, same buffer size 15.37.54 Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) 15.37.54 # * moos forgot to to check with svn (I will) 15.38.35 # Normally this patch should increase dircache stack usage so I would like to now if t's safe or not :) 15.39.19 # if you are curious, the cache here take 20s to process, and my buffer is around 1,47mo, for 22200+ elements 15.39.43 # 120gb disc and gigabeast btw 15.39.49 # hehe, I will compare 15.39.56 # ok thanks a lot 15.40.50 # Is there a way to know from how much rombox overflow the flash area on ondio SP ? 15.40.57 # no problems, thanks to you to works on :) (or to be brave enough to work on... to pe more precise ;) 15.42.58 # btw I noticed that the "scaning disc" splash was in english (I do remenber to saw it too last time I tested your commited changes). 15.43.21 # I will check if is not french specific (i.e my mistake :) 15.45.27 Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 15.45.57 # amiconn, Unhelpful : does any of you know a way to know how much binsize we would have to free to have rombox fit the flash ? (becuse the error message does not give any information) 15.48.56 # to finally reach realtime for atrac on coldfire mr.someone should add some asm for the iqmf_dewindowing 15.49.56 # moos: The localisation of boot splashes got broken with one of the theming commits. Another thing JdGordon or kugel need to fix :\ 15.50.19 Quit S_a_i_n_t (Ping timeout: 256 seconds) 15.50.34 Join Scary [0] (~AreaFileU@93.115.9.163) 15.50.42 # amiconn: duh :/ (I was checking with another translation) 15.50.44 # It's not just the dircahce scanning splash, but also db commit, out of extension array etc 15.50.54 # * moos is annoyed by the boot time also :( 15.51.18 # JdGordon don't trust use and wants stats compare :( 15.51.39 # Buschel: Doesn't atrac have similar complexity as mp3? 15.52.33 # amiconn: no, atrac uses very computing intensive qmf-filterbanks 15.52.54 # Hmm, ok 15.52.59 # amiconn: at least 48 muls per sample (!) 15.53.13 # * amiconn wonders whether he could do something there 15.53.18 # jobec, can you try another battery bench on your clip after explicitly enabling and disabling the radio? 15.53.20 # Filters... and asm :) 15.53.23 # amiconn: and there is an imdct as well 15.54.13 # pamaury: I guess it's some 500 bytes, but no, you can't see it directly. 15.54.16 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.122) 15.54.33 # amiconn: yes, the dewindowing function is quite dumb, should be easy to implement in asm -- if one is able to write cf-asm :o) 15.54.35 # IIRC newer LD versions tell you how much more memory they would need 15.55.57 # TheSeven: I have a weird way to found but I don't like it but if there isn't a clean way to do it, I have no choice 15.58.08 # pamaury: going back to plain svn, and no functionnal changes as far I can tell, except of course the stack usage change (on the debug to 1%-->72%). Your code changes seems safe at least :) 15.59.38 # moos: the 1% is probably here because dircache loaded the cache from the disk. Can you try with plain svn and rebuild cache ? (this 1% is impossible otherwise) 16.00.27 # pamaury: amiconn is maybe one of the only one user/who knows about rombox around here 16.01.10 Quit teru (Quit: Quit) 16.01.26 # Hum, rombox would need 548 free bytes to fit the flash 16.02.40 Quit Sajber^ (Read error: Connection reset by peer) 16.03.10 Join moos_ [0] (moos@85-171-102-158.rev.numericable.fr) 16.04.01 # depends on which rombox you are talking about (which target)... 16.04.38 # ondio SP 16.04.49 Quit moos (Ping timeout: 252 seconds) 16.04.50 Nick moos_ is now known as moos (moos@85-171-102-158.rev.numericable.fr) 16.05.09 Quit moos (Changing host) 16.05.09 Join moos [0] (moos@rockbox/staff/moos) 16.05.11 # I know, just saying that this is not the only target that would be interesting 16.05.37 Join GeekShado_ [0] (~Antoine@120.64.199-77.rev.gaoland.net) 16.05.56 # Is it the only one which doesn't fit in flash ? 16.07.53 Quit GeekShadow (Ping timeout: 240 seconds) 16.09.16 Quit moos (Ping timeout: 246 seconds) 16.09.18 Join moos_ [0] (moos@85-171-102-158.rev.numericable.fr) 16.09.22 Nick moos_ is now known as moos (moos@85-171-102-158.rev.numericable.fr) 16.09.35 # rombox doesn't fit on any other bitmap Archos anymore (just the compile errors have been silenced) and making it fit on the others is more far off. The reason is that others have more features that are possible (e.g. the OndioFM has a radio and recording, the Recorders also have backlight). I'm impressed you want to help there anyways though :) 16.09.43 Quit moos (Changing host) 16.09.43 Join moos [0] (moos@rockbox/staff/moos) 16.11.13 # Perhaps there is nothing do to but at least I can try. 16.12.24 Join moos_ [0] (moos@85-171-102-158.rev.numericable.fr) 16.12.36 # the worst are probably the FM-Recorders/ RecorderV2s 16.13.07 # pamaury: comment added to the task. 16.13.16 # moos_: I just saw it ;) 16.13.23 # :) 16.13.45 # another difference between Ondios and all Recorders is the RTC 16.14.33 Quit moos (Ping timeout: 256 seconds) 16.14.35 Nick moos_ is now known as moos (moos@85-171-102-158.rev.numericable.fr) 16.14.47 Quit moos (Changing host) 16.14.47 Join moos [0] (moos@rockbox/staff/moos) 16.16.18 Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) 16.18.00 Join moos_ [0] (moos@85-171-102-158.rev.numericable.fr) 16.19.05 Quit moos (Ping timeout: 256 seconds) 16.19.10 Nick moos_ is now known as moos (moos@85-171-102-158.rev.numericable.fr) 16.19.17 Quit moos (Changing host) 16.19.17 Join moos [0] (moos@rockbox/staff/moos) 16.22.47 Join moos_ [0] (moos@85-171-102-158.rev.numericable.fr) 16.23.48 Quit moos (Ping timeout: 264 seconds) 16.23.58 Nick moos_ is now known as moos (moos@85-171-102-158.rev.numericable.fr) 16.24.15 Quit moos (Changing host) 16.24.15 Join moos [0] (moos@rockbox/staff/moos) 16.29.12 Quit moos (Ping timeout: 264 seconds) 16.31.57 Quit FlynDice (Remote host closed the connection) 16.32.14 Join FlynDice [0] (~FlynDice@wsip-98-191-154-2.oc.oc.cox.net) 16.34.00 Join moos [0] (moos@rockbox/staff/moos) 16.36.13 Join Jungti1234 [0] (~709bdd7e@giant.haxx.se) 16.36.20 # hello 16.38.16 # long long time no see 16.38.18 # wow, svn is slow today: last commit: 4kbytes transfered in 3m,10s :-) 16.39.01 # yeah, same for me 16.41.45 Quit n17ikh (Ping timeout: 256 seconds) 16.44.39 Quit Jungti1234 (Quit: CGI:IRC (EOF)) 16.46.35 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 16.46.41 # hehe, I just won 16 bytes on ondio SP ... :) 16.48.17 # Have people forgotten about the manual for WPS tags? 16.48.33 Quit phanboy4 (Ping timeout: 256 seconds) 16.51.05 # domonoky, git ftw ;) 16.51.45 # danopia_: git doesnt help if the repository i want to commit to is svn :-) 16.52.04 # i can mirror rockbox onto git :P 16.53.06 # does some one know what happens if i load a cfg with settings which only exist for color targets on a non-color target ? 16.53.55 # are the non-existing settings safely ignored ? (thinking about checking theme cfgs on the theme page) 16.53.56 # I also seriously doubt the slowness there was scm related 16.53.58 *** Saving seen data "./dancer.seen" 16.55.00 # More likely a holdup with the cia notification 16.55.08 # Since cia appears to be gone 16.55.29 # also what happens with non existing setting values ? for example "selector type: bar (color)" on a greyscale target ? 16.56.15 # true, a timeout in the commit hooks is probably the cause for this slowness. 16.59.53 # cia is down 17.00.05 # All the bots have disappeared and the site is down 17.00.37 # And Rockbox has a bit mirror already, but it is checkout only (obviously) 17.00.52 Quit Adub- (Read error: Connection reset by peer) 17.00.55 # s/bit/git/ 17.01.03 Join Adub- [0] (~Rotting@xplr-ts-t11-208-114-159-122.barrettxplore.com) 17.01.47 # yea CIA is down 17.02.40 # i'd offer my replacement (FBI) but i'd probably have to add hacks for it to work with your repo 17.03.01 # i can't recieve email withotu some advanced mailserver goodnes but i think i can do XML-RPC 17.04.28 # bertrik: i could try to remember to run one this night 17.06.07 Quit Scary (Ping timeout: 256 seconds) 17.17.38 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 17.23.24 Join Loggerin [0] (~tanjango@216.201.66.220) 17.24.53 Quit Loggerin (Client Quit) 17.30.28 Quit fxb (Read error: Connection reset by peer) 17.35.49 Quit akur (Quit: Leaving.) 17.39.42 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 17.41.32 Quit bmbl (Quit: Bye!) 17.47.54 Join fxb [0] (~felixbrun@h1252615.stratoserver.net) 17.50.00 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 17.50.02 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 17.54.26 # pixelma, pamaury: Actually there is still one target where rombox is available: the Archos Player 17.55.10 # And the warnings/errors haven't been silenced, the rombox build step has been deactivated for the targets where it doesn't fit anymore 17.55.16 # which is no bitmap Archos... and there are also flashed H100s (which I meant earlier with "two") 17.55.52 # * amiconn overlooked the word 'bitmap' 17.56.06 # domonoky: you can commit locally on git. ;) 17.56.27 # The H1x0 has no space problem at all (1MB flash instead of 256KB) 17.56.57 # Although swcodec rockbox is considerably larger than hwcodec (and the larger and 2bpp bitmaps add to that) 17.57.18 # Unhelpful: thats not what i want todo :-) 17.58.15 # domonoky: you want to be able to commit, i told you how you can commit. what's the problem? ;) 17.59.05 Quit martian67 (Ping timeout: 258 seconds) 17.59.10 # Unhelpful: no i want to make my changes live, the commit is only the tool for it. :-) 17.59.58 # you can do that too! mirror your git repo somewhere public. ;) 18.02.18 # "somewhere" is the wrong place. 18.05.24 Quit tha (K-Lined) 18.06.04 # Is rombox compressed in any way ? 18.07.21 # wow, it that valid C: [0 ... REC_NUM_FORMATS-1] = AFMT_UNKNOWN ??? 18.08.13 Join Jaykay [0] (~chatzilla@p5DDC76E9.dip.t-dialin.net) 18.08.27 Join JdGordon1 [0] (~jonno@c-24-22-210-83.hsd1.wa.comcast.net) 18.08.47 # pamaury: it can't be, it's executed directly from flash. 18.09.01 # ah true ;) I'm so stupid 18.09.08 Join Guest57645 [0] (~martian67@over.the.cat) 18.09.56 # that might be another thing you could try re: initdata, though... rather than looking for individual initdata arrays that could be calculated, just compress the whole lot. :) 18.10.34 Join petur [0] (~peter@d54C6F9B2.access.telenet.be) 18.10.34 Quit petur (Changing host) 18.10.34 Join petur [0] (~peter@rockbox/developer/petur) 18.11.08 # Unhelpful: you mean, compress all initdata and at runtime, uncompress them to RAM ? 18.11.33 # what is happening if the version.sh script returns weirs version like "r23773:24648M-100214"? where does the first "r23773:" come from? 18.11.44 # *weird 18.12.45 # pamaury: why not? initdata is used to provide the initial values of writable arrays, isn't it? so it needs to be copied to RAM anyway, doesn't it? it's at least worth seeing if compressed initdata + a decompressor will fit. 18.13.03 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 18.13.03 # assuming it's not compressed already, of course... 18.14.52 # That works only for initdata which is RW no ? Because otherwise will put it in .rodata and that will never end up in ram 18.15.14 # There isn't that much int data 18.15.34 # Although we could also compress all .icode, .irodata and .idata 18.15.53 # Not that much either - SH7034 has 4KB of IRAM 18.16.35 # amiconn: is "part of the data is compressed" perhaps something that could be done by the bootloader? i gather that bootbox is responsible for decompressing non-rombox firmwares... or am i mistaken? 18.16.56 # Not bootbox, but the flash loader 18.17.20 # The flash boot on archos is a bit more modular than on the other targets 18.18.37 # What exactly does the boot time looks like on an archos ? First there is the flash boot and then ? 18.19.42 Join moos [0] (moos@rockbox/staff/moos) 18.20.56 # It depends on whether the archos is flashed (flashing is optional, and not all boxes are flashable), and where you have a box with or without bootrom (the latter variant is rare) 18.21.53 # if it's flashed and with a box ? 18.22.39 # maybe we should work further on making features that make no sense on archos optional... the bitmap loader already doesn't support scaling on mono targets, but we could probably make a smaller bitmap loader specialized for loading bitmaps to mono. 18.23.14 # what's the point? we are just going to be back here in a few weeks anyway 18.23.19 Join robin0800_ [0] (~quassel@general-ld-216.t-mobile.co.uk) 18.23.33 # it broke just before 3.5 branch 18.24.02 # The standard way (without rockbox in flash): (1) CPU boots from its internal rom (it's a mask rom, not changeable). (2) The boot rom starts the archos firmware in flash. The loader that's part of it copies the rest of the firmware to RAM, then jumps there. (3) The firmware looks for an on-disk update (archos.mod for Players, ajbrec.ajz for the others). If it exists, it loads and starts that one 18.25.09 Quit robin0800 (Ping timeout: 258 seconds) 18.25.11 Quit JdGordon1 (Ping timeout: 252 seconds) 18.25.22 # On a flashable box, we replace the in-flash firmware with 3 components: our flash loader, and two firmware images, which can bei either compressed or uncompressed 18.27.22 Join MethoS- [0] (~clemens@134.102.106.250) 18.27.46 # Boot sequence changes as follows: (1) CPU boots from its internal rom (it's a mask rom, not changeable). (2) The boot rom starts our flash loader. (3) The flash loader checks buttons, and does one of three actions depending on that. (a) start the second firmware image. This is the default, full rockbox, which is updated by rockbox_flash.rock 18.29.35 # (b) start the first firmware image. This is the backup - bootbox, a cut-down rockbox that just handles charging and usb. It is there in case the default image is broken. (c) start minimon, a mini serial monitor for debugging/testing 18.33.52 # I think I will go back to my dircache optimizations, that's easier ;) 18.38.00 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 18.40.03 # Each of the two firmware images can bei either compressed (ucl) or uncompressed. In the latter case it is execute inplace 18.40.09 # Bootbox is compressed, of course 18.41.09 Join sudoman [0] (~sudoman@static-151-204-226-99.bos.east.verizon.net) 18.50.38 # rbuitilqt 1.2.5 is quitting unexpectedly when i try to open it. 1.2.4 works. 18.50.46 # this might help: http://pastebin.ca/1796406 18.51.06 # os 10.5.8 18.51.11 # * os x 18.51.13 Quit S_a_i_n_t (Ping timeout: 258 seconds) 18.53.08 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.131) 18.53.58 # sudoman: arg, not again. We had the same error with 1.2.4 on osx 10.4 :-/ 18.54.00 *** Saving seen data "./dancer.seen" 18.55.39 # bluebroth3r: ping ? 18.57.14 Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) 18.59.46 Join Strife89 [0] (~michael@adsl-154-22-223.mcn.bellsouth.net) 19.03.17 # the buttons used to force a ipod 3G reboot and then to enter disk mode are different than explained on http://www.rockbox.org/wiki/IpodConversionToFAT32#For_5G_and_below_iPods 19.03.27 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.03.51 # sudoman: it's a wiki, you can change it :) 19.04.02 # haha. thanks 19.04.27 Quit HBK (Read error: Connection reset by peer) 19.04.30 Quit phanboy4 (Read error: Connection reset by peer) 19.04.58 Join phanboy4 [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) 19.05.32 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 19.05.43 Join Lss__ [0] (~Lss@cm48.omega219.maxonline.com.sg) 19.06.04 Join hd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 19.06.04 Quit hd (Changing host) 19.06.04 Join hd [0] (~jd@Wikipedia/HellDragon) 19.06.13 Quit jd (Read error: Connection reset by peer) 19.06.21 # sudoman: as far as I know it's correct (menu + select to reboot and then select + play) 19.06.42 # for me, neither of those combos worked 19.06.59 # i did play and menu then back and next 19.07.16 # menu and select may work in the rb firmware, but i'm not sure 19.07.17 Quit lyngaas (Ping timeout: 272 seconds) 19.07.21 Quit shai (Read error: Connection reset by peer) 19.07.31 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.07.37 Quit Lss (Read error: Connection reset by peer) 19.08.47 Quit Adub- (Read error: Connection reset by peer) 19.08.58 Join Adub- [0] (~Rotting@xplr-ts-t11-208-114-159-122.barrettxplore.com) 19.09.48 # ah, 3rd gen (and older) might be different 19.10.59 # i made a wiki account. could i please be given editing permission? 19.11.14 # What's your wiki name? 19.12.19 # AndrewEngelbrecht 19.13.21 # OK, done 19.13.21 Quit flydutch (Quit: /* empty */) 19.13.31 # thanks ; ) 19.14.52 Quit robin0800_ (Remote host closed the connection) 19.17.32 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 19.17.44 Quit Adub- (Quit: japanese men make hot trannies) 19.20.42 Quit shai (Quit: Leaving) 19.20.53 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.20.55 # i reported a bug a couple days ago where when installing rockbox for the first time on a 3G ipod, the screen boots up with the contrast all the way up so that it is black and almost impossible to see anything. 19.20.57 # http://www.rockbox.org/tracker/task/11006 19.21.37 # as i mentioned in the report, this could be fixed by setting the default contrast to about 36 19.23.32 # JdGordon: What's the plan for the fms? 19.24.17 Quit Tomis (Ping timeout: 252 seconds) 19.27.46 # pixelma, sudoman: Yes, for ipod 1st..3rd Gen Menu+Play is reset, and Back+Next is diskmode 19.27.46 Quit HBK (Read error: Connection reset by peer) 19.28.12 # I didn't know the wiki stated the wrong combos. Iirc the manual is correct 19.28.22 Join HBK [0] (~hbk@HBK.broker.freenet6.net) 19.28.51 # Apple changed it with the clickwheels (4th Gen and later), since pressing the opposite sides is mechanically impossible on those 19.29.53 # i updated the wiki for the subject 19.30.07 # what about ipod nanos? 19.30.25 # Nano, mini etc are all clickwheel ipods as well 19.31.34 Quit shai (Quit: Leaving) 19.31.45 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 19.31.57 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 19.33.23 Quit stripwax (Ping timeout: 258 seconds) 19.40.08 # would it be out of the question to have the option in rbutilqt to not check for new updates but install using whatever cached information it has? this could be useful if someone needs to reinstall the firmware but doesn't have an internet connection close by. 19.43.26 Join Tomis [0] (~Tomis@70.134.85.73) 19.49.16 Join toffe82 [0] (~chatzilla@adsl-75-23-149-171.dsl.frs2ca.sbcglobal.net) 19.50.31 Quit crashd (Read error: Operation timed out) 19.53.30 # sudoman: rbutil already has a cache, but dont know if all code places really use it. 19.55.51 # sudoman: there is also the "Offline mode" checkbox. Also not sure if it works for all. 19.56.55 # domonoky: thanks 19.59.31 Quit Jaykay (Ping timeout: 256 seconds) 20.08.50 Join anewuser [0] (anewuser@190.73.72.96) 20.08.53 Quit anewuser (Changing host) 20.08.53 Join anewuser [0] (anewuser@unaffiliated/anewuser) 20.16.16 Join Jaykay [0] (~chatzilla@p5DDC76E9.dip.t-dialin.net) 20.17.10 Quit amiconn (Disconnected by services) 20.17.12 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 20.17.18 Quit pixelma (Disconnected by services) 20.17.20 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 20.17.36 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 20.17.37 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 20.17.38 # HEHEHE, look at that green delta ;) 20.18.40 # AlexP: well, I need to figure out why hwcodec is broeknm 20.18.49 # pixelma: did you get a chance to try changin that line? 20.18.55 # ah, I didn't know it was 20.19.02 # pamaury: nice :) 20.19.11 # * AlexP misses the commit bot 20.19.59 # is anyone else having trouble with svn hanging after a commit? 20.20.10 # It isn't hanging, it is just *really* slow 20.20.21 # give it a minute or two and it'll come back 20.20.22 # Yes, everyone. With CIA absent the commit hook times out before returning 20.20.59 Join lead [0] (~lead@p4FED8111.dip0.t-ipconnect.de) 20.21.36 # JdGordon: The fms patch doesn't apply at the moment incidently (I guess multifont). I didn't bother to look at fixing it :) 20.22.01 # I'm hoping to commit it this week... but depends on hwcodec testing 20.22.18 # as much as I dont care about those targets, I don't exactly want to intentioally break them :p 20.22.23 # sure 20.23.00 # pamaury: nice! shame its all ram though 20.24.41 Join KBH [0] (~hbk@rrcs-97-77-49-215.sw.biz.rr.com) 20.26.44 Quit panni_ (Ping timeout: 252 seconds) 20.26.52 Quit HBK (Read error: Connection reset by peer) 20.30.53 # my ipod dies at the battery level of 50%. is there any way to calibrate the indicator so that it's more accurate? 20.31.32 Join _zic [0] (~user@83-156-253-58.rev.libertysurf.net) 20.31.41 # is there anyone around who's interested in participating in the nano4g work? 20.31.51 # we have a bootrom-level code execution exploit :-) 20.33.54 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 20.35.09 Part jeffp 20.43.29 Quit stooo (Ping timeout: 240 seconds) 20.44.13 Join stooo [0] (~sto@e181183239.adsl.alicedsl.de) 20.49.10 # linuxstb: I wonder how to integrate the new mmx code in our build system 20.49.17 # amiconn: gevaerts was asking the other day about using asm-optimisations in the sim (for his n900). So I guess using MMX optimisations are the same issue.... 20.49.27 # Do we want to enable mmx permanently (for x86, that is)? 20.50.00 # On x86_64, mmx is standard, so we can do that, but not all 32 bit x86's support it 20.50.14 # That said, all non-stoneage x86's do 20.50.32 # I'd say we can safely require mmx for the sim 20.51.14 # Intel supports it since Pentium MMX, AMD since the K6. Cyrix 6x86 does as well (it even implements a slightly extended variant) 20.51.38 # Although maybe with the ability to disable it? 20.52.01 # The way libdemac is built doesn't allow runtime detection (currently) 20.52.13 # Unless it's fairly simple - I wouldn't spend much time on letting it be disabled 20.52.32 # It's just a matter of passing -mmmx to gcc or not 20.52.33 Quit mc2739 (Ping timeout: 248 seconds) 20.52.43 # gevaerts: How did you get on with enabling the ARM optimisations in the sim? 20.52.54 # amiconn: Then I guess disabling it is just editing the Makefile to move that... 20.52.57 # (yes, 3 'm's) 20.53.02 # Then I'd enable it uncoditionally and just document that if people really want to run without they can 20.53.03 Join lude187 [0] (~chris@cpe-75-187-48-206.columbus.res.rr.com) 20.53.15 # s/move/remove/ 20.53.16 Join gevaerts-phone [0] (~bc058851@rockbox/developer/gevaerts) 20.53.29 Quit lude187 (Client Quit) 20.54.03 *** Saving seen data "./dancer.seen" 20.54.25 # sudoman: you could try to set your battery capacity to a smaller value 20.54.31 # linuxstb: Regarding the n900 - it uses an arm, right? 20.54.34 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 20.54.41 # amiconn: Yes. 20.54.45 # linuxstb: those ARM defines do the trick, together with enabling one or two more files in SOURCES 20.55.04 # That makes everything build, axcept ape 20.55.18 # What happens with ape? 20.55.46 # Buschel: right now it's at the smallest setting. (it says there's about 126h on a full charge, but that's a known problem) i think that setting doesn't affect the charge percent calculation anyways. 20.55.46 # Did it give you a decent speed-up? 20.55.50 # I'll tell you later, when I'm home 20.56.26 # It didn't fix the audio dropouts, I didn't do test_codec tests 20.57.31 # sudoman: what iPod do you use? 20.57.42 # Buschel: ipod 3G 20.58.53 # Buschel: it might be relevant that i installed a replacement battery a couple of years ago. i only get about 2.5 hours out of it at this point. (but that might not be from a completely full charge) 20.59.11 # % is from voltage IIRC 20.59.22 # So if the battery is buggered that is probably it 20.59.36 # It can't supply the current required so shuts down early 20.59.44 # Buschel: there's no way of telling with the rockbox firmware as it doesn't say when the battery is charging or not, but the apple firmware does 21.00.02 # AlexP: is there a way to fix that? 21.00.08 # sudoman: ah ok. The iPod 3G has no correct estimation implemented as there were no reliable battery runtime measurements availabe. 21.00.10 # replace the battery 21.00.22 Quit tetsuo55 () 21.00.23 # If it is a dead battery 21.00.42 # AlexP: yeah, i might do that, or just get a 5.5G 21.00.54 # sudoman: We could easily implement the needed changes if you could do a battery bench with a good working (new?) battery. 21.00.58 # the % comes from the voltage AND the battery curve in the powermgmt-xxx.c files. so a different battery could also cause "low battery" shutdowns. 21.01.15 # ah, OK 21.01.29 # If the discharge curve is different 21.01.48 # or maybe the battery curve and min values were never calibrated for ipod 3g ? 21.01.54 # would it not be useful to submit a curve with my current battery? 21.01.57 # could be 21.02.12 # sudoman: Only if we know it is good 21.02.47 Nick KBH is now known as HBK (~hbk@rrcs-97-77-49-215.sw.biz.rr.com) 21.02.50 # AlexP: would i need to get an apple-supplied battery, or could i use a souped-up one? 21.02.52 Join tetsuo__ [0] (~eteu@82-136-192-201.ip.telfort.nl) 21.03.20 # * domonoky sees a: FIXME calibrate value for other 3g+ ipods in the relevant powermgmt-xxx.c file :-) 21.03.42 # hmmm :) 21.04.16 # sudoman: I'm not sure to be honest 21.04.24 # sudoman: it could also be a replacement battery. but we need to know the capacity in mAh 21.05.41 # current values for ipod3g: 3,37V = 0%. 3,38V is considered dangerious and 3,02V is shutdown. 21.05.45 # ok. is this issue related?: when charging from a "dead" battery, the percent quickly goes up to 100%. does that mean the charging is terminated early, or that charging is continuing and that the calibration needs fixing? 21.06.23 # there is also a curve for charging, which is probably wrong too. 21.06.28 # sudoman: and of course you should perform the test following the standards (e.g. clean restart after full charge, looping a folder that is larger than the iPods RAM) 21.06.38 # huh, my player shut down at 3.82V 21.07.14 # domonoky: It'll also shutdown if it fails to spin up the disk right? 21.07.16 # ^ (from my last test which didn't follow all of the standard rules) 21.07.24 # 3.82V should show ~50% with the current battery curve. 21.07.42 # domonoky: that's correct 21.07.47 Quit gevaerts-phone (Quit: Page closed) 21.07.48 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 21.08.01 # AlexP: yes, that values are only pure software. We also shutdown if we cant spin up the HD, or if power goes just out. 21.08.04 # AlexP: it managed to write the value to disk one second after the previous entry, so it must not have been a disk issue 21.08.28 # I don't quite follow that sentence :) 21.09.37 # sudoman: did it show the "low battery" warning before shutdown ? 21.09.56 # the battery benchmark writes a new set of data points every minute. when the disk is accessed, it writes them to disk. my final value is listed as being one second later than the previous, which implies that it detected the low power and wrote to disk 21.10.04 # domonoky: no it did not 21.10.15 # sudoman: Does it? 21.10.22 # Does battery nench work like that? 21.11.07 # as far as I know battery_bench caches values in RAM until the next spinup (e.g. for rebuffering) 21.11.09 # i was accessing a context menu or something. i guess it could have been a bug because i've experienced shutdowns while using the menus before. thought it was just a coincidence 21.11.18 # sudoman: then it probably wasnt a shutdown based on the values from the battery curve. 21.12.14 Nick Guest57645 is now known as martian67 (~martian67@over.the.cat) 21.12.26 # *correction: it saves a new set of points to memory every minute, and writes to disk occasionally, according to the manual 21.12.29 Quit martian67 (Changing host) 21.12.29 Join martian67 [0] (~martian67@about/linux/regular/martian67) 21.12.35 # sudoman: indeed 21.13.04 # domonoky: was it a power-failure then? 21.13.05 # sudoman: jup, if it would write directly to disk, the bench would not show normal behavior (much more power use) 21.13.27 # sudoman: either that, or a bug :-) 21.13.48 # gevaerts: Could you paste the output of gcc -E -dM - < /dev/null | cut -c 9- | sort on your n900 somewhere? 21.14.04 # could be a bug. i do remember having a bug/power-failure(?) at 40% once... 21.14.17 # sudoman: it could also have been a simple crash. 21.14.27 # if you expirienced shutdowns while using context menus before, it looks more like a bug. 21.14.45 # how is a crash different than a bug? 21.15.40 # sudoman: could you please be so kind and perform a battery bench without touching your ipod? ;o) as soon as there is a full reasonable battery bench we can change the code to allow (more or less) proper estimation of runtime. 21.16.05 # Buschel: ok i'll do that ; ) 21.18.34 # perfect :) 21.19.45 # gevaerts: The output of uname -m would also be interesting 21.20.43 Quit Buschel () 21.24.45 # for the benchmark, should i charge with the rockbox firmware or the apple firmware? 21.25.14 Quit shai (Quit: Leaving) 21.25.29 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 21.25.44 # sudoman: Using the apple firmware is probably safer. 21.25.52 # (and probably faster) 21.26.05 # faster? 21.27.25 # for the charging part 21.27.51 # pixelma: why is charging faster on the apple firmware? 21.27.58 # amiconn: how hard would it be for the flashloader to handle a firmware with a compressed and uncompressed section? presumably the compressed portion would need a list of offsets and lengths, or it could be decompressed contiguously with start/end addresses for each section used to move things to their proper places. 21.28.54 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 21.32.18 # Quite difficult... and it would mean that a full reflash is required 21.33.26 # I think it would better to make this part of crt0.S (which does the copying anyway, so it could uncompress instead of copying) 21.37.17 # The question is whether it's worth it. We're talking about ~8KB of data (probably compressible to half of that) 21.38.35 # is it ok to switch on "hold" during the battery test? 21.40.41 # so where do you guys host SVN? sourceforge? 21.41.12 # my commit announcer works with sourceforge now, it acts as a mailing list subscriber 21.41.35 Join freddyb [0] (~fred@pool-68-238-8-141.chi.dsl-w.verizon.net) 21.44.29 # danopia_: svn.rockbox.org 21.44.44 Quit tetsuo__ () 21.45.00 # hmm 21.45.09 # that makes it a little harder :P 21.46.55 Join checker [0] (~621342a9@giant.haxx.se) 21.48.12 # danopia_: but we ofcourse also have a commit mailing list, so you could just subscribe to that. 21.48.43 # domonoky, where is that, and if it works, are you interested in me putting an announcing bot in here (at least until CIA lives)? 21.49.34 Quit shai (Quit: Leaving) 21.49.42 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 21.50.38 Quit bertrik (Read error: Connection reset by peer) 21.50.44 # danopia_: http://cool.haxx.se/mailman/listinfo/rockbox-cvs a interim commit message bot till CIA is back would be cool. 21.50.54 Quit shai (Read error: Connection reset by peer) 21.51.00 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 21.52.43 # does anybody knows how to debug a plugin using DEBUGF? Should I reconf it with logf enabled? 21.55.03 # * domonoky thinks DEBUGF only works on sims (and maybe needs a debugbuild)., for target debug, use logf with a logf enabled build. 21.58.58 # Technically it also works for targets with a gdb stub, doesn't it? 21.59.56 # It does 22.00.17 Quit Jaykay (Ping timeout: 248 seconds) 22.06.57 # pixelma: ping? 22.07.39 Quit utchybann (Quit: WeeChat 0.3.0) 22.09.30 Quit stoffel (Read error: Connection reset by peer) 22.13.23 Quit S_a_i_n_t_ (Read error: Connection reset by peer) 22.14.39 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 22.15.11 Quit GeekShado_ (Read error: Connection reset by peer) 22.16.23 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 22.16.58 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.25) 22.17.53 Quit S_a_i_n_t (Client Quit) 22.20.32 # amiconn: and we're over by how much, now? :/ 22.21.06 Join Utchybann [0] (~ElMonitor@rps6752.ovh.net) 22.24.23 Join Jaykay [0] (~chatzilla@p5DDC76E9.dip.t-dialin.net) 22.24.35 Quit n17ikh (Ping timeout: 256 seconds) 22.30.07 # amiconn: the build environment is in scratchbox, i.e. not actually on the phone (I gave up on that, too impractical) 22.30.14 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 22.30.22 # amiconn: gcc -E -dM - < /dev/null | cut -c 9- | sort output : http://pastie.org/824782 22.30.43 # uname -m says "arm" in scratchbox, and armv7l on the actual phone 22.31.11 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 22.33.03 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 22.33.09 # ape compilation fails with http://pastie.org/824786 22.33.33 # This is with -DCPU_ARM -DARM_ARCH=6 added to EXTRA_DEFINES 22.39.41 # anyone think there is any point trying to optimise the skin displayer code? 22.42.33 # in what way? 22.43.07 # not really sure, but its called pretty often and if its worth getting 1% out of the codecs it might just be worth getting the same from there 22.43.26 # I'm sure there is plenty of room for improvement 22.45.08 # gevaerts: Hmm, strange. Would it be possible to get to see this intermediate .s file somehow? 22.45.32 Quit lyngaas (Ping timeout: 256 seconds) 22.47.40 # Hmm, eabi? 22.48.05 Quit tomers (Ping timeout: 252 seconds) 22.48.06 # I think so, yes 22.49.02 # amiconn: adding -S to the gcc line gives me http://www.evonet.be/~gevaerts/output.s 22.54.05 *** Saving seen data "./dancer.seen" 22.55.50 # Hrmm. It seems http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Extended-Asm.html#Extended-Asm "5.35.1 Size of an asm" is the problem 22.57.14 # I have no idea how to solve this, apart from removing all usage of .rept and manually replicating all this code in vector_math??_*.h 22.58.34 # it's not actually a real problem right now I think 22.59.09 Quit bertrik (Quit: De groeten) 22.59.31 # I mean, it breaks compilation of ape in this particular weird setup, but there are more important bugs to look at first before I can actually start thinking about actually playing ape files 23.01.27 # Is part of the website broken? I can't get to flyspray. 23.01.41 # wfm 23.01.49 # I can 23.02.00 Join saratoga [0] (~9803c6dd@giant.haxx.se) 23.02.12 # i wonder if the dircache improvements help playback on the c200v2 23.02.19 # the added memory might make a difference 23.02.33 # 30KB is a large fraction of the entire audio buffer on that player 23.02.40 # Can someone tell FS#11011 that while it may not be the reset combo for his iPod, it certainly is for the Nano? 23.02.46 # * Llorean isn't sure which is the reset combo for the Mini. 23.03.29 # menu+select is a hard reset 23.04.42 Quit _zic (Remote host closed the connection) 23.05.32 # Llorean: i wrote that. i guess some nanos have click-wheel and some don't? 23.06.03 Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) 23.06.08 # All nanos use Menu+Select to reboot 23.06.25 # as far as I remember, mini 2g is the same as video 23.06.33 # oops. sorry. i got the nanos and minis backwards 23.06.40 # I though the only ones that don't use Menu+Select are ones that have buttons independent of the wheel. 23.06.50 # sudoman: it's been answered to you 23.06.52 # it only applies to 1G - 3G ipods 23.07.23 # pixelma: sorry, i don't understand 23.07.27 # sudoman: All minis have a clickwheel. 23.07.31 # I thought pamaury meant 30Kbits because of (Kb) ? 23.08.16 # sudoman: Are you perhaps confusing "1st/2nd gen mini" wiith "1st/2nd/3rd gen ipods" ? 23.08.46 # linuxstb: not sure, i think i just got my memory backwards for the minis and nanos 23.08.56 # sudoman: But the minis and nanos are the same 23.09.01 # sudoman: http://www.rockbox.org/irc/log-20100214#19:28:51 and the following minutes 23.09.04 # (in terms of key combinations) 23.09.12 # i mean that i got them both wrong 23.10.04 # amiconn: i was mostly thinking "loader has a decompressor already, maybe using that would save some more space"... perhaps a simple header could indicate the offset and length to the compressed portion, and the loader could always decompress it to a fixed, and contiguous, place in DRAM (which would be given as the load address for the various things that we might compress)? 23.13.23 # Unhelpful: how much it is "over" depends on the target, I guess for the FM-Recorder it is quite much already. IIRC rombox was broken on those about 3 years ago (or so) with the addition of cuesheet support and that endianness independent handling of tagcache files 23.14.33 Quit martian67 (Remote host closed the connection) 23.15.50 Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo Ï¢INTER ϾHIP 5iVE is OOON!!) 23.16.16 # wow, cuesheet support was added *exactly* 3 years ago... and I think I remember correctly that this broke rombox on the FM-Recorders 23.16.49 # was it me or nicoP who got the commit in for cuesheets? 23.17.10 # saratoga: atrac3 is still not realtime on cf targets with little iram 23.17.37 # JdGordon: are you making notches in your "modern" player for every "ancient" player on which you break rombox? ;) 23.17.50 # JdGordon: Nico_P, but the commit message reads "patch by JdGordon" 23.18.19 # sure, go ahead and blame me! 23.18.24 # * gevaerts blames JdGordon 23.18.38 # Unhelpful: not on my dap... the side of my cell's wall though :) 23.18.55 Join martian67 [0] (~martian67@about/linux/regular/martian67) 23.19.34 Quit Llorean (Quit: Leaving.) 23.19.36 Quit martian67 (Remote host closed the connection) 23.19.50 # endianness independency of tagcache was committed February 13th 2007 and added a lot too 23.21.31 # pixelma: easy fix, make the on-disk endianness of the tagcache same as that of sh1 ;) 23.22.09 # JdGordon: "patch by JdGordon and me" ... you're not the only one to blame then 23.22.31 # only good for a half-notch, then? 23.23.02 # pixelma: have you got time to play with the fm patch? 23.24.21 # I would really like to get this in soon 23.24.27 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 23.25.14 # Unhelpful: The default endianness for database is always equal to target endianness. The code can handle both, this is to support external database creation 23.25.33 # JdGordon: no. One thing I tried though is a peakmeter in the sbs and it works in every screen but lists. Looks like it doesn't update in lists - thought it was worth checking if it works in the radio and recording screen in general 23.26.06 # We *could* disable that for lowmem, but then these targets profit most from external creation, since on target it's slow (not unbearably slow though) 23.29.04 # JdGordon: do you want to get it in so quickly to break the OndioSP's rombox for good? ;\ 23.29.20 # my evil plot has been found out! 23.30.00 Join Buschel [0] (~ab@p54A3A9E4.dip.t-dialin.net) 23.30.05 # pixelma: can you try commenting out apps/recorder/radio.c lines 991-995 and replace them with splash(0,"something"); and see if you ever see that splash? 23.30.46 # and re rombox, multifont added hardly anything to bin size, it just shows how close it has been to being killed of for good for ages 23.31.23 # ok, you need some patience though, testing on the Ondio is a bit tedious :/ 23.31.53 Quit checker (Quit: CGI:IRC (EOF)) 23.32.25 # wanna setup ssh and a robot and a webcam so I can play from here? :) 23.32.58 # you won't test much anyways :P 23.33.21 Join martian67 [0] (~martian67@about/linux/regular/martian67) 23.34.38 Quit martian67 (Remote host closed the connection) 23.34.41 # did you try checkwps with the radio screen? Unfortunately checkwps doesn't build for me and since it fails in a file that is untouched by the patch, I think it is cygwin related 23.35.10 Join martian67 [0] (~martian67@about/linux/regular/martian67) 23.35.20 # mt: is mdctexp faster for atrac on coldfire as well? 23.36.14 # pixelma: no, i'll try that now 23.36.40 # Buschel: I'm not sure, the measurements were all done on arm targets. 23.37.09 # JdGordon: and when you commit the fms patch, remember that the themesite needs updates for that. (since my newest addition it wont a accept a fms without changes, because thats a unknown theme cfg value ) 23.37.17 # mt: somebody should support you with some measurements... 23.37.32 # domonoky: arg, is that a recent change? 23.37.39 # I thought it didnt go through the .cfg? 23.38.23 # JdGordon: yes, today. But you can add new allowed settings via the admin interface. (still needs changes to actually check a fms with checkwps) 23.38.24 # ok, the hardcoded fms passes checkwps 23.38.35 Join akur [0] (~akur@bl6-159-67.dsl.telepac.pt) 23.38.50 # I'm not an admin on the theme site 23.39.06 # the one with %pm in the conditional? 23.39.11 # mt: atrac's iqmf synthesis filter is nearly fully optimized on arm now. without dropping precision and/or dropping coefficients there is not much left to do. 23.39.11 # yeah 23.39.31 # JdGordon: ask rasher to give you admin access :-) 23.40.14 # domonoky: surely you have access to that as well - or are you just bothering me because I'm responsible for the current lack of admin interface for this? :) 23.40.17 # its more fun to annoy others to fix ti 23.40.23 # Buschel: Wouldn't say no to cf measurements of course :) 23.41.20 # rasher: no i cant do that. my login doesnt have write access to the db, i think 23.41.32 # Buschel: Do you think there's something else that could be optimized ? 23.41.55 # arg, I reckon there is enough duplicated code for the skin init/display stuff that we could get the ondio rombox going again, but that will only give us another few weeks... so what's the point? 23.41.59 # domonoky: ah yes, the sqlite db had the wrong permissions at one point - it should be fixed now 23.42.12 # ah, then i can do it too :-) 23.42.13 # domonoky: this also meant that checkwps wasn't able to update the db from cron 23.42.37 # JdGordon: the point is that it's always nice to save bin size/ RAM usage 23.42.53 # pixelma: the previous tests, you were just getting a blank fm area? the statusbar kept updating? 23.43.01 # mt: i had some questions in the area of joint stereo coding. especially the INTERPOLATE macros could be optimized and the div16 calls can be avoided via lookup tables... 23.43.03 # Buschel: I tried the the reversal of spectral coefficients of odd bands outside the imlt, but the gain was embarrassing; 0.16% on arm :-) 23.43.47 # JdGordon: statusbar was displayed, yes. I didn't pay much attention if it was updated or not though 23.44.23 # yeah, ok, if you could try the splash change and let me know if it ever shows up that would be great 23.45.25 # mt: afterwards i saw that i have no file with joint stereo at all :/ 23.45.53 # mt: nothing to optimize or verify... 23.46.04 # Buschel: Yes, was just going to point that out 23.46.45 # mt: nevertheless: is the calcualtion in fastSqrt(...) correct? 23.47.03 # mt: or better: the way it is used? 23.47.56 Join asjsafjoa [0] (~47eca4cc@gateway/web/freenode/x-etbwqagsehrkkwrh) 23.48.46 # mt: e.g. when ind==7 -> ch[0]=ONE_16 ch[1]=ONE_16. but when using ch[0]=ONE_16 withni the fastSqrt(...) formula the result is ch[1]=sqrt(ONE-16). 23.48.48 # Buschel: I did some tests against the floating point decoder back when I was still converting the codec to fixed point, and it was correct. 23.49.10 # mt: could you test with joint stereo files? 23.49.29 # JdGordon: and if it really is duplicated code, a cleanup will help maintaining the code a lot 23.49.44 # Buschel: Guess I have to now ! .. I'll look for some. 23.49.45 # if you remove it, I mean 23.50.24 # mt: we should make a lookup table for ch[0] and ch[1] to avoid the calculations. 23.50.27 # no, well the case can be made that it makes the code harder to read 23.50.35 # mt: if you find some, give me a message ;o) 23.50.52 # Sure. :) 23.52.50 # mt: I don't unerstand why the build_dev tables show 15Kb. On my computer I had a 30Kb augmentation irrc. But perhaps I made a mistake 23.54.18 # the delta table takes bin size and RAM usage into account (and takes the average) 23.54.22 Quit asjsafjoa (Quit: Page closed) 23.54.48 # pamaury: I don't know about that - I was just asking because saratoga said 30KB, while your message said 30Kb i.e < 4 KB. I was just confused whether you actually meant bits or bytes. :) 23.55.08 Join fml [0] (~5dd2e02e@giant.haxx.se) 23.55.43 # mt: I meant bytes 23.55.48 # pamaury: if you hove over a value in the table you can see both in the tooltip 23.56.08 # JdGordon: isn't there a signedness mismatch in buffer in skin_font and buffer_start in font 23.56.33 # mt: why the table show: bin: -420, ram: -30xxx and a global -15000 ? 23.56.42 # pamaury: average 23.56.50 # as pixelma explained 23.57.23 # * gevaerts thinks that average is a bit meaningless there 23.57.27 # Ah, I didn't see pixelma comment :) I've been afk for the last hours 23.57.35 # Maybe it should just be the sum? 23.57.39 # * pamaury agrees with gevaerts 23.57.50 # sum might be better, yes 23.57.51 # pamaury: it was just below your statement 23.57.52 # Or else it should be a score, rather than a delta 23.58.11 # sum is also wrong. ram includes bin 23.58.48 # take max ?