00:00:25 | | Quit Kohlriba ("Leaving") |
00:01:00 | elinenbe | amiconn: the unicode patch is very nice... it would be great if that was merged into CVS one day. |
00:02:27 | preglow | linuxstb: i can't even find where to control the bitrate in this thing |
00:03:09 | amiconn | elinenbe: Be patient... first TiMiD has to finish his remote work |
00:03:33 | linuxstb | preglow: I guess you've installed iTunes? |
00:04:26 | preglow | linuxstb: aye |
00:04:27 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
00:04:54 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
00:06:40 | linuxstb | I don't know about the Windows version, but on the Mac, it's the application menu, then preferences, then advanced, then importing. |
00:07:18 | TiMiD | amiconn: about the code size decrease, I'm becoming skeptical :) (well once the work finished, we will return around the initial level, but not as big as I expected : the menu's new implementation reduced it by 300bytes ... very poor ) |
00:07:22 | _FireFly_ | it seams that f2_screen, f3_screen and handle_usb in wps.h are not used can they be removed ?? |
00:07:26 | preglow | linuxstb: yeah, i found it |
00:07:31 | preglow | linuxstb: didn't notice the tabs |
00:07:35 | | Quit matsl (Remote closed the connection) |
00:08:06 | preglow | linuxstb: is vbr aac normal? |
00:08:44 | linuxstb | I don't think iTunes does VBR. But Nero does. |
00:09:25 | linuxstb | Just noticed the VBR checkbox - I guess it does it now. |
00:11:19 | preglow | hrmph, MUL_R is used not only for sbr |
00:11:29 | preglow | but most extensively in sbr, it seems |
00:15:48 | * | preglow cuddles MUL_F |
00:15:57 | preglow | i love it when the fixed point formats line up with what the emac unit uses |
00:17:38 | linuxstb | Is that good news then? |
00:18:17 | preglow | indeed |
00:18:28 | preglow | let's hope for some long accumulator chains |
00:18:35 | preglow | although i'm pretty certain they aren't there |
00:18:51 | preglow | aac doesn't use any good old-fashioned fir filtering |
00:18:55 | preglow | that i know of, at least |
00:19:53 | preglow | bad news is that the REAL_PRECISION is used in a couple of places |
00:20:00 | preglow | we might need to do a proper 64 bit multiply for that |
00:21:28 | linuxstb | In case you're wondering, my choice of what is in IRAM is pretty random. So feel free to change it if you think it can be better used elsewhere. |
00:21:34 | amiconn | The full 64*64->64 ? |
00:23:04 | preglow | amiconn: no, musepack style |
00:23:37 | preglow | but ok, i'm doing a couple of tests right now |
00:23:38 | amiconn | That's not too bad. Variable shift as well? |
00:24:37 | preglow | amiconn: nope, fixed shift |
00:24:51 | preglow | amiconn: but the majority of all muls will be emac |
00:25:04 | preglow | does anyone know if the "cc" clobber flag is really necessary? |
00:25:37 | amiconn | I'm not 100% sure, but I never used it and didn't run into problems |
00:30:04 | * | preglow spots a two-space indent level and looks at the culprit :P |
00:30:47 | _FireFly_ | it seams that the functions f2_screen, f3_screen, refresh_wps and handle_usb in wps.h are not used can they be removed ?? |
00:31:59 | LinusN | _FireFly_: yes |
00:32:05 | _FireFly_ | k |
00:32:22 | _FireFly_ | i'm trying to make a wps-widget :) |
00:34:52 | linuxstb | preglow: Fixed in CVS. I'm trying to comply... |
00:34:59 | preglow | goodie |
00:35:43 | preglow | i used to to two-level indenting myself when i used pascal |
00:35:51 | preglow | which is quite luckily very long ago |
00:36:25 | linuxstb | Maybe that's where I picked up the habit from - I used pascal for a long time. |
00:36:56 | | Join len0x_ [0] (n=len0x@mobileweb08.london.02.net) |
00:37:13 | elinenbe | _FireFly_: a widget that does what? |
00:37:59 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
00:38:18 | | Quit _DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
00:38:19 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
00:38:26 | _FireFly_ | draws the wps :) |
00:38:31 | preglow | replacing the math function alone isn't going to save aac, it seems |
00:38:44 | preglow | argh!!!! ice! |
00:39:37 | len0x_ | what's taking the most time in AAC decoding? iDCT? |
00:39:46 | preglow | i have no idea |
00:39:48 | _FireFly_ | elinenbe: i try to adapt the current wps code to the new multi-screen support |
00:40:13 | preglow | len0x_: not all words starting with an 'i' has to have a lowercase i, you know, it's called an IMDCT ;) |
00:40:48 | len0x_ | :) |
00:42:03 | len0x_ | back in the days it was just iDTC :) |
00:42:15 | len0x_ | iDCT :) |
00:42:23 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
00:42:45 | len0x_ | anyway - does it use asm ? |
00:42:54 | preglow | len0x_: nope |
00:43:06 | preglow | len0x_: everything but trivial multiply functions are c |
00:43:21 | Mode | "#rockbox +o LinusN " by ChanServ (ChanServ@services.) |
00:43:34 | Kick | (#rockbox len0x :LinusN) by LinusN!n=linus@labb.contactor.se |
00:44:11 | Mode | "#rockbox -o LinusN " by LinusN (n=linus@labb.contactor.se) |
00:46:03 | | Quit len0x_ ("Trillian (http://www.ceruleanstudios.com") |
00:47:39 | | Join len0x [0] (n=len0x@mobileweb08.london.02.net) |
00:48:22 | preglow | what the hell is it about libfaad that keeps provoking these ICEs |
00:49:21 | linuxstb | Did the version in CVS compile for you? |
00:50:05 | preglow | yes |
00:50:11 | preglow | it worked just fine with a replaced MUL_F |
00:50:20 | preglow | i've now replaced MUL_C, and it ICEs in tns.c |
00:50:48 | preglow | trying to replace functions with macros |
00:51:03 | preglow | nope, same error |
00:51:49 | linuxstb | One of the problems I had was the faad_getbits() function. It was originally inline, but that caused ICEs. So I had to make it a normal function. |
00:52:15 | linuxstb | Maybe it's worth trying gcc4 |
00:52:26 | preglow | perhaps |
00:53:06 | preglow | linuxstb: but now i made the mul functions macros, and it still didn't help. making them ordinary functions are out of the question |
00:53:41 | | Join einhirn [0] (i=Miranda@szgt-d9b8e957.pool.mediaWays.net) |
00:53:47 | preglow | is tns.c necessary for lc operation? |
00:54:16 | linuxstb | I have no idea. |
00:55:09 | preglow | i'm using gcc 3.4.1, however, could you test out the file with your gcc if it's newer? |
00:55:39 | linuxstb | Sure. But I'm not confident it will be any better. |
00:55:47 | linuxstb | I'm using 3.4.4 |
00:55:50 | | Part len0x |
00:56:30 | preglow | www.pvv.org/~thomj/rockbox/fixed.h |
00:57:46 | | Quit tvelocity ("Leaving") |
00:59:05 | linuxstb | ICE :( |
00:59:23 | preglow | arghhhh |
00:59:24 | linuxstb | tns.c:257 |
00:59:28 | preglow | yes |
00:59:57 | preglow | we've got heaps of codecs with no ICEs, and now suddenly, tons of them in one codec |
01:00 |
01:02:50 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
01:05:20 | amiconn | I already got memcpy() 3.5x..4x as fast as the C version for most alignment combos. That's still without using burst mode... :-) |
01:06:12 | preglow | hahaha |
01:08:00 | Moos | Seems promising :) |
01:08:54 | amiconn | Otoh, this might become a pretty large beast |
01:09:19 | preglow | about how large? |
01:10:16 | amiconn | 242 bytes already. Using burst mode optimised for various alignments might easily quadruple this. |
01:10:25 | amiconn | memmove will double the size again |
01:11:01 | preglow | well, as long as the speedup is goog enough |
01:11:06 | preglow | good, even |
01:11:22 | preglow | but it might be a tad too large for putting in iram |
01:19:59 | | Quit _FireFly_ (Read error: 110 (Connection timed out)) |
01:21:04 | *** | Saving seen data "./dancer.seen" |
01:28:29 | preglow | still not realtime, hrmph |
01:34:48 | linuxstb | Did you solve the ICE problem? |
01:35:26 | | Nick paugh is now known as AliasCoffee (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
01:37:55 | preglow | no |
01:38:05 | preglow | i'm just ignoring that particular mul function for now |
01:38:20 | amiconn | LinusN: Is there a reason why you didn't enable SDRAM page mode in the bootloader? |
01:40:53 | LinusN | amiconn: instead of burst-only page mode? |
01:41:04 | amiconn | yes |
01:41:50 | | Join ashridah [0] (i=ashridah@220-253-123-180.VIC.netspace.net.au) |
01:43:49 | amiconn | Afaiu, this isn't really 'instead of'. If PM isn't set, the coldfire uses page mode for bursts only. If it's set, the coldfire uses page mode for both burst and normal accesses |
01:44:42 | amiconn | (when appropriate) |
01:45:08 | LinusN | amiconn: iirc, i interpreted it as "instead of" for some reason, but now that i look at it, i seem to have been wrong |
01:45:12 | amiconn | The benefits might be small, because the coldfire doesn't have warp mode & ras down |
01:45:27 | LinusN | and the pipeline is rather lame |
01:45:52 | LinusN | still, i don't see a penalty |
01:46:09 | preglow | how is the pipeline lame? |
01:46:10 | LinusN | but there has to be one, otherwise it wouldn't have been an option |
01:49:19 | amiconn | MCF5249UM.pdf, section 7.3.3.4: "The use of continuous page mode is recommended because it can provide a slight performance increase." |
01:50:33 | | Quit linuxstb ("CGI:IRC") |
01:50:35 | LinusN | preglow: it's short, and doesn't group data access and instruction fetches very well, so it makes bad use of the burst controller |
01:51:11 | LinusN | admittedly, it's not all about the pipeline, it's more about the memory controller |
01:51:23 | preglow | exactly how short is it? i've tried to find some info about the pipeline, but i've failed miserably |
01:54:13 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
01:54:13 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
01:55:05 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) |
01:56:13 | | Quit Moos ("Glory to Rockbox") |
01:56:31 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
01:59:02 | amiconn | Wow... memory accesses on coldfire are pathetic. I did some calculations based on my memcpy() timing |
01:59:26 | preglow | we know that... |
01:59:46 | amiconn | A loop that would take 5 cpu clocks per pass according to the instruction timing, but copies one long from dram to dram takes 43 clocks (!!) |
02:00 |
02:00:20 | preglow | tried enabling page mode to see if it gets better? |
02:00:51 | amiconn | Page mode wouldn't help in this case. Source & destination are in different pages |
02:01:33 | preglow | are you sure the memory timing is as tight as it can be? |
02:02:06 | | Quit Moos ("Glory to Rockbox") |
02:02:18 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
02:02:28 | LinusN | yes it is |
02:03:55 | preglow | oh well |
02:07:59 | LinusN | unfortunately, the sdram controller clock is always 1/2 the cpu clock |
02:08:07 | LinusN | even at 11mhz |
02:08:22 | LinusN | a major suckfactor |
02:08:49 | preglow | man, aac is pretty memory heavy |
02:08:49 | preglow | :/ |
02:18:02 | preglow | we could have half a meg of iram for this and still not have enough |
02:20:18 | LinusN | gotta sleep, nite all |
02:20:35 | | Part LinusN |
02:22:26 | preglow | no matter what i stuff into iram, it's still dog slow |
02:31:12 | | Quit Slasher (kornbluth.freenode.net irc.freenode.net) |
02:31:12 | NSplit | kornbluth.freenode.net irc.freenode.net |
02:39:06 | | Quit Moos ("Glory to Rockbox") |
02:39:33 | preglow | bed |
02:39:53 | | Join Naked [0] (i=naked@naked.iki.fi) |
02:43:33 | NHeal | kornbluth.freenode.net irc.freenode.net |
02:43:33 | NJoin | Slasher [0] (i=miipekk@ihme.org) |
02:46:45 | | Quit AliasCoffee ("Leaving") |
02:50:32 | | Quit Hadaka (Read error: 111 (Connection refused)) |
02:51:11 | | Nick Naked is now known as Hadaka (i=naked@naked.iki.fi) |
03:00 |
03:11:53 | | Quit cYmen ("zZz") |
03:21:08 | *** | Saving seen data "./dancer.seen" |
03:28:58 | | Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) |
03:29:26 | | Join bagawk [0] (n=lee@unaffiliated/bagawk) |
03:32:48 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
03:51:14 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
03:51:14 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
03:55:22 | | Join Lost-ash [0] (i=ashridah@220-253-120-150.VIC.netspace.net.au) |
03:55:24 | | Quit ashridah (Nick collision from services.) |
03:55:43 | | Nick Lost-ash is now known as ashridah (i=ashridah@220-253-120-150.VIC.netspace.net.au) |
04:00 |
04:38:06 | | Join Paul_The_Nerd [0] (n=paulthen@cpe-66-68-93-2.austin.res.rr.com) |
05:00 |
05:01:13 | bagawk | Bagder, good day :-) |
05:21:13 | *** | Saving seen data "./dancer.seen" |
05:41:46 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
05:41:46 | | Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) |
05:48:04 | | Quit Paul_The_Nerd ("Chatzilla 0.9.68a [Firefox 1.0.7/20050915]") |
06:00 |
06:19:22 | | Join Serotta_b [0] (n=johhny@c-67-161-105-190.hsd1.wa.comcast.net) |
06:19:22 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
06:19:30 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
06:20:34 | | Part Serotta_b |
06:39:33 | | Quit bagawk (""umount /dev/brain"") |
06:40:09 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
06:49:31 | | Quit RotAtoR () |
07:00 |
07:21:17 | *** | Saving seen data "./dancer.seen" |
07:35:48 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
07:35:54 | | Quit Maxime (Read error: 104 (Connection reset by peer)) |
07:36:56 | | Nick Mxm`Pas`Bien is now known as Maxime (n=flemmard@fbx.flemmard.net) |
07:57:27 | | Quit matsl (Remote closed the connection) |
08:00 |
08:05:55 | | Quit lostlogic ("Going to the moon") |
08:16:39 | | Join solexx_ [0] (n=jrschulz@c203186.adsl.hansenet.de) |
08:28:09 | | Quit solexx (Connection timed out) |
08:33:50 | | Join webguest82 [0] (n=3a4d5064@labb.contactor.se) |
08:34:08 | webguest82 | hello |
08:34:50 | webguest82 | There is that wonder of some piece. Do you have person who reply? |
08:35:44 | webguest82 | Can you find out iRiver H300's firmware source? |
08:35:49 | webguest82 | Do you have person who answer? |
08:36:47 | ashridah | the source code to the iriver firmware? we won't ever get that |
08:37:39 | webguest82 | Too .. |
08:38:15 | webguest82 | Is not it hard to manufacture one after another? |
08:38:34 | ashridah | we can disassemble it. |
08:38:48 | ashridah | someone probably already has to a degree. |
08:39:14 | ashridah | the only thing impeeding H300 development at the moment is really manpower |
08:39:31 | ashridah | the people who have the tools who can work on it are very busy with work atm. |
08:40:10 | webguest82 | What work is ashridah doing? |
08:40:55 | ashridah | not much. i pretty much test rockbox against my H140 whenever i get time |
08:41:28 | webguest82 | Are there much that know about H300? |
08:41:43 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
08:42:24 | ashridah | most of the problems facing rockbox on H300 involve tracing the hardware and working with the unit with a BDM |
08:42:43 | thegeek | hehe |
08:42:44 | ashridah | as i say, the rockbox developer with the tools to do that is currently busy. |
08:42:47 | thegeek | you sound like an alien webguest82 |
08:43:53 | webguest82 | thegeek: So. |
08:44:21 | ashridah | thegeek: i'm guessing he's using a translator like babelfish. wasn't there someone else who found a better one? |
08:44:29 | webguest82 | I am H300 user who live in South Korea. |
08:45:06 | webguest82 | Used babelfish before, but unuse now. |
08:45:19 | webguest82 | Babelfish is miserable. |
08:45:25 | ashridah | indeed |
08:45:35 | ashridah | it doesn't seem to have improved too much |
08:46:00 | webguest82 | Speech which do now may understand. |
08:46:17 | webguest82 | Is using program of HaanGuide. |
08:47:19 | webguest82 | Where does ashridah live? |
08:47:25 | ashridah | anyway, as i was saying, the main obstacle with H300 and rockbox is free time for the developers who are working on it. |
08:47:31 | ashridah | I'm in Australia. |
08:48:24 | webguest82 | :) |
08:48:34 | webguest82 | Live in the good country. |
08:48:56 | webguest82 | The South Korea is complicated and dizzy. |
08:48:57 | thegeek | ashridah : yeah, I guessed that |
08:49:10 | thegeek | actually webguest82 |
08:49:14 | thegeek | it was not that bad |
08:49:24 | thegeek | I've seen much worse results from babelfish |
08:49:38 | thegeek | it was just wierd enough to sound like an alien;) |
08:50:11 | webguest82 | Where does thegeek live? |
08:50:56 | thegeek | Norway:) |
08:51:01 | thegeek | way up north |
08:51:02 | webguest82 | Does not the South Korea have a person who work in RockBox? |
08:51:20 | webguest82 | Norway is the great country. |
08:51:21 | thegeek | I dont think so |
08:51:26 | thegeek | yep, it's nice:) |
08:51:46 | webguest82 | OTL |
08:52:28 | webguest82 | Do you know meaning of 'OTL'? |
08:52:47 | thegeek | not really;) |
08:53:25 | webguest82 | Do not I know? |
08:53:37 | webguest82 | Do not you know? |
08:53:49 | webguest82 | (was mistake) |
08:54:24 | thegeek | I do not know what it means;) |
08:54:28 | webguest82 | 'OTL' is Emoticon that express image that a person is miscarrying. |
08:54:49 | thegeek | ah, I see, it means you dont understand ? |
08:54:52 | webguest82 | Various Emoticons are used in the South Korea. |
08:54:58 | thegeek | ;) |
08:55:35 | webguest82 | The South Korea is that is the bad country. |
08:55:54 | thegeek | bad country? |
08:55:57 | thegeek | you dont like it there? |
08:56:08 | webguest82 | How does the South Korea think about the country? |
08:57:08 | thegeek | otl ;) |
08:58:37 | webguest82 | 'OTL' is that express that a person miscarries. |
08:59:20 | webguest82 | OTL |
08:59:20 | webguest82 | O - Head |
08:59:20 | webguest82 | T - Trunk |
08:59:20 | DBUG | Enqueued KICK webguest82 |
08:59:20 | webguest82 | L - Leg |
09:00 |
09:00:16 | webguest82 | Even if the South Korea may go first in technology, the other is bad seldom. |
09:01:11 | | Quit goa ("Client suicide") |
09:02:03 | webguest82 | By the way, what is BDM Iraneunge? |
09:03:48 | webguest82 | Oh sorry |
09:03:49 | webguest82 | What is 'BDM'? |
09:04:49 | | Quit webguest82 ("CGI:IRC (EOF)") |
09:05:12 | | Join webguest82 [0] (n=3a4d5064@labb.contactor.se) |
09:05:21 | webguest82 | Returned. |
09:05:41 | ashridah | webguest82: 'BDM' is a special debugging interface for embedded hardware |
09:06:12 | ashridah | many embedded processors such as the motorola coldfire in the iriver devices have special debugging interfaces, the BDM hooks into those (amoungst other things) |
09:06:15 | | Join goa [0] (i=hd@gate-hannes-tdsl.imos.net) |
09:06:19 | webguest82 | Then, is work about H300 childhood yet? |
09:09:18 | ashridah | i'm not sure i understood that question, say it another way? |
09:11:09 | webguest82 | I am sorry. |
09:11:13 | webguest82 | Is work about H300 startup yet? |
09:12:45 | ashridah | it's started |
09:12:48 | ashridah | it's just not progressing very fast |
09:13:24 | webguest82 | Is ashridah busy? |
09:14:18 | ashridah | i'm not a developer, i just test on the H140 |
09:14:27 | ashridah | but atm i've got exams |
09:15:10 | webguest82 | I want to do small work. |
09:17:04 | webguest82 | Can I do if do well C language? |
09:17:56 | ashridah | most of rockbox is in C, and development can be done without extensive hardware specific knowledge. You may be better off asking questions on the mailing list tho. I'm not a rockbox developer as such, just an occasional tester |
09:18:30 | webguest82 | ha ha |
09:20:41 | webguest82 | Seem to be many as know still. |
09:21:19 | *** | Saving seen data "./dancer.seen" |
09:22:57 | | Quit webguest82 ("CGI:IRC (EOF)") |
09:23:00 | | Join webguest82 [0] (n=3a4d5064@labb.contactor.se) |
09:23:34 | webguest82 | Site structure of rock box is difficult. |
09:25:49 | ashridah | it contains a lot of technical information, it might be difficult to read when translated, yeah |
09:26:04 | ashridah | unfortunately, it's unlikely that there's much that can be done, i don't believe we really have any developers who speak korean |
09:26:41 | webguest82 | Is no there a person to do Korean? |
09:27:22 | | Join ender` [0] (i=ychat@84.52.165.220) |
09:28:36 | webguest82 | May I how about if I do such work? :) |
09:29:57 | ashridah | it's possible. I don't know how much support rockbox's interface code has for korean. You'd definently need to join the mailing list and discuss it, but that might be difficult. the main problem i have is that i'm not a rockbox developer, i can't really say what needs to be done |
09:35:07 | B4gder | there's a unicode patch pending that should enable korean and most other languages too |
09:36:02 | webguest82 | English learns. |
09:36:06 | amiconn | Of course someone would need to create the korean translation |
09:38:07 | webguest82 | English - > Hangul translation possible. |
09:41:35 | webguest82 | It does not well that speak in English, but it does well that translate from English into Hangul. |
09:47:03 | webguest82 | Thank that give help variously today. |
09:49:00 | | Quit XavierGr (Read error: 110 (Connection timed out)) |
09:49:10 | webguest82 | bye~ |
09:49:26 | | Quit webguest82 ("CGI:IRC (EOF)") |
09:57:04 | markun | amiconn: I have a korean translation here. |
09:57:47 | markun | and a japansese one |
10:00 |
10:03:30 | B4gder | and I have a cup of coffee! |
10:03:36 | B4gder | :-P |
10:08:42 | linuxstb | B4gder: Which version of gcc does the server use to generate the H1x0 simulator auto builds? |
10:09:04 | B4gder | gcc (GCC) 4.0.2 (Debian 4.0.2-2) |
10:09:14 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
10:09:32 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
10:09:45 | linuxstb | That explains the current warnings then. I'm not getting them with 3.3.5 |
10:10:08 | B4gder | actually when I think about it, the configure outputs the gcc version |
10:10:24 | B4gder | but yes, gcc4 is a lot more picky |
10:10:27 | linuxstb | That's true. Very useful. |
10:12:21 | B4gder | then the gcc4 builds even inhibits some warnings |
10:12:29 | B4gder | using -Wno-pointer-sign |
10:14:59 | linuxstb | I don't want to commit a patch without testing it, and I don't have gcc4. But I guess it's about time I upgraded (I'm on Debian). |
10:15:32 | B4gder | it seems to work rather well |
10:15:36 | ashridah | linuxstb: the gcc 4 transition's going to start merging into testing soon |
10:15:56 | B4gder | I use gcc4 quite a lot |
10:16:04 | linuxstb | I'm running unstable - so I'm guessing I can just do "apt-get install gcc-4.0" |
10:16:12 | B4gder | yeps |
10:16:17 | ashridah | linuxstb: it should already be the default compiler |
10:16:35 | linuxstb | It isn't for me. But I don't run "upgrade" very often. |
10:16:39 | ashridah | if you've been dist-upgrading, the compiler itself will be all you're missing, almost everything will have been compiled for it |
10:17:01 | linuxstb | I generally just upgrade packages when I need to. |
10:17:49 | B4gder | gcc4, x.org, openoffice2 tiny little updates... :-) |
10:20:39 | | Join _FireFly_ [0] (n=FireFly@p54A45739.dip.t-dialin.net) |
10:22:32 | linuxstb | I've just installed gcc-4.0, and nothing else was upgraded. So I guess I was already most of the way there. |
10:23:02 | B4gder | rerun configure then before you build the sim, or you'll get a bazillion extra bonus warnings |
10:23:29 | linuxstb | Mmm. /usr/bin/gcc is still a symbolic link to gcc-3.3. Is there a "correct" way to change that? |
10:24:14 | _FireFly_ | distri ?? |
10:24:58 | linuxstb | distri ? |
10:25:03 | B4gder | mine is a link to gcc-4.0 |
10:25:10 | B4gder | but I don't know exactly what made it so |
10:25:33 | _FireFly_ | which distribution(debian, fc3, gentoo, ...) do you use |
10:25:49 | linuxstb | _FireFly_: Debian unstable. |
10:26:45 | linuxstb | Oh well, just changed the link manually. I'll soon find out if that breaks anything. |
10:28:54 | ashridah | linuxstb: the 'gcc' package should deal with that |
10:29:26 | ashridah | if you'd just installed gcc-4.0 or something, it wouldn't set the default |
10:30:09 | ashridah | $ dpkg -S /usr/bin/gcc |
10:30:10 | ashridah | gcc: /usr/bin/gcc |
10:31:40 | linuxstb | ashridah: Thanks. I just did an "apt-get install gcc" and that updated the symbolic link. |
10:32:21 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
10:32:21 | * | ashridah nods |
10:52:32 | linuxstb | OK, we should have a nice clean build table again now. |
10:58:45 | | Join muesli_- [0] (i=muesli_t@Bc148.b.pppool.de) |
10:58:53 | muesli_- | hi |
11:00 |
11:17:34 | amiconn | gcc 4 is already default in debian testing |
11:17:37 | amiconn | (4.0.2) |
11:18:21 | | Join tvelocity [0] (n=tony@ipa105.5.tellas.gr) |
11:21:21 | *** | Saving seen data "./dancer.seen" |
11:31:46 | ashridah | amiconn: interesting, didn't think they'd started the c++ abi push yet. |
11:49:55 | | Quit muesli_- (Read error: 110 (Connection timed out)) |
12:00 |
12:06:17 | | Quit DangerousDan (Read error: 104 (Connection reset by peer)) |
12:11:24 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
12:22:41 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
12:27:53 | | Join cYmen_ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
12:31:46 | | Join muesli_- [0] (i=muesli_t@Bc124.b.pppool.de) |
12:32:27 | | Nick solexx_ is now known as solexx (n=jrschulz@c203186.adsl.hansenet.de) |
12:33:06 | | Join cYmen__ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
12:35:21 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
12:38:15 | | Join cYmen___ [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
12:38:15 | *** | Alert Mode level 1 |
12:38:15 | DBUG | Enqueued KICK cYmen |
12:38:15 | DBUG | Enqueued KICK cYmen_ |
12:38:15 | *** | Alert Mode level 2 |
12:38:15 | DBUG | Enqueued KICK cYmen__ |
12:38:15 | DBUG | Enqueued KICK cYmen___ |
12:38:15 | *** | Alert Mode level 3 |
12:40:03 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
12:40:18 | Moos | Hello guys |
12:40:21 | | Quit cYmen (Connection timed out) |
12:43:18 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
12:43:27 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
12:43:34 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
12:43:34 | *** | Alert Mode level 4 |
12:43:34 | *** | Alert Mode level 5 |
12:43:34 | DBUG | Enqueued KICK cYmen |
12:43:34 | *** | Alert Mode level 6 |
12:43:34 | *** | Alert Mode level 7 |
12:43:34 | *** | Alert Mode level 8 |
12:44:13 | Moos | Slasher: Hi, are you around? I encountered one odd playback bug :( |
12:45:36 | | Quit cYmen_ (Connection timed out) |
12:45:44 | Moos | when playing one song, and wait for filling bufering |
12:46:36 | Moos | when it's done, and I skip back for replay song before his end, the player freeze in spining down |
12:46:51 | Moos | easy to reproduce |
12:47:03 | Moos | anyone here can reproduce it? |
12:47:47 | Slasher | Moos: Hmm, i will try that |
12:48:19 | Moos | Hi: since your last playback change this week end |
12:48:59 | Slasher | good, i can reproduce it |
12:48:59 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
12:49:00 | | Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
12:49:24 | | Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) |
12:49:24 | Slasher | DrMoos: i was able to reproduce it - fix coming soon |
12:49:36 | Moos | oki thanks |
12:50:41 | Maxime | (ah, one detail, when song is Paused, and you start another, if crossfade enabled, you have the 'end' of the song before starting the other.. starting the other without finishing the paused song will be great, no?) |
12:50:46 | | Quit cYmen__ (Success) |
12:51:10 | Slasher | Maxime: Hmm, i can fix that too |
12:51:29 | Maxime | because it's "surprizing" the fadeout of the other song .. |
12:52:02 | Slasher | true |
12:52:09 | Maxime | ^^ |
12:52:25 | Maxime | and I always have a bug |
12:52:44 | Maxime | I have to start player, play, stop, shutdown, power on again and play again to have sound.. |
12:53:03 | Maxime | the first start, i have no sound |
12:53:06 | Maxime | and the player "lags" |
12:53:19 | Maxime | to shutdown, it reacts 20-30s after the button press |
12:53:35 | *** | Alert Mode OFF |
12:54:10 | Slasher | Hmm, that's weird :/ |
12:54:13 | Maxime | it(s strange, it seems i'm the only with this problem |
12:54:35 | Maxime | and sometimes the player hangs, i'm forced to reset it |
12:54:39 | Slasher | It's probably hardware related |
12:54:50 | Maxime | i've tried deleting the whole rockbox folder, resetting config and so on |
12:54:54 | Maxime | but nothing changes |
12:55:02 | Maxime | and the original firmware haven't this issue |
12:56:02 | Maxime | but it's a very annoying issue |
12:56:57 | | Quit cYmen___ (Connection timed out) |
12:57:23 | Slasher | unfortunately it's hard for us to fix it because no any developer has encountered it |
12:57:34 | Maxime | yeah.. |
12:57:36 | Maxime | i know |
12:57:51 | Maxime | but I have no idea of how to "isolate" this issue.. |
12:58:37 | Slasher | I you want to try, you could try to change some hardware initialization code from the rockbox source. (Something audio and i2c related for example) |
12:58:53 | Maxime | but what(s strange |
12:58:59 | Maxime | is that it's one time on two |
12:59:06 | Maxime | 1. no sound, 2. sound |
12:59:32 | Maxime | i'll try one thing |
12:59:50 | Slasher | btw, if you use rolo to reload rockbox, do you get sound then=? |
12:59:56 | Maxime | hm |
12:59:57 | Maxime | i'll try |
12:59:58 | Slasher | Or do you have to power it completely off? |
13:00 |
13:00:00 | Slasher | good |
13:01:12 | Maxime | hum |
13:01:52 | Maxime | i dont understand |
13:01:59 | Maxime | it's when the player is a long time powered off |
13:02:16 | Maxime | but .. can't explain this .. |
13:02:23 | Maxime | coz no RTC or else.. |
13:02:27 | Maxime | eating time, bbl |
13:06:19 | | Join muesli- [0] (i=muesli_t@c-180-36-74.h.dial.de.ignite.net) |
13:09:12 | | Join amiconn_ [0] (n=jens@p54BD7D7A.dip.t-dialin.net) |
13:14:08 | | Quit muesli_- (Read error: 104 (Connection reset by peer)) |
13:16:27 | Maxime | see, the player was powered off when I was eating, and now, no sound |
13:16:58 | | Join LinusN [0] (n=linus@labb.contactor.se) |
13:17:03 | Maxime | when No sound, when I restart rockbox using RoLo, don't have sound |
13:17:09 | Maxime | Slasher? |
13:17:13 | LinusN | Maxime: which bootloader version do you have? |
13:17:24 | Maxime | 2 i think |
13:17:31 | LinusN | that's your problem |
13:17:34 | Maxime | ah.. |
13:17:39 | Maxime | It's a known problem? |
13:17:48 | LinusN | yes |
13:17:57 | Maxime | when player was powered of a few minutes, no sound, the restart, sound again |
13:17:58 | Maxime | ok |
13:18:09 | LinusN | however, it should be fixable in rockbox as well |
13:18:11 | linuxstb | Just out of interest, what was the fix? |
13:18:33 | | Quit muesli- (Read error: 104 (Connection reset by peer)) |
13:18:47 | LinusN | the uda1380 isn't properly reset, so it doesn't reply to i2c commands |
13:19:21 | Maxime | so i'm going to upgrade bootloader then.. |
13:19:33 | LinusN | worth a try |
13:19:38 | Maxime | yup |
13:19:55 | Maxime | because this was very annoying lol |
13:20:03 | preglow | why is the uda init in the bootloader at all? |
13:20:18 | preglow | wouldn't it be better if it touched as little as possible? |
13:20:18 | LinusN | http://forums.rockbox.org/index.php?topic=1383.0 |
13:20:34 | LinusN | preglow: yes, rockbox should reset it as well |
13:21:01 | LinusN | the bootloader resets it to get rid of an annoying "hum" during boot |
13:21:07 | preglow | ahh |
13:21:25 | *** | Saving seen data "./dancer.seen" |
13:21:37 | LinusN | and each reset produces a slight "pop", so resetting it twice might be annoying too |
13:22:06 | Slasher | Hmm, i wonder if we could prevent those reset pops too |
13:22:08 | _FireFly_ | would be a mute before resetting help |
13:22:36 | LinusN | we can't mute before reset, since it doesn't respond to i2c commands before reset |
13:22:46 | _FireFly_ | ok |
13:22:49 | linuxstb | preglow: Any progress with AAC? |
13:23:23 | preglow | none at all |
13:23:42 | preglow | i'd absolutely love to run some memory access analyzer on this beast |
13:23:55 | preglow | replacing the fixed point functions with emac equivalents didn't help much |
13:24:12 | preglow | so it's obvious it's the memory accesses that are bogging stuff down |
13:24:15 | linuxstb | I think the memory is the problem - it's using too much slow DRAM |
13:24:19 | preglow | and faad most certainly seems to use much of it... |
13:24:27 | linuxstb | hehe. I think we agree. |
13:24:32 | preglow | i can perhaps fit one or two important buffers in iram |
13:24:37 | preglow | the rest, no way |
13:24:57 | | Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) |
13:24:58 | preglow | the fft/mdct does a ton of memory accesses, so might be beneficial to stuff something around that in iram |
13:25:02 | preglow | problem is, everything's so big.. |
13:25:05 | linuxstb | Do you think some of the buffers could be merged and therefore share the same IRAM? |
13:25:14 | preglow | i have no idea yet |
13:25:24 | preglow | i'd need to understand the code to know |
13:25:36 | preglow | and right now i haven't even superficially looked at it |
13:25:50 | linuxstb | Yes, I want to use the sim to try and trace the common code paths. At the moment I don't have a clue what it's doing. |
13:27:31 | preglow | also, defining out the profiles i don't want in common.h doesn't do anything for the plugin size |
13:27:38 | | Quit amiconn (Read error: 110 (Connection timed out)) |
13:27:39 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD7D7A.dip.t-dialin.net) |
13:27:41 | linuxstb | You should be able to use DEBUGF - I've defined a macro for it in common.h. We should probably move that to codeclib.h |
13:27:49 | linuxstb | (in the sim I mean) |
13:27:57 | linuxstb | Or LOGF for the target. |
13:28:05 | linuxstb | Inside libfaad. |
13:29:11 | preglow | yup |
13:29:15 | | Part LinusN |
13:29:21 | preglow | but i wont have time for rockbox today |
13:29:37 | preglow | but please do tell if you get some analyzing done for libfaad |
13:30:02 | preglow | we most certainly don't need SSR, LTP and LD |
13:30:08 | linuxstb | Not sure when I'll get time, but I do want to try and understand libfaad a little better. Maybe tonight. |
13:30:08 | preglow | we MIGHT not need main either |
13:30:52 | linuxstb | I'll also install gcc4 for m68k and see if that makes any difference with the ICEs |
13:31:00 | preglow | that would be great |
13:31:07 | preglow | i tried compiling gcc4 once, failed miserably |
13:31:14 | preglow | but that was on this box, which is amd64 |
13:32:20 | linuxstb | I think there is also a problem with the Makefile dependencies for libfaad - so be careful. If you change libfaad, then aac.codec isn't always updated. |
13:32:33 | preglow | oh? |
13:32:46 | preglow | think i'll just do some deleting and try again, then |
13:33:21 | preglow | not very likely, though, i think the time stamp changed |
13:34:14 | | Join Webguest82 [0] (n=zeroirc@58.77.80.100) |
13:34:31 | Webguest82 | hello~ |
13:35:32 | preglow | oh well |
13:35:40 | preglow | the gaps are lot smaller than the audio parts now |
13:35:43 | preglow | but still not realtime |
13:35:48 | preglow | i expect it'll be a bitch making this realtime as well |
13:35:53 | preglow | but i've got to go for a sec |
13:36:57 | Webguest82 | Established IRC at to have a Maneunsigan conversation little more with you danger and injury. :) |
13:37:31 | Webguest82 | -> Established IRC at to have a conversation during little more much times with you danger and injury. |
13:38:45 | B4gder | linuxstb: you prolly need to add a .elf line for the faad codec like the other codecs are listed |
13:39:09 | B4gder | hm, no sorry |
13:39:24 | Ctcp | Ignored 5 channel CTCP requests in 5 minutes and 19 seconds at the last flood |
13:39:24 | * | B4gder looks again |
13:39:27 | Webguest82 | Was H100's firmware made already all? |
13:39:29 | B4gder | yes you do |
13:39:53 | Webguest82 | Was Hangul translation published? |
13:39:58 | * | B4gder is confused and will shutup |
13:40:07 | Webguest82 | Korean |
13:41:14 | Webguest82 | Is thing which is made in Korean? |
13:42:27 | | Quit Maxime (Read error: 110 (Connection timed out)) |
13:48:53 | | Quit Webguest82 ("Http://www.ZeroIRC.NET ¢Æ Zero IRC ¢Æ Ver 2.8") |
14:00 |
14:03:34 | | Join muesli_- [0] (i=muesli_t@c-180-216-214.cvx-h.dial.de.ignite.net) |
14:13:54 | | Quit ashridah ("Leaving") |
14:18:37 | | Quit muesli_- (Read error: 104 (Connection reset by peer)) |
14:39:12 | Slasher | Moos: fixed |
14:50:39 | linuxstb | Slasher: That commit fixes a seeking problem I had as well. |
14:53:20 | preglow | what kind of seeking problem? |
14:55:08 | linuxstb | If I was randomly seeking backwards and forwards in the same file, then eventually it would stop playback and the hard disk would stay active. I then had to stop playback and restart it. |
14:55:34 | linuxstb | But that wasn't normal use - I was trying as hard as I could to break it. |
14:55:43 | linuxstb | But now I can't. |
15:00 |
15:04:52 | Slasher | linuxstb: that's good :) |
15:19:37 | | Join tucoz [0] (n=81b17b04@labb.contactor.se) |
15:19:52 | tucoz | Hi, Slasheri, are you here? |
15:21:12 | tucoz | I noticed something that is reproduceable(?). When I play a song from an album and press the joystick left during the last seconds of the song to play the song again, the wps do not update. |
15:21:26 | *** | Saving seen data "./dancer.seen" |
15:21:48 | tucoz | this is iriver |
15:27:02 | tucoz | This is for instance song 1 out of 10 in an album. I listen to the first song, and want to hear it again and press left during the last few seconds. Then wps is no more updated and the next song starts playing instead of the same track playing again. |
15:29:54 | linuxstb | The problem is that Rockbox has already started decoding the next track. So you are probably trying to seek in the next track, not the one that's being displayed. |
15:30:20 | linuxstb | So I'm not sure what the solution could be. It will be worse if you've got crossfade enabled - if you seek during the crossfade, what is Rockbox supposed to do? |
15:30:40 | tucoz | linuxstb: that is probably true. I just noticed that the wps says track 2:14. But, it is not updated. |
15:31:01 | linuxstb | I'm not trying to say Rockbox is correct. Just that it's a tricky problem. |
15:31:28 | tucoz | It is not that much of an issue, but the wps should not 'freeze' when this happens. |
15:32:34 | linuxstb | If you ignore the WPS problem, what happens? I'm guessing the seek is interpreted as being a seek in the next track. |
15:32:45 | tucoz | linuxstb: correct |
15:33:36 | tucoz | I guess the next track is already in the pcm buffer, and that is why this happens. |
15:34:25 | linuxstb | It's the fact that the codec is in the process of decoding the next track. A seek is processed by the codec - so after the previous track has been completely decoded, you can't seek in it any more. |
15:35:57 | tucoz | Ok, that makes sense. Still, there is a bug with the wps that makes it not updating. |
15:39:43 | linuxstb | It's possible that the WPS information for the previous track has been thrown away by that point. But I don't really know that code very well, so I'm only guessing. |
15:40:15 | linuxstb | Does the WPS display correctly for the next track? Or is that the problem? |
15:40:26 | preglow | wps is a bit glitchy |
15:40:30 | preglow | especially for short tracks |
15:41:48 | tucoz | the problem is that the WPS is not updating. The information for the previous track is showing. The time shows for instance 3.15/3.18 (3.15 being the time for the press left to happen, and 3.18 the total track length) |
15:42:13 | tucoz | and track number showing track 2:14 |
15:43:06 | tucoz | which is correct. But, nothing else is working. That is no progress bar updates, peak meters, id3 info etc. |
15:44:07 | tucoz | The id3 tags showing are those for the track that _were_ playing. |
15:56:04 | | Join lostlogic [0] (n=lostlogi@node-4024215a.mdw.onnet.us.uu.net) |
15:59:47 | | Part tucoz |
16:00 |
16:01:47 | | Quit Moos ("Glory to Rockbox") |
16:02:02 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
16:59:33 | | Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
16:59:37 | DMJC | um... ok |
16:59:44 | DMJC | can someone help me with warranty info? |
16:59:46 | | Quit DMJC (Client Quit) |
17:00 |
17:01:00 | | Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
17:01:09 | DMJC | anyone here from australia? |
17:01:14 | DMJC | I need to know some info fast |
17:01:17 | DMJC | IHP-140 |
17:01:22 | DMJC | I need to do a warranty claim |
17:01:41 | DMJC | to uninstall rockbox... do I just flash it with the original firmware? |
17:01:50 | DMJC | I sat on my iriver, the screen is busted |
17:02:03 | DMJC | the actual unit itself seems fine except the lcd screen |
17:02:12 | DMJC | the glass outer cover of the screen is intact |
17:02:49 | DMJC | I also need to know which version of the firmware to use |
17:02:55 | DMJC | american? |
17:04:04 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
17:04:12 | crwl | that shouldn't matter |
17:04:40 | crwl | flash it with the original firmware and remove the .rockbox directory at root |
17:06:03 | DMJC | ok |
17:06:45 | DMJC | luckily it's under warranty |
17:12:30 | crwl | of course, warranties usually don't cover user-induced damage |
17:12:38 | crwl | but i hear iriver hasn't been too strict on that |
17:13:52 | DMJC | nice |
17:13:54 | DMJC | hmm |
17:13:59 | DMJC | how the hell do I flash this thing? |
17:14:15 | DMJC | I can't see the option, screen damage makes it unreadable |
17:14:16 | crwl | i think it's doable with the remote |
17:19:26 | | Join DMJC-L [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
17:20:50 | DMJC-L | hmmm |
17:20:53 | DMJC-L | ok I reflashed |
17:21:04 | DMJC-L | and now it doesn't boot unless I hit the reset button |
17:21:30 | *** | Saving seen data "./dancer.seen" |
17:22:34 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
17:24:15 | | Join rubberglove [0] (n=463079b7@labb.contactor.se) |
17:25:20 | rubberglove | hello all (or any!) i was just trying to compile todays build and got this error: make: *** libm4a: No such file or directory. Stop. |
17:25:53 | B4gder | did you re-run configure? |
17:26:07 | rubberglove | yup. |
17:26:12 | rubberglove | i'll try it again. |
17:27:33 | B4gder | did you use 'cvs up -d' (the -d being the key) or how did you get the source? |
17:28:12 | rubberglove | the daily builds page.. with the 'latest' source |
17:28:26 | B4gder | ok, I'll check that... |
17:29:18 | rubberglove | yup. same error. i ran make clean and then configure |
17:30:31 | B4gder | right, libm4a is missing |
17:31:24 | rubberglove | oops. |
17:31:36 | B4gder | fixed in CVS just now |
17:31:49 | linuxstb | Thanks - sorry about that. |
17:32:07 | rubberglove | cool. thanks. |
17:33:18 | linuxstb | Is anyone worried about libFLAC still being in CVS? I was going to delete it, but then thought we might want to try the encoder one day. |
17:33:31 | B4gder | nah, leave it around |
17:34:54 | linuxstb | The "apps" directory is almost 40MB now... |
17:35:33 | B4gder | Totals grouped by language (dominant language first): |
17:35:33 | B4gder | ansic: 235877 (95.26%) |
17:35:40 | B4gder | perl: 5621 (2.27%) |
17:35:40 | B4gder | sh: 3457 (1.40%) |
17:35:40 | B4gder | asm: 2513 (1.01%) |
17:35:43 | preglow | not bad |
17:35:45 | B4gder | (lines of code) |
17:36:13 | B4gder | Total Estimated Cost to Develop = $ 8,812,593 |
17:36:15 | B4gder | ;-) |
17:36:20 | preglow | hahah |
17:36:45 | B4gder | count and estimate by 'sloccount' |
17:36:55 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
17:37:03 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
17:37:15 | preglow | that's entire rockbox? |
17:37:19 | B4gder | yes |
17:37:33 | preglow | codecs amount to quite a fraction |
17:37:53 | linuxstb | I would guess the majority. |
17:37:58 | B4gder | codecs are ~100K lines |
17:38:37 | B4gder | time to go |
17:38:39 | | Quit B4gder ("time to say moo") |
17:39:23 | linuxstb | More useless stats - rockbox.iriver: 224356 bytes, aac.codec: 471428 bytes |
17:39:29 | preglow | ahahahah |
17:39:35 | | Quit DMJC (Read error: 110 (Connection timed out)) |
17:40:23 | linuxstb | Even removing the bss, I think aac.codec is bigger than rockbox... |
17:41:44 | preglow | i wonder how that's possible... |
17:41:55 | preglow | this is the same codec they're stuffing in mobile phones |
17:41:59 | preglow | hardware based, sure, but still |
17:42:40 | linuxstb | I'm sure we can strip it down a lot - it will just take some time for us to understand it. |
17:42:48 | preglow | yep |
17:42:54 | preglow | it's quite a complicated piece of software |
17:43:06 | | Quit DMJC-L (Read error: 110 (Connection timed out)) |
17:44:48 | | Join ender` [0] (i=ychat@84.52.165.220) |
17:47:25 | | Join DMJC [0] (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
17:47:37 | | Nick DMJC is now known as DMJC-sleep (n=DMJC-L@220-245-177-240-sa-pppoe.tpgi.com.au) |
17:48:01 | amiconn | linuxstb: I checked the apps/ dir size, including subdirs. 9.97 MB, occupying 12 MB of disk space. Nowhere near 40 MB... |
17:48:16 | | Quit ender` (Read error: 104 (Connection reset by peer)) |
17:49:17 | amiconn | All source dirs together: 15.5 MB |
17:50:11 | linuxstb | Must be my cluster size then. "du -m" says 39MB |
17:51:17 | linuxstb | Oops. No - it's the test WAV file I have in there.... |
17:51:48 | linuxstb | Now it's about 13MB of space. |
18:00 |
18:04:46 | | Join ender` [0] (i=ychat@84.52.165.220) |
18:10:42 | | Quit rubberglove ("CGI:IRC") |
18:32:12 | | Join DrMoos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
18:32:23 | | Quit Moos (Read error: 104 (Connection reset by peer)) |
18:32:29 | | Nick DrMoos is now known as Moos (i=DrMoos@m79.net81-66-158.noos.fr) |
19:00 |
19:13:47 | | Quit Moos ("Glory to Rockbox") |
19:14:56 | | Join Moos [0] (i=DrMoos@m79.net81-66-158.noos.fr) |
19:21:31 | *** | Saving seen data "./dancer.seen" |
19:30:30 | preglow | linuxstb: we agree we're not going to support more than two channels unless multichannel is the norm for the codec in question (like ac3), yes? |
19:34:13 | | Join arkascha [0] (n=arkascha@xdsl-213-196-216-245.netcologne.de) |
19:35:56 | | Quit arkascha (Remote closed the connection) |
19:43:55 | preglow | amiconn: i've solved the mystery of the slow layer1, it seems |
19:46:08 | preglow | amiconn: seems it was a cache issue, it works without boosting for 256kbps layer 1 if i just inline the per sample function that's used in the frame decoding |
20:00 |
20:48:43 | | Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) |
20:49:10 | | Quit ghode|afk (Read error: 104 (Connection reset by peer)) |
20:49:41 | | Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) |
20:52:19 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
20:55:54 | | Join ghode|afk [0] (n=garudin@host-212-158-193-204.bulldogdsl.com) |
21:00 |
21:19:07 | | Quit ghode|afk (Read error: 104 (Connection reset by peer)) |
21:19:49 | amiconn | preglow: Nice... Did you check whether this also helps layer 2 performance? |
21:20:13 | preglow | amiconn: it can't, layer 1 and 2 decoding is separate |
21:20:22 | preglow | amiconn: but if you mean just inlining, i'm going to try that afterwards |
21:20:23 | amiconn | Oh ok |
21:20:51 | preglow | layer 2 decoding has a similar routine, but it eats three samples and not just one |
21:21:04 | preglow | i'll check it out anyway, there's no reason for layer2 to actually be slower than layer3 |
21:21:13 | preglow | i hate these one way associative caches |
21:21:32 | *** | Saving seen data "./dancer.seen" |
21:22:14 | amiconn | It's not necessarily a cache issue |
21:22:32 | amiconn | You say this function is called for every sample, i.e. really often |
21:22:47 | amiconn | Parameter passing is done via the stack on coldfire |
21:23:49 | preglow | yes, sure |
21:23:54 | preglow | but i can't imagine it should hurt _this_ much |
21:23:55 | preglow | i mean |
21:24:06 | preglow | it's actually heavier than a full imdct per band |
21:24:10 | preglow | and that's just plain impossible |
21:24:28 | amiconn | Inlining avoids the whole call overhead |
21:24:43 | preglow | it does |
21:24:46 | preglow | and it can aid optimising |
21:25:04 | preglow | perhaps i should just try compiling the entirety of libmad O3 |
21:25:16 | preglow | that should auto-inline functions if it thinks it'll benefit |
21:25:27 | amiconn | I can't build the h1x0 win32 sim, I get a really strange error |
21:26:02 | amiconn | CC bits.c |
21:26:02 | amiconn | In file included from common.h:261, |
21:26:02 | amiconn | from bits.c:28: |
21:26:02 | DBUG | Enqueued KICK amiconn |
21:26:02 | amiconn | fixed.h: In function `MUL_R': |
21:26:02 | amiconn | fixed.h:67: error: `_asm' undeclared (first use in this function) |
21:26:02 | *** | Alert Mode level 1 |
21:26:02 | amiconn | fixed.h:67: error: (Each undeclared identifier is reported only once |
21:26:04 | amiconn | fixed.h:67: error: for each function it appears in.) |
21:26:06 | amiconn | fixed.h:67: error: parse error before '{' token |
21:26:08 | amiconn | fixed.h:71: warning: no return statement in function returning non-void |
21:26:10 | amiconn | fixed.h: In function `MUL_C': |
21:26:12 | amiconn | etc etc |
21:26:26 | amiconn | some more undeclared symbols named "_asm" |
21:26:31 | preglow | ahh, riiight |
21:26:39 | preglow | it probably doesn't check if it uses msvc or gcc |
21:26:46 | preglow | libfaad uses msvc style inline asm |
21:26:52 | amiconn | This is really strange, I can build the x11 sim just fine - also under cygwin, using the very same gcc! |
21:27:23 | preglow | #if defined(_WIN32) && !defined(_WIN32_WCE) |
21:27:27 | preglow | yes, like i thought |
21:27:28 | amiconn | urgs |
21:27:45 | amiconn | I think that can be safely removed... |
21:28:10 | preglow | i think i'm a bit lagged |
21:29:20 | amiconn | Way back in time we had an msvc project for building the sim, but that broke long ago, and was removed because nobody fixed it again |
21:29:31 | preglow | just as well |
21:29:36 | preglow | can't see a reason to use msvc |
21:33:45 | preglow | apart from the ui, of course |
21:33:52 | preglow | the compiler itself isn't very good |
21:36:03 | *** | Alert Mode OFF |
21:41:39 | amiconn | Imho these msvc-style inlines should be removed, and perhaps replaced by gcc-style inline asm for x86 |
21:41:44 | amiconn | What do you think? |
21:42:59 | preglow | i agree |
21:43:08 | preglow | can't see a use for the msvc ones, at least |
21:43:27 | preglow | though i'm a bit puzzled by the need for these functions anyway |
21:43:44 | preglow | i would have thought x86 compilers were clever enough to actually use those instructions anyway |
21:45:16 | amiconn | Perhaps msvc isn't? ;) |
21:45:31 | preglow | wouldn't have surprised me |
21:45:35 | preglow | it used to be a really poor compiler |
21:45:41 | preglow | though i here the more recent incarnations are pretty good |
21:57:20 | amiconn | What's so special about these inlines? The use of the imul instruction. |
21:57:25 | preglow | yes |
21:57:31 | amiconn | (I'm an x86 asm noob) |
21:57:31 | preglow | it does a 32x32->64 bit mul |
21:57:43 | preglow | i'm not much of an expert myself |
21:57:46 | preglow | but i know that |
21:57:59 | amiconn | If so, I think the inlines can probably removed |
21:58:03 | preglow | and then theres the shrd instruction, that does shifting from one register to another one |
21:58:04 | amiconn | gcc, uses imul |
21:59:19 | amiconn | I disassembled the simulator aac.codec with objdump, and checked a function that uses some MUL_R s |
21:59:51 | preglow | does it use shrd as well? |
22:00 |
22:00:14 | amiconn | There are seveal imul instruction, and also some shrd |
22:00:19 | amiconn | *several |
22:00:46 | preglow | anywho |
22:00:52 | preglow | i think they can be removed |
22:01:04 | preglow | i refuse to believe modern compilers can't do 64 bit muls on x86 |
22:01:21 | amiconn | x86 asm looks strange |
22:01:29 | preglow | and the less i see of the idiot inline assembler thing msvc uses, the better |
22:01:31 | preglow | in what way? |
22:02:16 | amiconn | Really complex instruction format, and looong instructions |
22:02:34 | amiconn | It seems instructions can be any length from 1 to 10 bytes |
22:03:00 | preglow | yup |
22:03:05 | preglow | the instruction length varies wildly |
22:03:36 | preglow | i'm not really fond of x86 assembler myself |
22:04:04 | preglow | it got a bit easier with x86-64, since you at least get a semi-decent number of registers to play around with |
22:11:15 | preglow | i'll try inlining the layer 2 routine now, and see if it helps |
22:11:22 | amiconn | Okay, completely removed these inlines locally. Now the win32 sim builds again :) |
22:11:49 | amiconn | Shall I commit? |
22:14:41 | preglow | sure |
22:14:55 | preglow | amiconn: performance actually seemed to get worse if i inline II_samples |
22:16:13 | preglow | but it's hard to say, at least it didn't get any better that i could see |
22:18:36 | amiconn | aac.codec is a monster on the sim as well. 250KB for win32, and 662KB (!) for x11 |
22:18:47 | preglow | eh? |
22:18:55 | preglow | what's the size difference? |
22:19:10 | amiconn | I'm not sure... perhaps debug symbols |
22:19:23 | amiconn | All codecs are larger for x11 than for win32 |
22:19:49 | preglow | it doesn't make sense to include debug symbols in a binary image |
22:20:10 | amiconn | The sim codecs aren't plain binary images |
22:20:13 | preglow | and the size for windows doesn't make sense either, that's actually almost twice as small as for the actual target version |
22:20:16 | preglow | no? |
22:20:17 | amiconn | They are shared libraries |
22:20:19 | preglow | ok |
22:21:42 | amiconn | Some codecs are half the size of the target version in windows, but some are roughly equal in size |
22:21:42 | preglow | i'd like for us to use something like that on target as well, one day |
22:21:50 | preglow | at least just a simple format with relocation information |
22:22:00 | amiconn | This doesn't correlate to the absolute size, must be something else |
22:22:33 | preglow | i think i'll just commit the few libfaad macros i have so far |
22:22:51 | preglow | without commiting the one that provokes the ICE |
22:23:30 | amiconn | You could put that in as well, and disable it for now (#if 0) |
22:28:55 | | Quit Kohlrabi (Nick collision from services.) |
22:28:58 | | Join Kohlrabi [0] (n=Kohlrabi@dslb-082-083-130-062.pools.arcor-ip.net) |
22:33:08 | preglow | hmm |
22:33:42 | preglow | MUL_R requires me to do a 64 bit shift by 17 |
22:33:53 | preglow | think i'll just modify your libmusepack routine a bit for that one |
22:34:39 | | Join ghode|afk [0] (i=testing@host-212-158-193-204.bulldogdsl.com) |
22:38:32 | amiconn | shift by 17? |
22:38:50 | amiconn | Shouldn't that be 14? |
22:40:14 | amiconn | Iiuc this is exactly the same as mpc_multiply() |
22:43:40 | | Join muesli_- [0] (i=muesli_t@Bc0a8.b.pppool.de) |
22:45:22 | preglow | should be 14, yes, i misread |
22:45:37 | preglow | mpc_multiply shifts by 16 |
22:46:16 | preglow | bah |
22:46:18 | preglow | forget me |
22:46:28 | preglow | yes, i can just use the mpc_multiply verbatim, it seems |
22:53:46 | | Join Midgey34 [0] (n=chatzill@c-67-172-68-52.hsd1.mi.comcast.net) |
23:00 |
23:10:52 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
23:10:52 | * | preglow hopes for a new ICE |
23:12:45 | preglow | bah |
23:21:33 | *** | Saving seen data "./dancer.seen" |
23:48:19 | | Join RotAtoR [0] (n=e@12-210-82-91.client.insightBB.com) |
23:54:04 | | Quit _FireFly_ ("Leaving") |
23:56:54 | | Quit Kohlrabi (Read error: 104 (Connection reset by peer)) |
23:58:20 | linuxstb | preglow: I've just updated to your fixed.h changes, and I am just getting noise out of the decoder now. |