| 00:00:09 | saratoga | for now I was just going to try and use the new fft with it |
| 00:00:17 | saratoga | since thats really easy and would get most of the speed up |
| 00:00:21 | mt | Oh yes I remember now. I looked at that months ago and forgot about it. (bias) |
| 00:01:19 | saratoga | #define BIAS(x) ((x) + (bias*0)) |
| 00:01:20 | saratoga | hmmmmm |
| 00:02:20 | mt | haha |
| 00:02:35 | | Quit petur (Quit: Zzzz) |
| 00:02:40 | waran | Mhm. I think I found the guy, but not sure ^.^ |
| 00:03:14 | saratoga | email him and ask |
| 00:03:20 | waran | Thats what I did |
| 00:04:40 | waran | 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 | pixelma | 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 | saratoga | i'll try to be more careful in the future |
| 00:05:52 | pixelma | thanks |
| 00:06:53 | saratoga | liba52 hasn't been updated since 2002 |
| 00:07:04 | saratoga | anyone care if I kill dead code and such in it |
| 00:08:39 | mt | saratoga: I think that bias is just there for floating point. |
| 00:09:00 | saratoga | yeah looks like it |
| 00:09:05 | saratoga | i took it out |
| 00:09:24 | saratoga | i'll commit it to the mdct branch and then when we merge it'll get clean up |
| 00:10:34 | mt | ok. |
| 00:10:49 | saratoga | 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 | mt | 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 | mt | saratoga: I used vnc when I needed to work remotely. |
| 00:13:18 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 00:13:47 | freddyb | saratoga: try ssh -X user@remote |
| 00:14:26 | | Quit checker (Quit: CGI:IRC (EOF)) |
| 00:16:32 | saratoga | but I'll still need an xwindows program for windows right? |
| 00:18:23 | rasher | Better suited for #rockbox-community |
| 00:18:36 | freddyb | 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 | waran | 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 | waran | (by which I mean most of you guys, I suppose) |
| 00:22:47 | Strife89 | waran: Most. :) |
| 00:22:56 | Strife89 | 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 | saratoga | 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 | saratoga | doing it on pc takes too long |
| 00:29:38 | | Quit punkt (Quit: Leaving) |
| 00:29:49 | saratoga | someone deleted a locked thread with an explination of why I locked the thread |
| 00:30:07 | saratoga | 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 | saratoga | 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 | saratoga | for now its a lot easier to use the fft directly then to figure out how to use the mdct itself |
| 00:34:10 | mt | I don't see a problem. |
| 00:34:28 | saratoga | do you think its possible to put windowing code in the codeclib as well? |
| 00:34:46 | saratoga | liba52 should have an ASM optimized version, maybe sharing with another codec is possible |
| 00:37:31 | saratoga | 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 | mt | You mean having separate windowing code/function in codeclib, that liba52 could use ? |
| 00:38:07 | saratoga | yeah |
| 00:38:25 | saratoga | or maybe having an imdct_window function |
| 00:38:37 | saratoga | that computes the IMDCT and then windows the data during post rotations |
| 00:38:45 | saratoga | using a window function supplied by the codec |
| 00:39:00 | mt | Yes I was just thinking of that too :) |
| 00:39:02 | saratoga | i think most codecs could use that |
| 00:40:28 | mt | 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 | amiconn | saratoga: "compare wav file" only makes sense for lossless |
| 00:41:24 | TheSeven | having separate functions might be marginallly faster |
| 00:42:11 | saratoga | 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 | saratoga | but yeah i suppose having it compute the RMS difference or something would be most useful |
| 00:42:42 | mt | 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 | TheSeven | 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 | mt | TheSeven: Missed that ! Thanks. |
| 00:47:33 | saratoga | 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 |
| 01:00:13 | | Part froggyman |
| 01:03:22 | | Quit utchybann (Read error: Operation timed out) |
| 01:04:13 | saratoga | heh liba52 doesn't even use IRAM for its imdct |
| 01:04:45 | saratoga | well the trig stuff is, but now the rest |
| 01:08:23 | saratoga | switching over to the new FFT gives 21.94MHz decoding for the 192k sample |
| 01:08:26 | saratoga | 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 | mt | saratoga: Wasn't liba52's fft a bit faster ? or is the fft we're using now optimized ? |
| 01:13:32 | saratoga | mt: the one we're using now has a lot of ASM |
| 01:13:35 | saratoga | so its probably faster |
| 01:13:43 | saratoga | and 22.76MHz |
| 01:13:50 | mt | oh ok. |
| 01:13:51 | saratoga | so we're 800kHz faster |
| 01:14:00 | saratoga | but i only switched long blocks over, not short |
| 01:14:27 | saratoga | using IRAM this thing could probably decode at << 20MHz on ARM |
| 01:14:32 | saratoga | we should really be using it for mpegplayer |
| 01:18:01 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 01:19:13 | saratoga | oh local variables are on the stack which is IRAM anyway |
| 01:19:14 | saratoga | duh |
| 01:20:36 | mt | :) |
| 01:22:08 | | Quit moos (Read error: Connection reset by peer) |
| 01:22:36 | | Join moos [0] (moos@rockbox/staff/moos) |
| 01:25:35 | saratoga | " warning: dereferencing type-punned pointer will break strict-aliasing rules" |
| 01:26:08 | saratoga | 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 | saratoga | hmm easy enough to fix i guess |
| 01:30:04 | | Join checker [0] (~621342a9@giant.haxx.se) |
| 01:30:19 | pamaury | 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 | waran | Merely bad style, but works ;) |
| 01:31:41 | saratoga | the structures are actually identical, they just have different member names |
| 01:31:42 | checker | %?bl<-1|0|1|2|...|N> using that conditional, |...| can be filled with as many sections "|-|" as desired? |
| 01:31:47 | saratoga | so i just renamed them |
| 01:32:13 | pamaury | I'm puzzled. Why isn't there a "title" object property with MTP... |
| 01:32:37 | pamaury | Isn't the title of an audio file one of its most important property oO |
| 01:32:43 | waran | 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 | saratoga | this is c, a struct is just a funny type of array :) |
| 01:35:02 | saratoga | converting short blocks makes no measureable difference in performance, probably because my sample doesn't really use them |
| 01:35:08 | waran | Actually there is no array in c. Everything-is-a-pointer(TM) :D |
| 01:35:42 | pamaury | That's false. |
| 01:36:07 | waran | thats why offset[pointer_var] works just like pointer_var[offset] |
| 01:36:24 | pamaury | In some cases there is a fundamental difference between an array and a pointer. But these are subtle (and useful !) |
| 01:37:00 | waran | example? |
| 01:38:19 | pamaury | Hum, that's should happen on community perhaps ? |
| 01:38:56 | waran | just a tab away. Lets take it to community. |
| 01:39:31 | saratoga | ok liba52 now uses the new codeclib in the mdct branch |
| 01:40:14 | saratoga | 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 | saratoga | 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 | saratoga | 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 | saratoga | huh looking at it more closely, it does look like its using IRAM extensively |
| 01:47:28 | saratoga | i wonder what the gigabeat F does better |
| 01:47:37 | saratoga | to overcome the IRAM advantage |
| 01:48:31 | Unhelpful | 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 | pamaury | Clearly strict aliasing is an optimiazation tool |
| 01:50:23 | checker | 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:00 |
| 02:03:18 | saratoga | 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 | saratoga | it'll just be a lot of work that'll have to be undone later |
| 02:08:18 | pamaury | 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 | saratoga | pamaury: you could call the metadata parser on it I suppose |
| 02:09:28 | pamaury | Yes of course but it's slow so if I can avoid it it's better |
| 02:09:38 | saratoga | although i'm curious why libmtp needs to know what the sample rate of files already on the disk is? |
| 02:09:47 | saratoga | err mpt |
| 02:09:53 | saratoga | mtp |
| 02:10:09 | pamaury | libmtp doesn't it but I'm trying to implement the properties that are usually implemented in MTP |
| 02:10:15 | pamaury | *doesn't need it |
| 02:10:22 | pamaury | And sample rate is one of them |
| 02:10:26 | saratoga | 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 | mt | hmm .. avoiding the reversal of the spectral coefficients in the imlt in atrac3 only saves 0.11 MHz :/ |
| 02:15:23 | saratoga | i remember looking at requantization in atrac last summer and thinking we could speed that up a bit |
| 02:15:52 | saratoga | 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 | saratoga | and of course theres the little issue with it not being real time on coldfire |
| 02:17:50 | mt | Is it still not realtime ? I thought Buschel's optimizations last summer fixed that ? |
| 02:19:02 | saratoga | i don't think he did anything for coldfire |
| 02:19:07 | saratoga | IIRC he only has an arm target |
| 02:20:37 | mt | found it : http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22561 .. The amazing +639% ! |
| 02:21:20 | saratoga | ah |
| 02:21:39 | | Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo ϢINTER ϾHIP 5iVE is OOON!!) |
| 02:23:16 | tetsuo55 | makes me wonder if that patch was ever upstreamed to ffmpeg |
| 02:23:26 | saratoga | mt: http://forums.rockbox.org/index.php?topic=22932.0 |
| 02:23:32 | saratoga | thats why i was thinking it wasn't real time |
| 02:23:39 | saratoga | perhaps some files are slower then others |
| 02:24:37 | saratoga | tetsuo55: it won't be, its not really applicable to ffmpeg |
| 02:25:06 | tetsuo55 | its a lossy speedup? |
| 02:25:31 | saratoga | no its fixed point only |
| 02:25:48 | mt | ah I see .. |
| 02:26:04 | saratoga | or at least not obviously applicable to ffmpeg |
| 02:27:11 | tetsuo55 | doesnt look that obvious to me |
| 02:27:19 | mt | Maybe that user was using an old revision . the thread was in october, ~2 months after the optimizations. |
| 02:27:47 | tetsuo55 | 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 | saratoga | tetsuo55: it optimizes fixed point math |
| 02:30:01 | saratoga | ffmpeg doesn't even do fixed point math |
| 02:30:23 | tetsuo55 | it doesnt? |
| 02:30:23 | tetsuo55 | :P |
| 02:30:25 | saratoga | so its not really applicable to them |
| 02:31:16 | | Quit domonoky1 (Read error: Connection reset by peer) |
| 02:32:11 | mt | 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 | saratoga | i was wondering that |
| 02:32:39 | | Join perfectdrug [0] (~marko@p5B0ED3E6.dip.t-dialin.net) |
| 02:32:40 | saratoga | is it in a file we'll need to change to use the new mdct? |
| 02:33:04 | saratoga | the ARM ltd profiler looks really nice |
| 02:33:15 | saratoga | i wonder if theres a way we can get them to donate a copy or two |
| 02:33:17 | tetsuo55 | 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 | tetsuo55 | theres even a fixed point math port from rockbox to ffmpeg on the to-do list |
| 02:34:05 | tetsuo55 | but not for this particular codecd |
| 02:34:29 | mt | 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 | tetsuo55 | would make it easier to stay in sync with ffmpeg trunk too (assuming it gets accepted) |
| 02:35:32 | saratoga | tetsuo55: do you have a link about the fixed point stuff? |
| 02:35:41 | tetsuo55 | http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008684.html |
| 02:35:49 | tetsuo55 | http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks#Add_wma_fixed_point_decoder_back_into_libavcodec |
| 02:35:53 | saratoga | heh 2006 |
| 02:36:04 | tetsuo55 | ignore the dates |
| 02:36:35 | tetsuo55 | 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 | saratoga | well when they get around to adding a fixed point decoder we should see about giving them optimizations for it |
| 02:37:23 | tetsuo55 | anything that improves ffmpeg is a win in my book |
| 02:37:33 | tetsuo55 | saratoga dont expect that |
| 02:37:57 | tetsuo55 | 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 | tetsuo55 | rockbox clearly has a fixed point local version, that could be upstreamed |
| 02:38:12 | saratoga | yes I know, i've spent a good deal of time over there |
| 02:38:38 | tetsuo55 | and its probably not just atrac, but many other codecs |
| 02:39:04 | tetsuo55 | may sound obvious, but ideally all codec updates will occur in the ffmpeg trunk, then get synced into rockbox |
| 02:39:46 | tetsuo55 | 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 | mt | 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 | tetsuo55 | but if we find anything like memory leaks, etc.. we quickly submit a patch upstream |
| 02:40:20 | tetsuo55 | damn |
| 02:40:22 | tetsuo55 | i want that |
| 02:40:22 | mt | s/in there/in their/ |
| 02:40:22 | tetsuo55 | :P |
| 02:40:58 | mt | Well, You have it in rockbox already. :) |
| 02:41:02 | tetsuo55 | i assume you harras tem all the time in #ffmpeg-dev |
| 02:41:04 | tetsuo55 | i dont |
| 02:41:06 | tetsuo55 | :( |
| 02:41:11 | * | tetsuo55 has a D2 |
| 02:41:29 | tetsuo55 | i only play with rockbox in the sandbox on windows |
| 02:42:04 | tetsuo55 | i use cook audio ALL the time on the pc though |
| 02:42:19 | tetsuo55 | and that codec needs a lot of TLC |
| 02:42:31 | Llorean | 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 | tetsuo55 | only 1 rockbox dev really needs commit access |
| 02:43:19 | Llorean | This 1 dev being magically available 24/7/365? |
| 02:43:29 | tetsuo55 | 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 | tetsuo55 | i have to go to bed now, more here http://producingoss.com |
| 02:44:08 | Llorean | 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 | tetsuo55 | ideally things would go smoothly on irc |
| 02:44:32 | | Quit pamaury (Quit: abort();) |
| 02:44:43 | tetsuo55 | and snippets of code would turn into commits swiftly on their side |
| 02:45:05 | tetsuo55 | instead of slowly in a mailing list that nobody cares about |
| 02:45:27 | saratoga | i don't think trying to convert all of ffmpeg to fixed point makes much sense |
| 02:45:35 | saratoga | it'd just make a mess of their codecs |
| 02:45:43 | tetsuo55 | i agree, just the parts your already doing anyway |
| 02:45:47 | saratoga | combined fixed/float codecs are ugly and difficult to work with |
| 02:46:03 | tetsuo55 | i would guess rockbox has a large pile of patches, that get applied to ffmpeg in some way |
| 02:46:14 | saratoga | we don't actually use ffmpeg itself |
| 02:46:18 | tetsuo55 | (locally) |
| 02:46:32 | saratoga | we do adapt [by rewriting] some of their code though |
| 02:46:33 | Llorean | 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 | tetsuo55 | saratoga so you only use small bits of ffmpeg, in your own codebase? |
| 02:47:50 | saratoga | 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 | tetsuo55 | 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 | tetsuo55 | Llorean > i do agree that its hard to swallow, to have to do the whole thing yourself |
| 02:48:39 | Llorean | tetsuo55: That also doesn't really reflect the real-world situation |
| 02:48:50 | tetsuo55 | unfortunately it doesnt :( |
| 02:48:52 | Llorean | As saratoga said, we're not really a port of ffmpeg. They're not really, realistically, "upstream" |
| 02:49:04 | saratoga | tetsuo55: what is involved in converting a codec to fixed point? |
| 02:49:05 | tetsuo55 | yeah, i just understood that just now |
| 02:49:22 | Llorean | It's a good idea to try to learn about the situation before you make suggestions on how to 'improve' it. ;) |
| 02:49:42 | tetsuo55 | 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 | tetsuo55 | saratoga > LOTS of beer |
| 02:50:45 | saratoga | 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 | tetsuo55 | Llorean > i based it off the few svn logs :P |
| 02:51:29 | | Quit toffe82 (Ping timeout: 240 seconds) |
| 02:53:11 | tetsuo55 | 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 | tetsuo55 | damn1 |
| 02:53:35 | tetsuo55 | [02:53] <tetsuo55> 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 | saratoga | tetsuo55: if you have no idea what you're looking at its still not a good idea to give advice |
| 02:55:11 | saratoga | also, if people are using lots of words you don't understand, thats another clue |
| 02:55:18 | saratoga | hope that helps |
| 02:55:39 | tetsuo55 | 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 | Llorean | A lot of what we've got doesn't even make sense as a patch against their tree. |
| 02:56:48 | tetsuo55 | yeah |
| 02:56:52 | Llorean | 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 | tetsuo55 | yeah |
| 02:58:01 | saratoga | hence my original comment that most of it isn't applicable to ffmpeg |
| 02:58:46 | tetsuo55 | didn't most codecs used to be fixed point anyway? |
| 02:58:52 | tetsuo55 | some time ago |
| 02:59:09 | tetsuo55 | and now transitioned into all being floating |
| 02:59:30 | saratoga | no |
| 02:59:59 | Llorean | The transition from mostly fixed to mostly floating point code happened before compressed audio codecs like MP3 really took off |
| 03:00 |
| 03:00:11 | | Quit Rob2223 (Ping timeout: 272 seconds) |
| 03:02:08 | tetsuo55 | maybe im misunderstanding, but google is giving me fixed point decoders for almost all popular formats |
| 03:03:01 | saratoga | probably ours |
| 03:03:34 | tetsuo55 | ouch> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-April/057293.html |
| 03:04:49 | tetsuo55 | saratoga > that might be the cause yeah |
| 03:04:50 | tetsuo55 | http://www.google.nl/search?hl=nl&safe=off&q=fixed+point+codec&btnG=Zoeken&meta=&aq=f&oq= |
| 03:05:00 | tetsuo55 | lots of closed source stuff too |
| 03:05:34 | tetsuo55 | but i can clearly see the rockbox patches being ignored in those search results too |
| 03:06:15 | tetsuo55 | 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 | saratoga | all the results on that page for open source decoders are in rockbox as far as I can tell |
| 03:08:15 | tetsuo55 | makes sense |
| 03:08:20 | tetsuo55 | allright |
| 03:09:19 | tetsuo55 | thanks for your serious responces |
| 03:09:27 | tetsuo55 | 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 | saratoga | 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 | Nimbus | is anyone in here? |
| 03:50:21 | mt | 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:00 |
| 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:00 |
| 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:00 |
| 06:15:12 | JdGordon | arg! |
| 06:15:38 | * | S_a_i_n_t is poised for emplanation |
| 06:15:47 | S_a_i_n_t | *fail |
| 06:15:53 | S_a_i_n_t | explanation rather |
| 06:31:15 | | Part toffe82_ |
| 06:42:01 | | Nick kramer3d_ is now known as kramer3d (~kramer@unaffiliated/kramer3d) |
| 06:44:18 | tmzt | 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 | tmzt | 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 | tmzt | embedded linux |
| 06:46:10 | tmzt | 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 | JdGordon | freddyb: seet, all targets build? |
| 06:56:24 | JdGordon | sweet* |
| 07:00 |
| 07:02:00 | * | S_a_i_n_t wonders how checking out a 'clean' svn revision reports being 24***:24***M |
| 07:02:56 | freddyb | 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 | S_a_i_n_t | I wonder what I broke...svn is having a hissy fit at me. |
| 07:07:19 | freddyb | JdGordon: is there an automatic way to build all the targets? |
| 07:07:41 | JdGordon | there is a script somewhere to do it |
| 07:07:55 | JdGordon | tools/release/sims.pl |
| 07:10:28 | S_a_i_n_t | can it mess things up somehow if the connection drops while checking out a souce revision? |
| 07:11:11 | S_a_i_n_t | 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 | freddyb | 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 | Llorean | S_a_i_n_t: Are you using real linux, cygwin, or vmware, or something else? |
| 07:16:49 | JdGordon | freddyb: ok, let me know when you are done and I'll commit it |
| 07:17:38 | S_a_i_n_t | cygwin...(yeah, yeah :P) |
| 07:18:33 | S_a_i_n_t | deleting the old source folder should be sufficient no matter how bad I mess the tree up..no? |
| 07:19:02 | Llorean | Cygwin can pose line ending problems. Are you using the console SVN command or something like TortoiseSVN? |
| 07:19:19 | S_a_i_n_t | console. |
| 07:20:00 | freddyb | JdGordon: Will do. |
| 07:20:12 | S_a_i_n_t | 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 | S_a_i_n_t | which definately didn;t alredy exist... |
| 07:26:08 | JdGordon | here we go..... |
| 07:26:55 | JdGordon | ... |
| 07:27:25 | * | S_a_i_n_t is killed by suspense... |
| 07:27:58 | JdGordon | Transmitting file data .................... |
| 07:28:10 | JdGordon | is svn on the fritz |
| 07:28:55 | S_a_i_n_t | that may explain my recent 'piss-offs' with trying to check-out... |
| 07:33:46 | JdGordon | ok wierd, the checkin shows up on the main page.. I wonder whats broken |
| 07:34:29 | JdGordon | wtf? |
| 07:36:45 | | Quit kaniini (Quit: E.T. go home.) |
| 07:44:03 | JdGordon | 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:00 |
| 08:02:00 | S_a_i_n_t | 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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 | Buschel | anyone with a coldfire target willing to test a atrac codec optimization? patch -> http://www.pastebin.org/91504 |
| 12:14:43 | Buschel | I need a short run with svn against the patched version |
| 12:14:51 | Buschel | maybe pixelma? ;o) |
| 12:20:38 | | Join Sajber^ [0] (~Sajber@h-143-173.A213.priv.bahnhof.se) |
| 12:21:38 | gevaerts | Buschel: what exactly do you need tested? Also, is there a test file somewhere I can use? |
| 12:24:31 | Buschel | gevaerts: I need a speed test via the test_codec plugin |
| 12:24:51 | Buschel | I am a bit puzzld there are no *.rm test files on http://download.rockbox.org/test_files/ |
| 12:24:57 | Buschel | *puzzled |
| 12:25:17 | gevaerts | no free encoder maybe? |
| 12:30:53 | Buschel | 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 | pixelma | mt once linked me to a few (from some mplayer page or so?). Can't remember exactly unfortunately :\ |
| 12:36:22 | gevaerts | testing on plain svn now (I assume you want to have both) |
| 12:36:46 | Buschel | pixelma: same for me. I have the files, but no link... |
| 12:36:52 | Buschel | 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 | gevaerts | Do you want me to listen to them as well, to see if the codec still works properly? |
| 12:39:44 | Buschel | 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 | Buschel | too many typos today... :/ |
| 12:41:41 | gevaerts | http://pastie.org/824273 |
| 12:41:45 | gevaerts | 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 | Buschel | thanks! +8-10%, but still not fully realtime... |
| 12:44:02 | Buschel | but there is still some room left for tweaking :) |
| 12:44:11 | petur | progress is always good |
| 12:46:02 | Buschel | gevaerts: what target did you use? |
| 12:46:18 | petur | certainly not h120 :) |
| 12:46:18 | gevaerts | h300 |
| 12:47:08 | stripwax | Buschel - atrac not realtime on coldfire? |
| 12:48:05 | Buschel | 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 | stripwax | have you tried the mdctexp mdct ? |
| 12:48:42 | Buschel | stripwax: it is realtime on coldfire targets with large iram. |
| 12:49:12 | stripwax | ah, which coldfire targets have 'small' iram? i have an h120 |
| 12:49:19 | Buschel | 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 | stripwax | Buschel - I think mt reported an 11% speedup, or something (can't remember if that was for atrac though) |
| 12:50:01 | stripwax | (that wasn't on coldfire though) |
| 12:50:03 | Buschel | stripwax: the "large" one is CPU == MCF5250 |
| 12:50:19 | stripwax | Buschel - ok so the h120 has a 'small' one I guess |
| 12:50:26 | gevaerts | Buschel: no |
| 12:50:31 | gevaerts | IRAM full |
| 12:50:44 | Buschel | gevaerts: too bad |
| 12:51:09 | * | gevaerts goes out to buy more IRAM |
| 12:51:26 | Buschel | hehe :) |
| 12:51:39 | stripwax | 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 | Buschel | 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 |
| 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 | Buschel | gevaerts: does this patch compile for your h300? -> http://pastie.org/824320 |
| 13:34:35 | gevaerts | yes |
| 13:34:57 | Buschel | :o) is it faster? |
| 13:36:07 | * | gevaerts wonders where he put this usb cable |
| 13:36:54 | mt | gevaerts: You sent it to me, remember ? |
| 13:38:02 | gevaerts | Did I? I thought I sent it to funman! |
| 13:39:21 | pamaury | Hum, tagcache_fill_tags does not fill the length entry of mp3entry. I think I'll fix that in a second |
| 13:40:24 | gevaerts | Buschel: http://pastie.org/824326 |
| 13:41:55 | Buschel | gevaerts: hmm, same as with first patch |
| 13:47:52 | pamaury | svn is really slooooooooooooooooooow today |
| 13:49:45 | | Quit bmbl (Ping timeout: 245 seconds) |
| 13:51:05 | moos | 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 | pamaury | moos: hello |
| 13:52:15 | moos | pamaury: waw it tested enough? |
| 13:52:16 | pamaury | 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 | pamaury | moos: you mean the one I commited more than one week ago ? |
| 13:53:32 | moos | oh ok, still working on it... If you need testing on big discs (aka big cache) I could |
| 13:54:15 | moos | pamaury: the complete scan rework. I didn't find time yet to fix my laptop problems (ie no dev env) |
| 13:55:12 | pamaury | 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 | pamaury | moos: but yes, if you can try it on a big disc this would be great |
| 13:56:21 | moos | do you get improvements? I mean: is the scan faster now? |
| 13:57:02 | moos | pamaury: I will retry to get e dev env here, sinon, you will have to build me a beast build patched |
| 13:57:22 | pamaury | 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 | pamaury | I'm not sure it will scan faster with this because beasically it does the same thing but uses less memory |
| 13:58:17 | moos | okok |
| 13:58:31 | moos | did you get Slasheri's attention about it? |
| 13:58:54 | pamaury | 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 | pamaury | I haven't seen Slasheri for more than one week |
| 13:59:43 | moos | pamaury: ok, I will say you how things became here... |
| 14:00 |
| 14:00:41 | pamaury | 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 | moos | yup he advised that the rombox is now out |
| 14:02:49 | moos | "game over" for it to use his words :) |
| 14:03:01 | moos | *tu use |
| 14:03:28 | * | moos hides from amiconn's ammo :) |
| 14:03:43 | gevaerts | I wonder if it wouldn't be possible to regain some space by e.g. loading bitmaps from disk after boot |
| 14:03:46 | S_a_i_n_t | yes, I believe it was something along the lines of "bugger, its game over for the ondio sp's rombox..." |
| 14:04:34 | pamaury | I guess ondio sp doesn't use dircache... |
| 14:05:17 | gevaerts | it doesn't |
| 14:06:06 | pamaury | 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 | gevaerts | apparently, yes |
| 14:09:01 | Buschel | gevaerts: next try -> http://pastie.org/824345 does it compile and is it any faster? |
| 14:10:41 | Unhelpful | could just make multifont a bigmem-only feature :P |
| 14:12:05 | gevaerts | 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 | gevaerts | 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 | S_a_i_n_t | are commits not showing in channel for some reason? |
| 14:14:30 | moos | no CIA bot anymore |
| 14:14:41 | S_a_i_n_t | ah... |
| 14:15:06 | gevaerts | Buschel: http://pastie.org/824348 |
| 14:15:14 | gevaerts | No real change |
| 14:16:06 | Buschel | 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 | gevaerts | pamaury: tagcache uses 27K on the archoses, so yes, there might be room there |
| 14:25:45 | gevaerts | *27K binsize |
| 14:27:18 | tetsuo55 | moos > CIA is down |
| 14:29:10 | pamaury | 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 | gevaerts | 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 | pamaury | 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 | gevaerts | 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 | jeffp | hey guys, i was just wondering whether anyone's working on rb for sansa fuze v2 |
| 14:34:02 | amiconn | 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 | amiconn | *especially* when running from flash |
| 14:34:54 | gevaerts | 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 | pamaury | 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 | Unhelpful | 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 | pamaury | Don't know but I'm listing areas where there is some things to take (in a general way) |
| 14:40:14 | amiconn | Unhelpful: Of course not |
| 14:40:24 | pamaury | What uses flash memory ? |
| 14:40:46 | amiconn | In fact the binsize increase for multifont is relatively moderate, given what it adds (unlike some other features...) |
| 14:41:13 | Unhelpful | pamaury: code. read-only data. not much else, i'd expect. |
| 14:41:17 | amiconn | pamaury: Code, read-only data and initial values for data |
| 14:41:40 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:43:21 | gevaerts | amiconn: do plugins change between rombox and rambox? |
| 14:43:42 | * | gevaerts suspects not |
| 14:43:51 | amiconn | Ahem, no |
| 14:44:31 | amiconn | 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 | gevaerts | 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 | amiconn | And it wouldn't work |
| 14:49:24 | amiconn | If you leave out tagcache (or any other non-trivial feature), language and voice ids change |
| 14:50:33 | gevaerts | yes, they'd have to be fully separate builds. Not good |
| 14:50:35 | amiconn | 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 | gevaerts | You could have an equivalent disk-based rockbox with it |
| 14:51:47 | gevaerts | 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 | linuxstb | Move the "optional" feature strings to the end? |
| 14:52:19 | gevaerts | that would still break the plugin API |
| 14:52:47 | * | gevaerts doesn't like this sort of "solution" at all |
| 14:53:03 | amiconn | Runtime isn't really different on te Ondios |
| 14:53:18 | pixelma | 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 | amiconn | But the larger buffer has other advantages, e.g. being able to view larger jpegs etc |
| 14:53:41 | pixelma | or using a better quality voice |
| 14:53:54 | *** | Saving seen data "./dancer.seen" |
| 14:54:20 | amiconn | In fact runtime might be *slightly* worse with Ondio rombox |
| 14:55:16 | amiconn | 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 | amiconn | On the hdd-based archoses, the savings from having less disk spinups more than make up for this |
| 14:57:14 | amiconn | 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 |
| 15:00:57 | Buschel | 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 | gevaerts | Buschel: no change |
| 15:10:43 | Buschel | 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 | gevaerts | Buschel: I have to go now. If you need more tests, you'll have to look for another victim^Wvolunteer |
| 15:15:02 | Buschel | gevaerts: thank you for your time! |
| 15:16:35 | Buschel | 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 | moos | re pamaury, tested your dircache patch. Working as plain svn (RAS). |
| 15:37:05 | pamaury | And what about dircache thread usage ? |
| 15:37:22 | moos | 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 | pamaury | Normally this patch should increase dircache stack usage so I would like to now if t's safe or not :) |
| 15:39:19 | moos | if you are curious, the cache here take 20s to process, and my buffer is around 1,47mo, for 22200+ elements |
| 15:39:43 | moos | 120gb disc and gigabeast btw |
| 15:39:49 | moos | hehe, I will compare |
| 15:39:56 | pamaury | ok thanks a lot |
| 15:40:50 | pamaury | Is there a way to know from how much rombox overflow the flash area on ondio SP ? |
| 15:40:57 | moos | no problems, thanks to you to works on :) (or to be brave enough to work on... to pe more precise ;) |
| 15:42:58 | moos | 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 | moos | 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 | pamaury | 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 | Buschel | to finally reach realtime for atrac on coldfire mr.someone should add some asm for the iqmf_dewindowing |
| 15:49:56 | amiconn | 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 | moos | amiconn: duh :/ (I was checking with another translation) |
| 15:50:44 | amiconn | 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 | moos | JdGordon don't trust use and wants stats compare :( |
| 15:51:39 | amiconn | Buschel: Doesn't atrac have similar complexity as mp3? |
| 15:52:33 | Buschel | amiconn: no, atrac uses very computing intensive qmf-filterbanks |
| 15:52:54 | amiconn | Hmm, ok |
| 15:52:59 | Buschel | amiconn: at least 48 muls per sample (!) |
| 15:53:13 | * | amiconn wonders whether he could do something there |
| 15:53:18 | bertrik | jobec, can you try another battery bench on your clip after explicitly enabling and disabling the radio? |
| 15:53:20 | amiconn | Filters... and asm :) |
| 15:53:23 | Buschel | amiconn: and there is an imdct as well |
| 15:54:13 | TheSeven | 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 | Buschel | 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 | TheSeven | IIRC newer LD versions tell you how much more memory they would need |
| 15:55:57 | pamaury | 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 | moos | 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 | pamaury | 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 |
| 16:00:27 | moos | 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 | pamaury | 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 | pixelma | depends on which rombox you are talking about (which target)... |
| 16:04:38 | pamaury | 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 | pixelma | 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 | pamaury | 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 | pixelma | 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 | pamaury | 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 | pixelma | the worst are probably the FM-Recorders/ RecorderV2s |
| 16:13:07 | moos_ | pamaury: comment added to the task. |
| 16:13:16 | pamaury | moos_: I just saw it ;) |
| 16:13:23 | moos_ | :) |
| 16:13:45 | pixelma | 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 | Jungti1234 | hello |
| 16:38:16 | Jungti1234 | long long time no see |
| 16:38:18 | domonoky | wow, svn is slow today: last commit: 4kbytes transfered in 3m,10s :-) |
| 16:39:01 | pamaury | 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 | pamaury | hehe, I just won 16 bytes on ondio SP ... :) |
| 16:48:17 | rasher | Have people forgotten about the manual for WPS tags? |
| 16:48:33 | | Quit phanboy4 (Ping timeout: 256 seconds) |
| 16:51:05 | danopia_ | domonoky, git ftw ;) |
| 16:51:45 | domonoky | danopia_: git doesnt help if the repository i want to commit to is svn :-) |
| 16:52:04 | danopia_ | i can mirror rockbox onto git :P |
| 16:53:06 | domonoky | 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 | domonoky | are the non-existing settings safely ignored ? (thinking about checking theme cfgs on the theme page) |
| 16:53:56 | rasher | I also seriously doubt the slowness there was scm related |
| 16:53:58 | *** | Saving seen data "./dancer.seen" |
| 16:55:00 | rasher | More likely a holdup with the cia notification |
| 16:55:08 | rasher | Since cia appears to be gone |
| 16:55:29 | domonoky | also what happens with non existing setting values ? for example "selector type: bar (color)" on a greyscale target ? |
| 16:56:15 | domonoky | true, a timeout in the commit hooks is probably the cause for this slowness. |
| 16:59:53 | AlexP | cia is down |
| 17:00 |
| 17:00:05 | AlexP | All the bots have disappeared and the site is down |
| 17:00:37 | AlexP | 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 | AlexP | s/bit/git/ |
| 17:01:03 | | Join Adub- [0] (~Rotting@xplr-ts-t11-208-114-159-122.barrettxplore.com) |
| 17:01:47 | danopia_ | yea CIA is down |
| 17:02:40 | danopia_ | i'd offer my replacement (FBI) but i'd probably have to add hacks for it to work with your repo |
| 17:03:01 | danopia_ | i can't recieve email withotu some advanced mailserver goodnes but i think i can do XML-RPC |
| 17:04:28 | jobec | 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 | amiconn | pixelma, pamaury: Actually there is still one target where rombox is available: the Archos Player |
| 17:55:10 | amiconn | 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 | pixelma | 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 | Unhelpful | domonoky: you can commit locally on git. ;) |
| 17:56:27 | amiconn | The H1x0 has no space problem at all (1MB flash instead of 256KB) |
| 17:56:57 | amiconn | Although swcodec rockbox is considerably larger than hwcodec (and the larger and 2bpp bitmaps add to that) |
| 17:57:18 | domonoky | Unhelpful: thats not what i want todo :-) |
| 17:58:15 | Unhelpful | 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 | domonoky | Unhelpful: no i want to make my changes live, the commit is only the tool for it. :-) |
| 17:59:58 | Unhelpful | you can do that too! mirror your git repo somewhere public. ;) |
| 18:00 |
| 18:02:18 | domonoky | "somewhere" is the wrong place. |
| 18:05:24 | | Quit tha (K-Lined) |
| 18:06:04 | pamaury | Is rombox compressed in any way ? |
| 18:07:21 | pamaury | 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 | Unhelpful | pamaury: it can't be, it's executed directly from flash. |
| 18:09:01 | pamaury | ah true ;) I'm so stupid |
| 18:09:08 | | Join Guest57645 [0] (~martian67@over.the.cat) |
| 18:09:56 | Unhelpful | 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 | pamaury | Unhelpful: you mean, compress all initdata and at runtime, uncompress them to RAM ? |
| 18:11:33 | Buschel | 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 | Buschel | *weird |
| 18:12:45 | Unhelpful | 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 | Unhelpful | assuming it's not compressed already, of course... |
| 18:14:52 | pamaury | 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 | amiconn | There isn't that much int data |
| 18:15:34 | amiconn | Although we could also compress all .icode, .irodata and .idata |
| 18:15:53 | amiconn | Not that much either - SH7034 has 4KB of IRAM |
| 18:16:35 | Unhelpful | 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 | amiconn | Not bootbox, but the flash loader |
| 18:17:20 | amiconn | The flash boot on archos is a bit more modular than on the other targets |
| 18:18:37 | pamaury | 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 | amiconn | 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 | pamaury | if it's flashed and with a box ? |
| 18:22:39 | Unhelpful | 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 | JdGordon | 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 | JdGordon | it broke just before 3.5 branch |
| 18:24:02 | amiconn | 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 | amiconn | 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 | amiconn | 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 | amiconn | (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 | pamaury | 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 | amiconn | Each of the two firmware images can bei either compressed (ucl) or uncompressed. In the latter case it is execute inplace |
| 18:40:09 | amiconn | Bootbox is compressed, of course |
| 18:41:09 | | Join sudoman [0] (~sudoman@static-151-204-226-99.bos.east.verizon.net) |
| 18:50:38 | sudoman | rbuitilqt 1.2.5 is quitting unexpectedly when i try to open it. 1.2.4 works. |
| 18:50:46 | sudoman | this might help: http://pastebin.ca/1796406 |
| 18:51:06 | sudoman | os 10.5.8 |
| 18:51:11 | sudoman | * 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 | domonoky | 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 | domonoky | 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:00 |
| 19:03:17 | sudoman | 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 | Jaykay | sudoman: it's a wiki, you can change it :) |
| 19:04:02 | sudoman | 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 | pixelma | sudoman: as far as I know it's correct (menu + select to reboot and then select + play) |
| 19:06:42 | sudoman | for me, neither of those combos worked |
| 19:06:59 | sudoman | i did play and menu then back and next |
| 19:07:16 | sudoman | 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 | pixelma | ah, 3rd gen (and older) might be different |
| 19:10:59 | sudoman | i made a wiki account. could i please be given editing permission? |
| 19:11:14 | AlexP | What's your wiki name? |
| 19:12:19 | sudoman | AndrewEngelbrecht |
| 19:13:21 | AlexP | OK, done |
| 19:13:21 | | Quit flydutch (Quit: /* empty */) |
| 19:13:31 | sudoman | 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: <Tobin> 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 | sudoman | 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 | sudoman | http://www.rockbox.org/tracker/task/11006 |
| 19:21:37 | sudoman | as i mentioned in the report, this could be fixed by setting the default contrast to about 36 |
| 19:23:32 | AlexP | JdGordon: What's the plan for the fms? |
| 19:24:17 | | Quit Tomis (Ping timeout: 252 seconds) |
| 19:27:46 | amiconn | 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 | amiconn | 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 | amiconn | Apple changed it with the clickwheels (4th Gen and later), since pressing the opposite sides is mechanically impossible on those |
| 19:29:53 | sudoman | i updated the wiki for the subject |
| 19:30:07 | sudoman | what about ipod nanos? |
| 19:30:25 | amiconn | 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 | sudoman | 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 | domonoky | sudoman: rbutil already has a cache, but dont know if all code places really use it. |
| 19:55:51 | domonoky | sudoman: there is also the "Offline mode" checkbox. Also not sure if it works for all. |
| 19:56:55 | sudoman | domonoky: thanks |
| 19:59:31 | | Quit Jaykay (Ping timeout: 256 seconds) |
| 20:00 |
| 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 | pamaury | HEHEHE, look at that green delta ;) |
| 20:18:40 | JdGordon | AlexP: well, I need to figure out why hwcodec is broeknm |
| 20:18:49 | JdGordon | pixelma: did you get a chance to try changin that line? |
| 20:18:55 | AlexP | ah, I didn't know it was |
| 20:19:02 | AlexP | pamaury: nice :) |
| 20:19:11 | * | AlexP misses the commit bot |
| 20:19:59 | JdGordon | is anyone else having trouble with svn hanging after a commit? |
| 20:20:10 | AlexP | It isn't hanging, it is just *really* slow |
| 20:20:21 | AlexP | give it a minute or two and it'll come back |
| 20:20:22 | rasher | 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 | AlexP | 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 | JdGordon | I'm hoping to commit it this week... but depends on hwcodec testing |
| 20:22:18 | JdGordon | as much as I dont care about those targets, I don't exactly want to intentioally break them :p |
| 20:22:23 | AlexP | sure |
| 20:23:00 | JdGordon | 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 | sudoman | 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 | TheSeven | is there anyone around who's interested in participating in the nano4g work? |
| 20:31:51 | TheSeven | 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 | amiconn | linuxstb: I wonder how to integrate the new mmx code in our build system |
| 20:49:17 | linuxstb | 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 | amiconn | Do we want to enable mmx permanently (for x86, that is)? |
| 20:50:00 | amiconn | On x86_64, mmx is standard, so we can do that, but not all 32 bit x86's support it |
| 20:50:14 | amiconn | That said, all non-stoneage x86's do |
| 20:50:32 | rasher | I'd say we can safely require mmx for the sim |
| 20:51:14 | amiconn | 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 | linuxstb | Although maybe with the ability to disable it? |
| 20:52:01 | amiconn | The way libdemac is built doesn't allow runtime detection (currently) |
| 20:52:13 | rasher | Unless it's fairly simple - I wouldn't spend much time on letting it be disabled |
| 20:52:32 | amiconn | It's just a matter of passing -mmmx to gcc or not |
| 20:52:33 | | Quit mc2739 (Ping timeout: 248 seconds) |
| 20:52:43 | linuxstb | gevaerts: How did you get on with enabling the ARM optimisations in the sim? |
| 20:52:54 | linuxstb | amiconn: Then I guess disabling it is just editing the Makefile to move that... |
| 20:52:57 | amiconn | (yes, 3 'm's) |
| 20:53:02 | AlexP | 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 | linuxstb | 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 | Buschel | sudoman: you could try to set your battery capacity to a smaller value |
| 20:54:31 | amiconn | linuxstb: Regarding the n900 - it uses an arm, right? |
| 20:54:34 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 20:54:41 | linuxstb | amiconn: Yes. |
| 20:54:45 | gevaerts-phone | linuxstb: those ARM defines do the trick, together with enabling one or two more files in SOURCES |
| 20:55:04 | gevaerts-phone | That makes everything build, axcept ape |
| 20:55:18 | amiconn | What happens with ape? |
| 20:55:46 | sudoman | 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 | linuxstb | Did it give you a decent speed-up? |
| 20:55:50 | gevaerts-phone | I'll tell you later, when I'm home |
| 20:56:26 | gevaerts-phone | It didn't fix the audio dropouts, I didn't do test_codec tests |
| 20:57:31 | Buschel | sudoman: what iPod do you use? |
| 20:57:42 | sudoman | Buschel: ipod 3G |
| 20:58:53 | sudoman | 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 | AlexP | % is from voltage IIRC |
| 20:59:22 | AlexP | So if the battery is buggered that is probably it |
| 20:59:36 | AlexP | It can't supply the current required so shuts down early |
| 20:59:44 | sudoman | 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 |
| 21:00:02 | sudoman | AlexP: is there a way to fix that? |
| 21:00:08 | Buschel | sudoman: ah ok. The iPod 3G has no correct estimation implemented as there were no reliable battery runtime measurements availabe. |
| 21:00:10 | AlexP | replace the battery |
| 21:00:22 | | Quit tetsuo55 () |
| 21:00:23 | AlexP | If it is a dead battery |
| 21:00:42 | sudoman | AlexP: yeah, i might do that, or just get a 5.5G |
| 21:00:54 | Buschel | sudoman: We could easily implement the needed changes if you could do a battery bench with a good working (new?) battery. |
| 21:00:58 | domonoky | 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 | AlexP | ah, OK |
| 21:01:29 | AlexP | If the discharge curve is different |
| 21:01:48 | domonoky | or maybe the battery curve and min values were never calibrated for ipod 3g ? |
| 21:01:54 | sudoman | would it not be useful to submit a curve with my current battery? |
| 21:01:57 | AlexP | could be |
| 21:02:12 | AlexP | 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 | sudoman | 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 | AlexP | hmmm :) |
| 21:04:16 | AlexP | sudoman: I'm not sure to be honest |
| 21:04:24 | Buschel | sudoman: it could also be a replacement battery. but we need to know the capacity in mAh |
| 21:05:41 | domonoky | current values for ipod3g: 3,37V = 0%. 3,38V is considered dangerious and 3,02V is shutdown. |
| 21:05:45 | sudoman | 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 | domonoky | there is also a curve for charging, which is probably wrong too. |
| 21:06:28 | Buschel | 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 | sudoman | huh, my player shut down at 3.82V |
| 21:07:14 | AlexP | domonoky: It'll also shutdown if it fails to spin up the disk right? |
| 21:07:16 | sudoman | ^ (from my last test which didn't follow all of the standard rules) |
| 21:07:24 | domonoky | 3.82V should show ~50% with the current battery curve. |
| 21:07:42 | sudoman | 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 | domonoky | 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 | sudoman | 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 | AlexP | I don't quite follow that sentence :) |
| 21:09:37 | domonoky | sudoman: did it show the "low battery" warning before shutdown ? |
| 21:09:56 | sudoman | 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 | sudoman | domonoky: no it did not |
| 21:10:15 | AlexP | sudoman: Does it? |
| 21:10:22 | AlexP | Does battery nench work like that? |
| 21:11:07 | pixelma | as far as I know battery_bench caches values in RAM until the next spinup (e.g. for rebuffering) |
| 21:11:09 | sudoman | 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 | domonoky | 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 | sudoman | *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 | AlexP | sudoman: indeed |
| 21:13:04 | sudoman | domonoky: was it a power-failure then? |
| 21:13:05 | domonoky | sudoman: jup, if it would write directly to disk, the bench would not show normal behavior (much more power use) |
| 21:13:27 | domonoky | sudoman: either that, or a bug :-) |
| 21:13:48 | amiconn | gevaerts: Could you paste the output of gcc -E -dM - < /dev/null | cut -c 9- | sort on your n900 somewhere? |
| 21:14:04 | sudoman | could be a bug. i do remember having a bug/power-failure(?) at 40% once... |
| 21:14:17 | Buschel | sudoman: it could also have been a simple crash. |
| 21:14:27 | domonoky | if you expirienced shutdowns while using context menus before, it looks more like a bug. |
| 21:14:45 | sudoman | how is a crash different than a bug? |
| 21:15:40 | Buschel | 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 | sudoman | Buschel: ok i'll do that ; ) |
| 21:18:34 | Buschel | perfect :) |
| 21:19:45 | amiconn | gevaerts: The output of uname -m would also be interesting |
| 21:20:43 | | Quit Buschel () |
| 21:24:45 | sudoman | 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 | linuxstb | sudoman: Using the apple firmware is probably safer. |
| 21:25:52 | linuxstb | (and probably faster) |
| 21:26:05 | sudoman | faster? |
| 21:27:25 | pixelma | for the charging part |
| 21:27:51 | sudoman | pixelma: why is charging faster on the apple firmware? |
| 21:27:58 | Unhelpful | 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 | amiconn | Quite difficult... and it would mean that a full reflash is required |
| 21:33:26 | amiconn | 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 | amiconn | The question is whether it's worth it. We're talking about ~8KB of data (probably compressible to half of that) |
| 21:38:35 | sudoman | is it ok to switch on "hold" during the battery test? |
| 21:40:41 | danopia_ | so where do you guys host SVN? sourceforge? |
| 21:41:12 | danopia_ | 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 | rasher | danopia_: svn.rockbox.org |
| 21:44:44 | | Quit tetsuo__ () |
| 21:45:00 | danopia_ | hmm |
| 21:45:09 | danopia_ | that makes it a little harder :P |
| 21:46:55 | | Join checker [0] (~621342a9@giant.haxx.se) |
| 21:48:12 | domonoky | danopia_: but we ofcourse also have a commit mailing list, so you could just subscribe to that. |
| 21:48:43 | danopia_ | 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 | domonoky | 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 | tomers | 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 | rasher | Technically it also works for targets with a gdb stub, doesn't it? |
| 21:59:56 | amiconn | It does |
| 22:00 |
| 22:00:17 | | Quit Jaykay (Ping timeout: 248 seconds) |
| 22:06:57 | JdGordon | 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 | Unhelpful | 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 | gevaerts | 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 | gevaerts | amiconn: gcc -E -dM - < /dev/null | cut -c 9- | sort output : http://pastie.org/824782 |
| 22:30:43 | gevaerts | 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 | gevaerts | ape compilation fails with http://pastie.org/824786 |
| 22:33:33 | gevaerts | This is with -DCPU_ARM -DARM_ARCH=6 added to EXTRA_DEFINES |
| 22:39:41 | JdGordon | anyone think there is any point trying to optimise the skin displayer code? |
| 22:42:33 | gevaerts | in what way? |
| 22:43:07 | JdGordon | 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 | JdGordon | I'm sure there is plenty of room for improvement |
| 22:45:08 | amiconn | 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 | amiconn | Hmm, eabi? |
| 22:48:05 | | Quit tomers (Ping timeout: 252 seconds) |
| 22:48:06 | gevaerts | I think so, yes |
| 22:49:02 | gevaerts | 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 | amiconn | 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 | amiconn | 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 | gevaerts | it's not actually a real problem right now I think |
| 22:59:09 | | Quit bertrik (Quit: De groeten) |
| 22:59:31 | gevaerts | 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:00 |
| 23:01:27 | Llorean | Is part of the website broken? I can't get to flyspray. |
| 23:01:41 | JdGordon | wfm |
| 23:01:49 | gevaerts | I can |
| 23:02:00 | | Join saratoga [0] (~9803c6dd@giant.haxx.se) |
| 23:02:12 | saratoga | i wonder if the dircache improvements help playback on the c200v2 |
| 23:02:19 | saratoga | the added memory might make a difference |
| 23:02:33 | saratoga | 30KB is a large fraction of the entire audio buffer on that player |
| 23:02:40 | Llorean | 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 | JdGordon | menu+select is a hard reset |
| 23:04:42 | | Quit _zic (Remote host closed the connection) |
| 23:05:32 | sudoman | 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 | Llorean | All nanos use Menu+Select to reboot |
| 23:06:25 | gevaerts | as far as I remember, mini 2g is the same as video |
| 23:06:33 | sudoman | oops. sorry. i got the nanos and minis backwards |
| 23:06:40 | Llorean | I though the only ones that don't use Menu+Select are ones that have buttons independent of the wheel. |
| 23:06:50 | pixelma | sudoman: it's been answered to you |
| 23:06:52 | sudoman | it only applies to 1G - 3G ipods |
| 23:07:23 | sudoman | pixelma: sorry, i don't understand |
| 23:07:27 | linuxstb | sudoman: All minis have a clickwheel. |
| 23:07:31 | mt | I thought pamaury meant 30Kbits because of (Kb) ? |
| 23:08:16 | linuxstb | sudoman: Are you perhaps confusing "1st/2nd gen mini" wiith "1st/2nd/3rd gen ipods" ? |
| 23:08:46 | sudoman | linuxstb: not sure, i think i just got my memory backwards for the minis and nanos |
| 23:08:56 | linuxstb | sudoman: But the minis and nanos are the same |
| 23:09:01 | pixelma | sudoman: http://www.rockbox.org/irc/log-20100214#19:28:51 and the following minutes |
| 23:09:04 | linuxstb | (in terms of key combinations) |
| 23:09:12 | sudoman | i mean that i got them both wrong |
| 23:10:04 | Unhelpful | 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 | pixelma | 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 | pixelma | 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 | JdGordon | was it me or nicoP who got the commit in for cuesheets? |
| 23:17:10 | mt | saratoga: atrac3 is still not realtime on cf targets with little iram |
| 23:17:37 | Unhelpful | JdGordon: are you making notches in your "modern" player for every "ancient" player on which you break rombox? ;) |
| 23:17:50 | pixelma | JdGordon: Nico_P, but the commit message reads "patch by JdGordon" |
| 23:18:19 | JdGordon | sure, go ahead and blame me! |
| 23:18:24 | * | gevaerts blames JdGordon |
| 23:18:38 | JdGordon | 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 | pixelma | endianness independency of tagcache was committed February 13th 2007 and added a lot too |
| 23:21:31 | Unhelpful | pixelma: easy fix, make the on-disk endianness of the tagcache same as that of sh1 ;) |
| 23:22:09 | pixelma | JdGordon: "patch by JdGordon and me" ... you're not the only one to blame then |
| 23:22:31 | Unhelpful | only good for a half-notch, then? |
| 23:23:02 | JdGordon | pixelma: have you got time to play with the fm patch? |
| 23:24:21 | JdGordon | 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 | amiconn | 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 | pixelma | 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 | amiconn | 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 | pixelma | JdGordon: do you want to get it in so quickly to break the OndioSP's rombox for good? ;\ |
| 23:29:20 | JdGordon | my evil plot has been found out! |
| 23:30:00 | | Join Buschel [0] (~ab@p54A3A9E4.dip.t-dialin.net) |
| 23:30:05 | JdGordon | 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 | JdGordon | 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 | pixelma | 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 | JdGordon | wanna setup ssh and a robot and a webcam so I can play from here? :) |
| 23:32:58 | pixelma | 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 | pixelma | 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 | Buschel | mt: is mdctexp faster for atrac on coldfire as well? |
| 23:36:14 | JdGordon | pixelma: no, i'll try that now |
| 23:36:40 | mt | Buschel: I'm not sure, the measurements were all done on arm targets. |
| 23:37:09 | domonoky | 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 | Buschel | mt: somebody should support you with some measurements... |
| 23:37:32 | JdGordon | domonoky: arg, is that a recent change? |
| 23:37:39 | JdGordon | I thought it didnt go through the .cfg? |
| 23:38:23 | domonoky | 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 | JdGordon | ok, the hardcoded fms passes checkwps |
| 23:38:35 | | Join akur [0] (~akur@bl6-159-67.dsl.telepac.pt) |
| 23:38:50 | JdGordon | I'm not an admin on the theme site |
| 23:39:06 | pixelma | the one with %pm in the conditional? |
| 23:39:11 | Buschel | 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 | JdGordon | yeah |
| 23:39:31 | domonoky | JdGordon: ask rasher to give you admin access :-) |
| 23:40:14 | rasher | 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 | JdGordon | its more fun to annoy others to fix ti |
| 23:40:23 | mt | Buschel: Wouldn't say no to cf measurements of course :) |
| 23:41:20 | domonoky | rasher: no i cant do that. my login doesnt have write access to the db, i think |
| 23:41:32 | mt | Buschel: Do you think there's something else that could be optimized ? |
| 23:41:55 | JdGordon | 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 | rasher | domonoky: ah yes, the sqlite db had the wrong permissions at one point - it should be fixed now |
| 23:42:12 | domonoky | ah, then i can do it too :-) |
| 23:42:13 | rasher | domonoky: this also meant that checkwps wasn't able to update the db from cron |
| 23:42:37 | pixelma | JdGordon: the point is that it's always nice to save bin size/ RAM usage |
| 23:42:53 | JdGordon | pixelma: the previous tests, you were just getting a blank fm area? the statusbar kept updating? |
| 23:43:01 | Buschel | 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 | mt | 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 | pixelma | JdGordon: statusbar was displayed, yes. I didn't pay much attention if it was updated or not though |
| 23:44:23 | JdGordon | 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 | Buschel | mt: afterwards i saw that i have no file with joint stereo at all :/ |
| 23:45:53 | Buschel | mt: nothing to optimize or verify... |
| 23:46:04 | mt | Buschel: Yes, was just going to point that out |
| 23:46:45 | Buschel | mt: nevertheless: is the calcualtion in fastSqrt(...) correct? |
| 23:47:03 | Buschel | mt: or better: the way it is used? |
| 23:47:56 | | Join asjsafjoa [0] (~47eca4cc@gateway/web/freenode/x-etbwqagsehrkkwrh) |
| 23:48:46 | Buschel | 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 | mt | 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 | Buschel | mt: could you test with joint stereo files? |
| 23:49:29 | pixelma | JdGordon: and if it really is duplicated code, a cleanup will help maintaining the code a lot |
| 23:49:44 | mt | Buschel: Guess I have to now ! .. I'll look for some. |
| 23:49:45 | pixelma | if you remove it, I mean |
| 23:50:24 | Buschel | mt: we should make a lookup table for ch[0] and ch[1] to avoid the calculations. |
| 23:50:27 | JdGordon | no, well the case can be made that it makes the code harder to read |
| 23:50:35 | Buschel | mt: if you find some, give me a message ;o) |
| 23:50:52 | mt | Sure. :) |
| 23:52:50 | pamaury | 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 | pixelma | 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 | mt | 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 | pamaury | mt: I meant bytes |
| 23:55:48 | pixelma | pamaury: if you hove over a value in the table you can see both in the tooltip |
| 23:56:08 | fml | JdGordon: isn't there a signedness mismatch in buffer in skin_font and buffer_start in font |
| 23:56:33 | pamaury | mt: why the table show: bin: -420, ram: -30xxx and a global -15000 ? |
| 23:56:42 | B4gder | pamaury: average |
| 23:56:50 | B4gder | as pixelma explained |
| 23:57:23 | * | gevaerts thinks that average is a bit meaningless there |
| 23:57:27 | pamaury | Ah, I didn't see pixelma comment :) I've been afk for the last hours |
| 23:57:35 | rasher | Maybe it should just be the sum? |
| 23:57:39 | * | pamaury agrees with gevaerts |
| 23:57:50 | B4gder | sum might be better, yes |
| 23:57:51 | pixelma | pamaury: it was just below your statement |
| 23:57:52 | rasher | Or else it should be a score, rather than a delta |
| 23:58:11 | gevaerts | sum is also wrong. ram includes bin |
| 23:58:48 | pamaury | take max ? |
icon identifies that the person is a core developer (has commit access).