| 00:00:08 | pixelma | not at the moment, have to think about it |
| 00:00:14 | JdGordon_ | %?St(setting)<one|two> |
| 00:00:40 | | Part anethema |
| 00:00:53 | pixelma | () is not nice as you will need %( and %) then and using braces is quite common |
| 00:01:16 | JdGordon_ | not necessarily |
| 00:02:35 | AlexP | JdGordon_: Now I get 716 if (id < SYSTEMFONTCOUNT || id >= MAXFONTS-1) 717 return WPS_ERROR_INVALID_PARAM; 725 } |
| 00:03:05 | JdGordon_ | the numbers are? |
| 00:03:30 | AlexP | sorry, one mo |
| 00:03:40 | | Join Rob2222 [0] (~Miranda@p4FDCAF91.dip.t-dialin.net) |
| 00:04:05 | JdGordon_ | oh, gdb output? that means the the font is being loaded into the id for the remote user font |
| 00:04:31 | JdGordon_ | oh bloody hell |
| 00:04:34 | * | JdGordon_ appologises |
| 00:04:44 | JdGordon_ | yeah, but that line back.. bloody stupid of me |
| 00:05:00 | JdGordon_ | FFS :p |
| 00:05:02 | AlexP | heh, OK :) |
| 00:05:15 | JdGordon_ | id -= SYSTEMFONTCOUNT; should be id -= FONT_UI |
| 00:05:24 | JdGordon_ | right area, wrong fix :p |
| 00:05:26 | pixelma | and I still want preset name on it's own line or only with the preset number max as it is in SVN (line too long) |
| 00:05:26 | AlexP | OK, one mo |
| 00:05:33 | pixelma | and scrolling lines |
| 00:06:39 | | Quit Bagder (Ping timeout: 260 seconds) |
| 00:07:02 | pixelma | oh, I said I'll take care of that... but only if own FMS don't need a hard reset for me |
| 00:07:11 | | Quit Rob2223 (Ping timeout: 256 seconds) |
| 00:07:31 | pixelma | removing %pm from my FMS didn't help |
| 00:07:38 | * | JdGordon_ doesnt understand the but part? |
| 00:08:10 | AlexP | JdGordon_: p id $1 = 1 p font_ids[id] $2 = 3 |
| 00:08:32 | AlexP | Should I see if it works now? |
| 00:08:39 | JdGordon_ | yep, just hit c |
| 00:09:10 | pixelma | a hard reset is the only way to exit the radio screen with an own FMS is a hard reset currently (on my Ondio) so it's not nice to test FMSs |
| 00:09:54 | | Quit perfectdrug (Quit: perfectdrug) |
| 00:10:48 | * | JdGordon_ heading home |
| 00:11:00 | JdGordon_ | please nmentino that in the tracker incase I forget |
| 00:11:05 | | Quit JdGordon_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 00:11:57 | | Quit ender` (Quit: Connection Reset by Gypsies with Wire Cutters) |
| 00:13:44 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 00:13:50 | AlexP | JdGordon: It now gives an error on parsing if I misspell the font in the %Fl, but the wps still doesn't use it |
| 00:14:04 | * | pixelma wonders about something |
| 00:21:20 | | Quit mt (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) |
| 00:25:45 | | Quit MaadMan (Quit: Verlassend) |
| 00:26:14 | | Join ecio_ [0] (~ecio@32.130.89.182) |
| 00:26:31 | | Nick knine is now known as kaniini (~kaniini65@dyn75-70.yok.fi) |
| 00:28:07 | | Quit freddyb (Ping timeout: 260 seconds) |
| 00:29:59 | | Quit ecio (Ping timeout: 260 seconds) |
| 00:30:00 | | Nick ecio_ is now known as ecio (~ecio@32.130.89.182) |
| 00:30:40 | pixelma | JdGordon: any own FMS with a FMS tag makes it break. I just tried "..." as the only things in the FMS and it works - whereas "%Tn" as the only thing doesn't |
| 00:31:00 | | Join Farthen [0] (~chatzilla@p50988dd0.dip0.t-ipconnect.de) |
| 00:31:14 | | Join Omlet05 [0] (omlet05@61.118-244-81.adsl-dyn.isp.belgacom.be) |
| 00:31:32 | pixelma | although it is correctly parsed and shows me the preset name |
| 00:31:37 | | Quit Omlet05 (Client Quit) |
| 00:33:00 | | Quit Tomis (Read error: Operation timed out) |
| 00:33:27 | | Quit huelk (Read error: Operation timed out) |
| 00:33:50 | | Join Sajber^ [0] (~Sajber^@93-252.anonymous.at.anonine.com) |
| 00:34:18 | | Quit robin0800 (Remote host closed the connection) |
| 00:34:25 | pixelma | and not sure if it is relatad (guess not) but I still get unused variable warnings in radio.c (line 592, variables in question are "minutes" and "hours" |
| 00:34:26 | | Join Tomis [0] (~Tomis@70.134.68.71) |
| 00:34:28 | | Quit Omlet (Ping timeout: 276 seconds) |
| 00:39:27 | | Quit piotrekm (Quit: piotrekm) |
| 00:42:33 | TucknDar | gevaerts, I've tried to get the card in my mini to be as thick as the original hard drive, but I can't get the click working... do you by any chance have any other suggestions? |
| 00:43:28 | pixelma | I think people successfully used pieces of cardboard to fill the gap |
| 00:44:39 | TucknDar | yeah, I'm trying but no... weird. guess I'll have to keep experimenting. |
| 00:45:11 | JdGordon | AlexP: bloody hell :p |
| 00:45:14 | JdGordon | umm |
| 00:45:31 | CIA-8 | New commit by funman (r24778): rbutil: link to the Sansa forums when the user is requested to download a Sansa AMS firmware |
| 00:46:16 | | Quit petur (Quit: Zzzzzz) |
| 00:49:19 | CIA-8 | New commit by jdgordon (r24779): fix possible out-of-bounds error on remote lcd targets if they try loading a font to id==2 |
| 00:49:52 | | Quit Tomis (Read error: Connection reset by peer) |
| 00:50:57 | JdGordon | TucknDar: I didnt use anything to fill the gap.. my clickwheel still works fine |
| 00:51:07 | | Join Tomis [0] (~Tomis@70.134.68.71) |
| 00:51:33 | TucknDar | my doesn't... another test now though. Thanks for your replies, btw! Appreciate it! |
| 00:51:53 | JdGordon | minig1 or g2? |
| 00:52:00 | TucknDar | g2 |
| 00:52:15 | JdGordon | same, yeah, some thick card should do the trick |
| 00:52:33 | pixelma | hopefully you didn't damage the cable? |
| 00:52:37 | | Join Strife1989 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) |
| 00:52:58 | TucknDar | don't think so, as it works with apple firmware, which I obviously don't want to use ;) |
| 00:54:37 | CIA-8 | New commit by jdgordon (r24780): and actually fix multifont on remote lcd targets also |
| 00:54:53 | JdGordon | AlexP: there you go! |
| 00:55:10 | AlexP | thank you :) |
| 00:55:13 | pixelma | JdGordon: I just tested the pm on its own line theory with a test.wps containing %?mh<%pm|AAA> (and on a second line with %?mh<HHH|AAA> to see if the hold tag works and it does) - and the first line always shows the peakmeters, whether on hold or not... |
| 00:55:15 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 00:56:08 | JdGordon | ok, I guess thats not really surprising. did we ever expect %pm to work in conditionals? |
| 00:56:44 | pixelma | you seemed to :P |
| 00:56:52 | JdGordon | apart from me :) |
| 00:56:53 | *** | Saving seen data "./dancer.seen" |
| 00:57:00 | JdGordon | (who knows nothing about actually using the skins) |
| 00:57:17 | | Nick Strife1989 is now known as Strife89|Desktop (~Strife89@adsl-220-102-6.mcn.bellsouth.net) |
| 00:58:06 | | Quit jgarvey (Quit: Leaving) |
| 00:58:30 | AlexP | JdGordon: ta, multifont works nicely now :) |
| 00:58:37 | JdGordon | weeeee :) |
| 00:59:01 | AlexP | I'll try out fms shortly |
| 01:00 |
| 01:02:04 | | Join crwl [0] (~crwlll@a88-112-134-63.elisa-laajakaista.fi) |
| 01:05:10 | | Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 01:05:23 | | Join CaptainKwel [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 01:07:22 | | Quit Strife89|Desktop (Quit: Log out, log in.) |
| 01:08:31 | | Join Strife1989 [0] (~Strife89@adsl-220-102-6.mcn.bellsouth.net) |
| 01:09:39 | saratoga | ha the new mdct library flips the order of the input and output arguments |
| 01:09:56 | | Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 01:10:00 | | Quit CaptainKewl (Ping timeout: 264 seconds) |
| 01:12:07 | | Nick Strife1989 is now known as Strife89|Desktop (~Strife89@adsl-220-102-6.mcn.bellsouth.net) |
| 01:14:38 | | Quit tomers (Client Quit) |
| 01:16:22 | | Quit TucknDar (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 01:24:03 | AlexP | JdGordon: limits exceeded! : |
| 01:24:10 | AlexP | Where do I increase them? |
| 01:24:18 | JdGordon | which limit? |
| 01:24:34 | JdGordon | probably apps/gui/skin_engine/skin_buffer.c at the top |
| 01:24:54 | AlexP | dunno, the sim just says ERR: Failed parsing on line 31 : ERR: Limits exceeded |
| 01:25:03 | AlexP | Although neither my wps or fms have a line 31 |
| 01:27:32 | JdGordon | yeah, probably that file ten |
| 01:27:41 | AlexP | hang on |
| 01:27:43 | | Quit bertrik (Ping timeout: 246 seconds) |
| 01:29:32 | CIA-8 | New commit by saratoga (r24781): Use new MDCT library for libfaad. Speeds up AAC-LC by 2.5MHz. |
| 01:30:20 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 01:32:06 | saratoga | I guess we can remove the old MDCT now |
| 01:32:12 | saratoga | its not used for anything |
| 01:32:28 | JdGordon | AlexP: are you using different backdrops for the 3 possible skins? (sbs/setting, wps, fms)? |
| 01:32:47 | AlexP | JdGordon: no sbs and at the moment the fms and wps are using the same one |
| 01:32:52 | AlexP | (or trying to) |
| 01:33:05 | JdGordon | lots of images? or fonts? |
| 01:33:26 | AlexP | 1 additional font in the wps, two in the sbs |
| 01:33:40 | AlexP | and not many images, no - just vol, battery etc from cabbiev2 |
| 01:33:43 | JdGordon | 30K, shouldnt be such a big deal |
| 01:34:10 | AlexP | A slight ofddity is the error at line 31 - the wps has 24 lines, the fms 23 |
| 01:34:17 | JdGordon | we really need to get better debug info from skins :/ |
| 01:34:26 | JdGordon | awesome! |
| 01:34:28 | AlexP | sorry, two additional fonts in the fms not sbs |
| 01:34:38 | AlexP | There is no sbs |
| 01:34:41 | JdGordon | remote target though, so the remote maybe? |
| 01:34:57 | AlexP | ah, possibly - I haven't touched that yet |
| 01:35:55 | AlexP | yes, the cabbie rwps has 34 lines :) |
| 01:36:19 | AlexP | I'll cut that down into one of my own with a sngle line or something and see if it goes away |
| 01:37:30 | AlexP | yes, that was it |
| 01:37:51 | AlexP | but without remote wps or fms I'm already at 38620/44032 |
| 01:38:04 | AlexP | without any images to speak of, and three additional fonts |
| 01:38:21 | AlexP | well, with a few images |
| 01:38:26 | AlexP | but not going mental :) |
| 01:39:16 | | Join phanboy4 [0] (~benji@gate-20.spsu.edu) |
| 01:39:58 | JdGordon | that seems too high |
| 01:40:09 | Unhelpful | amiconn: pong? |
| 01:40:17 | AlexP | I'll finish up and then upload somewhere |
| 01:40:21 | | Join kimi-sharamin [0] (~karashata@74-220-162-11.wightman.ca) |
| 01:40:28 | JdGordon | which target? |
| 01:40:35 | AlexP | H120 |
| 01:41:12 | amiconn | Unhelpful: I don't understand your ARMv6 division optimisation (udiv32_arm.S lines 241ff) |
| 01:41:56 | saratoga | oddly enough on the nano2g rbutil said i already had a bootloader installed, and i'm pretty sure i didn't |
| 01:42:15 | amiconn | Your're using smmla (should be equivalent to the smlal with low word cleared used on ARM <v6, which is understandable and saves two cycles |
| 01:42:34 | AlexP | JdGordon: I'm going to bed in a bit - I'll have a play tomorrow then bug you on Sunday :) |
| 01:42:44 | JdGordon | AlexP: easiest fix is apps/gui/skin_engine/skin_buffer.c line 58, change that 2* to 4* or something |
| 01:42:45 | amiconn | But then you're using smmul, which needs correction if the sign bit is set |
| 01:42:46 | | Quit karashata (Ping timeout: 265 seconds) |
| 01:42:51 | JdGordon | sounds good |
| 01:43:31 | amiconn | However, tst + not-taken branch + smmul is even one cycle more than just using umull |
| 01:44:58 | Unhelpful | amiconn: the reciprocal won't have the sign bit set, and the test ensures that the numerator does not either. this benches faster on beast, but whether it's faster in practice probably depends on the frequency with which the branch is taken. |
| 01:45:02 | | Quit Tomis (Read error: Connection reset by peer) |
| 01:45:26 | saratoga | oh shit plugged my ipod into a sansa USB cable |
| 01:45:52 | amiconn | I understand what the test does, however, I would expect umull to be faster here, as it doesn't need the test + branch |
| 01:46:38 | saratoga | strange that they fit so well |
| 01:46:43 | Unhelpful | also both test and branch should fit into result delays for multiplies - the smmla uses the result of the mul, which means it can't execute for 3c (iirc) after the mul completes. |
| 01:48:05 | | Quit Farthen (Read error: Connection reset by peer) |
| 01:48:14 | Unhelpful | and the smmla result is used in the following smmul, so the smmul will block for 3c if reached as well |
| 01:48:49 | Unhelpful | but unless i've misunderstood the arm1136 manual and ASDG the tst and bmi can execute without penalty during these delays? |
| 01:49:31 | amiconn | Hmm, that is true |
| 01:50:02 | Unhelpful | i should probably remove the note about this being an APE-specific optimization as well... from what i see it should be successful as long as the branch is not taken *too* often and is predicted successfully most of the time. |
| 01:50:17 | amiconn | This whole streak of multiplications depending on each other's result is rather bad for the arm11 pipeline |
| 01:50:19 | | Join Tomis [0] (~Tomis@70.134.99.142) |
| 01:51:18 | amiconn | What I don't understand as well is why this case would only account for 1 in 10^7 cases |
| 01:51:22 | Unhelpful | it is, but it give me lots of places to put tests and branches for special cases. |
| 01:51:47 | Unhelpful | ah, well, it does on APE (i counted) which is why i said i should remove the note about this being APE-specific. |
| 01:52:17 | amiconn | hmm |
| 01:52:39 | amiconn | I would expect this to occur much more often with random test data |
| 01:54:31 | Unhelpful | the test set my benchmark uses isn't random, either.... but are neither are most actual divisions, and i suspect that in typical uses sign bit is set <50% of the time. values in actual use are probably more likely to be evenly distributed among lengths than across all possible values |
| 01:57:07 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 01:58:19 | Unhelpful | but even if the branch is taken exactly half of the time, it shouldn't be a *huge* expense... ASDG gives branch as taking 1c on correct prediction, 4c on incorrect prediction, but it's in a 3c delay slot already. also the failed-prediction case is given as needing flags 2c early, but since the smmla between tst and bmi is a 2c instruction, that should be satisfied as well. |
| 02:00 |
| 02:00:36 | Unhelpful | the test set i used for benchmarks consists of 1-bit, 2-bit, 3-bit, etc up to 32-bit values, one of each, and each repeated at each possible left-shift position... so there is exactly 1 1-bit value in the set, 2 2-bit values, 3 3-bit values, etc. the benchmark divides every possible combination of values in the set. i could easily run with a pre-generated array of random numbers, instead, though. |
| 02:08:32 | | Quit moos (Ping timeout: 260 seconds) |
| 02:12:35 | Unhelpful | there's also another way to handle the "main" division path (the one followed if none of the special-case branches occur). a goldschmidt divider takes two multiplies per iteration, but they can be done independently. this should reduce stalling on arm11 and should be almost free of stalls on arm9e, and can use the same initial-estimate table as the N-R version (and therefore the same trick of using the estimate-table value directly for |
| 02:12:35 | Unhelpful | large enough divisors). |
| 02:13:50 | Unhelpful | *however* goldschmidt does not converge as quickly as N-R - two iterations are required to get as good an approximation, and the second one would need to use umull on arm9e. |
| 02:17:07 | Unhelpful | if it's placed carefully perhaps a test/branch could cheaply avoid the second iteration when the divisor is the right size. i never got to tuning the goldschmidt divider that finely, and then the implementation got lost (i hadn't committed what i *thought* i had comitted) |
| 02:18:09 | | Quit komputes (Remote host closed the connection) |
| 02:29:53 | | Quit GeekShadow (Read error: Connection reset by peer) |
| 02:34:29 | | Quit kimi-sharamin (Read error: Connection reset by peer) |
| 02:35:30 | | Join Kitr88 [0] (~Kitr88@BSN-182-6-34.dial-up.dsl.siol.net) |
| 02:36:30 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
| 02:37:19 | | Quit kugel (Remote host closed the connection) |
| 02:37:58 | Unhelpful | funman: i modified your test to print amount written every 256B while writing to iram. it never prints anything. now trying with print every iteration... |
| 02:38:18 | Unhelpful | hangs after writting 0x20 bytes |
| 02:38:35 | | Quit Kitar|st (Ping timeout: 252 seconds) |
| 02:40:28 | | Quit Kitr88 (Ping timeout: 272 seconds) |
| 02:45:36 | | Join Kitar|st [0] (Kitr88@BSN-142-90-236.dial-up.dsl.siol.net) |
| 02:46:02 | Unhelpful | the last address it writes to successfully seems to be 0x81000018 |
| 02:49:09 | | Quit archivator (Quit: Leaving) |
| 02:51:22 | Unhelpful | leavittx: *real* 3d accel support? or only some 2D blend/blit/scale stuff like the beast's IPU can do? if it can draw textured tris or quads, even with only 2D coordinates, that might at least be something to start with. |
| 02:56:56 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:04:59 | CIA-8 | New commit by uchida (r24782): commit FS #10424 and FS #10425 ... |
| 03:07:56 | | Join ucchan [0] (~ucchan@softbank219205175105.bbtec.net) |
| 03:11:12 | | Part fleebailey33 |
| 03:15:56 | ucchan | Thereis a question. My task(FS #10424, FS #10425) cannot be close because the authority doesn't exist. |
| 03:16:00 | ucchan | How should I do to close my task? |
| 03:19:51 | | Quit nimak (Ping timeout: 256 seconds) |
| 03:22:58 | | Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) |
| 03:23:08 | | Join nima [0] (~nima@adsl-75-45-231-54.dsl.sfldmi.sbcglobal.net) |
| 03:24:32 | | Quit ps-auxw (Ping timeout: 248 seconds) |
| 03:25:04 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
| 03:26:28 | | Quit robin0800 (Client Quit) |
| 03:26:55 | | Join robin0800 [0] (~quassel@genkt-050-078.t-mobile.co.uk) |
| 03:27:45 | Unhelpful | ucchan: are they committed, or is there some reason they ought to be rejected without further consideration? |
| 03:42:08 | | Quit GodEater (Ping timeout: 248 seconds) |
| 03:43:12 | | Quit robin0800 (Remote host closed the connection) |
| 03:44:11 | ucchan | I committed the patch that exists in these tasks, then I want to close them. |
| 03:44:51 | | Quit Adnyxo (Quit: Leaving) |
| 03:48:00 | | Quit ps-auxw (Ping timeout: 248 seconds) |
| 03:50:53 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
| 03:52:16 | | Quit ucchan (Quit: Leaving...) |
| 03:57:39 | | Join Schmogel [0] (~Miranda@p3EE214B2.dip0.t-ipconnect.de) |
| 04:00 |
| 04:05:21 | Unhelpful | ah... you probably need developer rights on the tracker |
| 04:09:38 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.227) |
| 04:11:40 | | Quit TheSeven (Disconnected by services) |
| 04:11:53 | | Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) |
| 04:12:03 | | Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) |
| 04:16:18 | | Quit phanboy4 (Read error: Connection reset by peer) |
| 04:20:57 | | Quit mikroflops (Remote host closed the connection) |
| 04:21:04 | | Join mikroflops_ [0] (~yogurt@217-208-157-242-no112.tbcn.telia.com) |
| 04:26:37 | | Quit Schmogel (Read error: Connection reset by peer) |
| 04:33:53 | | Join DerPapst1 [0] (~DerPapst@p4FE8E8D8.dip.t-dialin.net) |
| 04:35:39 | tmzt | saratoga: do you know what pins are different? I'm considering getting a radio with dtwo docks but want sansa and a touch to work. it would also be interesting to see AAP support on the sansas |
| 04:36:01 | | Quit DerPapst (Ping timeout: 248 seconds) |
| 04:41:49 | | Quit efyx_ (Remote host closed the connection) |
| 04:43:20 | | Quit S_a_i_n_t (Quit: There are 10 types of people, those who understand binary, and those who don't.) |
| 04:45:48 | | Quit MethoS- (Remote host closed the connection) |
| 04:46:31 | | Join Barahir [0] (~jonathan@gssn-5f754de5.pool.mediaWays.net) |
| 04:49:55 | | Quit Barahir_ (Ping timeout: 252 seconds) |
| 04:51:39 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.1) |
| 04:53:39 | | Nick jfc^2 is now known as jfc (~john@dpc6682208002.direcpc.com) |
| 04:54:56 | | Quit DerPapst1 (Quit: Leaving.) |
| 04:57:00 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:05:01 | | Quit ecio (Quit: Colloquy for iPhone - http://colloquy.mobi) |
| 05:05:29 | | Join ecio1 [0] (~Moo@244-108.202-68.tampabay.res.rr.com) |
| 05:07:44 | leavittx | Unhelpful: I don't know details. Even google didn't helped me. But it seems to me that real. :) |
| 05:09:30 | | Part froggyman |
| 05:50:09 | | Quit tmzt (Ping timeout: 248 seconds) |
| 05:51:05 | | Join tmzt [0] (~tmzt@adsl-99-164-34-42.dsl.akrnoh.sbcglobal.net) |
| 05:51:45 | | Quit shai_ (Ping timeout: 248 seconds) |
| 06:00 |
| 06:00:54 | | Nick ecio1 is now known as ecio (~Moo@244-108.202-68.tampabay.res.rr.com) |
| 06:31:43 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
| 06:35:29 | Unhelpful | amiconn: i tried replacing the 528 selected values with 528 random ones. handling large numerators in a separate branch is still faster, though only marginally. the random values were generated in python, which uses MT, so they should be quite random enough. |
| 06:56:01 | | Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) |
| 06:57:04 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:04:08 | | Join CPICH_ [0] (~Moo@244-108.202-68.tampabay.res.rr.com) |
| 07:05:28 | | Quit ecio (Ping timeout: 246 seconds) |
| 07:17:58 | | Join ecio [0] (~ecio@32.130.89.182) |
| 07:18:55 | | Quit CPICH_ (Ping timeout: 245 seconds) |
| 07:21:33 | | Quit nima (Read error: Connection reset by peer) |
| 07:21:34 | | Join nimak [0] (~nima@adsl-75-45-231-54.dsl.sfldmi.sbcglobal.net) |
| 07:24:35 | | Join moos [0] (moos@rockbox/staff/moos) |
| 07:27:19 | | Quit martian67 (Ping timeout: 268 seconds) |
| 07:29:27 | CIA-8 | New commit by unhelpful (r24783): Clarify comments in ARMv6 divider regarding special-case handling of large (high bit set) numerators. |
| 07:35:14 | | Join Horschti [0] (~Horscht2@xbmc/user/horscht) |
| 07:39:02 | | Quit Horscht (Ping timeout: 268 seconds) |
| 07:39:13 | | Join Guest88353 [0] (~martian67@over.the.cat) |
| 07:42:48 | CIA-8 | New commit by tomers (r24784): Comment out lcd_drawline() DEBUGF messages which show in various simulators |
| 07:46:00 | | Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 07:49:35 | | Quit CaptainKwel (Ping timeout: 252 seconds) |
| 07:54:45 | | Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 08:00 |
| 08:03:00 | | Join stoffel [0] (~quassel@p57B4D107.dip.t-dialin.net) |
| 08:05:35 | | Quit liar (Ping timeout: 245 seconds) |
| 08:09:59 | amiconn | tomers: Those debug messages were there for a reason. |
| 08:10:23 | tomers | amiconn: what what the reason? |
| 08:10:56 | tomers | amiconn: s/what/was/ |
| 08:11:03 | amiconn | Several plugin developers just used lcd_drawline() in places where they should have used lcd_hline() or lcd_vline() for performance reasons |
| 08:11:39 | tomers | amiconn: Should the 'user' of the simulator have to see all these debug messages? |
| 08:11:46 | amiconn | Those plugins showed *massive* output from these messages, so I was able to find and fix them |
| 08:12:20 | amiconn | I left those messages in place in case it will happen again |
| 08:12:40 | tomers | but it does happen often today |
| 08:12:58 | tomers | does those prints indicate something is wrong? |
| 08:13:12 | tomers | or need to be addressed to? |
| 08:13:46 | tomers | you use the simulator for your own reasons and then you get all that debug output which seems irrelevant... |
| 08:13:58 | amiconn | Of course there are some calls to lcd_drawline() which do *occasionally* show this message (because a random line is exactly horizontal or vertical by coincidence) |
| 08:14:29 | tomers | so do you want me to revert? |
| 08:14:56 | tomers | don't we need to keep the simulator output clean? |
| 08:15:15 | amiconn | The latter is unfortunately unavoidable for this optimisation hint, the former is something that should be fixed in the plugin |
| 08:16:17 | amiconn | Why should we need to keep the simulator out put clean? The simulator is meant for developers, and debug output should point out problems |
| 08:17:03 | tomers | yeah but most developers want the output to show whatever is relevant for them. |
| 08:17:22 | amiconn | The question is whether this optimisation hint should be kept enabled all the time, but if you really found plugins which output lots of those messages, you should rather check those plugins whether they can be optimized... |
| 08:17:22 | tomers | they don't want to get usb messages, lcd messaged, storage messages, etc. |
| 08:19:16 | tomers | i think that most developers (like me) are not aware of that, and even if they see it they don't really know it is a hint for them to use lcd_[vh]line for optimisation. I guess that from time to time someone should enable these messages and review all plugins |
| 08:19:34 | tomers | but that's not going to happen, i guess |
| 08:20:16 | tomers | maybe i'll wrap these messages with #ifndef HIDE_LCD_LINE_WARNING or something? |
| 08:21:19 | amiconn | Nah. There are already more than enough ifdefs |
| 08:21:24 | tomers | so i guess i should revert this commit so that these messages will show by default? |
| 08:22:28 | amiconn | Hmm. I would tend to say yes, but your other concern is also valid. |
| 08:23:02 | amiconn | I wonder if there are other similar debugging aids which are forgotten by now because they're disabled |
| 08:23:43 | amiconn | (this one is an optimisation hint though, it doesn't point out functional bugs) |
| 08:25:01 | amiconn | Do you remember which plugins printed this message a lot? |
| 08:25:21 | tomers | amiconn: maybe we should re-enable these prints, and change the message to something like '<filename>:<line>: consider using lcd-[hv]line instead...', and use a single macro for that |
| 08:25:33 | tomers | amiconn: I can't remember. sorry. |
| 08:26:12 | amiconn | What would 'filename' and 'line' be? |
| 08:26:24 | tomers | __FILENAME__ and __LINE__ |
| 08:27:02 | tomers | e.g. firmware/drivers/lcd-16bit-vert.c:361 |
| 08:27:21 | amiconn | Those would always be the same for a certain sim, e.g. lcd-16bit.c and 354 or 361 |
| 08:28:34 | amiconn | But that would be misleading imo. The caller (e.g. a plugin) should use the specialised versions if possible |
| 08:28:55 | tomers | Current message, "lcd_drawline() called for vertical line - optimisation.\n" is rather confusing. 'optimisation' sounds like it notifies you of an optimisation that took place, not that you should consider using other function for performance reasons. |
| 08:29:31 | amiconn | It does both |
| 08:30:01 | tomers | oh |
| 08:30:14 | tomers | I don't understands ^^^, can you elaborate? |
| 08:30:51 | amiconn | lcd_drawline() takes this optimisation, and notifies you that you can save the decision overhead if you call lcd_hline() and lcd_vline() directly |
| 08:31:47 | tomers | i got that part, but I didn't get what you said about the caller (e.h. a plugin), do you mean that it should print "bubbles:100" instead of lcd-16bit.c:200 ? |
| 08:31:58 | Unhelpful | it looks like goldschmidt can produce an inverse in 4 multiplies, the same number as newton-raphson. pros: multiplies in goldschmidt are on two values and can be carried out (somewhat) independently, for large-enough divisors we could potentially do one iteration instead of two. cons: there are some shifts require between iterations if we don't want to see performance destroyed. |
| 08:31:59 | tomers | s/bubbles/bubbles.c/ |
| 08:32:25 | amiconn | Yes that's what I meant, but afaik this is not possible |
| 08:33:28 | Unhelpful | amiconn: it's *somewhat* possible - wrap lcd_drawline in a macro of the same name that tests and prints the message. since the macro exists at the callsite it should output the correct filename/line. |
| 08:34:06 | amiconn | But the idea of printing the location where a debug message comes from is good, imo. |
| 08:34:23 | amiconn | It makes it easier to identify them if you know where they come from |
| 08:35:51 | amiconn | Unhelpful: (1) That won't work for plugins though, as they are loaded dynamically |
| 08:36:04 | amiconn | s/\(1\)// |
| 08:36:13 | * | Unhelpful will try implementing goldschmidt in arm asm again and see where it gets him |
| 08:36:46 | Unhelpful | amiconn: i wonder what happens if you try to #define rb->lcd_drawline(...) ... nothing nice probably. |
| 08:37:15 | amiconn | I would expect that the preprocessor complains |
| 08:37:32 | amiconn | - and > are not valid in macro names afaik |
| 08:37:51 | Unhelpful | indeed they're not. |
| 08:39:01 | amiconn | Hmm. Enabling the debug messages now is more difficult than disabling them if they're enabled by default |
| 08:39:10 | Unhelpful | you could also have lcd_drawline take the filename and line number as args on simulator builds, and then the same define would work for plugins. |
| 08:40:01 | Unhelpful | ie #define lcd_drawline(args) lcd_drawline(args, __FILENAME__, __LINE__) |
| 08:41:51 | amiconn | Not always |
| 08:42:38 | amiconn | There are plugins which call lcd_drawline() via a function pointer |
| 08:42:50 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:43:46 | amiconn | At least these plugins are calling several lcd_* functions via pointer - I'm not sure whether lcd_drawline() is among those. |
| 08:47:14 | | Nick kaniini is now known as knine (~kaniini65@dyn75-70.yok.fi) |
| 08:56:45 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 08:57:07 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:02:08 | Unhelpful | the cutoff point for stopping at 1 goldschmidt iteration appears to be divisors >= 0x9e000 (that's the smallest such cuttoff that is a valid arm immediate, anyway). |
| 09:05:05 | | Join flydutch [0] (~flydutch@host154-132-dynamic.15-87-r.retail.telecomitalia.it) |
| 09:09:21 | | Quit CaptainKewl (Ping timeout: 272 seconds) |
| 09:19:22 | leavittx | Devs: why didn't you finally swiched to git? |
| 09:19:45 | leavittx | The git mirror of svn is nice, but... |
| 09:21:53 | Unhelpful | leavittx: serial numbering of revisions for one thing - you can always tell if one build is newer/older than another. and it's already svn. and devs who want to use git already can - it's not like being able to git push would be so very much easier than git svn dcommit. |
| 09:22:05 | Unhelpful | also i believe the majority of devs prefer to use svn |
| 09:23:06 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 09:23:59 | | Join TopyMobile_ [0] (~topy@f048242082.adsl.alicedsl.de) |
| 09:27:47 | | Quit TopyMobile__ (Ping timeout: 256 seconds) |
| 09:44:11 | | Quit tomers (Ping timeout: 272 seconds) |
| 09:48:26 | * | pixelma wonders if USB HID should really be enabled by default |
| 09:50:31 | pixelma | after experiencing myself that some OSs can't cope with it (which is why the option to turn it off was implemented) and reading some reports from other people, I start thinking that the default should be off - at least for the release |
| 09:51:24 | | Quit Zarggg (Ping timeout: 264 seconds) |
| 09:52:06 | pixelma | HID is a plus and I never heard of any other MP3 players that offers it, whereas USB data connection is something everyone expects to be working |
| 10:00 |
| 10:06:58 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 10:14:27 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 10:16:18 | ThomasAH | pixelma: I don't know about the effects of having the player as HID, but the hard disc accelerometer being presented as a joystick device caused some troubles for me on LInux |
| 10:17:16 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 10:27:05 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 10:37:20 | leavittx | Why doesn't rb->lcd_clear_display(); clear display after rb->splash? |
| 10:39:24 | leavittx | ok, how to clear display after rb->splash()? |
| 10:39:41 | amiconn | You need to update afterwards |
| 10:40:27 | amiconn | lcd_clear_display() only changes the framebuffer, like all lcd_* drawing functions |
| 10:43:29 | leavittx | amiconn: what do you mean by "update afterwards"? |
| 10:43:47 | | Join DerPapst [0] (~DerPapst@p4FE8F6DE.dip.t-dialin.net) |
| 10:44:19 | stripwax | lcd_update() |
| 10:48:49 | * | stripwax doh's - new MDCT doesn't have an icode_attr - that'll give an extra MHz-or-so bonus.. |
| 10:49:36 | leavittx | stripwax: you mean rb->lcd_update, right? Not helps. Look smb on my code plz: http://dpaste.org/Wuww/ |
| 10:50:42 | stripwax | leavittx - I don't see you calling rb->lcd_clear_display - you need to call both lcd_clear_display AND lcd_update, right? |
| 10:51:04 | leavittx | ah |
| 10:51:06 | stripwax | I don't know what "look smb on my code plz" means. Please use real words in this channel, helps. |
| 10:51:57 | leavittx | Sorry, will not repeat anymore :-\ |
| 10:53:55 | | Join m3dlg [0] (~m3dlg@212.183.140.53) |
| 10:57:10 | *** | Saving seen data "./dancer.seen" |
| 10:58:17 | stripwax | looks like wma about 5.5Mhz faster on coldfire (h120) with icode_attr in new mdct. will double check vs unchanged, but can't believe we missed that! |
| 11:00 |
| 11:00:04 | bertrik | Nice! |
| 11:00:45 | stripwax | in fact it can *almost* run unboosted at 40Mhz at 96kbps .. |
| 11:00:55 | leavittx | Question: after calling lcd_clear_display() display becomes black. How do I restore normal rockbox background with logo? |
| 11:10:45 | | Quit m3dlg (Ping timeout: 240 seconds) |
| 11:11:35 | stripwax | leavittx - if you can think of another (existing) rockbox plugin that has the behaviour that you want to copy, then you can look at the sourcecode for that other plugin and see how it is done.. |
| 11:12:55 | pixelma | I guess you have to keep an eye on the drawmodes (and foreground/background definitions) |
| 11:15:38 | CIA-8 | New commit by uchida (r24785): libpcm: linear pcm decode logic separates according to each bitspersample, endian, and signess. |
| 11:24:36 | | Quit stoffel (Remote host closed the connection) |
| 11:50:46 | stripwax | correction - it runs almost unboosted at 40Mhz at *128* kbps. h120 wma at 96kbps only 37MHz |
| 11:52:10 | | Join Buschel [0] (~ab@p54A3B16E.dip.t-dialin.net) |
| 11:52:21 | Buschel | stripwax: \o/ |
| 11:52:42 | Buschel | stripwax: what clock was needed before mdctexp? |
| 11:54:46 | stripwax | Buschel - 43Mhz or more I think. I actually don't think I still have those timings to hand though :( |
| 11:55:02 | stripwax | That's 43Mhz for 96kbps. |
| 11:55:42 | stripwax | I'm tempted to do a rebuild of the old code and put a definitive comparison on the wiki page .. |
| 11:58:24 | Unhelpful | hrm, so the estimated division result may be low by as much as 2, or high by as much as 1. wonder how best to correct that... |
| 11:59:28 | stripwax | Excellent, ICODE gives us another 0.5Mhz boost on arm also. So 96kbps on ipod video now 24.99MHz :) |
| 11:59:38 | stripwax | committing.... |
| 12:00 |
| 12:00:19 | CIA-8 | New commit by stripwax (r24786): Adding ICODE for imdct (and its constituent ifft bits) gives 0.5MHz boost on arm (ipod video) and about 5MHz boost on coldfire (H120) |
| 12:01:42 | stripwax | that svn comment really makes no sense at all, sorry. 0.5MHz boost on ipod vorbis, and 5MHz on h120 wma. |
| 12:02:10 | stripwax | (measuring ipod wma improvement now, suspect minimal though) |
| 12:02:18 | Buschel | stripwax: the results are really impressive! :o) |
| 12:02:20 | Buschel | good work! |
| 12:02:41 | stripwax | thanks! |
| 12:03:21 | * | Buschel needs to optimize mpc again to keep the performance headroom to "other" codecs :) |
| 12:13:02 | stripwax | Buschel - according to this, we're now a clear 2MHz faster on coldfire vorbis, and 7MHz faster on coldfire wma, versus 3 months ago. http://www.rockbox.org/wiki/CodecPerformanceComparison |
| 12:13:33 | stripwax | a bit surprised that coldfire vorbis hasn't seen as big an improvement, but I have a suspicion about that (revtab being in ram not iram..) |
| 12:15:50 | | Quit bertrik (Ping timeout: 276 seconds) |
| 12:19:06 | | Join m3dlg [0] (~m3dlg@212.183.140.2) |
| 12:19:29 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 12:19:46 | kugel | stripwax: I think most of the time you should s/arm/PP/ |
| 12:21:06 | Unhelpful | have you tested on arm9tdmi, arm9e, and arm11? arm9tdmi has 1c loads (with delayed result availability) and arm9e/arm11 have the 2c multiplier w/ respectively 1c and 2c delay for result after the multiply completes execution |
| 12:21:54 | stripwax | kugel - probably right, good point |
| 12:22:11 | Unhelpful | on all three you can benefit from loading data well before it's needed, and on the last two putting in non-dependent ops around multiplies will help |
| 12:22:21 | stripwax | Unhelpful - nope. I have tested only on the targets I have access to (h120 and ipod video). Can you, please? |
| 12:22:54 | stripwax | luckily I didn't hand-optimise *everything*, so gcc should be able to do some suitable scheduling |
| 12:23:30 | | Quit m3dlg (Ping timeout: 245 seconds) |
| 12:24:00 | Unhelpful | stripwax: i'll try to find time this weekend, then. there aren't any very-working arm9e targets, and i don't have any arm9tdmi, but i can benchmark on the beast... just checkout the mdct_exp branch and build? |
| 12:24:46 | kugel | it's in trunk now I believe |
| 12:24:56 | stripwax | yep, it's all in trunk... |
| 12:25:21 | stripwax | so you'd probably be best to test_codec before you upgrade (or build an old version, or something) |
| 12:25:39 | Unhelpful | oh... hrm, i assume we made sure it was at least not slower on non-PP before moving it to trunk? ;) |
| 12:25:57 | Unhelpful | if you pester somebody w/ nano2g i believe that's arm9tdmi |
| 12:26:14 | stripwax | Yes, we made sure it was faster on both PP and coldfire (I tested h120 and I believe someone else tested H340) |
| 12:26:38 | Unhelpful | yes, but not all ARM targets are PP ;) |
| 12:26:38 | stripwax | Unhelpful - oh, cool! |
| 12:27:02 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 12:27:09 | stripwax | TheSeven - would you be able to check test_codec performance on nano2g versus a few revisions ago? (i.e. before mdctexp committed to trunk)? |
| 12:27:13 | kugel | fx and samsa are 9tdmi also |
| 12:27:25 | stripwax | Unhelpful - right. saratoga tested some kind of e2x0 |
| 12:27:31 | stripwax | I don't know if that's pp |
| 12:27:55 | TheSeven | stripwax: sure, if you can name me an exact revision number that i should test |
| 12:28:16 | Unhelpful | if you look in tools/configure targets that are arm9xx*bunchofjunk*e are arm9e, other arm9 targets are arm9tdmi |
| 12:28:26 | | Join Omlet [0] (omlet05@76.152-242-81.adsl-dyn.isp.belgacom.be) |
| 12:29:17 | TheSeven | and can anybody point me to a link to those codec test files? they are being referred to on the codec performance page, but there is no link (or i didn't find it) |
| 12:29:39 | amiconn | Unhelpful, stripwax: ARM9e is e.g. Cowon D2, and the D2 is usable for this kind of tests |
| 12:29:42 | stripwax | TheSeven - fab. ok so r24786 versus r24711 (although I see some nano2g fixes put in after 24711 so I don't know if 24711 works for you) |
| 12:29:45 | kugel | thegeek: http://download.rockbox.org/test_files/ |
| 12:29:59 | stripwax | ^theseven |
| 12:30:07 | TheSeven | ah, i did miss the underscore when guessing :-) |
| 12:30:12 | amiconn | Afaik the D2 can even be used to play music from SD, just the internal flash isn't usable (ftl missing) |
| 12:30:22 | kugel | thegeek: sorry :( |
| 12:30:45 | stripwax | anyone other than shotofadds have a D2? |
| 12:30:47 | Unhelpful | amiconn: that might need some fixing to test_codec? doesn't it always write logs in /? |
| 12:30:47 | TheSeven | stripwax: should all be minor stuff (power management etc.) |
| 12:30:53 | stripwax | or, shotofadds, if you're listening.. |
| 12:31:01 | stripwax | TheSeven - ah ok |
| 12:31:08 | amiconn | Unhelpful: Well, gevaerts did several tests on D2 for me already |
| 12:31:20 | kugel | stripwax: tomers, gevaerts and Llorean have one |
| 12:31:22 | amiconn | And ARM9 v4 can be tested on Gigabeat F/X |
| 12:31:39 | | Join stoffel [0] (~quassel@p57B4D107.dip.t-dialin.net) |
| 12:31:44 | Unhelpful | amiconn: remind me to bother him about these dividers, he needs more excuses to make up division puns, anyway :) |
| 12:32:12 | Unhelpful | although i guess i can benchmark them well enough on clipv2, just not via the plugin i wrote for it. |
| 12:32:32 | TheSeven | stripwax: should i test with/without eabi? |
| 12:32:41 | amiconn | Keep in mind that the D2 has no iram (actually it does, but afaik nobody found out how to use it properly) |
| 12:32:57 | stripwax | TheSeven - whatever works best for you. I didn't use eabi |
| 12:33:03 | amiconn | So no small-dividers special table... |
| 12:33:06 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 12:33:43 | TheSeven | stripwax: they both work fine - so i'll probably do all 4 combinations, so that we also have a result whether eabi makes a difference |
| 12:33:46 | | Join TheSphinX^ [0] (~cold@p54A5BBEB.dip.t-dialin.net) |
| 12:33:50 | Unhelpful | amiconn: we don't use that on arm9e anyway |
| 12:33:57 | amiconn | Gigabeat F/X also uses no iram - iirc the reasoning was that it's too small to be of use on swcodec |
| 12:34:30 | kugel | 4k only |
| 12:34:44 | amiconn | Iirc the S3C2440 has 4KB of IRAM. On SH1, which has the same amount, we do use it though - and it's very beneficial |
| 12:34:57 | amiconn | But then SH1 has no cache |
| 12:35:20 | kugel | maybe it's used for target specific stuff, I can imagine rolo runs from it |
| 12:35:31 | TheSeven | that s3c2440 actually is only present because they need it as as steppingstone buffer :-) |
| 12:35:48 | Unhelpful | the only divider specialization for APE on arm9e/arm11 is that if there's iram a copy of the divider goes there and is used by the UDIV macro |
| 12:35:54 | TheSeven | that iram on* |
| 12:39:22 | amiconn | It's very interesting that the benefit of using ldm varies wildly between arm versions and variants |
| 12:39:53 | amiconn | On arm7tdmi it is *very* useful in that a single load takes 3 cycles, whereas ldm takes n+2 cycles |
| 12:39:55 | Unhelpful | initially i wrote the branch-for-large-numerator optimization only for APE, because i knew it would be so rarely taken there... but it turned out to bench faster in general as well. |
| 12:40:10 | | Quit ecio (Ping timeout: 245 seconds) |
| 12:40:49 | amiconn | On arm9 (both v4 and v5) this advantage (almost) vanishes as a single load is 1 cycle (as long as you don't use it in the next cycle), and ldm is n cycles |
| 12:40:56 | amiconn | Of course it still reduces code size |
| 12:41:50 | amiconn | On armv6 it becomes very useful again, because a single load is 1 cycle, and ldm is *also just one cycle, as the fetches happen in the background |
| 12:42:27 | amiconn | Of course this needs proper design wrt latencies |
| 12:43:07 | stripwax | the bulk of the arm-specific code is optimising register (re)usage and ldm/stm - but since it was tested for arm7tdmi I don't know what impact will be on arm9/arm6 - sounds like there could be some scheduling problems if I ldm followed by using it immediately |
| 12:43:55 | TheSeven | damn, my internet connection is faster than copying the test files to the ipod |
| 12:44:17 | amiconn | Iirc I squeezed quite a bit of performance out of the ape predictor on armv6 by just reordering instructions, without negative impact on the earlier arm versions |
| 12:44:50 | Unhelpful | reordering doesn't really matter to arm7... and only barely to arm9tdmi |
| 12:45:46 | Unhelpful | and i don't think reordering that will help arm9e/arm11 will ever hurt arm9tdmi, will it? |
| 12:45:54 | amiconn | Ah yes - r19210; 20% speedup |
| 12:46:01 | kugel | stripwax: what files would I test? |
| 12:46:03 | stripwax | what targets use armv6? |
| 12:46:04 | amiconn | No it shouldn't |
| 12:46:05 | stripwax | kugel - ? |
| 12:46:12 | kugel | for the mdct comparison |
| 12:46:12 | amiconn | stripwax: Just Gigabeat S |
| 12:46:18 | stripwax | ah |
| 12:47:22 | kugel | stripwax: I mean which type of files are relevant for this? |
| 12:47:39 | kugel | wma,ogg. what else? |
| 12:47:45 | stripwax | kugel - Start with vorbis and wma for now, just for ease of comparison |
| 12:48:30 | stripwax | really all that use the mdct are relevant. so atrac3, cook, a52. But I don't know how well those are represented in the existing test_files downloadable stuff |
| 12:53:55 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 12:57:13 | *** | Saving seen data "./dancer.seen" |
| 12:58:28 | | Quit kugel (Ping timeout: 265 seconds) |
| 13:00 |
| 13:00:08 | TheSeven | erm, does make reconf lose the information that a build dir is supposed to use eabi? |
| 13:00:43 | | Join Farthen [0] (~chatzilla@p50988dd0.dip0.t-ipconnect.de) |
| 13:04:25 | TheSeven | ok, after some build problems, test_codec is finally running. on r24711-noeabi for now |
| 13:05:43 | TheSeven | 64kaahce roughly realtime, does that make sense, or are we having boosting problems again? |
| 13:06:41 | TheSeven | 190.13 MHz |
| 13:08:29 | | Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) |
| 13:09:37 | TheSeven | grr, doom fails to build again |
| 13:14:03 | TheSeven | ape c2000: 66.4 MHz, ape c4000: 301.16 MHz |
| 13:16:27 | TheSeven | c3000: 102.7 MHz |
| 13:16:52 | * | amiconn wonders how large the filter coefficients in demac can become |
| 13:16:55 | stripwax | TheSeven - can you try vorbis and wma first please - ape doesn't use mdct so wouldn't have any delta to pre-mdctexp changes |
| 13:17:23 | amiconn | If 15 bits were enough, the swar stuff could be sped up |
| 13:17:27 | * | stripwax tries to fix red - atrac3 iram full on a handful of targets |
| 13:18:00 | amiconn | (for armv5) |
| 13:18:51 | | Join kugel [0] (~kugel@e178088187.adsl.alicedsl.de) |
| 13:18:55 | | Quit kugel (Changing host) |
| 13:18:55 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 13:19:07 | kugel | stripwax: old: http://pastie.org/834085 ; new: http://pastie.org/834086 |
| 13:19:20 | amiconn | Oh, and for coldfire too of course |
| 13:19:54 | stripwax | kugel - cheers - remind me what target that is for? |
| 13:20:00 | kugel | fuze |
| 13:20:15 | kugel | I can't test higher bitrates due to limited ram (and the fact that test_codec doesn't handle it) |
| 13:20:29 | kugel | but it's at least 3-4MHz faster |
| 13:23:31 | | Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 13:24:25 | | Quit stripwax (Ping timeout: 240 seconds) |
| 13:24:45 | | Quit anewuser (Quit: http://xrl.us/WinterChipV =ooo ϢINTER ϾHIP 5iVE is OOON!!) |
| 13:25:14 | Buschel | stripwax: regarding reds caused by iram in atrac3 -> try to remove iconst_attr for several array in atrac3data_fixed.h, but keep window_loopup[]. |
| 13:27:05 | stripwax_ | Buschel - yep, I can do that, but unfortunately I don't have a target to test/compare. But I'll do whatever is needed for it to continue to build .. |
| 13:27:25 | Buschel | stripwax: if this still isn't sufficient, define the iram usage for imdct in a way that it is only used on targets with large iram (like PP5022) |
| 13:27:27 | | Quit AlexP (Remote host closed the connection) |
| 13:28:33 | stripwax_ | BUschel - I'm (re)using the same define that was already in place for the old mdct (the Tremor one). So it's already defined per-target, etc. I don't want to change that unless I really have to. |
| 13:29:15 | stripwax_ | after all, all of the other codecs are fine, and iram is a major speedup for wma for example. so I'd rather just hobble atrac3 rather than hobble any other codecs. |
| 13:29:43 | stripwax_ | atrac3 still needs more optimising, anyway |
| 13:30:08 | Buschel | stripwax_: that's right |
| 13:31:33 | Buschel | hmm, it is only red for PP's, right? |
| 13:31:41 | stripwax_ | Buschel - building for a new target is so slow (on a netbook, running cygwin..) |
| 13:32:02 | stripwax_ | Buschel - I don't know about mrobe, vibe or the samsungs.. |
| 13:32:37 | Buschel | PP5020 |
| 13:33:02 | stripwax_ | I guess they all have a bit less iram than the 5022? |
| 13:33:10 | Buschel | yes |
| 13:33:23 | | Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 13:33:32 | Buschel | 96KB vs. 128KB |
| 13:33:37 | Buschel | quite a lot |
| 13:34:19 | stripwax_ | atrac3 only recently got changed to use the new imdct - and I suspect subsequently some ICODE/ICONST got added to atrac3 (when it should have been added to the imdct). |
| 13:34:51 | stripwax_ | anyway, when I've got a build that works, I'll commit the changes. I think atrac3 is all mt/saratoga right now |
| 13:34:54 | Buschel | it was :o) I did it :) |
| 13:35:02 | stripwax_ | oh! hahahaha |
| 13:35:31 | Buschel | I am also just starting to compile for h10... |
| 13:37:28 | Buschel | btw, I'm also buidling on a slow notebook... will take 10min |
| 13:40:20 | Buschel | got it compiling for h10 with a small change |
| 13:41:07 | | Quit Guest88353 (Read error: Operation timed out) |
| 13:41:41 | stripwax_ | ok cool. gain_tab1 looks a bit silly, by the way .. |
| 13:42:26 | stripwax_ | it's just 1<<(20-i) |
| 13:42:26 | Buschel | remove ICONST_ATTR for qmf_48tap_half_fix[], matrixCoeffs_fix[], channelWeights0[] and channelWeights1[9 |
| 13:42:49 | stripwax_ | Buschel - are they likely to have the least impact on speed? |
| 13:42:52 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 13:43:00 | | Quit kugel (Ping timeout: 264 seconds) |
| 13:43:30 | | Quit cjcopi (Ping timeout: 268 seconds) |
| 13:43:40 | Buschel | only matrixCoeffs_fix[] could have an impact for JointStereo files. all other are irrelevant |
| 13:44:54 | Buschel | ok, matrixCoeffs_fix[] can still be iram'ed for h10 |
| 13:44:54 | CIA-8 | New commit by stripwax (r24787): Remove ICONST_ATTR from some tables, to fit into PP5020 iram (now that mdct is in iram it's a bit of a squeeze). (per Buschel on irc) |
| 13:45:02 | stripwax_ | pah, too late! |
| 13:45:04 | stripwax_ | :) |
| 13:45:05 | Buschel | :) |
| 13:45:20 | Buschel | let's see what the tables will look like in a few minutes ;) |
| 13:46:05 | stripwax_ | I confirmed it built ok for ipod1g/2g |
| 13:46:22 | | Join Omlet05 [0] (omlet05@165.159-241-81.adsl-dyn.isp.belgacom.be) |
| 13:46:23 | Buschel | so, the chance is good |
| 13:46:36 | stripwax_ | I'm going to blow away gain_tab1 and replace it with 1<<(20-i) in the code, if no objections? |
| 13:49:07 | Buschel | no objections from my side. delete the array and readd ICONST_ATTR for the matrix-array :) |
| 13:49:15 | Buschel | re-add* |
| 13:49:25 | | Quit Omlet (Ping timeout: 276 seconds) |
| 13:49:36 | | Join Omlet [0] (omlet05@54.105-244-81.adsl-dyn.isp.belgacom.be) |
| 13:49:36 | Buschel | green :) |
| 13:49:53 | | Join Guest88353 [0] (~martian67@over.the.cat) |
| 13:51:03 | | Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 13:51:28 | | Join cjcopi [0] (~craig@charon.craig.copi.org) |
| 13:51:49 | stripwax_ | matrixCoeffs_fix also looks like a bit of a silly table.. does that really need to be a lookup? there's not a lot of information in it... |
| 13:52:16 | | Quit Omlet05 (Ping timeout: 260 seconds) |
| 13:52:16 | amiconn | What's the range of i? |
| 13:53:14 | amiconn | Depending on the stupidity of gcc, it might be better to use (1<<20) >> i |
| 13:53:15 | | Quit flydutch (Quit: /* empty */) |
| 13:53:42 | amiconn | But this requires i to be non-negative |
| 13:53:49 | stripwax_ | amiconn - I'm actually using (ONE_16<<4)>>i . which I think is consistent with what you said, as ONE_16 is defined as 1<<16 |
| 13:54:03 | stripwax_ | i is definitely no-negative (given that it was an index into a table?) |
| 13:54:13 | gevaerts | amiconn: actually, the D2 does have read-only ftl code that works fine for most people. It just doesn't have write support |
| 13:54:32 | stripwax_ | range is 0<=i<=15 |
| 13:55:30 | | Join TucknDar [0] (~Miranda@168.146.16.62.customer.cdi.no) |
| 13:55:38 | CIA-8 | New commit by stripwax (r24788): Reinstate ICONST_ATTR for matrixCoeffs_fix ; remove (silly) gain_tab1 and replace with a simple bitshift in the code |
| 13:56:05 | Buschel | stripwax_: as JointStereo decoding is still buggy I would like too keep those lookups until the code has been debugged. otherwise it becomes harder to find the error... |
| 13:56:14 | stripwax_ | which lookups? |
| 13:56:31 | amiconn | stripwax_: Yes it is |
| 13:56:39 | stripwax_ | Buschel - gain_tab1? |
| 13:56:55 | Buschel | stripwax_: the silly matrixCoeffs_fix[] |
| 13:57:24 | amiconn | A table index may be negative, depending on the table. Not common in C, but I'm using this in the SH1 bitswap |
| 13:57:30 | stripwax_ | Buschel - oh yeah, no problem with leaving that in place. That one at least has *some* information in it compared to gain_tab1 :) |
| 13:57:59 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 13:58:04 | stripwax_ | amiconn - the code was gain_tab1[ index ] and the code is now (1<<20)>>index |
| 14:00 |
| 14:02:07 | stripwax_ | amiconn - (I'm still struggling to see how a table index can be negative −− unless your table 'pointer' is something other than the start of the table, e.g. the middle) |
| 14:02:18 | stripwax_ | I guess I could read the SH1 bitswap to find out :) |
| 14:02:34 | amiconn | Yes, the table base is in the centre |
| 14:02:39 | stripwax_ | neat! |
| 14:03:14 | amiconn | This is because SH1 sign-extends by default. Making the table work this way saves a separate extend-unsigned instruction |
| 14:04:05 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 14:04:58 | amiconn | This table is defined in asm, but also used from C code on Ondio, and then the table index is an explicit 'signed char' |
| 14:05:29 | teru | JdGordon: ping |
| 14:06:01 | gevaerts | amiconn: that will need watching with new gcc versions |
| 14:10:32 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 14:13:23 | | Quit stripwax_ (Ping timeout: 265 seconds) |
| 14:13:34 | | Join ecio [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 14:14:56 | | Quit Guest88353 (Ping timeout: 268 seconds) |
| 14:16:58 | | Join Guest88353 [0] (~martian67@over.the.cat) |
| 14:24:44 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:25:31 | stripwax | TheSeven - did you get a chance to do test_codec on vorbis/wma ? |
| 14:25:57 | | Quit Buschel (Ping timeout: 265 seconds) |
| 14:26:52 | CIA-8 | New commit by tomers (r24789): WPS: Use helper local variable instead of its value (no functional change) |
| 14:28:12 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 14:28:16 | | Quit Frampis (Ping timeout: 240 seconds) |
| 14:28:21 | AlexP | tomers: Did you see the comments about your commit message yesterday? |
| 14:28:30 | | Quit Horschti (Ping timeout: 252 seconds) |
| 14:28:39 | | Join Frampis [0] (famas@noppakerho.com) |
| 14:29:11 | AlexP | tomers: "Some changes for brickmania" even with the flyspray number isn't very descriptive. It would be nice to describe what those changes were in the commit message |
| 14:29:28 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 14:33:15 | | Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 14:34:13 | TucknDar | gevaerts, thanks for the pointers about increasing the thickness of the CF card in my iPod mini, yesterday. Finally got it working and I can now enjoy a 2g 16gb ipod mini with Rockbox! :) |
| 14:34:26 | | Join TheSeven|Mobile [0] (~theseven@rockbox/developer/TheSeven) |
| 14:34:54 | gevaerts | excellent! |
| 14:35:54 | | Quit Guest88353 (Ping timeout: 268 seconds) |
| 14:36:00 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 14:36:48 | TucknDar | luckily I had two minis, cause I managed to break one :p |
| 14:36:59 | TucknDar | but I only need one anyway ;) Thanks again. |
| 14:37:23 | | Quit killan_ (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 14:39:05 | | Join killan [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 14:39:15 | tomers | AlexP: I agree. Sorry for that |
| 14:39:26 | AlexP | no worries :) |
| 14:40:42 | | Join Guest88353 [0] (~martian67@over.the.cat) |
| 14:42:25 | | Quit stripwax (Quit: http://miranda-im.org) |
| 14:42:42 | | Join funman [0] (~fun@rockbox/developer/funman) |
| 14:44:43 | funman | Unhelpful: thanks for the test, the IRAM might be disabled on clipv2, can you add a CGU_PERI |= (1<<25) before the test ? |
| 14:45:07 | Unhelpful | funman: i can later. :) |
| 14:45:45 | funman | the datasheet says it should be default enabled but perhaps they disable it and then enable it only in some use case |
| 14:47:12 | funman | still weird that nothing happens, i'd think the data abort mode would be entered |
| 14:47:47 | | Join mirak_ [0] (~mirak@85-171-108-41.rev.numericable.fr) |
| 14:49:07 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 14:54:25 | | Quit Guest88353 (Ping timeout: 268 seconds) |
| 14:56:14 | | Join Guest88353 [0] (~martian67@over.the.cat) |
| 14:57:17 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:00:59 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:01:13 | | Quit kugel (Read error: Connection reset by peer) |
| 15:01:23 | | Join kugel_ [0] (~kugel@e178088187.adsl.alicedsl.de) |
| 15:01:29 | | Nick kugel_ is now known as kugel (~kugel@e178088187.adsl.alicedsl.de) |
| 15:01:41 | | Quit kugel (Changing host) |
| 15:01:41 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 15:05:31 | | Quit Guest88353 (Ping timeout: 268 seconds) |
| 15:06:37 | | Quit robin0800 (Remote host closed the connection) |
| 15:06:56 | | Join Guest88353 [0] (~martian67@over.the.cat) |
| 15:11:56 | | Quit funman (Quit: free(random());) |
| 15:14:19 | * | kugel grumbles at FS #11041 |
| 15:18:14 | kugel | it happened to me yesterday too, but not in the week of testing prior to committing |
| 15:20:40 | | Join webguest [0] (~5563422f@giant.haxx.se) |
| 15:20:59 | Torne | there seem to be more people than usual who can't reset their ipods :( |
| 15:21:19 | Torne | would it be controversial to suggest we enable bootloader usb on ipod? |
| 15:22:03 | kugel | on all pp please then :) |
| 15:22:29 | kugel | Torne: I don't think there would be objections, it just wasn't needed yet |
| 15:22:32 | Torne | i guess the only reason not to is size |
| 15:22:36 | Torne | and sure, its' not technically needed |
| 15:22:43 | Torne | but i think it would be easier for some people to recover from mistakes that way |
| 15:23:01 | kugel | but with rockbox usb and the ability to completely replace the of (including bootloaders) there should be a bootloader recovery mode |
| 15:23:04 | | Quit TheSeven|Mobile (Ping timeout: 240 seconds) |
| 15:23:05 | gevaerts | is size really an issue on the usual pp targets? |
| 15:23:11 | Torne | gevaerts: don't think so |
| 15:23:21 | Torne | also, does bootloader usb always go into usb mode if the cable is inserted? |
| 15:23:27 | Torne | because we probably don't want that on ipod |
| 15:23:34 | Torne | for the same reason that usb isn't enabled in release builds |
| 15:23:48 | Torne | it would be nice if it was just if the main binary was not loadable |
| 15:23:54 | kugel | it happened to me once that I trashed my rockbox installation so that I needed e200tool to get it running again. that wouldnt be needed with bootloader usb |
| 15:24:30 | Torne | there just seem to be a lot of people lately who can't reset their ipods |
| 15:24:42 | gevaerts | yes, it's weird |
| 15:24:46 | Torne | and i'm wondering if the reset keys are really as bulletproof as we claim |
| 15:24:48 | Torne | :) |
| 15:26:00 | kugel | so I definitely vote for it |
| 15:27:06 | Torne | i assume that it does always go into usb mode, though |
| 15:27:19 | Torne | which could be undesirable |
| 15:27:54 | gevaerts | yes, that's the main problem |
| 15:28:27 | Torne | i guess it shouldn't be too hard to arrange for it to only go into usb mode when it would otherwise display a boot failure message |
| 15:28:36 | Torne | and maybe on a button press? dunno. |
| 15:28:45 | kugel | both would be nice |
| 15:30:11 | | Join Schmogel [0] (~Miranda@p3EE214B2.dip0.t-ipconnect.de) |
| 15:30:22 | Torne | yah |
| 15:31:03 | Torne | actually i guess you'd just have to patch out the check for usb connected on start? |
| 15:31:17 | Torne | and leave usb insertion as it is |
| 15:34:30 | | Quit tmzt (Ping timeout: 268 seconds) |
| 15:36:39 | | Quit webguest (Quit: CGI:IRC) |
| 15:43:46 | kugel | it would surprise me if my buffering commit had any impact on a 64MB device (FS #11041) |
| 15:45:16 | | Quit Strife89 (Read error: Connection reset by peer) |
| 15:54:38 | TheSeven | [15:21]<kugel>but with rockbox usb and the ability to completely replace the of (including bootloaders) there should be a bootloader recovery mode |
| 15:54:49 | TheSeven | you mean flashing the nor on older ipods? do we do that? |
| 15:55:31 | Torne | no |
| 15:55:48 | kugel | hrm, I think ipodpatcher offers some advanced installation procedure overcoming the of but it's not the default, sansapatcher has something similar |
| 15:55:55 | Torne | but if you drop rockbox into OSOS then turninghold on to boot the OF won't get you the disk mode either |
| 15:56:25 | TheSeven | holding the button combo should do so |
| 15:56:51 | Torne | it would, except there seem to be quite a few people on the forums who can't reset their ipods |
| 15:56:56 | Torne | and have great trouble as a result |
| 15:57:23 | TheSeven | how would bootloader usb help there, if the ipod is stuck in a state where it's locked up and you can't reset it? |
| 15:57:33 | TheSeven | or do you mean that the reset fails when the bootloader fails to load rockbox? |
| 15:57:35 | Torne | because it's not stuck in such a state |
| 15:57:43 | Torne | they just cocked up the install and don't ahve .rockbox on there |
| 15:57:50 | Torne | but they now can't reset to get into disk mode |
| 15:58:05 | Torne | one guy got it sorted by letting the battery run right down then turning hold on and connecting usb |
| 15:58:59 | TheSeven | has anyone ever investigated how that reset works? |
| 15:59:03 | Torne | don't know. |
| 15:59:09 | Torne | we have always assumed it's "hardware" |
| 15:59:16 | Torne | which is a great non-answer |
| 15:59:26 | Torne | maybe someone knows, but i haven't heard :) |
| 15:59:34 | TheSeven | on the nano2g it seems to be 100% bullet-proof, the clickwheel seems to signal the pmu that it should shut off the cpu's power for half a second |
| 15:59:53 | Torne | as far as my experience goes it's 100% bullet proof on all the others as well |
| 15:59:58 | TheSeven | but on the nano4g, there seems to be a way to inhibit a reset, ipod is doing that during a restore |
| 16:00 |
| 16:00:06 | Torne | well, all the PP ipods |
| 16:00:17 | Torne | but there seem to be people having trouble anyway |
| 16:00:26 | Torne | previously they mostly went "oh right" when we told them to hold it down for longer |
| 16:00:38 | Torne | but the last two or three occurrences on teh forums they just can't make it work |
| 16:02:21 | Torne | anyway, my point was that there are cases wher bootloader usb might help, and i don't think there's much reason *not* to add it :) |
| 16:02:54 | | Join tmzt [0] (~tmzt@99.164.34.42) |
| 16:03:35 | * | kugel thinks the use of size_t in buffering.c is generally wrong |
| 16:05:02 | | Quit teru (Quit: Quit) |
| 16:08:36 | | Quit tomers (Ping timeout: 252 seconds) |
| 16:13:55 | CIA-8 | New commit by kugel (r24790): Use a helpfer function to avoid ugly casting and correct some data types (no functional change). |
| 16:18:17 | | Nick Guest88353 is now known as martian67 (~martian67@over.the.cat) |
| 16:18:30 | | Quit martian67 (Changing host) |
| 16:18:30 | | Join martian67 [0] (~martian67@about/linux/regular/martian67) |
| 16:31:02 | S_a_i_n_t | TheSeven: Torne: I have *once* had an issue (nano2g) where the OF crashed and I couldn't reset it using menu+select, had to let the battery drain completely also (which didn't take too long actually as it froze on a full white screen with the backlight on ;) ). |
| 16:31:22 | S_a_i_n_t | apart from that *one* time, the reset key combo has worked perfectly. |
| 16:31:53 | TheSeven | hm, can one shut off the clickwheel power in the pmu? |
| 16:32:06 | TheSeven | i haven't managed to do that yet at least... |
| 16:36:10 | | Quit stoffel (Ping timeout: 256 seconds) |
| 16:43:19 | | Join Blue_Dude [0] (~chatzilla@64.134.184.121) |
| 16:45:17 | Blue_Dude | Can anyone confirm that r24782 fixed FS #11038? It seems to be OK now. |
| 16:47:53 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 16:49:15 | S_a_i_n_t | RE: Nano 1/2g Themes, the original of my Radiance theme had to go (copyright issues), so I'm guessing the guy that mixed it up and used all the art from the original's theme has to go too? I hadn't looked at the theme site in ages. |
| 16:51:24 | | Quit petur (Quit: time!) |
| 16:57:20 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:01:47 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 17:05:30 | | Quit dmb (Quit: No Ping reply in 180 seconds.) |
| 17:07:03 | | Quit piotrekm (Quit: piotrekm) |
| 17:07:07 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 17:09:49 | | Join dmb [0] (~dmb@unaffiliated/dmb) |
| 17:19:28 | | Quit kugel (Ping timeout: 260 seconds) |
| 17:21:44 | | Quit S_a_i_n_t (Quit: "PC Restart") |
| 17:22:13 | | Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 17:23:54 | | Quit stripwax (Ping timeout: 245 seconds) |
| 17:25:05 | | Join marcol [0] (~4e6222cd@giant.haxx.se) |
| 17:25:51 | | Quit marcol (Client Quit) |
| 17:25:54 | | Join marcol [0] (~4e6222cd@giant.haxx.se) |
| 17:26:45 | | Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 17:26:52 | | Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920]) |
| 17:28:36 | marcol | hi there |
| 17:30:39 | liar | TheSeven: r24725 breaks rockboy(stkov main) |
| 17:31:50 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.10) |
| 17:36:01 | | Quit simabeis (Quit: leaving) |
| 17:36:08 | | Join simabeis [0] (~simabeis@lobmenschen.de) |
| 17:37:30 | | Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 17:37:56 | | Join CaptainKwel [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 17:38:34 | | Quit TucknDar (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:39:29 | | Join FOAD_ [0] (~dok@dinah.blub.net) |
| 17:42:21 | | Quit CaptainKewl (Ping timeout: 272 seconds) |
| 17:42:48 | | Quit FOAD (Ping timeout: 260 seconds) |
| 17:42:48 | | Nick FOAD_ is now known as FOAD (~dok@dinah.blub.net) |
| 17:43:54 | | Quit liar (Ping timeout: 245 seconds) |
| 17:49:58 | | Join ecio1 [0] (~ecio@244-108.202-68.tampabay.res.rr.com) |
| 17:51:49 | | Quit ecio (Ping timeout: 245 seconds) |
| 17:54:05 | | Quit marcol (Quit: CGI:IRC) |
| 17:54:58 | | Quit stripwax_ (Quit: http://miranda-im.org) |
| 17:57:20 | TheSeven | liar: i already wondered whether that would happen, but as it didn't break pictureflow which is also prone to stkov's and i don't have any roms, i assumed it should work |
| 17:57:53 | * | TheSeven wonders why rockboy doesn't just allocate it's own stack from plugin ram if it needs more stack than everything else in rockbox |
| 18:00 |
| 18:03:37 | | Quit fyre^OS (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) |
| 18:05:39 | TheSeven | liar: could you have a look into this? |
| 18:06:31 | | Join toffe82 [0] (~chatzilla@adsl-75-12-168-22.dsl.frs2ca.sbcglobal.net) |
| 18:07:04 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 18:07:20 | kugel | TheSeven: I think it's because plugins run within the main thread |
| 18:07:58 | TheSeven | i can see no reason why it should need that much stack. it just *must* be possible to move something from the stack to the heap to fix this |
| 18:08:15 | TheSeven | i really don't want to waste several kilobytes of iram because of rockboy |
| 18:15:47 | | Join fleebailey33 [0] (fleebailey@unaffiliated/fleebailey33) |
| 18:17:29 | TheSeven | btw: 4MHz improvement on vorbis, 11MHz on WMA |
| 18:18:09 | | Quit Xerion (Ping timeout: 246 seconds) |
| 18:34:12 | | Quit martian67 (Remote host closed the connection) |
| 18:37:06 | | Join saratoga_ [0] (~463f90ed@gateway/web/freenode/x-gesbelhyftqbzrbe) |
| 18:41:32 | | Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 18:44:29 | | Join martian67 [0] (~martian67@about/linux/regular/martian67) |
| 18:44:45 | | Join CGL [0] (~CGL@190.207.226.111) |
| 18:48:23 | | Join toffe82_ [0] (~chatzilla@adsl-70-235-226-240.dsl.frs2ca.sbcglobal.net) |
| 18:50:51 | | Quit toffe82 (Ping timeout: 260 seconds) |
| 18:53:52 | | Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de) |
| 18:57:23 | *** | Saving seen data "./dancer.seen" |
| 18:58:29 | | Quit AlexP (Remote host closed the connection) |
| 18:58:56 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 18:59:48 | | Quit AlexP (Remote host closed the connection) |
| 19:00 |
| 19:03:23 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 19:04:26 | | Quit toffe82_ (Remote host closed the connection) |
| 19:08:43 | | Join flydutch [0] (~flydutch@host154-132-dynamic.15-87-r.retail.telecomitalia.it) |
| 19:10:17 | saratoga_ | TheSeven: the nano2g has a lot more IRAM we could use for codecs right? |
| 19:14:03 | | Quit CGL (Remote host closed the connection) |
| 19:18:24 | | Join CGL [0] (~CGL@190.207.226.111) |
| 19:24:42 | | Join flyback [0] (~teac@c-98-219-129-239.hsd1.pa.comcast.net) |
| 19:25:38 | | Join phanboy4 [0] (~benji@adsl-219-59-106.asm.bellsouth.net) |
| 19:26:33 | | Join sudoman [0] (~d8ecfceb@gateway/web/freenode/x-lsjuxyvrzcudjtft) |
| 19:28:08 | | Quit tomers (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100214235838]) |
| 19:28:15 | | Join toffe82 [0] (~chatzilla@adsl-70-235-226-240.dsl.frs2ca.sbcglobal.net) |
| 19:28:29 | TheSeven | saratoga_: With some optimizations, we could give up to 128K to the codec |
| 19:29:26 | saratoga_ | TheSeven: that would be nice |
| 19:29:33 | saratoga_ | how much is available right now? |
| 19:30:12 | TheSeven | currently it's a 64/96 split, but I don't know which way round |
| 19:30:22 | TheSeven | the core easily fits into 64k though |
| 19:30:47 | TheSeven | and some time ago i managed to squeeze it into 48k as well |
| 19:32:24 | saratoga_ | i got a nano2g now |
| 19:32:34 | saratoga_ | i should look at some codecs and see how much is really useful |
| 19:33:00 | saratoga_ | more then 80KB would certainly be nice, though i don't know if we need the full 128k |
| 19:36:35 | | Join jordan` [0] (~jordan@78.235.252.137) |
| 19:47:27 | | Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) |
| 19:49:05 | kugel | can someone check if http://pastie.org/834425 builds fine (a manual patch)? |
| 19:53:06 | | Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) |
| 19:53:36 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 19:54:39 | * | kugel isn't able to install half a GB of latex stuff right now |
| 19:55:14 | kugel | AlexP, pixelma. mc2739 ^ ? |
| 19:57:46 | | Quit saratoga_ (Quit: Page closed) |
| 20:00 |
| 20:01:03 | TheSeven | kugel: checking... |
| 20:02:06 | TheSeven | everything ok :-) |
| 20:02:42 | | Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 20:03:46 | kugel | great, which manual did you build? |
| 20:04:44 | TheSeven | nano2g, pm'ed you a link to the pdf |
| 20:04:44 | kugel | the change was under "4.3 While Playing Screen" in the e200 manual (4.3.3 to be precise) |
| 20:05:01 | kugel | ah nice |
| 20:05:31 | TheSeven | is this specific to e200? |
| 20:06:42 | CIA-8 | New commit by kugel (r24791): Playlist Viewer Changes to bring consistency: ... |
| 20:06:45 | CIA-8 | New commit by kugel (r24792): Update the manual according to the playlist viewer changes |
| 20:06:49 | kugel | no, it's alright :) |
| 20:07:09 | kugel | TheSeven: the numbers might be different on other manuals though |
| 20:08:56 | pixelma | hmm, is things like moving tracks now in the same submenu as the playlist viewer settings? |
| 20:09:19 | kugel | the location of the playlist viewer settings changed |
| 20:09:49 | kugel | it's now in the context menu (along with moving etc) |
| 20:10:44 | pixelma | I'm trying to imagine if I would expect it there |
| 20:11:33 | kugel | where should it else be if not in the context menu? |
| 20:11:46 | kugel | on the button which goes to the main menu everywhere else? |
| 20:11:49 | | Join SeismicMike [0] (~seismicmi@adsl-76-235-41-169.dsl.dytnoh.sbcglobal.net) |
| 20:12:35 | pixelma | the context menu in the playlist viewer just dealt with the track you invoked it on, the viewer's settings are more general |
| 20:12:38 | TheSeven | btw. does anybody know what the "m" (manual) option in configure is doing? |
| 20:12:56 | TheSeven | i can't find any difference to "n" (normal) |
| 20:13:08 | pixelma | TheSeven: it's an old relict |
| 20:13:14 | TheSeven | make will always do a normal build, and make manual will always build a manual... |
| 20:13:16 | SeismicMike | I'm eyeballing this Coby 4GB mp3 video player at Walmart.com for $30... does anyone know if Rockbox will run on it? |
| 20:13:26 | | Join Buschel [0] (~ab@p54A3EBB4.dip.t-dialin.net) |
| 20:13:26 | TheSeven | probably not |
| 20:13:34 | TheSeven | see the list of supported devices on the front page |
| 20:14:33 | pixelma | there was a time where you didn't need "make manual" and could configure a manual target and just "make". It doesn't work anymore since the parsing of features.txt to options in the manual |
| 20:15:12 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 20:16:05 | kugel | I think the reason is rather the make remake |
| 20:16:25 | TheSeven | btw, is there anyone who wants to start a nano4g port? |
| 20:16:29 | pixelma | it's not |
| 20:16:57 | kugel | make always builds the first target in a make file. prior to the remake the makefile was generated, now it's not anymore (just a file that sets a few variables) |
| 20:17:21 | kugel | maybe it stopped working before that though |
| 20:17:33 | | Quit KBH (Ping timeout: 268 seconds) |
| 20:17:54 | kugel | TheSeven: heh, yes! If you have time and a nano4g for me :p |
| 20:18:07 | TheSeven | /data/rockbox-trunk/apps/plugins/lua/loslib.c: In function ‘os_exit’: /data/rockbox-trunk/apps/plugins/lua/loslib.c:176: warning: no return statement in function returning non-void |
| 20:18:24 | | Quit MethoS- (Remote host closed the connection) |
| 20:18:24 | TheSeven | why doesn't this yellow show up in the build table? |
| 20:18:57 | pixelma | kugel: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=16304 |
| 20:19:19 | | Quit flydutch (Quit: /* empty */) |
| 20:19:32 | kugel | TheSeven: you're building eabi with a newer compiler, right? I've seen this warning too but not under the default toolchain |
| 20:19:47 | TheSeven | oh yes |
| 20:20:14 | kugel | pixelma: ah, interesting. thanks |
| 20:20:16 | | Quit Torne (Ping timeout: 240 seconds) |
| 20:20:35 | | Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) |
| 20:21:16 | | Quit amiconn (Disconnected by services) |
| 20:21:17 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 20:21:26 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 20:21:27 | | Quit pixelma (Disconnected by services) |
| 20:21:41 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 20:21:44 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 20:22:03 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 20:29:06 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 20:30:48 | | Quit Schmogel (Ping timeout: 272 seconds) |
| 20:33:23 | | Join Torne [0] (torne@rockbox/developer/Torne) |
| 20:33:25 | | Join Schmogel [0] (~Miranda@p3EE214B2.dip0.t-ipconnect.de) |
| 20:35:11 | | Quit Buschel (Ping timeout: 264 seconds) |
| 20:38:04 | | Quit Torne (Ping timeout: 245 seconds) |
| 20:40:21 | CIA-8 | New commit by kugel (r24793): Remove a few unused defines |
| 20:41:02 | | Quit stripwax (Quit: http://miranda-im.org) |
| 20:42:02 | | Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) |
| 20:44:13 | | Join stoffel [0] (~quassel@p57B4E1EB.dip.t-dialin.net) |
| 20:47:24 | | Join Torne [0] (torne@rockbox/developer/Torne) |
| 20:48:00 | CIA-8 | New commit by kugel (r24794): Fix up Fuze's radio keymap a bit. |
| 20:49:20 | | Quit sudoman (Quit: Page closed) |
| 20:49:39 | | Quit bmbl (Quit: Bye!) |
| 20:53:08 | | Quit Torne (Ping timeout: 252 seconds) |
| 20:56:28 | kugel | haha, I know see what a mess radio.c is |
| 20:56:37 | kugel | it's really disturbing |
| 20:57:17 | | Join toffe82_ [0] (~chatzilla@adsl-70-137-197-2.dsl.frs2ca.sbcglobal.net) |
| 20:57:19 | | Quit toffe82 (Ping timeout: 260 seconds) |
| 20:57:25 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:12:55 | leavittx | It seems to me that rockbox just killed my beloved Cowon I7 :((( |
| 21:14:33 | leavittx | I made patched firmware with mktccboot, it updated, after that my cowon doesn't switches on at all |
| 21:14:37 | leavittx | wtf? |
| 21:15:00 | leavittx | /sorry for offtopic |
| 21:15:34 | kugel | leavittx: yea, I can imagine that happens |
| 21:15:42 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 21:16:02 | kugel | nobody is working on that port |
| 21:24:13 | leavittx | kugel: then what this target is doing in tools/configure? |
| 21:24:33 | leavittx | And is there any way to re-alive my i7? :) |
| 21:24:54 | | Quit Kitar|st () |
| 21:25:10 | kugel | it worked at some time |
| 21:25:31 | | Join robin0800 [0] (~quassel@genkt-050-207.t-mobile.co.uk) |
| 21:25:52 | | Quit stoffel (Remote host closed the connection) |
| 21:26:20 | kugel | no idea how you could unbrick it |
| 21:26:33 | leavittx | but broken now. heavy broken |
| 21:26:57 | kugel | leavittx: it's under "unusable", you shouldn't have been installing it in the first place |
| 21:27:16 | leavittx | I think that it will be good to remove this from tools/configure |
| 21:27:29 | kugel | I don't see why |
| 21:27:38 | kugel | it's clearly not our fault |
| 21:27:42 | leavittx | ok |
| 21:27:57 | leavittx | is there any info about this port? |
| 21:28:31 | kugel | have you visited our site at all? |
| 21:29:04 | TheSeven | http://www.rockbox.org/wiki/CowonIaudio7Info |
| 21:30:26 | | Join phanboy_iv [0] (~benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 21:30:36 | leavittx | Sad, sad, sad |
| 21:30:41 | saratoga | you can run rockbox on the i7 without installing it using ttctool |
| 21:30:47 | saratoga | i think thats what you are supposed to do |
| 21:31:00 | saratoga | you could probably use that now to put the OF back and fix your player |
| 21:31:14 | saratoga | but i don't know how, or even if anyone has done it |
| 21:31:35 | TheSeven | "Flashing: The OF does the flashing, so a bad flash will ruin the player until we figure out how to do the USB boot mode properly." |
| 21:31:54 | saratoga | i suggest reading through the i7 and d2 info |
| 21:32:17 | kugel | TheSeven: he hasn't read it prior to installing |
| 21:32:31 | leavittx | damn on me |
| 21:32:58 | leavittx | rb on my cowon d2 works so perfectly, so... |
| 21:33:54 | | Quit phanboy4 (Ping timeout: 245 seconds) |
| 21:35:14 | saratoga | i still think you should be able to fix it with tcctool |
| 21:35:35 | saratoga | the dfu mode thing probably doesn't need an intact OF, otherwise it would be pretty useless |
| 21:36:40 | | Quit toffe82_ (Ping timeout: 272 seconds) |
| 21:37:08 | saratoga | TheSeven: hilariously the sandisk connector fits nicely into a nano2g |
| 21:37:11 | saratoga | although it doesn't break it |
| 21:37:29 | saratoga | at least not if you only do it for a couple seconds :) |
| 21:38:01 | TheSeven | have you checked the pinout? |
| 21:38:05 | TheSeven | might it be even compatible? ;-) |
| 21:39:11 | saratoga | no they're definitely not compatible |
| 21:39:21 | saratoga | putting a sansa into an ipod cable bricks it |
| 21:40:21 | | Join Kitar|st [0] (Kitr88@BSN-142-86-131.dial-up.dsl.siol.net) |
| 21:41:57 | leavittx | saratoga: i tried to run ./tcctool -d iaudio7 ../../i7_boot/I7_FW.BIN |
| 21:42:00 | leavittx | not helped |
| 21:42:12 | leavittx | it says Ensure your TCC device is in USB boot mode and run tcctool again. |
| 21:42:20 | leavittx | how do i do this? |
| 21:43:00 | TheSeven | "USB Boot Mode: The iAudio7 has a USB boot mode, you can enter it by holding down the 'mode' button while plugging in the USB connector. The Vendor/Product id changes to a TCC specific pair (Vendor=140e ProdID=b021), it is then possible to upload code to the device via tcctool (source available in svn tree: http://svn.rockbox.org/viewvc.cgi/trunk/utils/tcctool/ ). " |
| 21:43:03 | TheSeven | see the wiki... |
| 21:44:55 | | Join m3dlg [0] (~m3dlg@212.183.140.51) |
| 21:47:45 | | Join mitk [0] (~tomekk@chello089078013146.chello.pl) |
| 21:48:04 | saratoga | leavittx: like I said I have no idea how to do this . . . |
| 21:48:36 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-062-030.pools.arcor-ip.net) |
| 21:49:31 | | Quit S_a_i_n_t (Quit: There are 10 types of people, those who understand binary, and those who don't.) |
| 21:51:10 | TheSeven | damn, my nano's lcd controller is dying |
| 21:51:22 | TheSeven | it's getting more and more bad GRAM cells |
| 21:51:26 | | Quit m3dlg (Ping timeout: 252 seconds) |
| 21:52:38 | | Join m3dlg [0] (~m3dlg@212.183.140.51) |
| 21:53:14 | CIA-8 | New commit by kugel (r24795): Quickscreen for the radio screen. I added a keymap for almost all targets. I couldn't find a nice one (i.e. one that's consistent with the wps/menu ... |
| 21:58:50 | saratoga | TheSeven: time to work on the 4g port ;) |
| 21:59:53 | saratoga | heh we have no recent PP ipod battery benchs |
| 22:00 |
| 22:00:30 | leavittx | TheSeven: I feel like an absolut noob, BUT what is the 'mode' button? |
| 22:02:13 | kugel | leavittx: everybody here is as clueless as you are... |
| 22:02:36 | TheSeven | leavittx: I've never even seen an i7, i just read what the wiki says |
| 22:02:40 | saratoga | you're probably the only one in this channel thats ever seen an i7 |
| 22:03:25 | leavittx | but there is no such button |
| 22:03:45 | | Quit robin0800 (Remote host closed the connection) |
| 22:04:19 | leavittx | there are power+hold button, menu, +, -, and some sensor buttons. Also reset. |
| 22:05:22 | kugel | try all |
| 22:06:45 | saratoga | did you check google? |
| 22:06:45 | leavittx | already ;) |
| 22:06:48 | leavittx | yep |
| 22:06:52 | leavittx | nothing |
| 22:06:52 | saratoga | theres lots of guides to fixing bad flashes |
| 22:06:55 | saratoga | none of them worked? |
| 22:07:07 | leavittx | no, I tried only tcctool |
| 22:07:33 | saratoga | http://iaudiophile.net/forums/showpost.php?p=231920&postcount=1 |
| 22:07:33 | leavittx | I can't get to USB boot mode |
| 22:07:44 | saratoga | this one says to use the "mode/menu" button |
| 22:07:47 | saratoga | did you try that |
| 22:08:06 | leavittx | hmm, I think, yes |
| 22:08:33 | saratoga | apparently a few other people have fixed this problem, maybe you could try asking one of them |
| 22:08:38 | kugel | I wonder if it makes sense to transform the preset list into a playlist |
| 22:08:53 | kugel | to enable saving, moving things around, other funny stuff |
| 22:09:00 | saratoga | also, what is the issue with supporting 240GB players in standard builds? |
| 22:09:14 | TheSeven | saratoga: I guess binsize... |
| 22:09:39 | kugel | didn't zagor and amiconn talk about it recently? i remember seeing it in the logs |
| 22:09:41 | saratoga | surely thats not a serious problem on the ipod video or gigabeats |
| 22:10:21 | TheSeven | saratoga: you know that some rockbox devs just get crazy when someone pulls their binsize trigger :-) |
| 22:11:19 | saratoga | binsize is important but it needs to be considered in context |
| 22:14:44 | saratoga | shouldn't the recent font stuff go into MajorChanges |
| 22:18:37 | | Quit Omlet (Read error: Connection reset by peer) |
| 22:20:26 | | Join Omlet [0] (omlet05@119.159-241-81.adsl-dyn.isp.belgacom.be) |
| 22:22:48 | | Quit m3dlg (Ping timeout: 260 seconds) |
| 22:25:19 | TheSeven | http://www.mediafire.com/file/1zwetvuzmdy/nano2g_test_codec_results.pdf |
| 22:25:28 | TheSeven | eabi seems to have a rather weird impact... |
| 22:26:30 | leavittx | saratoga: thanks, this helped me a little. Now what do i do after this message from tcctool: "[INFO] Patching application uploaded successfully!" ? How to says "copy 3 firmware files onto your i7 root folder" but how do i access root forder? |
| 22:27:11 | saratoga | look i have no idea |
| 22:27:13 | saratoga | stop asking me |
| 22:27:25 | leavittx | =) |
| 22:27:59 | saratoga | TheSeven: do you have a script for parsing the test_codec files? |
| 22:28:02 | saratoga | i was just about to write one |
| 22:31:07 | TheSeven | saratoga: a trivial 5-liner |
| 22:31:17 | TheSeven | i should write a proper one |
| 22:31:22 | TheSeven | the rest was openoffice magic :-) |
| 22:32:06 | saratoga | ok i'll do it now then |
| 22:32:12 | saratoga | this is easy in perl |
| 22:32:33 | CIA-8 | New commit by kugel (r24796): Factor out some drawing code. |
| 22:32:53 | kugel | TheSeven: I don't think eabi has much impact |
| 22:32:59 | kugel | I would blame the compiler version |
| 22:33:11 | kugel | it has been reported that 4.4.x doesn't work well on arm |
| 22:33:32 | TheSeven | it isn't always worse, it's also better on some codecs |
| 22:33:40 | TheSeven | ape is funny ;-) |
| 22:33:46 | saratoga | the results aren't much different except for mpc which is a little better |
| 22:33:47 | TheSeven | sorted it properly: http://www.mediafire.com/file/mdtt12nz0yq/nano2g_test_codec_results.pdf |
| 22:34:00 | | Quit CGL (Remote host closed the connection) |
| 22:34:37 | TheSeven | the lower ape compression levels are faster on eabi, the higher compression levels are slower |
| 22:35:05 | saratoga | do we actually want to show this: 175906 of 175906 | Decode time - 36.43s | File duration - 175.90s |
| 22:35:11 | saratoga | seems like we could cut that out of the wiki |
| 22:35:13 | kugel | low is better? |
| 22:35:27 | TheSeven | yes, it's the mhz value |
| 22:35:43 | kugel | yea, expected w.r.t to the eabi toolchain |
| 22:36:06 | TheSeven | seems so |
| 22:36:08 | kugel | generally: flac performs much worse, others vary within +-2% |
| 22:36:33 | kugel | I really want to try 4.4.3 and the last 4.3.x release |
| 22:37:00 | kugel | and some other compilers also :) |
| 22:37:45 | | Quit phanboy_iv (Read error: Connection reset by peer) |
| 22:38:03 | * | TheSeven wonders if it would be worth the effort to 1) add the device, build type and revision to the test-codec output, 2) make a website where one can upload the logs, 3) make an analyzer tool for the gathered results :-) |
| 22:38:13 | kugel | feel free to add your results to CodecPerformanceComparison |
| 22:38:33 | saratoga | kugel: the code sourcery gcc branch is supposed to be better for arm then stock |
| 22:38:43 | kugel | I heard that too |
| 22:39:20 | kugel | I would also like to try that other compiler that blog (forgot the names) mentioned |
| 22:39:23 | TheSeven | kugel: I think that many results get lost because most people are too lazy to work out how this weird wiki works... |
| 22:39:44 | kugel | I wonder how much effort you need to compile rockbox with a non-gcc-like compiler |
| 22:39:56 | TheSeven | and if you do a full test_codec, copying and pasting all the values will take quite a lot of time |
| 22:39:57 | saratoga | TheSeven: almost got a perl script together for that |
| 22:40:46 | kugel | especially msvc for targeting windows mobile with raap |
| 22:40:53 | | Join toffe82 [0] (~chatzilla@adsl-70-137-199-73.dsl.frs2ca.sbcglobal.net) |
| 22:41:51 | kugel | might not even be worth trying looking at windows phone 7 (I heard it only accepts managed .net apps) |
| 22:42:25 | | Join pamaury [0] (~pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
| 22:42:26 | kugel | TheSeven: the nano2g is pretty slow it seems? samsas have better results |
| 22:42:32 | saratoga | windows moble is a hard target because of all the annoyances of working with gnu stuff on windows |
| 22:47:15 | | Join Torne [0] (~torne@rockbox/developer/Torne) |
| 22:47:59 | TheSeven | kugel: not much cache, slow IRAM |
| 22:48:24 | TheSeven | uncached iram accesses seem to need 2 cycles, even if the result is just thrown away |
| 22:48:31 | kugel | I think the samsas have less cache and even slower iram |
| 22:48:50 | | Quit AlexP (Remote host closed the connection) |
| 22:48:56 | TheSeven | and test_codec is of course running at the full cpu speed |
| 22:49:01 | kugel | 2x8k and the iram is basicallly as fast as the dram |
| 22:49:04 | TheSeven | it might be more efficient when it isn't boostig |
| 22:49:13 | TheSeven | boosting* |
| 22:49:36 | TheSeven | (because it will run in fastbus mode then, while it is running in asynchronous mode when it needs to hurry) |
| 22:49:42 | kugel | what cpu is in the nano2g? |
| 22:49:47 | TheSeven | ARM940T |
| 22:49:54 | | Join AsaelReiter [0] (~d44c72e0@giant.haxx.se) |
| 22:49:56 | saratoga | TheSeven: http://pastebin.com/m1538eb51 |
| 22:50:14 | saratoga | takes 1 or 2 test codec results and will either compare them or just print one, either way formatted for the wiki |
| 22:50:45 | TheSeven | so it's 2x4k cache only |
| 22:51:21 | kugel | TheSeven: we use synchronous mode, that might make a difference. arm docs say asynchronous imposes performance penalties for synchronizing |
| 22:51:50 | kugel | ok, that's less cache, I guess that's it |
| 22:52:26 | TheSeven | i couldn't make out any real differences in the docs between sync and async mode, the penalties seemed to rougly the same if it's running at an int multiple anyways |
| 22:52:27 | kugel | a ldr should still only take 1c on all arm9 IIUC |
| 22:52:34 | kugel | (with result delay) |
| 22:52:43 | TheSeven | the problem is just that it immediately locks up if i switch it to sync mode, no matter what |
| 22:53:02 | TheSeven | haven't yet found out why (1:4 factor between the clocks) |
| 22:53:17 | saratoga | if the arm bus and the memory bus don't have an integer relationship, then there pretty much has to be 1 clock delay |
| 22:53:51 | TheSeven | firing semi-random ldrs one after another, 256 of them in a loop takes ~520 clocks with caches disabled and the accesses hitting iram |
| 22:54:16 | TheSeven | (CPU at 192MHz, bus at 96MHz, async mode) |
| 22:54:32 | kugel | ah we run at 248, another reason |
| 22:54:43 | kugel | bus at 62 |
| 22:54:45 | TheSeven | that shouldn't affect the mhz values though |
| 22:55:19 | TheSeven | actually your bus to cpu ratio is worse, so the ipod should be better |
| 22:57:27 | *** | Saving seen data "./dancer.seen" |
| 22:57:38 | saratoga | the IRAM on the AMS players is really slow |
| 22:57:43 | saratoga | its basically just DRAM |
| 22:57:49 | saratoga | so performance is more like the gigabeat F |
| 22:58:23 | kugel | TheSeven: every target does worse it seems. PP is so fast compared to other arm targets looking at codec performance |
| 22:58:55 | kugel | PP needs 10MHz less than samsa for vorbis, for example |
| 22:59:12 | kugel | I think that's because the iram is as fast as the caches |
| 23:00 |
| 23:00:08 | | Quit mitk (Quit: Ex-Chat) |
| 23:01:15 | saratoga | PP's custom IRAM implementation makes a huge difference |
| 23:01:25 | saratoga | since it makes memory accesses basically free for most codecs |
| 23:03:10 | saratoga | D2 should probably be faster then PP if it really has SRAM and armv5e |
| 23:03:10 | | Quit AsaelReiter (Quit: CGI:IRC (EOF)) |
| 23:03:17 | saratoga | though i heard we don't use the IRAM yet |
| 23:09:02 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 23:10:16 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 23:10:37 | amiconn | saratoga: The main problem with supporting those 240GB disks is the large sector mess |
| 23:11:07 | CIA-8 | New commit by bluebrother (r24797): If the Ipod has been recognized as MacPod always consider no bootloader installed. |
| 23:11:09 | CIA-8 | New commit by bluebrother (r24798): Update an outdated comment. |
| 23:11:15 | CIA-8 | New commit by bluebrother (r24799): Recognize and handle MacPods during autodetection. ... |
| 23:11:51 | amiconn | Torne: The PP based ipods *can* apparently reach a state where reset doesn't work, but this is rare |
| 23:12:04 | amiconn | I had this happen once on my Mini G2 |
| 23:12:12 | Torne | hm |
| 23:12:14 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:12:19 | | Quit bluebroth3r (Ping timeout: 276 seconds) |
| 23:12:24 | Torne | that shouldn't be happening for people who have just forgotten to put .rockbox on the player though |
| 23:12:41 | amiconn | Letting the battery run down helped (took a few days) |
| 23:13:07 | | Quit AlexP (Remote host closed the connection) |
| 23:13:14 | amiconn | This only happened once, among probably hundreds of times I had to reset the ipod for various reasons |
| 23:14:20 | | Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) |
| 23:14:47 | | Join robin0800 [0] (~quassel@genkt-057-078.t-mobile.co.uk) |
| 23:14:47 | amiconn | Normally, if the reset doesn't work first time, it helps to flip the hold switch, flip it back, and try again |
| 23:15:29 | | Quit hebz0rl (Read error: Connection reset by peer) |
| 23:15:55 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 23:15:57 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 23:17:38 | Unhelpful | TheSeven: hrm, ldr on arm9tdmi is supposed to be 1c... |
| 23:19:39 | kugel | it looks like the build system got slower after attaching my client |
| 23:19:40 | TheSeven | possibly not if the bus is slower and it's getting swamped with them? (every single instruction in that loop was an ldr) |
| 23:19:42 | Unhelpful | although perhaps when async it can't actually fetch every cycle? |
| 23:20:56 | | Quit robin0800 (Remote host closed the connection) |
| 23:22:36 | | Join Buschel [0] (~ab@p54A3FA48.dip.t-dialin.net) |
| 23:22:40 | Unhelpful | TheSeven: hrm, what if you interleave w/ nops? i bet it stays about the same... |
| 23:23:10 | | Join CGL [0] (~CGL@190.207.226.111) |
| 23:26:46 | CIA-8 | New commit by kugel (r24800): Correct ActionFMPreset manual entry for the Fuze. |
| 23:29:09 | kugel | gah, we really need to generate those button maps from the actualy source files :( |
| 23:32:15 | saratoga | Unhelpful: the ARM9TDMI load/store unit adds one cycle of latency |
| 23:32:28 | saratoga | that doesn't mean the bus and DRAM accesses are free however |
| 23:33:05 | saratoga | (if thats what you were asking) |
| 23:33:39 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 23:37:24 | | Quit kugel (Remote host closed the connection) |
| 23:40:23 | | Quit pamaury (Quit: abort();) |
| 23:40:30 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-062-030.pools.arcor-ip.net) |
| 23:42:42 | | Quit AlexP (Ping timeout: 240 seconds) |
| 23:43:57 | amiconn | TheSeven: Did your back-to-back ldr instructions use different destination registers? |
| 23:44:54 | | Join AlexP [0] (~ap@rockbox/staff/AlexP) |
| 23:46:57 | CIA-8 | New commit by bluebrother (r24801): Add missing class prefix to logging call. |
| 23:47:00 | CIA-8 | New commit by bluebrother (r24802): Be more strict when when resolving devices and allow hfs too. ... |
| 23:48:44 | TheSeven | amiconn: not sure, probably not |
| 23:48:52 | TheSeven | amiconn: not sure, probably not |
| 23:51:24 | | Quit m3dlg (Ping timeout: 245 seconds) |
| 23:52:05 | amiconn | I'm not sure, but using the same destination register might also cause an interlock. Alternating between two destination registers should be enough |
| 23:52:24 | amiconn | ..to avoid that |
| 23:54:56 | | Quit Buschel () |
icon identifies that the person is a core developer (has commit access).