| 00:00:08 | bluebrother | pamaury: what are those "subtle properties" of FAT? |
| 00:01:25 | pamaury | basically, when you do an opendir or more generally an open without modify any entry, one of the parameters is useless. This allows to get rid of the 30kib buffer used before. This is subtle because it's highly implementation specific (and I hope it's true actually ;)) |
| 00:01:55 | pamaury | If you want more details, I can go on... |
| 00:02:20 | stripwax | Sigh: run test_codec on a folder, but don't exit at the end. Then plug in USB, and delete the (0-byte length) test_codec_001.txt file in root. unmount and unplug USB: "Panic deleting zero length directory entry" |
| 00:03:06 | *** | Saving seen data "./dancer.seen" |
| 00:05:23 | | Join piotrekm [0] (~pm@addq131.neoplus.adsl.tpnet.pl) |
| 00:05:39 | | Quit captainkewllll (Quit: Page closed) |
| 00:05:44 | | Quit piotrekm (Changing host) |
| 00:05:45 | | Join piotrekm [0] (~pm@unaffiliated/piotrekm) |
| 00:05:56 | | Quit piotrekm (Client Quit) |
| 00:06:12 | | Join piotrekm [0] (~pm@addq131.neoplus.adsl.tpnet.pl) |
| 00:06:24 | | Quit piotrekm (Changing host) |
| 00:06:24 | | Join piotrekm [0] (~pm@unaffiliated/piotrekm) |
| 00:06:57 | bluebrother | pamaury: interesting. Though I guess it's too late for me to go into details :) |
| 00:07:53 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 00:08:45 | | Join akur [0] (~akur@bl11-193-76.dsl.telepac.pt) |
| 00:08:53 | pamaury | Interestingly, this patch also augments the stack usage on my device when doing a full rebuild... I need to investigate that. Perhaps it's because I put fat_dir and fat_direntry on the stack at the beginning. If something as a device with lots of directory and (preferably) a very deep directory structure, I would like to see the result. |
| 00:09:01 | | Join dmb_ [0] (~Dmb@unaffiliated/dmb) |
| 00:12:58 | | Quit bertrik (Read error: Connection reset by peer) |
| 00:13:19 | | Quit evilnick (Ping timeout: 256 seconds) |
| 00:14:19 | | Quit Kitar|st () |
| 00:15:55 | | Quit pamaury (Quit: abort();) |
| 00:20:28 | JdGordon_ | . |
| 00:21:25 | | Join Kitar|st [0] (Kitr88@BSN-182-123-171.dial-up.dsl.siol.net) |
| 00:24:50 | flyback | well my 5 broken sansa's I got for $5 arrived |
| 00:24:58 | flyback | and I just realized I need sync cables to test anything |
| 00:24:58 | flyback | ugh |
| 00:26:57 | flyback | also guys I got an error and if anyone has smart code in devel no matter how buggy, i'd like to try it |
| 00:27:03 | flyback | cause I fear the drop damaged the hd |
| 00:31:06 | flyback | i'll get the error in a bit |
| 00:31:41 | flyback | I bought the sansa's cause I heard rockbox has a usb debug driver so you can see what's on the lcd off the usb thru some kind of terminal |
| 00:31:57 | flyback | also figured I could cut the dead lcd and possibly wire up another to the i/o pins |
| 00:32:09 | CIA-88 | New commit by stripwax (r24575): Whoops, get rid of V, there is no V |
| 00:32:47 | flyback | also |
| 00:33:03 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 00:33:14 | flyback | i'll seriously consider setting up a old p1, p2 linux box, with ssh login and sansa's left on it if any of you devels want somerthing to bang code off of |
| 00:33:37 | stripwax | flyback - hm, didn't we talk about this the other day? there's no 'usb debug lcd terminal'. |
| 00:34:31 | flyback | well I mean like message passing over usb |
| 00:34:33 | | Join Tomis [0] (~Tomis@70.134.77.131) |
| 00:34:36 | stripwax | there's a usb serial debug but I think that needs to be enabled specifically (plus device needs to be running rockbox etc already) |
| 00:34:49 | flyback | no I am not talking about serial pins |
| 00:34:53 | flyback | I was talking about what you just said |
| 00:35:06 | flyback | but thx that gives me an idea |
| 00:35:07 | flyback | :P |
| 00:35:13 | flyback | I could probably jtag these also |
| 00:35:15 | | Join DerPapst1 [0] (~DerPapst@p4FE8E678.dip.t-dialin.net) |
| 00:35:27 | stripwax | jtag probably only way, in fact :-p |
| 00:35:53 | flyback | well I got a wiggler jtag that does +5 and +3.3 targets |
| 00:36:06 | flyback | plus I bought a breakout board for a max30002 bidirectional logic level shifter |
| 00:36:09 | flyback | goes down to 1.5 |
| 00:36:19 | flyback | so I can buffer the jtag outputs if the jtag pins are lower than +3.3 |
| 00:37:00 | | Quit DerPapst (Ping timeout: 264 seconds) |
| 00:37:22 | flyback | really neat little chip |
| 00:37:31 | flyback | only paid $10 for the breakout board with the chip already mounted |
| 00:37:41 | flyback | up to 20mhz at some voltages and up to 40mhz on others |
| 00:37:51 | flyback | which is fast enough for a slow speed wiggler jtag |
| 00:38:25 | flyback | it's dual vcc so you don't have to deal with /direction pins and host/target modifications you just supply each side with the vcc for that side's logic level |
| 00:38:33 | * | TheSeven just spotted that there is no "Rockbox 3.5" choice for "Reported Version" in flyspray! |
| 00:40:35 | | Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 00:41:18 | linuxstb | TheSeven: That's because it's bug-free ;) |
| 00:42:12 | linuxstb | TheSeven: Err, I can see "Rockbox 3.5" there... |
| 00:42:13 | | Quit togetic (Ping timeout: 256 seconds) |
| 00:42:40 | | Join evilnick__ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 00:42:59 | linuxstb | TheSeven: Hmm, it appears as an option in the advanced search, but not when you add a new task... |
| 00:43:21 | | Quit evilnick (Ping timeout: 256 seconds) |
| 00:45:03 | | Quit evilnick_ (Ping timeout: 256 seconds) |
| 00:48:32 | | Join PaulJam__ [0] (~Paule@p54BEEDE2.dip.t-dialin.net) |
| 00:49:01 | | Quit evilnick__ (Ping timeout: 256 seconds) |
| 00:55:05 | | Quit DerPapst1 (Quit: Leaving.) |
| 00:58:32 | | Join togetic [0] (~togetic@unaffiliated/ibuffy) |
| 01:00 |
| 01:00:36 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
| 01:01:45 | | Join phanboy4 [0] (~benji@gate-22.spsu.edu) |
| 01:02:19 | | Quit ender` (Quit: Life is what happens to you when you had other plans. -- John Lennon) |
| 01:03:45 | | Join ansuz [0] (~ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) |
| 01:04:43 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 01:07:55 | | Quit ansuz (Remote host closed the connection) |
| 01:10:44 | | Quit jgarvey (Quit: Leaving) |
| 01:14:31 | | Quit evilnick (Ping timeout: 256 seconds) |
| 01:16:51 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 01:18:39 | | Join Tomis2 [0] (~Tomis@70.134.92.60) |
| 01:20:56 | | Quit Tomis (Ping timeout: 252 seconds) |
| 01:20:56 | | Nick Tomis2 is now known as Tomis (~Tomis@70.134.92.60) |
| 01:21:53 | | Quit evilnick (Ping timeout: 248 seconds) |
| 01:25:30 | | Quit piotrekm (Quit: Leaving.) |
| 01:26:46 | | Quit Tomis (Read error: Operation timed out) |
| 01:27:56 | | Join Tomis [0] (~Tomis@70.134.92.60) |
| 01:29:12 | flyback | hey |
| 01:29:16 | flyback | if I don't make it, it's been fun |
| 01:29:31 | flyback | roads are bad and they accidnetley rmoetely powered off a server at work so I gotta drive over to hit the button |
| 01:30:13 | krazykit` | thanks for being offtopic |
| 01:32:00 | stripwax | Does anyone have sample vorbis files that contain 4096-sample or 8192-sample blocksizes? i.e. files encoded as -q -1 (negative quality) and/or files encoded from 64kHz or higher source material? |
| 01:32:38 | stripwax | Think that we should add these to the test files for vorbis, since 4096 & 8192 blocksizes are something of an outlier but invariable someone complains whenever we (.. I) break vorbis decoding.. |
| 01:34:17 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 01:35:31 | flyback | krazykit`, i might not be back, the roads are getting bad already |
| 01:35:46 | flyback | and if you actually read what I said, I said it's been fun being in this channel |
| 01:35:48 | flyback | but whatever |
| 01:35:51 | Mode | "#rockbox +o rasher" by ChanServ (ChanServ@services.) |
| 01:35:52 | Mode | "#rockbox +q *!~teac@*" by rasher (~rasher@rockbox/developer/rasher) |
| 01:35:56 | Mode | "#rockbox -o rasher" by rasher (~rasher@rockbox/developer/rasher) |
| 01:37:18 | | Part flyback |
| 01:39:57 | | Quit MethoS- (Remote host closed the connection) |
| 01:40:01 | CIA-88 | New commit by stripwax (r24576): Complete the job done in previous revision - now MDCT has NO INIT of its own. Only remaining init now is the revtab in fft. Removed swathes of ... |
| 01:41:16 | * | linuxstb wonders how stripwax can complete a job done |
| 01:41:23 | stripwax | ha |
| 01:41:39 | * | stripwax never completes anything, really, ever ... |
| 01:41:57 | linuxstb | So "Continue the job started..." ? |
| 01:42:15 | stripwax | More likely "Finish the job started, I think" |
| 01:42:24 | | Quit Farthen (Ping timeout: 264 seconds) |
| 01:42:39 | linuxstb | You just said you never complete anything ;) |
| 01:42:43 | * | linuxstb thinks it's getting late... |
| 01:42:52 | stripwax | hence "I think" |
| 01:43:00 | stripwax | anyway. goodnight to you also :) |
| 01:43:11 | | Quit stripwax (Quit: http://miranda-im.org) |
| 01:43:13 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 01:43:37 | | Join Farthen [0] (~chatzilla@e179233053.adsl.alicedsl.de) |
| 01:47:03 | | Quit PaulJam__ (Ping timeout: 260 seconds) |
| 01:55:38 | | Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 02:00 |
| 02:00:38 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
| 02:03:09 | *** | Saving seen data "./dancer.seen" |
| 02:05:35 | | Quit komputes (Ping timeout: 245 seconds) |
| 02:10:54 | Unhelpful | stripwax: i have 96KHz files but nothing redistributable :/ |
| 02:13:08 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 02:17:59 | | Quit evilnick (Ping timeout: 256 seconds) |
| 02:20:44 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 02:22:25 | | Quit akur (Quit: Leaving.) |
| 02:23:47 | | Quit bmbl (Quit: Bye!) |
| 02:24:16 | | Quit JdGordon_ (Quit: Page closed) |
| 02:24:40 | | Join gigatheme [0] (~62134578@giant.haxx.se) |
| 02:25:07 | saratoga | should be easy enough to transcode the FLAC sample file into vorbis q -1 |
| 02:25:21 | | Quit evilnick (Ping timeout: 256 seconds) |
| 02:25:47 | gigatheme | can anyone here help me with the %Vi viewport tag for the .sbs files? |
| 02:27:17 | | Quit maraz (Ping timeout: 265 seconds) |
| 02:27:44 | CIA-88 | New commit by mc2739 (r24577): Thai translation update ... |
| 02:28:20 | gigatheme | %Vi|5|5|230|210|-|-|-| basically what does each section refer to? |
| 02:28:57 | Stephen__ | Vi|x|y|length|height|font|fgcolor|bgcolor| afaik |
| 02:29:09 | | Join maraz [0] (maraz@kapsi.fi) |
| 02:29:19 | gigatheme | ok, is that for the text area then? |
| 02:29:28 | Stephen__ | yep. |
| 02:29:34 | Stephen__ | the list position |
| 02:29:44 | gigatheme | so i define the text's area then the images can fill the rest? |
| 02:29:55 | gigatheme | with being overwritten |
| 02:30:01 | gigatheme | or covered :P |
| 02:30:06 | Stephen__ | use the %V for the images etc just like the .wps |
| 02:30:25 | Stephen__ | the %Vi is just to define the list/menu |
| 02:30:48 | gigatheme | if i dont fill in the |font|fg|bg| does it pull those from the .cfg |
| 02:31:14 | Stephen__ | yep you can just leave them as |-|-|-| if you like |
| 02:31:18 | Unhelpful | what are our correctness tests for mdct_exp? "audio files don't sound obviously wrong"? |
| 02:31:26 | gigatheme | thanks for the help :) |
| 02:31:35 | Stephen__ | welcome |
| 02:33:06 | | Quit gigatheme (Quit: CGI:IRC) |
| 02:38:28 | | Quit Stephen__ (Quit: Leaving) |
| 02:40:00 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 02:42:25 | | Part froggyman |
| 02:46:06 | | Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 02:48:01 | | Quit evilnick (Ping timeout: 256 seconds) |
| 02:48:22 | saratoga | Unhelpful: yeah |
| 02:48:38 | saratoga | i guess before we commit we should compute RMS errors |
| 02:52:47 | | Join CaptainKewl [0] (jds@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 02:54:08 | | Quit evilnick_ (Ping timeout: 248 seconds) |
| 02:54:36 | | Join froggyman [0] (~sopgenort@pool-72-69-210-48.chi01.dsl-w.verizon.net) |
| 02:55:28 | | Join histumness [0] (~6340d5b7@giant.haxx.se) |
| 02:57:06 | | Quit histumness (Client Quit) |
| 03:00 |
| 03:09:03 | | Join gigatheme [0] (~62134578@giant.haxx.se) |
| 03:10:56 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 03:11:34 | gigatheme | how do i specify a font for use on the .sbs? |
| 03:12:02 | gigatheme | not for the file browser, but like for the time and stuff |
| 03:13:30 | linuxstb | gigatheme: Rockbox only has two fonts - the small built-in system font, and the user-selected font. You can specify which one to use in the viewport definition |
| 03:14:08 | gigatheme | is that the difference between 0 and 1 in the %Vi |
| 03:14:29 | linuxstb | Yes |
| 03:14:33 | gigatheme | %Vi|12|20|216|222<<<would be here>>>|-|-| |
| 03:14:53 | gigatheme | meh, i messed that up %Vi|12|20|216|222|<<>>|-|-| |
| 03:15:03 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.147) |
| 03:15:27 | gigatheme | so 0 means small system, and 1 is user? or opposite |
| 03:15:28 | | Quit evilnick (Ping timeout: 248 seconds) |
| 03:15:53 | S_a_i_n_t | gigatheme: 0 system, 1 user |
| 03:16:06 | gigatheme | k |
| 03:16:06 | S_a_i_n_t | Torne: ping? |
| 03:16:07 | gigatheme | thanks |
| 03:17:16 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 03:21:25 | gigatheme | wait, this 0 or 1, that would apply to the file browser correct? |
| 03:24:10 | S_a_i_n_t | gigatheme: yes |
| 03:25:01 | gigatheme | well i want to keep the file browser in the user font, but i also want the time deisplayed in the small system font |
| 03:25:18 | gigatheme | the time will be in the .sbs |
| 03:25:23 | S_a_i_n_t | you'd need to do it with viewports then |
| 03:25:34 | S_a_i_n_t | or an .sbs |
| 03:25:51 | gigatheme | yes .sbs is what im writing (first time :P) |
| 03:26:40 | S_a_i_n_t | well, if there is "user" font in the .sbs, but you want the time to be in "system" font...the .sbs need to draw another viewport fot the time |
| 03:26:50 | S_a_i_n_t | s/fot/for/ |
| 03:27:52 | gigatheme | i want to put the menu and files in the user font, then i need the time, and probably volume dB, and battery precentage in the system font |
| 03:28:48 | | Quit evilnick (Ping timeout: 248 seconds) |
| 03:29:14 | gigatheme | the stock .sbs does this, im looking at it right here, but i need to figure out how its done |
| 03:29:50 | S_a_i_n_t | well, if you look hard enough...it's right there. you're looking at Cabbie, yes? |
| 03:30:04 | gigatheme | %Vi|0|8|-|-|1|-|-| this comes from the "classic_statusbar.sbs" |
| 03:30:18 | gigatheme | no not for the .wps at all |
| 03:30:29 | gigatheme | just for the browser stuff |
| 03:30:54 | S_a_i_n_t | yes, the first two " - "'s mean the viewport is fullscreen, the 1 means it's in "user" font |
| 03:31:30 | gigatheme | ok, and thats right, the files and menus are in the user font, but there is also a text clock in the top right which is in system font |
| 03:31:31 | S_a_i_n_t | nope...don't listen to me...that's completely wrong :P |
| 03:31:34 | S_a_i_n_t | ooops |
| 03:31:45 | gigatheme | lol |
| 03:32:33 | S_a_i_n_t | what they've done there is set a "UI Viewport, that uses the user font |
| 03:32:45 | S_a_i_n_t | anything outside of that will use the system font |
| 03:32:52 | gigatheme | ah ok |
| 03:33:11 | gigatheme | that makes sense |
| 03:33:37 | | Quit saratoga (Ping timeout: 248 seconds) |
| 03:33:45 | S_a_i_n_t | UI Viewport lets you specify an area of the scree nto display the UI in...so that it isn;t fullscreen for example |
| 03:34:01 | gigatheme | yes |
| 03:34:13 | gigatheme | %Vi|1|16|238|278|0| thats mine |
| 03:34:48 | gigatheme | so everything in the 238x278 square will be user font |
| 03:34:54 | S_a_i_n_t | so you'd need to look at the viewports that draw the clock etc, and change the 0 to 1, and it should all be in User font |
| 03:35:26 | S_a_i_n_t | *as an example |
| 03:36:56 | gigatheme | %?cc<%?ca<%?St|time format|<%cH|%cI>:%cM|−−:−−>|> thats from classic_statusbar.sbs and it does what i want it to, but is there any reference to font there? |
| 03:38:20 | S_a_i_n_t | nope |
| 03:38:43 | S_a_i_n_t | the reference to font will be in the "main" viewport its dran in |
| 03:38:55 | S_a_i_n_t | s/dran/drawn/ |
| 03:38:59 | S_a_i_n_t | *I think* |
| 03:39:27 | gigatheme | we'll i'll mess with it and see what happens |
| 03:39:48 | gigatheme | maybe if i figure it out i can work on a new guide for the site |
| 03:40:24 | S_a_i_n_t | It is a little outdated, well not really, it assumes a certain amount of knowledge is attained beforehand |
| 03:40:34 | S_a_i_n_t | there isn;t really a "beginners guide" |
| 03:40:44 | S_a_i_n_t | but there's an attempt at one :D |
| 03:41:02 | gigatheme | yeah, i thought maybe id be a little ahead since ive already written 3 .wps |
| 03:41:12 | gigatheme | lol apparently not though |
| 03:41:44 | S_a_i_n_t | everything keeps changing with the .sbs's atm...so, that's *maybe* the reason it's been left alone for some time now. |
| 03:42:01 | S_a_i_n_t | what's your target device btw? |
| 03:42:09 | gigatheme | gigabeat f20 |
| 03:44:30 | S_a_i_n_t | gigatheme: try messing with animation....that gets tricky :P |
| 03:44:30 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 03:44:43 | S_a_i_n_t | I've got like 5/5 abandoned WPS's....LOL |
| 03:44:57 | gigatheme | .gif? |
| 03:44:57 | S_a_i_n_t | 5/6 rather |
| 03:45:12 | gigatheme | .gif animation |
| 03:45:15 | S_a_i_n_t | no, bitmap strips and conditional |
| 03:45:24 | gigatheme | ah |
| 03:45:25 | S_a_i_n_t | but I don't wanna put ideas in your haed :P |
| 03:45:40 | gigatheme | http://themes.rockbox.org/index.php?target=gigabeatfx |
| 03:45:47 | gigatheme | second over is my latest |
| 03:45:59 | S_a_i_n_t | if .gif was supported...it'd take SOOOO much bloat out of my code |
| 03:46:14 | | Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 03:46:27 | gigatheme | what are you tring to animate? a clock? |
| 03:46:55 | | Quit Zarggg (Read error: Connection reset by peer) |
| 03:47:00 | S_a_i_n_t | *everything* |
| 03:47:03 | * | S_a_i_n_t grins |
| 03:47:10 | gigatheme | lol |
| 03:47:30 | S_a_i_n_t | playmode, AA transitional effects/...you name it, it moves :D |
| 03:48:01 | S_a_i_n_t | yours is citrate? |
| 03:48:05 | gigatheme | yeah |
| 03:49:23 | S_a_i_n_t | you've got some slight problems with the "magic" colour (255,0,255 magenta) on your shuffle and repeat icons...or was that intentional? |
| 03:49:49 | gigatheme | no, i accidently packaged the wrong file :P |
| 03:50:13 | S_a_i_n_t | just reupload it with the same name, it'll replace the theme. |
| 03:50:17 | | Join Rob2222 [0] (~Miranda@p4FDCB472.dip.t-dialin.net) |
| 03:50:25 | S_a_i_n_t | you'll get a confirmation email, then it''l get replaced |
| 03:50:26 | gigatheme | what a novel idea! :D |
| 03:50:43 | gigatheme | didnt know that worked that way |
| 03:50:50 | * | S_a_i_n_t bows graciously |
| 03:51:28 | S_a_i_n_t | it was added *fairly* recently, I think because admins got sick of people asking "hay, I messe *this* up, can you replace X with Y"? |
| 03:53:43 | | Quit Rob2223 (Ping timeout: 252 seconds) |
| 03:53:47 | gigatheme | that would get annoying |
| 03:54:02 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 03:55:56 | | Join evilnick_ [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 03:58:36 | | Quit perfectdrug_ (Read error: Operation timed out) |
| 03:58:40 | | Quit evilnick (Ping timeout: 248 seconds) |
| 03:59:27 | S_a_i_n_t | gigatheme: I *finally* found the thread....missed it like 4 times looking for it. |
| 03:59:32 | S_a_i_n_t | http://forums.rockbox.org/index.php?topic=23648.0 should help |
| 03:59:35 | | Quit phanboy4 (Read error: Connection reset by peer) |
| 04:00 |
| 04:00:13 | | Quit panni_ (Read error: Connection reset by peer) |
| 04:00:17 | | Quit evilnick_ (Ping timeout: 248 seconds) |
| 04:00:21 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 04:01:16 | | Quit panni_ (Read error: Connection reset by peer) |
| 04:01:32 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 04:02:03 | | Quit froggyman (Quit: Goodnight moon!) |
| 04:03:10 | *** | Saving seen data "./dancer.seen" |
| 04:06:10 | gigatheme | what does RTC mean :S |
| 04:06:22 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 04:06:37 | S_a_i_n_t | Real Time Clock |
| 04:06:56 | * | S_a_i_n_t bows graciously |
| 04:07:00 | gigatheme | that makes sense :) |
| 04:07:35 | gigatheme | # Clock on RTC able targets, and disk access %V|-43|0|31|8|0|-|-| # align on the right with room for 5 SYSFONT digits %?cc<%?ca<%?St|time format|<%cH|%cI>:%cM|−−:−−>|> |
| 04:07:41 | | Quit Tomis (Quit: Tomis) |
| 04:08:00 | gigatheme | thats from the stock .sbs, and there it sets a viewport and uses 0 for system font |
| 04:08:25 | S_a_i_n_t | that .sbs *probably* isn't the bast to learn from...as it uses negative values for the viewport declaration |
| 04:08:37 | S_a_i_n_t | which can get confusion pretty quickly |
| 04:08:44 | S_a_i_n_t | well, I found it did anyway |
| 04:09:00 | gigatheme | yeah thats kinda weird but i its just screen width subtract value = +version |
| 04:09:25 | gigatheme | 240 - 43 = 197 |
| 04:09:31 | gigatheme | for gigabeat |
| 04:09:50 | S_a_i_n_t | ah...you are wise with the ways of the force young padawan :D |
| 04:10:36 | gigatheme | starwars fan? |
| 04:10:42 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 04:10:43 | | Quit evilnick (Read error: Connection reset by peer) |
| 04:10:46 | S_a_i_n_t | not really.... |
| 04:10:47 | S_a_i_n_t | lol |
| 04:10:50 | gigatheme | lol |
| 04:11:07 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 04:11:09 | | Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-lwemduzemodcajhr) |
| 04:11:50 | S_a_i_n_t | gigatheme: did you notice the # |
| 04:11:59 | gigatheme | comment |
| 04:12:04 | S_a_i_n_t | on those lines the # means they aren't read |
| 04:12:16 | S_a_i_n_t | aha...so you did. |
| 04:12:21 | gigatheme | yeah... i kinda got that already thanls though lol |
| 04:12:29 | gigatheme | thanks* |
| 04:12:59 | S_a_i_n_t | some people are like.."the code is right there!" why doesnt it work"...."remove the #"...."oh, right, lol" |
| 04:14:42 | gigatheme | if i set the clock viewport "%V||0|31|8|0|-|-|" with a foreground color, will it change the system font color inside of the clock viewport? |
| 04:15:33 | S_a_i_n_t | yep |
| 04:15:54 | gigatheme | excellent |
| 04:16:45 | gigatheme | you know off the top of your head (or deep within) how many pixels high the system font is? |
| 04:16:46 | S_a_i_n_t | I should've realised you've got a large DPI'd player when you were wanting to use the sysfont |
| 04:17:11 | * | S_a_i_n_t has a nano (well 5 of them actually), ans sysfont is almost IMPOSSIBLE to read :D |
| 04:17:30 | S_a_i_n_t | 8 high, 12 wide |
| 04:17:45 | S_a_i_n_t | *I think* |
| 04:17:53 | gigatheme | seems high |
| 04:17:53 | | Quit evilnick (Ping timeout: 248 seconds) |
| 04:18:15 | gigatheme | ah, i cna measure a screendump |
| 04:18:58 | S_a_i_n_t | I think sysfont is just 08-Schumacher-Clean |
| 04:19:04 | S_a_i_n_t | pretty sure it is anyway |
| 04:20:24 | S_a_i_n_t | there is *probably* a blank pixel on top/bottom of the font as well, to accomodate for "y" and such |
| 04:20:39 | S_a_i_n_t | but I'm pretty sure sysfont needs an 8px line |
| 04:21:07 | S_a_i_n_t | and that each char is fixed width to 12px |
| 04:21:42 | Unhelpful | saratoga: don't at least vorbis and mp3 have mdct error-tolerance specs? |
| 04:21:49 | | Quit TheSeven (Disconnected by services) |
| 04:22:02 | | Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) |
| 04:22:03 | gigatheme | well my top bar is 10px, so do i put it down 1y to center on the line, or do the invisible spaces make it 10 high and i put it a 0y |
| 04:22:05 | saratoga | Unhelpful: i don't think vorbis has any accuracy spec |
| 04:22:11 | saratoga | but mp3 does have conformance tests |
| 04:22:12 | | Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) |
| 04:22:23 | saratoga | but they test the entire decoder |
| 04:23:08 | saratoga | for our purposes its probably sufficient to just test a WMA file with the new and old transform and a Vorbis file with 4096 blocks |
| 04:23:22 | saratoga | between them, all block sizes will be used |
| 04:23:28 | S_a_i_n_t | gigatheme: 0y |
| 04:24:00 | Unhelpful | i'd say rather than tests on the audio a set of test coefficients and expected transform outputs would be good. the "expected" results could be computed via mdct on doubles, and compared to the mdct_exp outputs... +/- 1 we can dismiss as rounding error. or maybe i'm making it more complicated than it needs to be :/ |
| 04:24:02 | | Quit panni_ (Read error: Connection reset by peer) |
| 04:24:37 | saratoga | the current transform is abotu as accurate as IEEE754 single precision, so it should be the same thing i think |
| 04:26:02 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 04:26:04 | Unhelpful | single is still 24 bits of mantissa, i believe?i was just thinking the "desired" result set ought to be generated with doubles to guarantee that no rounding errors (except from conversion to fixed-point of the output) are visible |
| 04:27:57 | Unhelpful | remember, i optimize for the sake of optimization... and do the same thing w/ accuracy ;) |
| 04:28:01 | saratoga | doesn't hurt, but i don't think it matters |
| 04:28:13 | saratoga | as long as you're above ~10 bits no one can tell the difference |
| 04:29:05 | saratoga | I'd be pretty surprised if this version is less then 20 bits, baring algorithmic errors |
| 04:29:51 | Unhelpful | and those ought to be glaringly obvious if we have compare to even outputs of our current transform |
| 04:30:17 | saratoga | given the 1/2*log2(N) rounding error accumulation rule of thumb, we should expect ~26 bits |
| 04:30:39 | saratoga | (for fourier related transforms) |
| 04:30:41 | | Quit evilnick (Ping timeout: 248 seconds) |
| 04:31:07 | * | Unhelpful is actually not familiar w/ this particular rule of thumb... |
| 04:31:34 | Unhelpful | N = operations? |
| 04:31:51 | saratoga | points |
| 04:31:55 | saratoga | i've seen it around, but basically it just says you lose on average half a bit per level of divide and conquer in an fft like transform |
| 04:32:01 | saratoga | which i guess is kind of obvious |
| 04:32:55 | Unhelpful | ah, it's transform-specific? i've only worked on one transform, and i only reimplemented ijg's C exactly. |
| 04:32:56 | saratoga | i tend to think a split radix transform can do a bit better since its doing a lot fewer multiplies, but i'm not sure |
| 04:33:31 | | Quit gigatheme (Quit: CGI:IRC) |
| 04:34:34 | saratoga | ah yaeh, its for any sort of efficient fourier related transform |
| 04:34:37 | Unhelpful | and i still wonder if perhaps a more mac-friendly algorithm might be possible... i had very few opportunities to use mac or armv6's packed dual-multiply-and-add |
| 04:35:48 | saratoga | isn't the packed MAC half accuracy? |
| 04:37:33 | saratoga | on armv6 i tend to think the biggest problem is going to be cache performance, since we don't even pay attention to that on PP/CF |
| 04:37:49 | S_a_i_n_t | iPod Nano 1g (not sure if it makes a difference), where in the Dubug Info should I be looking to see if the player knows whether or not it is charging? |
| 04:38:27 | saratoga | does the debug screen actually show that? |
| 04:39:04 | saratoga | i expect it to know if you're on external power, but i'm not sure it would know what the battery is doing since IIRC that target has a hardware charger |
| 04:39:09 | S_a_i_n_t | According to Torne |
| 04:39:13 | | Join Tomis [0] (~Tomis@70.134.92.60) |
| 04:39:23 | saratoga | well if you know its there just look |
| 04:39:55 | Unhelpful | saratoga: all of the constants are 16-bit. were in the original code. as are the inputs. |
| 04:40:06 | S_a_i_n_t | %?bp and %?bc arent working...and he told me to check the debug screen to see if it was registering the charge there or not... |
| 04:40:13 | S_a_i_n_t | if it is there, I keep missing it. |
| 04:40:13 | saratoga | for MDCT or something else? |
| 04:40:35 | | Quit anewuser (Quit: Another edition of chiptune gig WinterChip5! :O http://xrl.us/WinterChipV =ooo) |
| 04:40:41 | Unhelpful | ah, no, the transform i worked on for arm is ijg's jpeg idct |
| 04:41:16 | Unhelpful | for audio i'd say we can pretty much never use those lovely armv5e and armv6 bits :/ |
| 04:41:58 | saratoga | you probably could, but it would require some effort |
| 04:42:14 | saratoga | a lot of the old ATRAC players for instance used 16 bit precision DSPs |
| 04:42:22 | | Quit Sajber^ (Read error: Connection reset by peer) |
| 04:42:41 | saratoga | and very carefully chose where to use 48 bit software emulated operations and where to use 16 bit ones in the MDCT |
| 04:44:12 | saratoga | or can you not do a packed 16x16=32,16x16=32 mul? |
| 04:45:47 | | Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) |
| 04:46:54 | Unhelpful | saratoga: no, they're 16x16=32. there's also 16x32=48>>16 |
| 04:47:10 | | Quit Barahir (Ping timeout: 246 seconds) |
| 04:47:12 | saratoga | wow |
| 04:47:27 | saratoga | you could make that work in the mdct i think with pretty good accuracy |
| 04:47:28 | Unhelpful | they're all great if you can use them, since from arm9e on there's no early termination and the multiplier is 32x16 |
| 04:48:20 | saratoga | i thought 9E had a fully pipelined mul? |
| 04:48:55 | saratoga | you could rescale the trig constants so they're all 15-16 bit, do the pre/post mul in steps with different scale factors to account for the prescale |
| 04:48:59 | | Join Barahir [0] (~jonathan@gssn-5f756ff5.pool.mediaWays.net) |
| 04:49:01 | Unhelpful | some multiply instructions still have worse than 1c throughput |
| 04:49:39 | | Quit evilnick (Client Quit) |
| 04:50:26 | | Quit n17ikh (Ping timeout: 256 seconds) |
| 04:50:42 | Unhelpful | mull/mlal are 3c, mul/mla are 2c... i believe all multiplies with an operand that is explicitly half-word are 1c throughput |
| 04:52:02 | saratoga | yeah but its fully pipelined, so its just an interlock and not a stall |
| 04:52:02 | Unhelpful | hrm, except for smlalxy, but that's 16x16=32 with a 64-bit accumulate |
| 04:52:41 | | Quit komputes (Ping timeout: 252 seconds) |
| 04:53:13 | Unhelpful | i wouldn't think so, those multiplies all have a further cycle of latency, so i take the table to mean that it actually takes 2 cycles to do mul/mla |
| 04:54:31 | Unhelpful | arm11 gets even worse w/ latency, most multiply instructions have no results available for 2c after execution |
| 04:55:07 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 04:55:23 | | Join midgey [0] (~tjross@rockbox/developer/midgey) |
| 04:55:50 | Unhelpful | and mull goes from 1c delay for rdhi on arm9e to 1c delay for rdlo, 2c for rdhi :/ |
| 04:56:37 | saratoga | "The ARM9E adds a 32 x 16 MAC unit (two-cycle latency with single-cycle throughput)" |
| 04:56:54 | saratoga | although i admit the pipeline diagram makes it look like there should be 2 cycle throughput |
| 04:57:05 | Unhelpful | saratoga: but 32x32 multiply (mul) is two operations on that unit |
| 04:57:30 | saratoga | but the manual says the first half happens in the execute stage, while the second half happens in the memory stage of the pipeline |
| 04:57:36 | Unhelpful | i'm still tempted to try a goldschmidt divider on arm11 again, it wasn't quite as fast but i never really tuned it much... and it does much more in parallel w/ fewer stalls on results |
| 04:57:48 | saratoga | if it really used the multiplier twice i don't think they'd say the stage advanced |
| 04:58:31 | Unhelpful | but it's 32x16, how *can* it perform a 32x32 multiply in one pass? |
| 04:59:10 | midgey | saratoga: i have some test_codec results for the mdctexp branch for the gigabeatf and e200 if you're interested |
| 04:59:43 | saratoga | Unhelpful: i assumed its actually two multipliers, one in the exec, and one in the mem stage |
| 04:59:55 | saratoga | midgey: sure, pastebin them |
| 05:00 |
| 05:00:16 | | Quit MethoS- (Remote host closed the connection) |
| 05:00:38 | Unhelpful | saratoga: ah. i must admit we're at the limit of my knowledge of processor design here... the cycle timings i have came from the arm system developer's guide, which has them in very handy tables :) |
| 05:01:02 | saratoga | yeah i looked at the tables now, just am not sure what they mean :) |
| 05:01:10 | | Join vegtoruci [0] (~vegtoruci@pool-96-246-120-217.nycmny.east.verizon.net) |
| 05:02:14 | Unhelpful | ah, the tables in the ASDG are not very hard to follow, there's a "cycles" column that they pretty clearly mean to indicate throughput, and a "notes" column with any other caveats that mentions latency on the arm9e, and also early registers on arm11 |
| 05:02:53 | Unhelpful | longer multiply latency on arm11 *and* multiplier inputs as early regs make algorithms that do many chained multiplies rather bad on it :/ |
| 05:02:58 | midgey | saratoga: http://rockbox.pastebin.ca/1792203 <- gigaf mdctexp |
| 05:03:09 | midgey | http://rockbox.pastebin.ca/1792204 <- gigaf trunk |
| 05:03:45 | midgey | i used r24576 for both, which is a bit unfair seeing as how trunk has had some optimizations to various codecs |
| 05:04:58 | saratoga | midgey: FWIW only vorbis and wma have the new mdct enabled |
| 05:05:02 | saratoga | the other codecs still use the old |
| 05:05:31 | midgey | well then you have a lot of useless data :) |
| 05:05:35 | saratoga | both vorbis and wma are 1-3 MHz faster |
| 05:05:43 | | Quit FOAD (Ping timeout: 246 seconds) |
| 05:05:50 | saratoga | midgey: update the codec performance wiki page, no one has done the gigabeat f since 2007 IIRC |
| 05:06:06 | midgey | will do |
| 05:06:09 | saratoga | for bonus points do the % improvement column |
| 05:06:22 | saratoga | Unhelpful: i guess you're right, thats really a let down |
| 05:06:22 | Unhelpful | the arm11 manual is similar, it says mul/mla are 2c, mull/mlal 3c, and the tiny muls are 1c. oddly the instructions that perform two 16x16=32 multiplies are *also* 1c... perhaps the multiplier on arm11 is "really" two 16x16 multipliers which may operate in parallel? |
| 05:07:01 | saratoga | yes I assumed the option to do 2x 16x16 meant there was actually a pair of pipelined 16 bit multipliers |
| 05:07:11 | saratoga | but apparently not |
| 05:07:24 | saratoga | i suppose this would explain why PP can keep up with the newer ARM targets |
| 05:07:37 | saratoga | i always wondered why it doesn't get destroyed if the multiplier is really 4x faster |
| 05:07:53 | saratoga | well probably more like 2-3x faster if early termination is taken into account |
| 05:08:11 | Unhelpful | saratoga: it's still never *slower* than arm7tdmi, and you can have 1c multiplies if you can wait for the results and both inputs are 16bit, or if you want to multiply-and-shift a 32-bit value by a 16-bit one. |
| 05:08:43 | Unhelpful | but i suspect a *large* number of cycles in the new divider are spent stalled on arm11 |
| 05:09:06 | saratoga | i wonder why cook_stereo_32 is more then two times faster then cook_stereo_64 |
| 05:09:06 | midgey | saratoga: http://rockbox.pastebin.ca/1792206 <- e200 mdctexp |
| 05:09:14 | saratoga | i wonder if the files are misnamed |
| 05:09:21 | midgey | with only wma and vorbis this time |
| 05:09:42 | saratoga | 300.94% realtime for 128k WMA |
| 05:09:43 | saratoga | amazing |
| 05:09:55 | saratoga | my first test of the codec was only 80% realtime on PP |
| 05:10:12 | midgey | excellent work all around |
| 05:10:25 | midgey | i can test on h300 if you'd like, but i'd need someone to provide me with a build |
| 05:10:40 | midgey | i haven't figured out how to compile gcc 3.4.6 on snow leopard yet.... |
| 05:11:24 | Unhelpful | ok, bed for me :P |
| 05:11:35 | saratoga | midgey: lets wait until the XNPROD31_R ASM for CF is fixed |
| 05:11:45 | saratoga | the results will be a little slower right now |
| 05:12:21 | midgey | yep, i assumed as much. just ping me or leave a message in the logs |
| 05:12:21 | saratoga | i'll try and fix it tomorrow if stripwax doesn't first, i have to get some work done now |
| 05:12:26 | saratoga | ok great |
| 05:12:36 | saratoga | good to know we're faster on the F |
| 05:12:37 | | Join FOAD [0] (~dok@dinah.blub.net) |
| 05:12:48 | saratoga | little more work on CF and we'll probably be faster on all targets |
| 05:13:02 | saratoga | then i guess we check accuracy and roll out the lib |
| 05:13:09 | midgey | i have a mini2g and ipod4g i can test on if it's useful |
| 05:13:10 | saratoga | and of course switch all the other codecs over to it |
| 05:13:15 | midgey | those are both pp5022 iirc |
| 05:13:22 | saratoga | isn't the 4G 5020? |
| 05:13:24 | midgey | so not too different than e200 |
| 05:13:27 | saratoga | that might be neat, IIRC it has less IRAM |
| 05:13:41 | saratoga | though i guess still enough that the lib will perform the same |
| 05:14:36 | midgey | you're right on the 4g, it has a pp5020 |
| 05:19:47 | saratoga | might be worth checking if it compiles and links |
| 05:19:54 | CIA-88 | New commit by jdgordon (r24578): Fix FS #10983 - r24568 was just moronic. Sorry |
| 05:21:13 | midgey | saratoga: i'm charging the 4g right now. i'll do a build with the same revision tomorrow |
| 05:21:34 | saratoga | midgey: just checked, it links fine, so probably not worth testing |
| 05:22:20 | saratoga | the only other really interesting targets to test on are the IPod < 4G and the gigabeat S |
| 05:23:11 | midgey | unfortunately i don't have any of those, the pp5002 targets will be interesting |
| 05:23:48 | saratoga | i'll do 3G later, need to get to work |
| 05:23:56 | saratoga | unhelpful can probably do the beast |
| 05:25:17 | | Quit saratoga (Quit: Page closed) |
| 05:41:32 | | Quit fyrestorm (Quit: lamers envy me like they envy bill g -- main boot xp, just the way it should be!) |
| 05:44:38 | | Join flyback [0] (~teac@c-98-219-129-239.hsd1.pa.comcast.net) |
| 05:53:08 | CIA-88 | New commit by jdgordon (r24579): OK, this is hopefully the last sbs related fix. This one will fix the backdrop going garbage, and add a missing else which kugel spotted |
| 06:00 |
| 06:03:13 | *** | Saving seen data "./dancer.seen" |
| 06:25:45 | | Join Guest23293 [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 06:25:55 | | Quit n17ikh (Disconnected by services) |
| 06:25:59 | | Quit Guest23293 (Client Quit) |
| 06:26:19 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 06:34:00 | | Quit dmb_ (Quit: Leaving) |
| 06:35:50 | | Quit jd (Read error: Connection reset by peer) |
| 06:36:08 | | Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 06:36:08 | | Quit jd (Changing host) |
| 06:36:08 | | Join jd [0] (~jd@Wikipedia/HellDragon) |
| 06:58:46 | | Quit midgey (Quit: midgey) |
| 07:00 |
| 07:00:12 | | Join DomasoFan [0] (~c2d0e4c8@giant.haxx.se) |
| 07:02:17 | DomasoFan | Hi. does someone know if the Sansa Fuze with the following model is a Sansa Fuze v1?: SDMX14R-008GK-E57 |
| 07:05:02 | | Quit DomasoFan (Client Quit) |
| 07:22:10 | | Quit HBK (Read error: Connection reset by peer) |
| 07:22:43 | | Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) |
| 07:23:11 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 07:23:15 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 07:49:30 | JdGordon | http://imagebin.ca/img/cje-32u.bmp multifont? |
| 07:49:33 | JdGordon | not quite :p |
| 07:50:06 | | Quit gevaerts (Disconnected by services) |
| 07:50:18 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 07:57:21 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:00 |
| 08:03:15 | *** | Saving seen data "./dancer.seen" |
| 08:10:12 | | Quit vegtoruci (Ping timeout: 260 seconds) |
| 08:23:31 | | Join dmb [0] (~Dmb@unaffiliated/dmb) |
| 08:30:39 | JdGordon | http://imagebin.ca/img/tarYa-a.bmp <- working multifont |
| 08:31:37 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 08:31:54 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 08:46:02 | | Join JdGordon1 [0] (~jonno@c-24-22-210-83.hsd1.wa.comcast.net) |
| 08:46:09 | | Quit JdGordon (Ping timeout: 256 seconds) |
| 08:51:45 | | Join flydutch [0] (~flydutch@host66-209-dynamic.15-87-r.retail.telecomitalia.it) |
| 09:00 |
| 09:00:47 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:01:09 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 09:06:39 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 09:12:40 | JdGordon | does anyone tihnk 10000 is too small for multifont for the fonts loaded by skins? (thats 10K each font) |
| 09:13:03 | | Join kugel [0] (kugel@rockbox/developer/kugel) |
| 09:15:02 | kugel | JdGordon: I noticed you're changing the settings string directly |
| 09:15:12 | JdGordon | which? where? |
| 09:15:26 | kugel | *ptr2 = '|'; |
| 09:16:00 | JdGordon | no, its copied to a buffer first |
| 09:16:33 | kugel | ptr2 = global_settings.ui_vp_config; |
| 09:17:17 | JdGordon | yes, keep reading |
| 09:17:30 | JdGordon | len = snprintf(ptr, remaining, "%%ax%%Vi|%s|\n", ptr2); |
| 09:17:36 | JdGordon | while ((ptr2 = strchr(ptr, ','))) |
| 09:17:47 | JdGordon | and ptr = buf; at the top |
| 09:17:56 | | Quit Adub- (Quit: <Tobin> japanese men make hot trannies) |
| 09:18:09 | kugel | ptr is the other buffer yes, but you're writing to ptr2 |
| 09:18:41 | | Quit JdGordon1 (Ping timeout: 248 seconds) |
| 09:18:51 | kugel | you make the ui viewport setting look like "ui viewport: 5|1|30|2|2|ffffff|000000" |
| 09:19:46 | pixelma | do we really need an ui viewport setting anymore? |
| 09:19:48 | JdGordon | no, its ptr2 is pointing inside the buf buffer |
| 09:20:39 | kugel | huh? |
| 09:20:42 | JdGordon | pixelma: IMO we never did. but yeah, we may as well keep it |
| 09:20:51 | pixelma | which is a hidden setting and therefore only known by 10 people or so :/ |
| 09:20:52 | JdGordon | are we looking at the same code? |
| 09:21:14 | kugel | yes |
| 09:21:23 | kugel | ptr2 is pointing to the settings string |
| 09:22:57 | JdGordon | yes |
| 09:23:08 | JdGordon | which ois then snpriontf()'ed into ptr which points to the new buffer |
| 09:23:30 | kugel | that doesn't change where it's pointing to |
| 09:23:40 | kugel | it's still pointing to the settings string |
| 09:24:11 | JdGordon | while ((ptr2 = strchr(ptr, ','))) |
| 09:24:45 | JdGordon | are you actually seeing the |'s in the .cfg file? |
| 09:24:57 | kugel | ah right, I'm sorry |
| 09:25:52 | | Join dmb_ [0] (~Dmb@unaffiliated/dmb) |
| 09:26:29 | pixelma | I could understand dropping the ui viewport setting much much more than dropping any other theme menu items I can currently think of because colours or backdrop are easily set on device and the menu items speak for themselves. The ui viewport setting is hidden and if you would want to adjust it on device it's as complicated as editing an sbs file with just the %Vi |
| 09:26:33 | kugel | did that commit also fix that the ui viewport is ignored? |
| 09:27:17 | kugel | pixelma: the ui viewport is for when you don't use a sbs |
| 09:27:54 | pixelma | but it can easily replaced by using the most simple sbs |
| 09:27:56 | kugel | removing it doesn't gain anything, it's impact on the code is about 10 lines |
| 09:28:07 | JdGordon | http://imagebin.ca/img/60lPObu.bmp working multifont :) |
| 09:28:37 | JdGordon | kugel: the missing else? yes |
| 09:28:50 | JdGordon | pixelma: I want to add a UI for setting the ui viewport |
| 09:29:13 | kugel | JdGordon: I rather thought about the missing trailing | that as fixed |
| 09:29:20 | kugel | was* |
| 09:29:26 | JdGordon | thats what caused the background garbage |
| 09:29:33 | JdGordon | I didnt realise the setting didnt have it |
| 09:29:41 | JdGordon | hence my commit message |
| 09:29:45 | kugel | we had multifont "working" long ago so your screenshot doesn't thrill me |
| 09:30:15 | kugel | I haven't looked at the patch but after what you're saying I'm not a fan as well (but I won't object, I want multifont as well) |
| 09:31:10 | pixelma | not sure if the intersection thing is still there which complicates things. And it also complicates understanding theme settings as you have two ways to achieve the same thing and might hit a situation where "a" doesn't work as you expect because "b" is in place and takes priority |
| 09:31:41 | JdGordon | the intersection thing is gone |
| 09:31:52 | JdGordon | and /me pokes his tounge out at kugel :p |
| 09:33:21 | JdGordon | I dont know how you can not like this method. 0 wasted RAM if you dont use it (well almost 0 anyway), theoretically unlimited fonts |
| 09:33:28 | JdGordon | makes the font cache more clever |
| 09:36:49 | kugel | I single buffer would be most clever |
| 09:37:55 | JdGordon | wtf? does the .glyphcache file only cache the glyph numbers? and not the actual glyph bits? |
| 09:38:09 | JdGordon | 1 buffer would be MUCH more complicated |
| 09:38:29 | JdGordon | and not ever big enough to satisfy everyone, and too big for others |
| 09:39:02 | kugel | it could also grow and shrink with the number of fonts |
| 09:39:13 | kugel | the lru mechanism works best in a single buffer |
| 09:40:08 | kugel | the glyph cache probably only saves the index; it's just for letting the lru survive a shutdown |
| 09:41:33 | JdGordon | yeah, it makes sense, its just thats not what I ever thought it was doing |
| 09:42:23 | JdGordon | and no, a single buffer doesnt make lru any better |
| 09:42:44 | JdGordon | it might make the overall buffer more efficient though\ |
| 09:47:58 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
| 09:52:59 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 09:53:12 | | Quit kugel (Ping timeout: 264 seconds) |
| 09:57:21 | | Join Speedy1 [0] (~Speedy@bzq-79-180-18-85.red.bezeqint.net) |
| 09:57:22 | Speedy1 | www.search2.net |
| 09:57:59 | | Part Speedy1 |
| 10:00 |
| 10:00:15 | | Quit amiconn (Disconnected by services) |
| 10:00:17 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 10:00:39 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 10:03:18 | *** | Saving seen data "./dancer.seen" |
| 10:12:04 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
| 10:13:05 | | Quit AndyIL (Ping timeout: 248 seconds) |
| 10:14:35 | S_a_i_n_t | pixelma: I see your point with the UI Viewpoint, but I think not dropping it as an option is more to do with not forcing people to use an .sbs |
| 10:14:48 | S_a_i_n_t | *note the "I think* however. |
| 10:15:20 | | Join Curulan [0] (~zarggg@2001:0:4137:9e74:0:96f8:beb1:ba3d) |
| 10:15:26 | | Quit Zarggg_ (Read error: Connection reset by peer) |
| 10:19:02 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 10:23:13 | | Quit AndyI (Ping timeout: 248 seconds) |
| 10:23:52 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 10:33:42 | | Join PaulJam__ [0] (~Paule@p54BEC922.dip.t-dialin.net) |
| 10:38:28 | | Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 10:41:24 | | Quit Curulan (Ping timeout: 260 seconds) |
| 10:42:49 | pixelma | S_a_i_n_t: well, it's been discussed to drop other theme settings too. To be exact: not the setting but the menu items, the settings will still be there but hidden which is worse and the ui viewport setting didn't ever make it into the menu. |
| 10:49:21 | S_a_i_n_t | to be honest, I'm not much of a fan of dropping the other theme settings from the menu... |
| 10:49:34 | S_a_i_n_t | but I do think UI Viewport should stay as a .cfg option |
| 10:49:45 | S_a_i_n_t | it's not doing any harm to those that don;t use it. |
| 10:50:10 | S_a_i_n_t | many I'm having bad luck with ; vs. ' today... |
| 10:53:02 | | Join _zic [0] (~user@91-165-251-120.rev.libertysurf.net) |
| 10:53:41 | S_a_i_n_t | Oh, wait...by me saying "not dropping it as an option", I didn't mean a menu option (as I know there isn't one), what I meant was the option to configure it via .cfg that I think should stay. |
| 11:00 |
| 11:06:36 | pixelma | I also want the other menu items to stay, at least as long as there is no other way of easily adjusting colours or stuff like that (via a plugin or so). But for ui viewport and an sbs with %we and your %Vi - I don't see a difference especially if the former stays a hidden setting - and then having two things doing the same can't be good. |
| 11:13:15 | S_a_i_n_t | there's probably more than one instance of "more than one way to do the same thing"...in fact there is, by that respect, anything that has a .cfg setting should be booted out of the menu. Or perhaps sleep deprivation has my thinking somewhat backward as to what you're suggesting. |
| 11:14:09 | gevaerts | Uhm, "anything that has a .cfg setting should be booted out of the menu" means "remove the settings menu" |
| 11:15:28 | S_a_i_n_t | that was kinda my point, but a hint of sarcasm need be implied also. |
| 11:15:40 | S_a_i_n_t | more than a hint actually |
| 11:17:14 | S_a_i_n_t | long story short, IMHO UI Viewport should stay in the .cfg until there's a better way to do it, and probably even if there is. |
| 11:22:19 | pixelma | huh? I think that's reverse - your "even" would be my only "if that happens then there might be one reason for it to stay". SBS is already another way to do it, not better but not worse (which is my point that other settings being cfg one only will be worse than what there is now, try chosing a different background colour if it is only a cfg file setting, getting your hex number out of thin air and only seeing the result after getting back and forth |
| 11:22:19 | pixelma | a few times usig the text editor. |
| 11:22:45 | AlexP | I did a battery bench on my clip last night - 09:02 |
| 11:24:46 | pixelma | no-one explained to me yet where the difference between ui viewport and such a simple sbs is (other than maybe the %we line), adjusting coordinates on target would be exactly the same |
| 11:25:05 | S_a_i_n_t | what I meant by "even if there is" is that it probably has the potential to give a lot of support related grief, like "why is my menu now only 1px wide" so on and so forth. |
| 11:25:36 | S_a_i_n_t | It's probaby better (for now) if themers handle the UI Viewport |
| 11:26:22 | pixelma | how? |
| 11:26:25 | S_a_i_n_t | and the difference is, not forcing people to use .sbs |
| 11:27:01 | S_a_i_n_t | at the moment, if you want UI viewport, but not an .sbs..you can. |
| 11:27:51 | pixelma | but the sbs would only be "use this %Vi" as ui viewport, nothing else |
| 11:27:51 | S_a_i_n_t | don;t get me wrong, I can see your point (and I think it's valid too), but there are two sides to a coin. |
| 11:28:21 | S_a_i_n_t | but it still forces an action, which isn't good IMO |
| 11:28:58 | * | gevaerts still thinks that *if* independently designed .sbs and menu backdrop are supposed to be supported, the intersection method is the only working solution |
| 11:29:01 | pixelma | what action (more than setting an ui viewport)? |
| 11:30:51 | S_a_i_n_t | this could go back and forth for a long time, so /me decides to drop it. |
| 11:31:10 | pixelma | I mean compared to editing the cfg file - where is a difference in "action" to editing an sbs file? |
| 11:31:17 | S_a_i_n_t | whilst retaining his opinion of course. |
| 11:31:36 | S_a_i_n_t | having to have an .sbs in the first place. |
| 11:31:45 | S_a_i_n_t | EVERYONE has a cfg |
| 11:31:55 | S_a_i_n_t | a LOT of people don't have .sbs's |
| 11:32:29 | S_a_i_n_t | (apparently dropping it isn;t an opyion) :P |
| 11:32:38 | pixelma | you would have to add a ui viewport line (and have to know the syntax) |
| 11:33:03 | S_a_i_n_t | UI viewport line is always in the .cfg |
| 11:33:08 | S_a_i_n_t | just with no options |
| 11:33:17 | S_a_i_n_t | ui viewport: - |
| 11:36:10 | pixelma | only if you save a full cfg and then I still have to know the syntax for the coordinates etc. |
| 11:36:46 | S_a_i_n_t | you need to know the syntax for .sbs also...it's totally double edged |
| 11:36:54 | S_a_i_n_t | nooone's going to be happy apparently |
| 11:38:21 | S_a_i_n_t | be back in 5 mins... |
| 11:38:23 | | Quit S_a_i_n_t (Quit: [St.] has exited mIRC™) |
| 11:39:02 | pixelma | yes, which is why I don't see a difference and sbs giving more power |
| 11:39:58 | | Quit bug2000 (Read error: Operation timed out) |
| 11:40:45 | gevaerts | Unless the sbs specifies the backdrop to use (does it these days? I haven't really followed closely), there should be a not-in-sbs way to specify the viewport |
| 11:42:02 | gevaerts | That way *should not* be used by themes, it's the way you adjust things if whatever viewport settings that come with the sbs/skin are not compatible with the backdrop the user selected |
| 11:42:06 | pixelma | it can |
| 11:42:29 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.240) |
| 11:42:41 | S_a_i_n_t | back |
| 11:43:30 | pixelma | but if you don't specify a backdrop, the main backdrop set through the menu is used (or that was the plan) |
| 11:43:34 | | Join evilnick [0] (~evilnick@rockbox/staff/evilnick) |
| 11:44:11 | * | S_a_i_n_t thinks he's missed some of this conversation... |
| 11:45:35 | * | pixelma points S_a_i_n_t to the topic |
| 11:45:45 | liar | i dont hear sound from rockboy - is it disabled for my target? (nano2g) |
| 11:45:54 | Torne | S_a_i_n_t: i did tell you exactly where the battery status was btw :) |
| 11:46:11 | Torne | S_a_i_n_t: if you didn't find it yet, the secret is that the "view battery" screen, with the graph, has multiple pages: scroll the wheel to see the others |
| 11:46:15 | S_a_i_n_t | in debug isn;t that exact... |
| 11:46:16 | gevaerts | ok. My view is that as long as that is supported, there should also be a non-sbs way to specify the viewport, and I think it should be as easy to use as the backdrop setting (i.e. not .cfg-only) |
| 11:46:43 | S_a_i_n_t | gevaerts: exactly |
| 11:46:46 | Torne | S_a_i_n_t: I told you to scroll down on the view battery screen |
| 11:46:56 | S_a_i_n_t | gevaerts argues a point a LOT better than I do apparently |
| 11:46:58 | Torne | so yes, it was exact :) |
| 11:48:14 | gevaerts | My reason for that is that you want to be able to update a theme from the theme site without having to re-do half of your local settings again (the other half being the backdrop itself) |
| 11:49:14 | S_a_i_n_t | Torne; I couldn't tell what it was I was supposed to be looking at "battery, power status, voltage delta or Last PowerHist) |
| 11:49:44 | Torne | er |
| 11:50:24 | Torne | is it not self-explanatory? |
| 11:50:38 | S_a_i_n_t | apparently not. |
| 11:50:58 | Torne | Aha |
| 11:51:11 | Torne | the screen i was directing you to is ifdef'ed for IPOD_NANO || IPOD_VIDEO |
| 11:51:15 | Torne | interesting |
| 11:51:48 | S_a_i_n_t | yeaH, someone else said your theory wouldn;t work (scorche maybe?) but I wanted to ask you... |
| 11:52:02 | S_a_i_n_t | F'N SEMICOLON!!! |
| 11:52:03 | Torne | that is odd, though, i'm pretty sure it should be available |
| 11:52:23 | Torne | which model is yours again? |
| 11:52:34 | S_a_i_n_t | and I'm guessing *that's* what %bp and %bc don;t work on the Nano |
| 11:52:42 | S_a_i_n_t | 1gen Nano |
| 11:52:43 | Torne | Wait, you have a nano1g? |
| 11:52:49 | S_a_i_n_t | havent tried the 2geb yet |
| 11:52:51 | Torne | the debug screen is enabled on IPOD_NANO |
| 11:52:55 | S_a_i_n_t | but I assume it's the same |
| 11:52:55 | Torne | so it should be right there |
| 11:53:04 | Torne | i thought you had a mini or something |
| 11:53:19 | S_a_i_n_t | nope...nano |
| 11:53:22 | S_a_i_n_t | 5 in fact |
| 11:53:25 | Torne | Power status screen |
| 11:53:42 | Torne | should list USB pwr, EXT pwr, Battery |
| 11:53:54 | Torne | USB pwr should be obvious.. |
| 11:54:01 | Torne | battery says charging/charged/discharging |
| 11:54:05 | Torne | which should be obvious also :) |
| 11:54:13 | Torne | ext pwr I believe is the 12V from the firewire pins? |
| 11:54:53 | Torne | are those lines not there for you? |
| 11:55:19 | S_a_i_n_t | no |
| 11:55:31 | Torne | Well, er |
| 11:55:34 | Torne | they are supposed to be |
| 11:55:45 | S_a_i_n_t | nothing changes in the power status screen except the voltage jumps slightly |
| 11:55:54 | S_a_i_n_t | after watching it for a few seconds though |
| 11:55:59 | Torne | Those lines should be there all the time |
| 11:56:06 | S_a_i_n_t | but the lines your talking about aren;t ther at all |
| 11:56:14 | Torne | well they're defined for nano and video |
| 11:56:23 | Torne | likewise the lines in power-ipod.c which return the charger status |
| 11:56:32 | Torne | which should be what drives the wps tokens |
| 11:56:42 | S_a_i_n_t | I can screendump if you want me to confirm I'm not an idiot..it may help |
| 11:56:45 | Torne | so yes i am pretty certain it should work. |
| 11:56:46 | S_a_i_n_t | just in case am |
| 11:57:15 | Torne | the screen starts with "Power status:" |
| 11:57:24 | Torne | then a line with "Battery: 3.6V" or whatever |
| 11:57:25 | Torne | yes? |
| 11:57:32 | Torne | those are unconditional for all targets so that *must* be there :) |
| 11:57:33 | S_a_i_n_t | yep |
| 11:57:41 | Torne | Hmm |
| 11:57:48 | Torne | there should be like 5-6 more lines |
| 11:57:48 | S_a_i_n_t | yes, and it just says Battery: *voltage |
| 11:58:13 | S_a_i_n_t | screendump? |
| 11:58:28 | Torne | no need.. |
| 11:58:32 | Torne | i have a theory |
| 11:59:17 | Torne | hm. mayhbe not. |
| 11:59:19 | Torne | bizarre. |
| 12:00 |
| 12:00:14 | Torne | back in a sec |
| 12:01:04 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.240) |
| 12:01:31 | S_a_i_n_t_ | shit, sorry...pressed X instead of minimise |
| 12:02:12 | S_a_i_n_t_ | I have a file on the root of my player called identify_info |
| 12:02:17 | S_a_i_n_t_ | not rb related? |
| 12:02:27 | S_a_i_n_t_ | I've never seen it before |
| 12:03:19 | *** | Saving seen data "./dancer.seen" |
| 12:04:34 | * | gevaerts accuses S_a_i_n_t_ of having selected random debug menu items :) |
| 12:05:07 | S_a_i_n_t_ | ssssshhhhh you :P |
| 12:05:46 | S_a_i_n_t_ | http://imgur.com/USku4.png |
| 12:05:56 | S_a_i_n_t_ | and no, it's not photochopped :P |
| 12:08:34 | S_a_i_n_t_ | Hmmmm...ok, so identify_info *is* Rb related...but what is it? |
| 12:08:40 | S_a_i_n_t_ | can I kill it? |
| 12:09:12 | | Join kugel [0] (kugel@rockbox/developer/kugel) |
| 12:16:27 | | Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) |
| 12:18:58 | archivator | Could someone please take a look at fs#10065 and my last comment on there? I would really like to see that task closed.. |
| 12:21:03 | gevaerts | archivator: if nobody beats me to it, I'll have a look tonight |
| 12:22:00 | archivator | Thanks, gevaerts :) |
| 12:22:11 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 12:22:56 | Torne | S_a_i_n_t: OK, I cannot find any reason why the nano1g shouldn't display that info. |
| 12:23:09 | Torne | S_a_i_n_t: it is indeed not present on any *other* ipod |
| 12:23:10 | S_a_i_n_t_ | well...it doesn;t. |
| 12:23:20 | S_a_i_n_t_ | guess I need to file a bug report then? |
| 12:23:21 | Torne | only nano1g and video (nano2g has its own different info there) |
| 12:23:49 | Torne | Ohhhh |
| 12:23:52 | Torne | There we go :) |
| 12:23:56 | Torne | nano1g doesn't define CONFIG_CHARGING |
| 12:23:59 | Torne | which is why none of this works |
| 12:23:59 | S_a_i_n_t_ | found it? |
| 12:24:11 | * | S_a_i_n_t_ was beginning to think he was going insane |
| 12:24:25 | Torne | Hmm |
| 12:24:38 | Torne | the 4g/color/mini1g/mini2g/video all have CHARGING_MONITOR |
| 12:24:42 | Torne | but nano1g has nothing |
| 12:25:05 | S_a_i_n_t_ | *should* it have it? |
| 12:25:12 | S_a_i_n_t_ | I'm guessing so |
| 12:25:25 | Torne | I was under the impression that all those models, including nano1g, had approximately the same charging arrangement |
| 12:25:37 | Torne | same PCF, same charge controller, just mayhbe different GPIO pins used |
| 12:25:41 | Torne | but i might be wrong |
| 12:26:13 | Torne | the code for it is there in power-ipod.c |
| 12:26:14 | Torne | but it's ifdef'ed out as a result of not having CONFIG_CHARGING |
| 12:26:32 | Torne | try setting it to CHARGING_MONITOR in the config |
| 12:26:35 | Torne | and see if that even compiles |
| 12:27:07 | S_a_i_n_t_ | that may take a while...I'll get back to you :P |
| 12:27:23 | Torne | well i can see if it compiles, if you want, but i can't test it :) |
| 12:27:32 | | Quit liar (Ping timeout: 252 seconds) |
| 12:27:57 | S_a_i_n_t_ | then it may as wel be me, I can do both |
| 12:28:03 | S_a_i_n_t_ | it'll just take longer |
| 12:28:32 | Torne | meh, i'm building it now |
| 12:29:01 | S_a_i_n_t_ | send me the .diff if it works then :P |
| 12:29:15 | S_a_i_n_t_ | works/compiles |
| 12:29:16 | Torne | you can just have the build |
| 12:29:21 | Torne | if you want to try it :) |
| 12:29:50 | S_a_i_n_t_ | thank the "friendly neighbours" |
| 12:29:51 | S_a_i_n_t_ | :P |
| 12:30:18 | S_a_i_n_t_ | dammit, my tranfer rate is shocking was supposed to come before that |
| 12:30:48 | | Join teru [0] (~teru@KD059133108225.ppp.dion.ne.jp) |
| 12:31:29 | Torne | linuxstb: do you know why nano1g doesn't have CONFIG_CHARGING defined? |
| 12:31:40 | Torne | rockbox builds, i'll let it do the rest and make you a zip |
| 12:32:28 | S_a_i_n_t_ | upload it somewhere, don't bother with DCC...you'll get pissed off by my shitty transfer rate |
| 12:33:07 | * | S_a_i_n_t_ solved his semicolon problem by remapping the keyboard, prying both keys off and switching them :D |
| 12:33:18 | S_a_i_n_t_ | better than learning to type properly :D |
| 12:33:35 | gevaerts | Torne: r16124 might half-explain this |
| 12:33:36 | S_a_i_n_t_ | s/better/easier/ |
| 12:33:39 | Torne | upload? doesn't every computer everywhere have a webserver? |
| 12:34:46 | S_a_i_n_t_ | this is a "....buh?" moment for me. |
| 12:34:52 | Torne | gevaerts: hm. the video/nano have different gpios |
| 12:35:01 | Torne | but the code implies strongly that the video/nano work identically |
| 12:35:12 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 12:36:13 | gevaerts | So the question is why it wasn't enabled by r8966 |
| 12:36:19 | Torne | r19315 added nano support to power-ipod.c |
| 12:36:23 | Torne | but didn't change CONFIG_CHARGING |
| 12:37:38 | Torne | S_a_i_n_t: http://whitefang.wolfpuppy.org.uk/temp/rockbox-nanocharging.zip |
| 12:38:09 | linuxstb | Torne: I've no idea. Has it never been enabled? |
| 12:38:15 | Torne | linuxstb: it's neve rbeen enabled |
| 12:38:30 | Torne | r16124 implemented charging monitoring for 4g/mini/color |
| 12:38:37 | Torne | video came at some differnet point |
| 12:38:48 | Torne | then 19315 changed the ifdefs to make the video code cover nano as well |
| 12:38:58 | Torne | but nothing ever turned on CONFIG_CHARGING for nano so that code isn't used |
| 12:39:06 | Torne | i guess S_a_i_n_t can try it for us |
| 12:39:13 | S_a_i_n_t_ | yay! |
| 12:39:17 | S_a_i_n_t_ | usefullness! |
| 12:39:18 | Torne | what else does CONFIG_CHARGING affect? is there any chance it could make stuff go horribly wrong? |
| 12:39:47 | S_a_i_n_t_ | bah....nano's (ipods in general) are unbrickable |
| 12:40:02 | S_a_i_n_t_ | besides the hammer (and my newfound coffee) method |
| 12:40:22 | S_a_i_n_t_ | that nano never recovered....R.I.P |
| 12:40:49 | linuxstb | Torne: I've no idea about the power management stuff. I wouldn't have expected it to make much difference on the ipods, apart from cosmetic things like charging indicators. |
| 12:41:21 | Torne | Yah, it's only monitoring |
| 12:41:28 | rasher | That's not insignificant |
| 12:42:13 | S_a_i_n_t_ | so this *is* the reason my %bc/bp tags are broken?!? |
| 12:42:20 | Torne | yes, this is exactly the reason |
| 12:42:27 | S_a_i_n_t_ | aha... |
| 12:42:35 | Torne | currently the nano1g does not support *any* kind of charging status whatsoever |
| 12:42:40 | Torne | because it's not been turned on :) |
| 12:42:45 | * | S_a_i_n_t_ finally found a bug of interest, and not annoyance |
| 12:42:54 | Torne | the code is there and it compiles |
| 12:42:59 | Torne | so i guess it's just whether it *actually works* |
| 12:43:05 | Torne | i.e. displays the right status |
| 12:43:16 | S_a_i_n_t_ | I'll let you know in 10mins or so. |
| 12:46:52 | Torne | have you got something that provides 12V firewire power, also? |
| 12:47:07 | Torne | if so it would be good to check whether the EXT power changes appropriately when you insert that |
| 12:47:12 | Torne | car chargers usually do? |
| 12:47:44 | S_a_i_n_t | no, and nano isnt firewire anyway. |
| 12:48:29 | Torne | No, but it still accepts 12V power on the pins used by the firewire cable |
| 12:48:32 | Torne | all the ipods do |
| 12:48:42 | Torne | the data lines don't exist, no |
| 12:48:46 | Torne | Hm |
| 12:49:01 | Torne | FS #6891 suggests that the code *isn't* right and that the nano has different GPIOs for this |
| 12:49:04 | | Quit Tomis (Read error: Operation timed out) |
| 12:49:09 | Torne | so yes there is alrady a bug for this |
| 12:49:25 | | Join Tomis [0] (~Tomis@70.134.92.60) |
| 12:49:38 | S_a_i_n_t_ | ah...so this wont work? |
| 12:49:45 | Torne | It might |
| 12:49:46 | | Quit PaulJam__ (Read error: Connection reset by peer) |
| 12:49:48 | Torne | It depends who is right :) |
| 12:50:05 | S_a_i_n_t_ | we'll see very soon |
| 12:50:10 | Torne | FS #10591 has a patch which does exactly what i have just done, dreamlayers evidently was also assuming tha tthe code already in svn works |
| 12:50:45 | Torne | FS #6940 is also relevant |
| 12:50:46 | Torne | so, hm |
| 12:50:53 | Torne | there have been three different patches that claim to fix this |
| 12:50:54 | Torne | all different :) |
| 12:50:56 | Torne | HOORAY :) |
| 12:51:09 | S_a_i_n_t_ | yay! ....not |
| 12:52:18 | Torne | so i guess the next question is does anyone have a nano1g and both usb/firewire chargers and can get a multimeter appropriately attached? :) |
| 12:54:24 | Torne | Oh wait, no |
| 12:54:34 | Torne | the patches are all using the same GPIO pins as the current code after all |
| 12:54:46 | Torne | the ipodvideo code got changed since these patches were written :) |
| 12:55:23 | | Quit Hadaka (Ping timeout: 276 seconds) |
| 12:55:56 | Torne | so if this works for you we can probably commit it and close out all three of those bugs |
| 12:58:12 | | Join watto [0] (~watto@193.203.81.165) |
| 12:58:51 | S_a_i_n_t_ | fingers crossed... |
| 12:59:03 | S_a_i_n_t_ | transer |
| 12:59:35 | S_a_i_n_t_ | (usb) is slooooooow for some reason... |
| 13:00 |
| 13:00:30 | Torne | usb transfers being slow on ipods is a known issue, no? |
| 13:00:43 | Torne | the rockbox build is made of loads of tiny files, which is a worst-case for USB mass storage anyway |
| 13:01:11 | S_a_i_n_t_ | yeah...nano2g is about 100% faster than 1g |
| 13:01:34 | S_a_i_n_t_ | for transfer that is. |
| 13:01:52 | Galois | I never experienced much speed difference between the two |
| 13:02:12 | linuxstb | Torne: Apple's emergency disk mode is known to be slow on the nano1g and video. |
| 13:02:14 | S_a_i_n_t_ | i have, DRAMATIC difference |
| 13:02:36 | Galois | I don't use the emergency disk mode, but I do use the disk mode |
| 13:02:45 | Galois | or are they the same |
| 13:02:47 | Torne | linuxstb: wait, on the video? |
| 13:03:02 | S_a_i_n_t_ | Galois: yep |
| 13:03:03 | Torne | i've not noticed it being slow |
| 13:03:10 | Torne | ahwell *shrug* |
| 13:03:23 | Torne | i was talking about using rockbox usb, anyway |
| 13:03:45 | Galois | well, either way, rockbox usb or disk mode, it's as fast as any other usb device for me |
| 13:03:47 | S_a_i_n_t_ | fwiw...so was i |
| 13:04:02 | linuxstb | Galois: "emergency disk mode" is the disk mode built into Apple bootloader in the NOR flash (accessed by pressing SELECT+PLAY when booting, or if Rockbox reboots into it). The other disk mode is the version in Apple's main firmware. |
| 13:04:29 | * | gevaerts ignores all USB speed reports that do not have actual numbers and a description of the testing method |
| 13:04:41 | | Join Hadaka [0] (~naked@naked.iki.fi) |
| 13:05:52 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 13:05:54 | S_a_i_n_t_ | Torne: sorry man, debug still has the one option |
| 13:06:04 | Torne | er |
| 13:06:17 | S_a_i_n_t_ | battery that is... :D |
| 13:06:20 | Torne | that's definately impossible ;) |
| 13:06:37 | S_a_i_n_t_ | er...hang on |
| 13:07:25 | S_a_i_n_t_ | you fixed it!!! |
| 13:07:25 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 13:07:43 | Torne | you mean the wps tokens work? |
| 13:07:50 | Torne | what about the debug menu? |
| 13:08:02 | S_a_i_n_t_ | usb power, ext power, battery, charging, headphone! |
| 13:08:09 | Torne | Yup, that's what's supposed ot be there :) |
| 13:08:15 | S_a_i_n_t_ | YAY! |
| 13:08:25 | S_a_i_n_t_ | my ipod did a "first something" |
| 13:08:30 | * | S_a_i_n_t_ feels speciasl |
| 13:09:03 | S_a_i_n_t_ | wow....3 bugs with one commit...that's gotta be a first, or close to a record :D |
| 13:09:12 | Torne | Well, don't jump the gun |
| 13:09:18 | S_a_i_n_t_ | ..er, not that it's committed yet |
| 13:09:22 | Torne | i presume usb power toggles on and off when you plug and unplug the cable? |
| 13:09:26 | Torne | and battery says charging/discharging? |
| 13:09:35 | S_a_i_n_t_ | it sure does |
| 13:09:40 | S_a_i_n_t_ | yep |
| 13:09:46 | Torne | can you check that it correctly reports when the battery is charged? |
| 13:09:48 | Torne | (ish) |
| 13:10:11 | Torne | best method to do this woul dbe boot the OF and let it charge there until the OF says charging is done, then start RB again and plug cable back in, give it a few mins |
| 13:10:44 | S_a_i_n_t_ | ok, but it may take a while... |
| 13:10:48 | S_a_i_n_t_ | will do however |
| 13:10:50 | Torne | i'm willing to assume the firewire power pin is handled right, since it's done the same on video and in the patches for the other issues, but none of them address the charged status |
| 13:10:52 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 13:10:58 | Torne | which is different code |
| 13:11:14 | Torne | thanks |
| 13:11:56 | Torne | (check both the debug menu state and the wps for that, btw) |
| 13:13:10 | S_a_i_n_t_ | ok....wil do, btw...is disk-mode god enough for the "charg in OF" bit? or actually boot into the OF necessary? |
| 13:13:16 | | Join DerPapst [0] (~DerPapst@p4FE8F013.dip.t-dialin.net) |
| 13:13:24 | Torne | disk mode will do if it actually tells you when the battery is charged |
| 13:13:26 | Torne | i dunno :) |
| 13:13:38 | TheSeven | it does so on the 2g at least |
| 13:13:38 | S_a_i_n_t_ | yeah...sweet |
| 13:14:03 | * | S_a_i_n_t_ feels usefull for a change |
| 13:14:12 | TheSeven | is there really a "charged" status reported by the hardware? i have the impression that on the 2g they just determine that by the battery voltage and current readings |
| 13:14:12 | * | S_a_i_n_t_ likes this new feeling :D |
| 13:15:03 | Torne | TheSeven: well, the code for the PP ipods does GPIOB_INPUT_VAL & 0x01 |
| 13:15:07 | Torne | for all models apart from Color |
| 13:15:16 | Torne | (and 1g/2g) |
| 13:15:26 | S_a_i_n_t_ | Hmmm....seperate topic, but last time I checked I noticed that the 2g reported "estimated time left" as 4000 minutes or so...that can't be right? no? |
| 13:16:14 | Torne | TheSeven: and as far as i've observed that reports accurately for the video |
| 13:16:25 | S_a_i_n_t_ | 4882 minutes even, at 100% |
| 13:16:28 | Torne | see charging_state in power-ipod.c |
| 13:16:30 | * | TheSeven blames that on nobody having calibrated it yet |
| 13:17:09 | * | TheSeven would actually like to do a rework of the whole rockbox power management code |
| 13:17:37 | Torne | well off you go :) |
| 13:17:47 | S_a_i_n_t_ | I was waiting for that :P |
| 13:18:03 | Torne | i'm only going to rework usb charging |
| 13:18:09 | Torne | the rest will have to be someone else ;) |
| 13:18:28 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 13:18:43 | TheSeven | we need to account for things like the inner resistance, and i would like to base the runtime estimates on real current readings for targets that have them |
| 13:19:24 | Torne | the latter would be nice, but i'd be a bit cautious about how you average ti |
| 13:19:49 | Torne | e.g. playlists that include a variety of codecs with drastically different boost ratios |
| 13:19:55 | TheSeven | Torne: yes, one of the problems of that is that measuring the current will cause additional current to be drawn, and thus included in the measurement |
| 13:20:03 | | Quit DerPapst (Ping timeout: 272 seconds) |
| 13:20:09 | Torne | well, i didn't mean that :) |
| 13:20:11 | Torne | but yes |
| 13:20:28 | Torne | i mean more the case where you have an album in something expensive, and one in something cheap.. |
| 13:20:38 | Torne | is the estimate going to shift by many hours depending which album the playlist has reached? :) |
| 13:20:40 | TheSeven | Torne: codecs won't really matter as mp3, wma, vorbis and flac all play realtime without needing to boost |
| 13:20:57 | TheSeven | and i don't think other codecs are popular enough to be an issue... |
| 13:20:58 | Torne | also the disk spinup frequency with flac.. |
| 13:21:01 | Torne | and so on |
| 13:21:04 | Torne | i dunno. i'm just speculating |
| 13:21:09 | Torne | it may be not that much of a problem |
| 13:21:48 | TheSeven | anyways, I think it will always be more accurate than what we're currently doing, which is just assuming that it will always take the same current |
| 13:22:14 | TheSeven | the bigger problem is, that when charging, the battery voltage will quickly be at 4.18V, but that doesn't tell *anything* about the charge it has taken with li-po batteries |
| 13:22:25 | Torne | right. |
| 13:22:38 | * | S_a_i_n_t_ is *really* glad he took this problem to IRC instead of the forums... ; |
| 13:23:20 | | Join DerPapst [0] (~DerPapst@p4FE8EBB2.dip.t-dialin.net) |
| 13:23:30 | TheSeven | we could fix that by finding out the approximate inner resistance of that battery and "fixing" the voltage reading according to the current |
| 13:24:00 | * | TheSeven needs to check whether that is linear for lipos though |
| 13:24:08 | S_a_i_n_t_ | and *really* glad for the existence of the lifeform known as Torne |
| 13:24:09 | Torne | well, that part is definately beyond me :) |
| 13:30:52 | | Part wookey_ |
| 13:37:26 | | Join perfectdrug_ [0] (~marko@p5B0EC836.dip.t-dialin.net) |
| 13:37:53 | | Quit antil33t (Read error: Connection reset by peer) |
| 13:38:00 | | Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) |
| 13:39:04 | | Join Omlet [0] (omlet05@171.102-240-81.adsl-dyn.isp.belgacom.be) |
| 13:53:17 | | Quit Galois (Remote host closed the connection) |
| 13:53:40 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 13:53:50 | | Quit Galois (Client Quit) |
| 13:54:26 | Torne | wow, someone uses frotz a lot, on the forums |
| 13:54:36 | | Join Galois [0] (djao@efnet.math.uwaterloo.ca) |
| 13:55:50 | CIA-88 | New commit by mc2739 (r24580): Updated Portuguese Translation ... |
| 13:56:00 | S_a_i_n_t_ | i do too, i just don't post about it. for me, IF on my ipod is better than...errr, somethingelse hat's good ;) |
| 13:58:17 | Bagder | did anyone ever try ffmp3 with rockbox? |
| 13:58:28 | Bagder | the ffmpeg guys says its faster than libmad at least |
| 13:58:59 | Torne | S_a_i_n_t_: actually playing existing IF wasn't what i had in mind for frotz at all, but hey, it's a freebie feature :) |
| 13:59:29 | S_a_i_n_t_ | what did you have in mind? |
| 13:59:33 | rasher | Bagder: So's our decoder :) |
| 14:00 |
| 14:00:04 | Bagder | yes, but our is libmad based |
| 14:00:09 | Bagder | afaiu |
| 14:00:20 | kugel | yes, and saratoga constantly complains about it |
| 14:01:14 | | Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) |
| 14:01:54 | * | kugel is scared by ffmp3.com |
| 14:03:20 | *** | Saving seen data "./dancer.seen" |
| 14:08:49 | | Quit AndyI (Ping timeout: 248 seconds) |
| 14:11:23 | | Join GeekShado_ [0] (~Antoine@185.189.204-77.rev.gaoland.net) |
| 14:11:32 | * | Bagder talked to the friendly people in #ffmpeg-devel |
| 14:11:46 | Bagder | I'll post a follow-up on the mailing list on that |
| 14:12:40 | | Quit linuxstb (Ping timeout: 245 seconds) |
| 14:13:55 | | Quit GeekShadow (Ping timeout: 265 seconds) |
| 14:14:06 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 14:16:05 | gevaerts | Torne: so you feel all useful now? :) |
| 14:17:20 | Torne | gevaerts: heh, it's nice to know that somoene cares |
| 14:17:33 | Torne | and it might encourage me to implement more of the missing features sooner |
| 14:17:46 | Torne | and if jd gets multifont to work.. ;) |
| 14:18:36 | Torne | S_a_i_n_t_: I was intending to use it as a platform to actually develop menu/button based games |
| 14:18:53 | Torne | S_a_i_n_t_: e.g. things with JRPG-style combat |
| 14:19:08 | Torne | so, text based, but not text adventures in the usual sense |
| 14:19:24 | Torne | or, choose-your-own-adventure style things |
| 14:19:34 | Torne | there are various libraries for inform that help to do some of that |
| 14:19:36 | linuxstb | kugel: Are you sure saratoga complains about our mp3 decoder? I thought he was happy with it, especially as he has made it dual-core. I know he (and anyone else who has looked at it) complains about libfaad (the AAC decoder), are you perhaps confusing them? |
| 14:19:38 | Torne | and i was going to maybe write some more. |
| 14:20:09 | Torne | thus it might eventually be possible for people with limited programming ability to write certain kinds of games for rockbox :) |
| 14:21:48 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 14:22:43 | kugel | linuxstb: yes, dual core makes it fast on PP, but not on the rest of the targets |
| 14:23:08 | rasher | I thought preglow took care of that long ago? |
| 14:23:12 | | Quit Rob2222 (Quit: Rob2222) |
| 14:23:59 | kugel | mp3 is slower than wma and ogg on the rest |
| 14:25:29 | | Quit AndyI (Read error: Connection reset by peer) |
| 14:26:13 | Bagder | so maybe ffmpeg's codec is an idea after all |
| 14:27:55 | | Quit piotrekm (Quit: piotrekm) |
| 14:28:06 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 14:30:06 | | Quit Tuplis (Quit: hetkinen...) |
| 14:30:15 | S_a_i_n_t_ | Torne: ok...so what am I doing? OF reports the battery is charged, so I connect under RB and see if RB thinks it's charged (after some minutes) also? |
| 14:32:58 | Torne | yeah |
| 14:33:08 | Torne | it might sag slightly from 100% while you reboot to RB |
| 14:33:15 | Torne | so you might have to give it a sec to finish topping up the battery |
| 14:33:19 | S_a_i_n_t_ | success! |
| 14:33:23 | Torne | but it should hopefully report charged within a short time |
| 14:33:26 | S_a_i_n_t_ | commit away |
| 14:33:39 | Torne | Well, that sounds good to me :) |
| 14:33:50 | S_a_i_n_t_ | me too ;) |
| 14:33:58 | Torne | the behaviour of the code in svn is already identical to the past patches for this issue |
| 14:34:04 | Torne | so the only change needed is to actually turn monitoring on. |
| 14:34:16 | Torne | i shall do it momentarily :) |
| 14:34:42 | S_a_i_n_t_ | thanks man...you made a feature of my wps...and cabbie actually, actually work! |
| 14:35:07 | S_a_i_n_t_ | does this mean i gt a spot in the credits? |
| 14:35:08 | S_a_i_n_t_ | jk |
| 14:36:24 | S_a_i_n_t_ | that, (the monitoring thing) sems WAY too obvious a thing for the ammount of people that "apparently |
| 14:36:44 | S_a_i_n_t_ | looked at it" to miss...o? |
| 14:36:56 | Torne | well those FS# all had various people propose fixes |
| 14:37:24 | Torne | but i would assume that the intersection between "people who could test it" and "people who are committers" and "people who noticed the FS# entries" was probably empty :) |
| 14:37:48 | S_a_i_n_t_ | ahhhh...then came me :) |
| 14:39:11 | | Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 14:39:31 | S_a_i_n_t_ | I *still* (and probably forever will) find it *really* cool that this Nano was a first to do something :D |
| 14:39:44 | * | S_a_i_n_t_ pats his trusty 1g Nano affectionately |
| 14:39:51 | CIA-88 | New commit by torne (r24581): Enable charging monitoring for the Nano 1G. ... |
| 14:40:16 | S_a_i_n_t_ | and scours at the bits of his coffee-ridden 2g |
| 14:40:19 | S_a_i_n_t_ | grrrrr. |
| 14:45:05 | | Quit shaggy-h (Ping timeout: 240 seconds) |
| 14:46:52 | | Quit linuxstb (Ping timeout: 260 seconds) |
| 14:50:59 | | Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) |
| 15:00 |
| 15:09:35 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 15:15:04 | | Quit S_a_i_n_t (Disconnected by services) |
| 15:15:57 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 15:15:59 | | Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.240) |
| 15:16:52 | | Quit HBK (Read error: Connection reset by peer) |
| 15:17:40 | | Quit antil33t () |
| 15:17:56 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 15:21:08 | | Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) |
| 15:21:50 | | Quit linuxstb (Ping timeout: 245 seconds) |
| 15:22:19 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 15:22:35 | | Quit HBK (Read error: Connection reset by peer) |
| 15:23:11 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 15:26:04 | | Quit HBK (Read error: Connection reset by peer) |
| 15:26:09 | | Join KBH [0] (~hbk@HBK.broker.freenet6.net) |
| 15:26:54 | | Quit kugel (Ping timeout: 265 seconds) |
| 15:27:11 | S_a_i_n_t | how often does "viewers.config" change...realistically? Despit the "don't edit viewers.config" thing, I have, and wonder how often I need to update/or bother to check to update it. |
| 15:27:46 | TheSeven | why do you need to edit it in the first place? |
| 15:28:13 | gevaerts | it's included in the build zip, so "every time you install a new build" |
| 15:28:26 | S_a_i_n_t | to get viewers icons working in the "Open With list" |
| 15:28:31 | S_a_i_n_t | ...a cheap workaround |
| 15:29:50 | S_a_i_n_t | viewer icons in "Open With" are applied incorrectly, or not at all...editing viewers.config is a cheap fix for that. |
| 15:30:10 | TheSeven | S_a_i_n_t: according to SVN, it is changed every ~2 months average |
| 15:30:15 | | Join HBK- [0] (~hbk@HBK.broker.freenet6.net) |
| 15:30:32 | | Nick HBK- is now known as HBK (~hbk@HBK.broker.freenet6.net) |
| 15:30:47 | S_a_i_n_t | Aha....so "not very often" or, "when/if I notice something breaks" |
| 15:30:49 | S_a_i_n_t | thanks. |
| 15:31:03 | TheSeven | the changes are usually just new plugins |
| 15:31:39 | S_a_i_n_t | yeah, I'm probably the only one with icons for Frotz :D |
| 15:32:36 | | Quit HBK (Read error: Connection reset by peer) |
| 15:32:43 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 15:33:04 | | Join Rob2222 [0] (~Miranda@p4FDCB472.dip.t-dialin.net) |
| 15:33:25 | | Quit KBH (Ping timeout: 258 seconds) |
| 15:33:41 | TheSeven | the last change of it was the addition of Frotz, btw :-) |
| 15:34:43 | S_a_i_n_t | even though I use "open with" very rarely, I *hate* seeing things in there with black squares or no icons at all...so I bypassed that untill someone with brains finds a propper/the correct/ fix. |
| 15:34:49 | | Quit HBK (Read error: Connection reset by peer) |
| 15:35:04 | S_a_i_n_t | that's one of the things that made me notice it :D |
| 15:35:14 | S_a_i_n_t | *frotz that is |
| 15:35:32 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 15:35:54 | CIA-88 | New commit by FlynDice (r24582): Sansa Clip+: Unset B0 correctly in dualboot.S |
| 15:36:18 | S_a_i_n_t | Not that I don;t have brains myself, I'm just not a coder...I could probably have a stroke and be a better coder than I am now. |
| 15:36:38 | TheSeven | then do something about it :-) |
| 15:36:50 | S_a_i_n_t | what? have a stroke? |
| 15:36:51 | S_a_i_n_t | :P |
| 15:36:57 | | Quit HBK (Read error: Connection reset by peer) |
| 15:37:00 | * | S_a_i_n_t knew what you actually meant :D |
| 15:37:01 | TheSeven | well, if that helps? ;-) |
| 15:37:38 | S_a_i_n_t | One of my problems is trying to learn too many languages (coding) at once |
| 15:37:47 | S_a_i_n_t | I should just stick with C |
| 15:37:56 | S_a_i_n_t | but I get distracted VERY easily |
| 15:37:57 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 15:38:05 | * | TheSeven shoves that discusson to #rockbox-community |
| 15:44:30 | | Join vegtoruci [0] (~vegtoruci@pool-96-246-120-217.nycmny.east.verizon.net) |
| 15:46:56 | | Quit HBK (Read error: Connection reset by peer) |
| 15:47:25 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 15:48:14 | | Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) |
| 15:48:46 | | Join KBH [0] (~hbk@HBK.broker.freenet6.net) |
| 15:50:28 | | Quit KBH (Read error: Connection reset by peer) |
| 15:51:02 | | Join KBH [0] (~hbk@HBK.broker.freenet6.net) |
| 15:52:12 | | Quit HBK (Ping timeout: 258 seconds) |
| 15:52:33 | | Quit evilnick_B (Quit: Page closed) |
| 15:55:01 | | Quit KBH (Read error: Connection reset by peer) |
| 15:57:46 | domonoky | is someone here who understands the subtrack handling in nsf ? |
| 15:58:40 | domonoky | i understand that it switches subtracks on trackskips if you are in repeat-one mode. but there is also internal playlist handling which i dont understand. |
| 15:58:56 | domonoky | i want to use the same/similar subtrack handling for the asap codec. |
| 16:00 |
| 16:03:22 | *** | Saving seen data "./dancer.seen" |
| 16:03:23 | | Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) |
| 16:03:26 | | Join HBK [0] (~hbk@rrcs-97-77-49-215.sw.biz.rr.com) |
| 16:04:33 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 16:06:06 | CIA-88 | New commit by teru (r24583): time menu: stop scrolling before leave the screen. |
| 16:21:01 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 16:22:15 | Unhelpful | saratoga: i assume you mean *testing* on beast? also i'm still not really clear on how you would be able to use the 16x16 and 16x32 multiplies without losing accuracy... surely multiplying by constants truncated at 16 bits will introduce errors at around that precision |
| 16:24:36 | Unhelpful | there's a ? missing somehow... the other thing you might want to know about is that if you're making any use of smull or smlal and discarding the bottom word of the result, armv6 can do that without producing the low word in a register, and with the same throughput and latency as mul/mla |
| 16:24:51 | | Quit grndslm (Remote host closed the connection) |
| 16:25:25 | | Quit Zarggg_ (Read error: Connection reset by peer) |
| 16:34:16 | | Quit AndyI () |
| 16:37:21 | | Join captainkewlllll [0] (~2669ecc2@gateway/web/freenode/x-sfhkmlohslcqebov) |
| 16:41:53 | | Quit Tomis (Ping timeout: 252 seconds) |
| 16:42:48 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 16:48:01 | | Join Tomis [0] (~Tomis@70.134.90.242) |
| 16:48:23 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
| 16:53:54 | | Quit Tomis (Read error: Operation timed out) |
| 16:54:13 | | Join Tomis [0] (~Tomis@70.134.83.103) |
| 16:55:11 | | Part watto |
| 16:59:13 | | Quit Bagder (Quit: It is time to say moo) |
| 17:00 |
| 17:01:03 | | Join watto [0] (~watto@193.203.81.165) |
| 17:01:28 | | Join jgarvey [0] (~jgarvey@cpe-071-070-228-143.nc.res.rr.com) |
| 17:15:11 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:19:21 | | Part evilnick_B |
| 17:19:24 | | Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) |
| 17:20:15 | | Quit Zagor (Quit: Clint excited) |
| 17:25:44 | | Quit AndyI () |
| 17:26:00 | | Quit robin0800 (Remote host closed the connection) |
| 17:31:36 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 17:32:15 | | Quit S_a_i_n_t (Quit: [St.] has exited mIRC™) |
| 17:42:24 | | Part watto |
| 17:45:03 | * | TheSeven might have spotted why the channel swapping is happening |
| 17:46:32 | TheSeven | will a pcm_more_callback_type always return an even number of samples? |
| 17:46:45 | TheSeven | (i.e. always start with the left channel) |
| 17:47:26 | | Join watto [0] (~watto@193.203.81.165) |
| 17:47:33 | | Quit linuxstb (Ping timeout: 265 seconds) |
| 17:48:17 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 17:49:36 | | Join pamaury [0] (~pamaury@ALyon-551-1-36-230.w80-9.abo.wanadoo.fr) |
| 17:53:16 | | Quit linuxstb (Ping timeout: 246 seconds) |
| 17:53:45 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 17:54:55 | | Quit Sajber^ (Read error: Connection reset by peer) |
| 17:55:21 | | Join Sajber^ [0] (~Sajber@h-65-75.A213.priv.bahnhof.se) |
| 17:57:02 | | Quit teru (Quit: Quit) |
| 18:00 |
| 18:01:28 | | Quit n17ikh (Ping timeout: 260 seconds) |
| 18:03:24 | *** | Saving seen data "./dancer.seen" |
| 18:04:44 | | Quit petur (Quit: work->home) |
| 18:06:09 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
| 18:10:20 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 18:19:40 | | Quit HBK () |
| 18:21:49 | | Quit AndyI () |
| 18:23:27 | | Quit togetic (Quit: WeeChat 0.3.0) |
| 18:24:04 | | Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-uxeftoofekqjpbkk) |
| 18:24:14 | | Join togetic [0] (~togetic@unaffiliated/ibuffy) |
| 18:25:28 | | Quit togetic (Client Quit) |
| 18:25:42 | saratoga | linuxstb: without dual core (AMS, Gigabeat, Nano2G) libmad is probably slower then libfaad |
| 18:25:55 | saratoga | but yes, I complain about libfaad a lot ;) |
| 18:26:04 | | Join togetic [0] (~togetic@unaffiliated/ibuffy) |
| 18:27:14 | saratoga | i suggested this as a possible GSOC project: http://www.rockbox.org/wiki/SummerOfCode2010#MPEG_Codec_Optimization |
| 18:30:51 | | Join HBK [0] (~hbk@HBK.broker.freenet6.net) |
| 18:33:55 | | Join AndyI [0] (~pasha_int@212.14.205.32) |
| 18:37:22 | | Join desowin [0] (~desowin@atheme/member/desowin) |
| 18:37:39 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:38:02 | topik | android seems to have grown a bit since you created that gsoc ideas page |
| 18:38:51 | | Join Zarggg [0] (~zarggg@2001:0:4137:9e74:0:4388:beb1:ba3d) |
| 18:41:45 | | Join petur [0] (~peter@d54C6F9B2.access.telenet.be) |
| 18:41:45 | | Quit petur (Changing host) |
| 18:41:45 | | Join petur [0] (~peter@rockbox/developer/petur) |
| 18:42:47 | bertrik | AlexP, nice to see your clip battery bench |
| 18:43:03 | AlexP | bertrik: Yeah, it wasn't bad |
| 18:43:54 | AlexP | Seems odd that you and I got much higher than the other one there |
| 18:46:54 | bertrik | yes, indeed, especially because runtime seems to be normal in the OF |
| 18:47:13 | bertrik | I'm trying to look into that, but it's a bit hard to get a grip on it |
| 18:47:31 | | Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 18:49:44 | AlexP | yeah, I can imagine |
| 18:49:45 | | Quit archivator (Ping timeout: 245 seconds) |
| 18:50:54 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
| 18:52:42 | topik | bertrik: are you still looking at meizu's these days? i have an unused m6sl that would love to get a new life like my nano2g did after getting rockbox |
| 18:53:36 | bertrik | topik, I'm not really active lately for the meizus. I do have a M6SP and a borrowed M3, but not an M6SL that I can work on |
| 18:54:32 | topik | i read on the forum thread you had quite some progress |
| 18:55:01 | bertrik | the main firmware for the m6sl probably does not compile, but you can probably get the bootloader compile with a limited amount of work, the display does not work at all yet AFAIK |
| 18:55:30 | topik | i tried to compile the bootloader and meizu_dfu but both didn't |
| 18:59:27 | topik | fair amount of m6sp stuff in the s5l8700 files, but not much m6sl |
| 19:00 |
| 19:04:55 | | Quit bluebrother (Disconnected by services) |
| 19:04:56 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 19:05:12 | | Join DumbSpammer [0] (~re@AntiLiberal-1-pt.tunnel.tserv9.chi1.ipv6.he.net) |
| 19:06:18 | | Join Casainho [0] (~chatzilla@87.196.59.58) |
| 19:09:21 | Mode | "#rockbox +o gevaerts" by ChanServ (ChanServ@services.) |
| 19:09:32 | Kick | (#rockbox DumbSpammer :you know why) by gevaerts!~fg@rockbox/developer/gevaerts |
| 19:10:02 | Mode | "#rockbox -o gevaerts" by ChanServ (ChanServ@services.) |
| 19:10:22 | AlexP | gevaerts: No ban? |
| 19:10:36 | saratoga | Bagder: would you mind deleting that from the logs? |
| 19:10:42 | TheSeven | he probably won't come back anyways |
| 19:10:43 | AlexP | A good idea |
| 19:10:46 | gevaerts | AlexP: I don't know. If he comes back, yes |
| 19:10:57 | gevaerts | and yes, I think that should be removed from the logs |
| 19:11:02 | AlexP | TheSeven: I know, but principle - if you come in just to spam then instant ban |
| 19:11:19 | gevaerts | AlexP: feel free |
| 19:11:23 | AlexP | nah :) |
| 19:11:34 | TheSeven | as he is probably doing that on a lot of channels, one might want to contact freenode staff |
| 19:13:16 | saratoga | B4gder: you too |
| 19:21:12 | gevaerts | topik: meizu_dfu builds fine here |
| 19:21:29 | topik | from the dir it is in? it complains about missing usb.h for me |
| 19:21:43 | | Quit FlynDice (Remote host closed the connection) |
| 19:21:56 | bertrik | you're missing libusb-dev then |
| 19:22:35 | topik | good point. it compiles rightaway now |
| 19:22:46 | | Join JdGordon_ [0] (~836b006a@gateway/web/freenode/x-iqqcwanrpzgvehlr) |
| 19:27:21 | | Join Strife89 [0] (~michael@168.16.237.214) |
| 19:27:27 | | Quit kugel (Quit: exit(0);) |
| 19:28:00 | | Quit pamaury (Ping timeout: 264 seconds) |
| 19:30:30 | | Quit togetic (Ping timeout: 265 seconds) |
| 19:31:08 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 19:41:52 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 19:42:49 | CIA-88 | New commit by b0hoon (r24584): Packard Bell Vibe 500: Improve/fix scrollstrip scrolling. The idea was taken from the ipod's clickweel source. |
| 19:45:35 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 19:45:42 | piotrekm | Hello |
| 19:46:06 | TheSeven | hi piotrekm |
| 19:46:26 | TheSeven | if you have time, i would like you to test some things regarding the lcd issue... |
| 19:46:35 | | Join Tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) |
| 19:46:44 | piotrekm | i might, i suppose |
| 19:47:16 | piotrekm | one quick question before: is the "tsst" (short white noise) on the beggining of track playback a nano2g-specific issue? |
| 19:47:22 | | Join fml [0] (~53ecea55@giant.haxx.se) |
| 19:47:43 | fml | JdGordon: ping |
| 19:48:14 | | Quit Farthen (Disconnected by services) |
| 19:48:22 | piotrekm | TheSeven: any special instructions for today, or should I just re-download the files? |
| 19:48:35 | | Join Farthen_ [0] (~chatzilla@e179234137.adsl.alicedsl.de) |
| 19:48:37 | | Nick Farthen_ is now known as Farthen (~chatzilla@e179234137.adsl.alicedsl.de) |
| 19:49:05 | TheSeven | i would first have a check if this also happens when the lcd init code is run through ibugger |
| 19:49:06 | | Quit vegtoruci (Ping timeout: 240 seconds) |
| 19:49:11 | TheSeven | that would ease debugging |
| 19:49:38 | piotrekm | ok, so first i'll reboot to linux |
| 19:49:42 | TheSeven | i'll prepare an image for you soon, need to fix something first |
| 19:50:22 | fml | JdGordon: (for the log) if, as we know now, the font cache only stores the glyph codes and not the glyphs bitmaps, wouldn't it be better to just have one glyph cache for all fonts? Why do we need separate caches? |
| 19:50:44 | JdGordon_ | well yeah |
| 19:50:48 | JdGordon_ | although, maybe not |
| 19:51:02 | JdGordon_ | I origionally thought it does store the glyphs bits which is why I did it this way |
| 19:51:10 | piotrekm | TheSeven: Anyway, I'll be back in about 40minutes. |
| 19:51:19 | | Quit piotrekm (Quit: piotrekm) |
| 19:51:32 | JdGordon_ | with more than one font loaded, its likely that their used glyphs wouold be different |
| 19:51:57 | JdGordon_ | one mighyt only be used for numbers, anther might only be used for text |
| 19:52:10 | JdGordon_ | and then there's the possibility of windings :p |
| 19:52:16 | pixelma | http://forums.rockbox.org/index.php?topic=23863.msg161967#msg161967 <- interesting picture as it shows a daughterboard with an "M5" marking. I suppose it's an X5V then (without the radio) but don't know if the loose wire has to so with it and if it should be this way |
| 19:52:32 | fml | JdGordon: it's not unlikely. But on the other hand, it's very likely that the sets will be roughly the same. Chars are used for displaying text after all. |
| 19:53:02 | | Join vegtoruci [0] (~vegtoruci@pool-96-246-120-217.nycmny.east.verizon.net) |
| 19:53:17 | JdGordon_ | yes, so I might go back and simplify that completly |
| 19:53:34 | JdGordon_ | probably change it to only cache the user font and not bother at all with the skin fonts |
| 19:54:17 | fml | JdGordon: I think we can cache all fonts, no need to handle the UI font in a special way. |
| 19:54:54 | CIA-88 | New commit by b0hoon (r24585): Packard Bell Vibe 500: Enable ATA DMA as in r24405. |
| 19:55:00 | JdGordon_ | are you talking about the .glyphcache file? or the actual in ram cache? |
| 19:55:09 | CIA-88 | New commit by kugel (r24586): Bubbles: Don't save scores when quit without saving is selected and reduce splash duration |
| 19:57:31 | fml | JdGordon: both |
| 19:57:33 | | Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 19:57:36 | kugel | what is gained by combining the glyph cache? combining means being potentially wrong and destroying the per-font glyphcache |
| 19:57:51 | kugel | (I mean the .glyphcache files) |
| 19:57:52 | | Quit FlynDice (Remote host closed the connection) |
| 19:58:30 | JdGordon_ | the on disk cache is tiny, so the only reason to not use a seperate one for each font is to cut down on junk files |
| 19:58:46 | JdGordon_ | the inram cache NEEDS to be seperate because the bits are actually stored there |
| 19:59:47 | fml | JdGordon: aha! Then we need separate caches indeed. Disk space doesn't matter |
| 20:00 |
| 20:00:01 | kugel | the inram cache could be combined |
| 20:00:21 | JdGordon_ | it can, but the gain isnt worth it |
| 20:00:27 | | Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) |
| 20:00:27 | kugel | it just needs a font index in the lru nodes, and it actually has an unused field |
| 20:00:39 | kugel | isn't worth what? |
| 20:00:47 | JdGordon_ | that doesnt work when each font has different glyph sizes |
| 20:01:01 | kugel | ?? |
| 20:01:04 | JdGordon_ | the wait and the effort and the extra ram usage |
| 20:01:06 | fml | kugel: the entries would be of variable size which is not supported now |
| 20:01:36 | fml | kugel: since the bits are also inside |
| 20:01:58 | | Quit evilnick_B (Quit: Page closed) |
| 20:02:00 | kugel | it is supported |
| 20:02:23 | fml | kugel: I don't think so |
| 20:02:23 | kugel | the lru node has a data pointer and a size field |
| 20:02:57 | gevaerts | archivator: I'm test-compiling things now. There are a few keypad issues that i need to look into |
| 20:03:22 | JdGordon_ | kugel: ok, if you really want it done that way then go for it, in the mean time, my way works, and is almost ready, and we dont have to deal with issues of dropping X glyphs to make room for Y other fonts glyphs |
| 20:03:27 | *** | Saving seen data "./dancer.seen" |
| 20:03:45 | fml | kugel: and how is that data managed? It has to be of a const size |
| 20:04:10 | kugel | JdGordon: yea, but with constant disk spinning because 10k seems pretty low |
| 20:04:22 | JdGordon_ | hardly |
| 20:04:34 | JdGordon_ | (I havnt tested on target yet) |
| 20:04:52 | JdGordon_ | 10k is how many 12x12 glyphs? |
| 20:05:08 | JdGordon_ | 1000/(12x12/8) ? |
| 20:05:12 | gevaerts | 70 or so |
| 20:05:34 | JdGordon_ | thanks, so easily enough for most people's secondary font |
| 20:05:50 | gevaerts | 55 actually |
| 20:06:27 | kugel | fml: why? |
| 20:06:41 | rasher | That's not a lot |
| 20:07:08 | JdGordon_ | rasher: for the secondary font? its plenty |
| 20:07:17 | rasher | How do you figure? |
| 20:07:18 | JdGordon_ | even if its closer to 45, still plenty |
| 20:07:21 | fml | kugel: look at the code. It's handled as an array, i.e. fix sized entries |
| 20:07:25 | amiconn | Ahem. 10k would be 10000 |
| 20:07:48 | rasher | It's entirely plausible that the secondary font will be needing the same glyphs as the main font |
| 20:08:01 | amiconn | But then, plain /8 is incorrect either, as the bitmaps cannot contain fractional bytes |
| 20:08:02 | TheSeven | waaaaaaaaaah! |
| 20:08:04 | gevaerts | ok, 568 |
| 20:08:05 | kugel | I can imagine the user fonts are used for bigger fonts so that the menu font isn't too huge, then 12px is a bad estimate |
| 20:08:07 | TheSeven | someone broke nano2g playback! |
| 20:08:25 | gevaerts | amiconn: that would mean (16x12)/8? |
| 20:08:31 | amiconn | yep |
| 20:08:39 | gevaerts | ok, 426 then |
| 20:09:00 | JdGordon_ | 10k is a number I pulled fairly randomly, we can increase that if its feeled we need to |
| 20:09:10 | JdGordon_ | ok 400 glyphs IS plenty |
| 20:09:23 | gevaerts | 140 glyphs for a 24x24 font |
| 20:10:06 | kugel | I wouldn't underestimate the overhead from the cache management either |
| 20:10:07 | fml | That's too much IMHO |
| 20:10:38 | kugel | it could probably be 10% less due to that |
| 20:10:39 | JdGordon_ | kugel: with a few lines of code we can get exact numbers |
| 20:10:52 | JdGordon_ | 10% of 426 is still only 42 |
| 20:11:03 | JdGordon_ | worst case is 300 |
| 20:11:06 | JdGordon_ | or 100 |
| 20:11:29 | JdGordon_ | fml: the RAM being used for fonts is preallocated for skins anyway so its not a waste |
| 20:12:02 | fml | JdGordon: ok then |
| 20:13:16 | JdGordon_ | has anyone looked at the latest patch? should I simplify it and move the skin_font_*() stuff into firmware/fonts? |
| 20:14:04 | JdGordon_ | the only downside doing that is a fwe extra font structs in firmware/ but it should make the code ismpler |
| 20:14:35 | | Quit amiconn (Disconnected by services) |
| 20:14:37 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 20:14:45 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 20:14:45 | | Quit pixelma (Disconnected by services) |
| 20:14:59 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 20:15:00 | kugel | fml: you seem correct |
| 20:15:02 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 20:15:24 | TheSeven | CC apps/codecs/asap.c |
| 20:15:26 | TheSeven | make: *** No rule to make target `/home/theseven/rockbox-trunk/apps/codecs/libasap/anylang.h', needed by `/home/theseven/rockbox-trunk/build/nano2-app/apps/codecs/libasap/acpu.o'. Stop. |
| 20:15:35 | JdGordon_ | make veryclean |
| 20:17:15 | | Quit archivator (Ping timeout: 245 seconds) |
| 20:18:24 | fml | JdGordon: I wouldn't handle fonts diferently at the firmware level. Make them equal. A font just gets a buffer for storing its cache. The caller must care about the buffer. Then the font buffer can be in the skin buffer or in the playback buffer (if we want it that way) or... |
| 20:19:22 | amiconn | Imo the proper solution would be a single font buffer for all fonts |
| 20:20:01 | fml | JdGordon: one font is special in the sense that it's the UI font and has its buffer in the core rockbox. Other fonts get the buffer from the skin. This can be changed later without changing the firmware. |
| 20:20:04 | kugel | I agree, but nobody is going to do it, and JdGordon's approach seems good enough |
| 20:20:33 | * | amiconn disagrees |
| 20:20:58 | amiconn | At the firmware level, all loadable fonts should be equal |
| 20:21:00 | fml | kugel: I think with the energy and speed JdGordon has it will be done in two, no, one hour |
| 20:21:12 | JdGordon_ | fml: so yeah, thats how I've done it now, but its got a vit too much special handling for the ui font |
| 20:21:40 | amiconn | This is important on devices with more than one display |
| 20:22:02 | fml | amiconn: you mean all but the system (inbuilt) font? Then I fully agree. |
| 20:22:03 | JdGordon_ | I agree that one buffer is better, but noone has done it and looks like they are going to |
| 20:22:12 | * | JdGordon_ totally forgot about multiple screen fonts :p |
| 20:22:16 | amiconn | Each display should be able to set its own ui font. That's in fact what's annoying me most |
| 20:23:07 | amiconn | I don't really need more than one font per display, but the single font for all lcd gets annoying, especially if there's a large difference in lcd size |
| 20:23:37 | amiconn | Think e.g. H300 main and remote, or even more obvious m:robe 500 and remote |
| 20:23:39 | fml | amiconn: ..which is always there |
| 20:25:14 | amiconn | JdGordon_: markun said that he did a bit of work on the font caching. Unfortunately he didn't get around to committing it |
| 20:25:15 | JdGordon_ | so I'm tempted to duplicate the user font handling for the remote (and just make sure the right FONT_UI is loaded for the display if the fonts are different), that wll double the buffer usage |
| 20:26:54 | Unhelpful | one buffer pretty much means coming up with a way to get entries of differing size into it |
| 20:27:04 | JdGordon_ | yes |
| 20:27:24 | JdGordon_ | which is what has been the problem the whole time |
| 20:27:35 | JdGordon_ | also coming up with a good buffer size to use |
| 20:27:45 | amiconn | The single buffer method has advantages if the theme has some special-use fonts |
| 20:27:49 | | Join moos [0] (moos@rockbox/staff/moos) |
| 20:28:15 | Unhelpful | i'd say maybe something like what buflib does - there's a table of offsets to the actual buffer items (quick access, one extra indirection vs direct array lookup) but the buffer items themselves are of arbitrary sizes. |
| 20:28:27 | amiconn | Think e.g. of an fm theme for users not caring about the station name. It would use a huge font for frequency display |
| 20:28:37 | Unhelpful | actually it's not an offset table, but a pointer table |
| 20:28:55 | amiconn | Of that huge font, only the digits, '.' and maybe 'M', 'H' and 'z' are needed |
| 20:29:06 | JdGordon_ | Unhelpful: that doesnt solve the problem of figuring out which glyphs to drop to make room for a different one |
| 20:29:48 | amiconn | Unhelpful: The pointers also cost 4 bytes extra per entry. But sure, it would probably already be an overall gain with a medium-sized proportional font |
| 20:29:53 | JdGordon_ | i.e you dont want to just drop the oldest one which is larger than the needed space, that one might be really really frequently used |
| 20:30:17 | Unhelpful | amiconn: that's what i'm thinking, a proportional font will rather quickly save when it caches narrow characters |
| 20:30:21 | amiconn | JdGordon_: You just drop from oldest to newest until you have enough free space |
| 20:30:32 | | Join stooo [0] (~sto@f051006239.adsl.alicedsl.de) |
| 20:31:13 | JdGordon_ | and the buffer size? 60K is obviously too small |
| 20:31:31 | Unhelpful | buflib could also be reworked a bit to support unaligned data - right now it's 32-bit aligned so 1) users never have to worry about allocation alignment 2) each item has a pointer to its table entry for easy update on compaction |
| 20:31:32 | JdGordon_ | 100K? probably too small for people that want 3 fonts, too big for those that only want one |
| 20:31:32 | amiconn | why? |
| 20:32:54 | JdGordon_ | 60K is how much we allocate now for one font, so it stands to reason that it's not enough for 2+ |
| 20:32:59 | fml | amiconn: and after each drop you compact the buffer? |
| 20:34:12 | amiconn | Yes, I think that's necessary |
| 20:34:36 | JdGordon_ | wont that get very slow? doing lots of memcpy? |
| 20:34:40 | gevaerts | JdGordon_: I'd assume that if people use more than one font, in many cases the extra fonts will be used for only a few words |
| 20:34:41 | amiconn | You might also track gaps and only compact if no large enough gap is left, but that tracking might be too much overhead |
| 20:35:11 | amiconn | JdGordon_: It needs memmove. Compared to the disk access, this memmove is blazingly fast |
| 20:35:17 | JdGordon_ | gevaerts: agreed, which is why I did 10K not the full 60K |
| 20:35:29 | amiconn | Btw, on lowmem swcodec the font buffer is 10k, and on archos even just 4k |
| 20:36:01 | amiconn | I would make that depend on lcd size. Larger lcds are likely to need larger fonts, hence a larger font buffer |
| 20:36:07 | fml | So we'd need yet another mini malloc |
| 20:36:21 | amiconn | why? |
| 20:37:36 | Unhelpful | amiconn: that's what buflib does already, compact-on-failure. also handles are allocated from the buffer so that there's not a fixed number of handles. |
| 20:37:59 | | Join phanboy4 [0] (~benji@gate-20.spsu.edu) |
| 20:38:01 | amiconn | hmm |
| 20:38:13 | | Join archivator [0] (~archivato@stu0279.keble.ox.ac.uk) |
| 20:38:41 | Unhelpful | search for allocation is done by walking the buffer items - since they each have an allocation size in their "header" they can be treated as a linked list. as an optimization a pointer to the lowest free buffer is maintained. |
| 20:38:57 | JdGordon_ | so is this just all talk? if someone is actually going to do this then I'm happy to sit on my patch, but if its just going to stay talk (like it has been for years) then I dont see any reason to wait once my patch is ready |
| 20:39:24 | gevaerts | archivator: I think I'll disable fft on touchscreen targets for now |
| 20:39:50 | amiconn | Unhelpful: Hmm. How does that perform if there are 1000 items or so? |
| 20:40:20 | amiconn | And does it reuse gaps? |
| 20:40:22 | | Join piotrekm [0] (~pm@unaffiliated/piotrekm) |
| 20:40:49 | amiconn | JdGordon_: Imo getting that right is a requirement for multifont |
| 20:41:39 | Unhelpful | amiconn: it depends on how out-of-date the gap information is, and i've never really tried to benchmark or stress-test it. but the lower-bound pointer for a free buffer is updated on each allocation. the worst case is if an allocation uses all of the lowest-address gap, since this means that the lower-bound pointer will actually point to a non-gap |
| 20:41:43 | archivator | gevaerts: I was actually considering dropping the current oscilloscope-inspired keymaps and try menu-based configuration... Shouldn't be too much work but I'm afraid it might make the plugin less usable |
| 20:41:46 | JdGordon_ | I agree that a single buffer is better, but this same conversation happens at least once a year and there has been no movement |
| 20:41:52 | | Join fleebailey33 [0] (fleebailey@unaffiliated/fleebailey33) |
| 20:41:54 | piotrekm | hello again |
| 20:42:05 | piotrekm | TheSeven: no i'm availabe |
| 20:42:11 | gevaerts | archivator: I'm about ready to commit, with a note that keymaps need more work |
| 20:42:13 | Unhelpful | i primarily optimized it for fast retrieval rather than allocation, but the allocation should be quite speedy in the typical case |
| 20:42:26 | gevaerts | Tell me if I should wait |
| 20:42:32 | * | amiconn thinks we need more devcon-like hacking sessions |
| 20:43:07 | archivator | gevaerts: no, by all means, commit it. I don't have time to do any serious refactoring right now... menu-based config was just a thought.. |
| 20:43:32 | archivator | gevaerts: oh, and thank you :) |
| 20:44:05 | Unhelpful | the same optimization is used in the handle table, so that allocating a free handle starts with the lowest possible handle number |
| 20:44:20 | CIA-88 | New commit by gevaerts (r24587): New plugin: FFT, A frequency analyzer plugin ... |
| 20:45:52 | gevaerts | archivator: if you could work on a manual patch, or at least a bit of text, that would be very welcome! |
| 20:46:23 | kugel | euw, typedefs :( |
| 20:46:33 | archivator | gevaerts: I'll see what I can do. I've never touched LaTeX though :( |
| 20:46:59 | gevaerts | kugel: imported code |
| 20:47:08 | gevaerts | hm |
| 20:47:35 | gevaerts | archivator: we probably need a line in CREDITS for that external code |
| 20:47:46 | kugel | if it's imported, why are there no (c) headers? |
| 20:48:59 | gevaerts | "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution" |
| 20:49:03 | gevaerts | uhm |
| 20:49:26 | archivator | where are you seeing that? |
| 20:49:41 | gevaerts | ok, standard BSD apparently |
| 20:49:52 | archivator | yes, it is. |
| 20:49:55 | gevaerts | kiss_fft.c |
| 20:51:05 | kugel | archivator: did you lack a malloc()? we have one for codecs and plugins |
| 20:52:03 | archivator | kugel: I don't remember ever needing a malloc but I could be forgetting something. What do you have in mind? |
| 20:52:29 | gevaerts | How do we handle credits for single-person projects where the author didn't contribute directly? The main name list, or the team list at the end? |
| 20:52:34 | kugel | I saw some #define *_MALLOC mallic and #define *_FREE free, so I just though |
| 20:52:36 | kugel | thought |
| 20:53:16 | | Quit flydutch (Quit: /* empty */) |
| 20:53:31 | kugel | gevaerts: I think we add them to the people's list, that's what happened with the timestretch feature |
| 20:53:38 | gevaerts | ok |
| 20:54:16 | kugel | if someone doesn't want to be named he shouldn't release code to the public :) |
| 20:54:21 | CIA-88 | New commit by gevaerts (r24588): Add Mark Borgerding to CREDITS, for kiss_fft which is used by the fft plugin |
| 20:54:54 | gevaerts | well actually, the license says we have to add him if I read it correctly :) |
| 20:55:14 | archivator | kugel: I didn't put too much effort into cleaning that library. I think the OPENMP stuff is still there.. |
| 20:56:05 | | Part watto |
| 20:56:15 | kugel | I also saw "this kiss fft can't use malloc" in a .c file |
| 20:56:38 | archivator | kugel: Ah, yes. I remember now. It's not that it can |
| 20:56:47 | archivator | 't but rather that I didn't want it to. |
| 20:57:48 | archivator | the library in its current form does not depend on core rockbox but only on the fp_sincos implementation. i wanted to confine all dependencies on core rockbox to the actual plugin. |
| 20:58:13 | kugel | our malloc isn't core :p |
| 20:59:38 | amiconn | gevaerts: Could you quick-check something on your D2? |
| 20:59:45 | gevaerts | sure |
| 20:59:57 | amiconn | (APE, testing just -c2000 and -c3000 is sufficient) |
| 21:00 |
| 21:00:01 | archivator | kugel: then I must have been seriously confused :) In any case, malloc isn't really needed - the allocation was made static as the size of the transform was fixed at compile time |
| 21:00:25 | amiconn | I want to make sure the armv5te does actually behave as described before doing more complex stuff |
| 21:00:33 | amiconn | Want a patch or a build? |
| 21:00:36 | kugel | well, your patch was maybe longer on the tracker than the time we have it |
| 21:00:39 | gevaerts | a patch is fine |
| 21:01:12 | piotrekm | gevaerts: is this fft plugin (it's great tirst of all) meant to have some config, refresh time for example? i wonder if it's only because of the unbound keys |
| 21:01:13 | | Quit TheSeven (Read error: Connection reset by peer) |
| 21:01:30 | kugel | piotrekm: ask archivator |
| 21:01:35 | archivator | piotrekm: no, not really. It refreshes as often as it gets data. |
| 21:01:37 | gevaerts | piotrekm: archivator can answer all questions about it! |
| 21:01:40 | | Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) |
| 21:01:42 | piotrekm | thanks |
| 21:01:54 | | Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115133306]) |
| 21:02:06 | kugel | I wonder if it can also analyize line in stuff? |
| 21:02:09 | | Quit fml (Quit: CGI:IRC) |
| 21:02:23 | amiconn | https://amiconn.dyndns.org/~jens/ape_armv5_sp_test.diff |
| 21:02:55 | amiconn | gevaerts: With this patch, APE should decode at the same speed or a little bit faster than SVN on D2 |
| 21:03:11 | amiconn | (a bit faster due to more registers left for gcc to play with) |
| 21:03:21 | piotrekm | TheSeven: in case the last message didn't arrive, i have some time now to test |
| 21:03:24 | | Quit linuxstb (Ping timeout: 264 seconds) |
| 21:03:48 | archivator | kugel: in theory, yes. I'm not sure how to switch between pcm output and line in mode. Can you record and have something playing at the same time? Sorry for the silly question, I've never recorded anything on a DAP.. |
| 21:06:57 | TheSeven | piotrekm: i uploaded a file called ibugger.bin to my server, can you check if the lcd driver used by that works? |
| 21:07:40 | | Quit stooo (Ping timeout: 245 seconds) |
| 21:07:47 | TheSeven | if yes, get inithw.bin and run sudo python control.py upload 22000800 inithw.bin && sudo python control.py execute 22000800 22000800 |
| 21:08:04 | TheSeven | run that within ibugger *loader*, so don't run control.py startup before |
| 21:09:01 | piotrekm | ok |
| 21:11:32 | gevaerts | amiconn: playback is still fine, test_codec results as soon as I stop doing things wrong |
| 21:11:53 | TheSeven | damn, just had another FTL crash |
| 21:12:15 | amiconn | You don't need to test correctness, I'm doing that on my beast (using the armv5 vector math of course) |
| 21:12:37 | piotrekm | TheSeven: see a mandelbrot;) |
| 21:12:49 | TheSeven | sounds like the driver works |
| 21:12:52 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 21:12:56 | TheSeven | what does happen if you run inithw.bin? |
| 21:13:07 | piotrekm | will do that in a moment |
| 21:14:10 | piotrekm | inithw gave white screen |
| 21:18:17 | gevaerts | amiconn: c2000 317%, c3000 213% |
| 21:18:22 | | Join anewuser [0] (~anewuser@unaffiliated/anewuser) |
| 21:18:47 | amiconn | Ah, very good. So armv5 actually behaves as described :) |
| 21:19:03 | * | amiconn starts working on the actual improvements |
| 21:19:31 | | Quit kugel (Remote host closed the connection) |
| 21:21:50 | | Quit linuxstb (Ping timeout: 245 seconds) |
| 21:23:48 | saratoga | archivator: we're about to add a very well optimized FFT to the library FWIW |
| 21:24:46 | archivator | saratoga: I'm aware of that, I'm waiting for it to go upstream and I'lll switch to it (if it's meant to be used by plugins, that is). |
| 21:25:43 | | Quit Tomers (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558]) |
| 21:25:44 | saratoga | ok cool |
| 21:25:51 | saratoga | its in the mdct branch if you'd like to try it |
| 21:26:27 | TheSeven | piotrekm: hm, not good |
| 21:26:39 | TheSeven | but at least we can test it easily now |
| 21:26:43 | archivator | saratoga: is the api stable? I.e., can I start switching to it now? |
| 21:26:51 | piotrekm | TheSeven: does it mean something else than lcd init is broken? |
| 21:27:29 | TheSeven | no, it probably is the lcd init, and we can now try to track the issue down |
| 21:27:52 | piotrekm | ok |
| 21:28:47 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 21:40:14 | saratoga | archivator: its not even exposed to plugins at the moment, but if you add it to plugins.h I doubt anyone will change it now |
| 21:40:41 | saratoga | its actually just a function used by our new MDCT, so we didn't need to expose it |
| 21:40:55 | saratoga | i wouldn't worry too much, we can always do this later |
| 21:41:32 | archivator | Right. I might work on this when I find the time (uni has been proving somewhat time-consuming :) ) |
| 21:41:44 | | Quit FOAD (Ping timeout: 260 seconds) |
| 21:42:08 | saratoga | should be quite simple unless your fft is doing something special (reordering or scaling) |
| 21:43:12 | | Join FOAD [0] (~dok@dinah.blub.net) |
| 21:45:07 | archivator | saratoga: it's doing scaling at the end of each iteration to prevent overflow. Other than that, it's pretty much taken from the books verbatim. |
| 21:47:15 | TheSeven | meh. i don't even get my nano to play back *anything* any more |
| 21:47:24 | | Quit piotrekm (Ping timeout: 246 seconds) |
| 21:49:01 | | Join piotrekm [0] (~pm@unaffiliated/piotrekm) |
| 21:49:46 | piotrekm | TheSeven: you mean it's permanently broken? |
| 21:50:18 | TheSeven | no, looks like somebody broke a bunch of things with a recent commit... |
| 21:50:29 | TheSeven | and it's reacting really weird |
| 21:50:45 | TheSeven | right now it failed to rolo a new build because of a checksum error? |
| 21:51:05 | TheSeven | oops, and there suddenly is a file called "tagna6i.conf)g" |
| 21:51:09 | piotrekm | i have the latest commit on mine and it works fine, with mp3s at least |
| 21:51:12 | TheSeven | erm, wtf... |
| 21:51:41 | TheSeven | well, i have enabled undervolting and boosting, but that was working fine before... |
| 21:51:46 | piotrekm | *not latest, 24587 |
| 21:51:53 | Unhelpful | TheSeven: disk corruption much? |
| 21:52:13 | piotrekm | undervolting? |
| 21:53:09 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 21:55:22 | | Quit Strife89 (Quit: Going home.) |
| 21:56:55 | TheSeven | Unhelpful: it also keeps prefetch/data aborting |
| 21:57:55 | | Join froggyman [0] (~sopgenort@pool-72-69-210-48.chi01.dsl-w.verizon.net) |
| 21:59:32 | | Quit phanboy4 (Quit: Leaving) |
| 22:00 |
| 22:00:17 | | Quit ender` (Quit: 'And you have to shout -' He tried to remember some far-off reading. '- er, bonsai. Yes. Bonsai!' -- Terry Pratchett: Reaper Man) |
| 22:03:31 | *** | Saving seen data "./dancer.seen" |
| 22:14:23 | TheSeven | argh, that channel swapping issue is driving me mad |
| 22:14:41 | TheSeven | i have files where it seems to swap like 5 times a second, and others that don't swap at all |
| 22:20:55 | CIA-88 | New commit by theseven (r24589): Fix iPod Nano 2G channel swapping issues |
| 22:25:28 | | Quit archivator (Quit: Leaving) |
| 22:25:32 | liar | thanks TheSeven |
| 22:27:57 | piotrekm | wow |
| 22:28:02 | piotrekm | thanks TheSeven |
| 22:29:56 | | Join Strife89 [0] (~michael@adsl-154-2-168.mcn.bellsouth.net) |
| 22:33:40 | TheSeven | well, that was a trivial one |
| 22:37:09 | piotrekm | TheSeven: you know that it also fixed the white noise appearance on the beginning of tracks? |
| 22:37:41 | piotrekm | or not... i said that too early |
| 22:37:43 | | Join Jaykay [0] (~chatzilla@p5DDC764A.dip.t-dialin.net) |
| 22:38:42 | | Quit JdGordon_ (Ping timeout: 248 seconds) |
| 22:38:44 | piotrekm | it's better than was anyway;) |
| 22:39:04 | AlexP | TheSeven: Can FS #10812 be closed? |
| 22:40:33 | | Quit captainkewlllll (Quit: Page closed) |
| 22:40:49 | | Join Buschel [0] (~ab@p54A3DCBE.dip.t-dialin.net) |
| 22:41:21 | TheSeven | piotrekm: i never have noise at the beginning of tracks... |
| 22:41:33 | piotrekm | strange |
| 22:41:43 | TheSeven | AlexP: thanks, was digging through flyspray right now to find it |
| 22:41:58 | | Quit mt (Remote host closed the connection) |
| 22:42:06 | TheSeven | we really need a way to list all bugs for a given targetr |
| 22:42:09 | TheSeven | target* |
| 22:42:12 | | Join JdGordon_ [0] (~836b006a@gateway/web/freenode/x-xhpxrbgutegziryi) |
| 22:42:19 | piotrekm | i get it in some albums, but when played on pc this doesn't occur |
| 22:42:39 | AlexP | Yeah - I was looking for that just now but it doesn't seem to appear in the advanced search bit |
| 22:43:27 | TheSeven | piotrekm: i sometimes get parts of other tracks etc. played for an instant when skipping around |
| 22:44:02 | AlexP | B4gder: When you get a second could you put me so I can assign flyspray things to myself? I'm not in the list of people to assign things to and a couple of times I wanted to give myself things |
| 22:44:30 | piotrekm | TheSeven: i think i wasn't precise again, this occurs only when one track ends and another begins, not if i manually skip |
| 22:45:06 | | Quit Omlet (Read error: Connection reset by peer) |
| 22:45:13 | B4gder | AlexP: checking... |
| 22:45:18 | AlexP | ta |
| 22:45:47 | B4gder | AlexP: so you have no "assign to me" button then? |
| 22:46:00 | AlexP | oh, er, maybe - one mo :) |
| 22:46:43 | | Join Omlet [0] (omlet05@49.145-242-81.adsl-dyn.isp.belgacom.be) |
| 22:47:30 | AlexP | B4gder: Sorry, yes - I didn't notice that and was trying to do it via the list when you edit the task :) |
| 22:47:39 | | Quit Farthen (Ping timeout: 256 seconds) |
| 22:47:48 | B4gder | oh well, issue sorted then I guess! ;-) |
| 22:47:52 | AlexP | yep :) |
| 22:48:12 | AlexP | Not sure how I didn't spot that button - it is right next to close task which I use quite a bit :) |
| 22:48:35 | B4gder | you've been SO focused on that close! |
| 22:48:41 | AlexP | :) |
| 22:50:23 | TheSeven | B4gder: is there any way to add the player type to the filter options in flyspray's advanced search? |
| 22:51:53 | B4gder | not that I know of, no |
| 22:52:26 | TheSeven | (besides patching flyspray) |
| 22:52:31 | B4gder | right |
| 22:52:38 | | Join Adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 22:55:55 | TheSeven | heh, I *think* I may have found a way to get rid of those boosting glitches |
| 22:56:19 | TheSeven | what about just switching the ARM core to fastbus mode instead of tampering with the prescalers? |
| 22:56:23 | | Join Horscht [0] (~Horscht2@xbmc/user/horscht) |
| 22:57:13 | bertrik | TheSeven, I think that's what we do for the as3525 targets |
| 22:57:27 | | Join Strife89|PalmTX [0] (~cstrife89@adsl-154-2-168.mcn.bellsouth.net) |
| 22:58:08 | TheSeven | we may want to additionally clock down the system bus, but as soon as the cpu and the bus are using the same clock, I don't think the freqswitch will cause any issues |
| 23:00 |
| 23:01:42 | | Quit Strife89|PalmTX (Client Quit) |
| 23:03:57 | saratoga | B4gder: what did the ffmpeg people want from us? |
| 23:04:24 | B4gder | wma, mdct and ape came up in the discussions |
| 23:04:43 | B4gder | I couldn't really comment on the details, as I don't know them... |
| 23:04:46 | saratoga | do you have the logs? |
| 23:04:55 | saratoga | i don't think they log their channel |
| 23:05:14 | B4gder | ehm, I don't right now as I did it from my other computer which is shut off atm |
| 23:05:19 | saratoga | ok |
| 23:05:19 | bertrik | We have a person called "Phinitnun Chanasabaeng" and another called "Pinitnun Shanasabang" in CREDITS. Are they actually different people? |
| 23:05:44 | saratoga | i've given merging our code a lot of thought and basically decided it wasn't practical, so i'm curious what they were thinking exactly |
| 23:05:50 | B4gder | saratoga: ask them, they're friendly and many in that channel ;-) |
| 23:05:58 | saratoga | haha thats not been my experience |
| 23:06:32 | saratoga | last time i asked the answer was something like "go away and stop forking ffmpeg" |
| 23:06:43 | B4gder | ouch |
| 23:07:05 | saratoga | although in fairness they were talking about AAC, and we don't even use their aac decoder, so the guy probably just didn't know what he was talking about |
| 23:07:13 | bertrik | maybe they didn't realise how serious you are about it |
| 23:07:54 | saratoga | the ffmp3 is a no brainer, and in fact its been proposed as a potiential GSOC project for this year |
| 23:08:04 | saratoga | the same for ffaac |
| 23:08:10 | B4gder | ok |
| 23:08:16 | saratoga | although they overestimate their improvements over libmad |
| 23:08:25 | saratoga | i think i saw 15% on x86 over libmad |
| 23:08:28 | B4gder | I somehow suspsected that |
| 23:08:39 | saratoga | which puts them somewhere around "astonishingly slow" |
| 23:08:40 | B4gder | they claimed ~50% |
| 23:08:55 | saratoga | you sure they didn't mean libfaad? |
| 23:09:03 | B4gder | yes |
| 23:09:09 | saratoga | they're about 50% faster then libfaad and people mix up it with libmad sometimes since they rhyme |
| 23:09:28 | B4gder | we explicitly talked about mp3 then so I'm quite sure |
| 23:09:37 | saratoga | FFmpeg: 22.3s libmad: 24.2s mpg123: 9.5s |
| 23:09:50 | saratoga | http://multimedia.cx/eggs/gcc-of-multimedia/ |
| 23:10:00 | | Quit anewuser (Quit: Another edition of chiptune gig WinterChip5! :O http://xrl.us/WinterChipV =ooo) |
| 23:11:31 | saratoga | although they've obviously got some algorithmic improvements, so its worth seeing if we can steal them |
| 23:11:56 | saratoga | do they actually want their fixed point mdct back? |
| 23:12:18 | saratoga | i remember reasonably efficient fixed point mdcts being propose to them before and going no where |
| 23:12:58 | saratoga | i assumed they weren't interested |
| 23:13:08 | B4gder | they do, but I'm not sure for what purpose exactly |
| 23:13:50 | TheSeven | hm, fastbus saves ~4mA |
| 23:13:55 | saratoga | mt's cook decoder is basically a dusted off set of patches for fixed point code in ffmpeg |
| 23:14:01 | TheSeven | and no glitches any more :-) |
| 23:14:05 | saratoga | TheSeven: the arm9 bus mode? |
| 23:14:14 | TheSeven | yep |
| 23:14:26 | bertrik | wow, nice! current consumption was already pretty low on the nano 2g, right? |
| 23:14:30 | saratoga | combined with his own rm parser and a lot of optimization of course |
| 23:14:40 | TheSeven | 21/22 vs. 25/26 mA |
| 23:14:50 | saratoga | fastbus is where you run the clocks at integer multiples right? |
| 23:15:21 | bertrik | no, that's synchronous |
| 23:15:31 | TheSeven | fastbus = arm runs at bus clock |
| 23:15:58 | TheSeven | synchronous doesn't work for me, even when they are running at integer multiples |
| 23:16:06 | saratoga | so how do you boost? |
| 23:16:17 | TheSeven | by switching between asynchronous and fastbus |
| 23:16:20 | saratoga | ah |
| 23:16:27 | saratoga | thats probably something we should check on ams then |
| 23:16:33 | TheSeven | (and additionally clocking the bus down to 50MHz when in fastbus mode) |
| 23:16:45 | saratoga | how does IRAM work on the 2G? |
| 23:16:57 | saratoga | is it off the AHB or some special bus |
| 23:17:03 | TheSeven | probably ahb |
| 23:17:10 | TheSeven | it needs 2 cycles per access IIRC |
| 23:17:19 | saratoga | isn't the AHB really slow |
| 23:17:33 | saratoga | i thought its a 16 bit bus with multiple cycle access times |
| 23:17:33 | TheSeven | AHB is 100MHz, ARM is 200MHz |
| 23:17:45 | saratoga | so that'd be no better then 4 clocks |
| 23:17:52 | TheSeven | hm, iirc AHB is 32bit... |
| 23:18:05 | | Quit _zic (Ping timeout: 245 seconds) |
| 23:18:06 | TheSeven | but it may well be a different bus |
| 23:18:16 | saratoga | ah ok |
| 23:18:39 | saratoga | the one on AMS is either amazingly slow, or else the IRAM is really slow |
| 23:20:55 | bertrik | the as3525 calls AHB the "the advanced *high-speed* bus" |
| 23:21:22 | saratoga | the ARM9TDMI also says it has a fast 4 cycle multiplier |
| 23:21:40 | saratoga | trust nothing arm tells you |
| 23:22:09 | bertrik | I have no reason to believe it's slow |
| 23:24:14 | TheSeven | oops, my nano is starving for cpu power, the menu is *very* sluggish, but it just doesn't want to boost (stays at 47MHz) |
| 23:25:01 | TheSeven | but it's still playing back realtime, only had 2 little gaps during that track (mp3) |
| 23:26:59 | | Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
| 23:28:00 | | Quit GeekShado_ (Read error: Connection reset by peer) |
| 23:29:39 | amiconn | gevaerts: Could you test a new patch? This time with real speed improvements... |
| 23:29:48 | gevaerts | sure |
| 23:30:22 | amiconn | http://amiconn.dyndns.org/~jens/ape_armv5_fused.diff |
| 23:30:57 | | Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 23:32:19 | amiconn | Please test -c2000 and -c3000 speeds first. I expect around 7% speedup for -c3000. If that works, you could do a full test; this will be the final version except some #if 0'd junk |
| 23:33:00 | | Quit piotrekm (Quit: Leaving.) |
| 23:33:51 | * | amiconn would be interested in the raw test_codec output as well, i.e. not rounded |
| 23:35:55 | Unhelpful | saratoga: well, average 4 cycles? |
| 23:36:08 | * | JdGordon_ points everyone to the mailing list |
| 23:36:24 | JdGordon_ | pixelma: amiconn: any chance you can test the fm patch on hwcodec+rec soonish please? |
| 23:36:46 | JdGordon_ | I'm at the pointt where its ready for commit |
| 23:37:38 | gevaerts | amiconn: c2000 220.01% |
| 23:37:47 | gevaerts | 330.01 that is |
| 23:39:25 | | Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) |
| 23:39:40 | gevaerts | amiconn: c3000 220.92 |
| 23:39:48 | JdGordon_ | rasher: domonoky: does anything need to be done for the theme site to accept fm skined themes? or will they just work (but not verify them) untill magic scripts are fixed? |
| 23:40:16 | domonoky | JdGordon_: it will accept them. |
| 23:40:47 | domonoky | to get them verify i just need to add extensions (if checkwps takes them without problems) |
| 23:41:36 | JdGordon_ | checkwps shouldnt have any problems, I dont tihnk it checks extensions |
| 23:41:43 | JdGordon_ | does the theme site verify the .cfg? |
| 23:42:29 | | Quit Buschel () |
| 23:43:54 | gevaerts | JdGordon_: just to clarify once more, "coming from the skin buffer" is talking about the skin usage, right? i.e. if it gets added to the plugin API, plugins would provide the RAM? |
| 23:44:37 | JdGordon_ | gevaerts: right now, no plugins would use the skin buffer also |
| 23:44:57 | JdGordon_ | but thats something that can change |
| 23:45:13 | amiconn | gevaerts: That's in fact reasonable. When estimating, I didn't take the other stages into account |
| 23:45:25 | amiconn | So filter speedup is ~9%, as it should be |
| 23:46:02 | JdGordon_ | the problem with passing extra buffers in is what happens when a plugin loads font A, and something else also loads font A? right now A is only loaded once and not unloaded untill both unload it. but if the first buffer points into the plugin buffer it will break |
| 23:46:10 | JdGordon_ | that shouldnt ever happen though |
| 23:46:13 | amiconn | Could you please do the other compression levels as well (including -c1000 - sometimes shifting code around changes speed due to cache influences) |
| 23:46:56 | gevaerts | amiconn: running now. It just started on c5000. I'll pastebin the output file once it's done |
| 23:47:03 | gevaerts | JdGordon_: right now it's not exported, so there is of course no issue :) |
| 23:47:13 | amiconn | thx |
| 23:47:22 | domonoky | JdGordon_: no it doesnt check the config at moment. |
| 23:47:35 | | Join pamaury [0] (~pamaury@ALyon-551-1-36-230.w80-9.abo.wanadoo.fr) |
| 23:47:48 | gevaerts | I see your point, but what if a WPS uses the full buffer, and then a plugin starts? Does the WPS get reloaded afterwards? |
| 23:47:52 | domonoky | that is a todo for the future. is there are list of allowed settings for themes ? |
| 23:48:04 | JdGordon_ | gevaerts: yes, but even when it is, the skins are the only things loading fonts, and that cant happen when a plugin is running (simply because it uses the plugin buffer to read the skin file :) ) |
| 23:48:13 | | Quit pamaury (Client Quit) |
| 23:48:39 | | Join pamaury [0] (~pamaury@ALyon-551-1-36-230.w80-9.abo.wanadoo.fr) |
| 23:48:48 | JdGordon_ | domonoky: no, but the list is fairly static so if its just a file in svn we can update it as needed |
| 23:49:06 | gevaerts | JdGordon_: ok, so a plugin can never fail to load a font because a the user happens to like complex wpses? |
| 23:49:35 | JdGordon_ | it can now, |
| 23:49:59 | JdGordon_ | yeah, so plugins do need to pass in a buffer somehow |
| 23:50:09 | | Quit domonoky (Read error: Connection reset by peer) |
| 23:50:49 | gevaerts | I think so, yes |
| 23:51:15 | gevaerts | Apart from that, I agree that a multi-buffer approach now is better than a nice single-buffer appoach in three years |
| 23:52:17 | JdGordon_ | also, with a sufficiently complicated theme a plugin could fail to load a font because the theme uses up all the font slots |
| 23:52:39 | JdGordon_ | unless we can come up with a better way of storing the font pointers |
| 23:53:15 | gevaerts | If possible, I'd look for a way for plugins to have their own font slots and only share the two main ones |
| 23:54:04 | gevaerts | or we could restrict font slots per user |
| 23:54:09 | JdGordon_ | so we use a callback for the lcd drivers to get the font from the plugin? |
| 23:55:37 | gevaerts | hm, yes. The lcd drivers shouldn't really have to know about plugins... |
| 23:56:27 | JdGordon_ | maybe we just up the font slots to something like 20 and assume noone will be able to fill that |
| 23:56:38 | JdGordon_ | 17 avialable for the apps/ layer ought to be plenty |
| 23:57:23 | gevaerts | I'd reserve a few explicitely for plugins then |
| 23:57:43 | JdGordon_ | how many? 3? 4? |
| 23:58:01 | * | amiconn thinks this sounds more complex than a single font buffer |
| 23:58:17 | | Quit pamaury (Quit: abort();) |
| 23:58:39 | JdGordon_ | amiconn: yes, but unless someone actually says they are going to code it then this is what we have |
| 23:58:45 | gevaerts | 3 or 4 is plenty, yes. The only plugin that we know really wants more fonts just needs one more after all |
| 23:58:50 | JdGordon_ | also, seperate buffers means less likelyhood of cache thrashing |
icon identifies that the person is a core developer (has commit access).