00:03:37 | | Join MethoS- [0] (~clemens@134.102.106.250) |
00:10:08 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
00:13:57 | Llorean | saratoga: The beast also charges from USB |
00:14:05 | Llorean | But unlike the F, it doesn't charge from USB when turned off (the F does) |
00:14:27 | saratoga | do I need to force it? i just plugged it in and it said discharging until i added ac power |
00:15:18 | | Quit ender` (Quit: "I'm the head wizard now. I've only got to give an order and a thousand wizards will ... uh ... disobey, come to think of it, or say 'What?', or start to argue. But they have to take notice." -- Archchancellor (Terry Pratchett: Lords and Ladies)) |
00:15:19 | Llorean | I generally don't have to. |
00:15:27 | Llorean | Just hold Menu while plugging in, and there it goes. |
00:15:49 | Llorean | It doesn't show the same charging display that AC power does, but battery charge does go up over time |
00:16:01 | | Quit dfkt (Ping timeout: 245 seconds) |
00:16:25 | saratoga | hmm it didn't go into USB mode either, so maybe i should try a different cable |
00:20:49 | saratoga | oh you said menu, i was expecting it to be select like on teh sansas |
00:20:51 | saratoga | that worked |
00:21:12 | saratoga | any reason we have a specific button to hold to get charge mode? it would be easier for users if you could hold any button |
00:22:53 | | Join webguest43 [0] (~5a23269f@giant.haxx.se) |
00:24:22 | | Quit webguest43 (Client Quit) |
00:26:56 | saratoga | aligning a few structs in libmad speed it up on the beast |
00:26:59 | Llorean | saratoga: I've been saying it should be any button for a while. I haven't really heard anyone argue strongly against it. |
00:27:10 | saratoga | any idea where the check is? |
00:27:25 | saratoga | grep suggests usb.c or powermangmt.c |
00:27:39 | Llorean | No idea. |
00:28:18 | Llorean | I think people have argued against it, but I honestly can't remember anything beyond "some buttons could have unexpected behaviour like fast forward" which doesn't seem much of a real problem / likelihood (I think people will realize holding a button will do whatever that button *does* until they insert the USB cable) |
00:30:05 | | Quit stripwax (Quit: http://miranda-im.org) |
00:30:29 | | Join ReimuHakurei [0] (~reimu@adsl-75-16-233-192.dsl.kntpin.sbcglobal.net) |
00:30:43 | saratoga | i wonder how you force alignment in a .S file |
00:33:41 | | Quit dys (Ping timeout: 276 seconds) |
00:33:54 | | Join JdGordon| [0] (~jonno@vl10.gw.ok-labs.com) |
00:33:54 | | Quit JdGordon| (Changing host) |
00:33:54 | | Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) |
00:34:32 | | Quit JdGord (Quit: Bye) |
00:37:59 | JdGordon| | saratoga: the usb connect thing is something that always get discussed but nothing ever happens with |
00:38:10 | saratoga | do you know where the check is |
00:38:21 | JdGordon| | I personally think a menu on connect is the best way to do it but noone will come to an agreement |
00:38:42 | JdGordon| | no, gevaerts would probbaly know |
00:38:52 | JdGordon| | or search for button_get() in firmware/ |
00:40:44 | gevaerts | saratoga: usb_power_button() in usb.c |
00:41:13 | soap | FWIW I believe I can pick up a Cowon S9 for $175. Not cheap, but cheaper than $250. |
00:41:14 | gevaerts | The button to use is in usb.h |
00:41:30 | saratoga | what header do i need to use MEM_ALIGN |
00:41:34 | Llorean | JdGordon|: Well there still needs to be a decision for cases where a menu can't come up, or be used for whatever reason, so menuless behaviour is still good whether or not a menu will go in in the future. |
00:41:56 | saratoga | it shouldn't check for any particular button, just if (btn) |
00:42:01 | saratoga | no bitmask |
00:42:22 | JdGordon| | that has been one of the common arguments |
00:42:25 | soap | ahh, nevermind. That was a local price. On ebay one can score a refurb for less than that. |
00:42:45 | * | JdGordon| is hoping to score a mini2g for $30 :) |
00:43:28 | saratoga | wtf adding codec.h is enough for layer3.c, but not for huffman.c |
00:43:36 | saratoga | can one macro depend on two headers? |
00:45:27 | saratoga | and make clean returns to both not compiling . . . |
00:47:44 | JdGordon| | sounds like you got yerself a broken header :p |
00:47:58 | saratoga | how the hell do i get system.h into a codec |
00:49:53 | JdGordon| | what do you need from it? it might be wrapped in !PLUGIN/CODEC? |
00:50:20 | saratoga | i just want to use mem_align in a codec |
00:50:31 | saratoga | and it randomly works or doesn't work in some files depending on the make -j setting |
00:53:01 | saratoga | huh __attribute__((aligned(16))) doesn't work either |
00:53:11 | saratoga | are there restrictions on what types of variables can be aligned? |
00:53:21 | JdGordon| | is your system stuffed? |
00:53:38 | JdGordon| | that all just sounds broken |
00:54:13 | *** | Saving seen data "./dancer.seen" |
00:54:52 | saratoga | no i see what it is |
00:55:05 | saratoga | the attribute has to go before the = |
00:55:34 | saratoga | I was doing "int x = 0 MEM_ALIGN;" |
01:00 |
01:03:43 | saratoga | anyone available to test on android? |
01:04:23 | Jonas29 | is it possible to go on web site with rockbox |
01:04:25 | saratoga | i get a small speed up on the beast, but I'd be curious what its like on Android where alignment seems more important |
01:04:29 | saratoga | no |
01:06:47 | | Quit markun (Ping timeout: 240 seconds) |
01:07:14 | saratoga | what does USBPOWER_BTN_IGNORE do exactly? |
01:07:46 | Jonas29 | is it preview to appear its a future version? |
01:09:05 | saratoga | no |
01:09:51 | Jonas29 | why? |
01:09:53 | saratoga | oh the sansa USBPOWER_BTN_IGNORE is power, but holding power will just turn off the player |
01:09:56 | saratoga | what is the idea here? |
01:10:04 | saratoga | Jonas29: not possible |
01:11:54 | | Join dys [0] (~andreas@krlh-5f72148d.pool.mediaWays.net) |
01:12:26 | Jonas29 | saratoga: why is it not possible? |
01:12:37 | saratoga | hardware limitations |
01:12:42 | Jonas29 | ok |
01:13:45 | Jonas29 | on the ipod touch, there is a hardware limitations |
01:15:23 | saratoga | we don't run on the ipod touch |
01:16:14 | saratoga | USBPOWER_BTN_IGNORE was added by amiconn in r7674 specifically for the archos players, it seems people continued to update the macros as new players were added even though they're often nonsensical |
01:17:03 | Jonas29 | ok it is probably eventually provided |
01:17:40 | saratoga | if it is, it'll probably be as an application so you would just use the apple web browser |
01:19:13 | saratoga | gevaerts: logs say you added the inverted USB connect logic for the H10, do you remember why thats needed? |
01:28:51 | | Join markun [0] (~markun@5ED33C2C.cm-7-4a.dynamic.ziggo.nl) |
01:28:51 | | Quit markun (Changing host) |
01:28:51 | | Join markun [0] (~markun@rockbox/developer/markun) |
01:34:21 | Llorean | saratoga: What button is it on the H10. I seem to remember when that happened and it making sense, but I can't for the life of me remember why so I may just be confused |
01:34:48 | saratoga | BUTTON_RIGHT |
01:37:18 | | Quit ReimuHakurei (Ping timeout: 264 seconds) |
01:40:31 | | Join Keripo [0] (~Keripo@eng239.wireless-resnet.upenn.edu) |
01:48:46 | saratoga | bah we use rockbox USB anyway, so that code never runs |
01:48:52 | saratoga | gonna throw up a patch |
01:51:05 | | Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) |
01:55:50 | | Quit Llorean (Read error: Connection reset by peer) |
02:00 |
02:07:30 | saratoga | FS #11769 - Change USB charge mode detection key |
02:07:48 | saratoga | i'd appreciate if amiconn or someone else who wrote the code originally for archos could comment on it |
02:10:48 | | Join ReimuHakurei [0] (~reimu@74.112.212.15) |
02:18:55 | saratoga | how hard is it to add a yes/no menu option to a plugin? |
02:20:15 | JdGordon| | not at all |
02:20:17 | | Quit BHSPitMonkey (Ping timeout: 265 seconds) |
02:21:17 | | Join Llorean [0] (~DarkkOne@adsl-66-142-150-38.dsl.hstntx.swbell.net) |
02:21:38 | | Quit Llorean (Client Quit) |
02:22:47 | saratoga | JdGordon|: right now, test_codec calls "do_menu" and then checks the result to figure out what to do, what would I need to have an option to set boosting to yes/no without returning from teh do_menu call ? |
02:23:00 | saratoga | basically i want to be able to choose any of the options on the menu with or without boosting |
02:24:54 | JdGordon| | probably not very much... hang on |
02:27:29 | JdGordon| | just add an item to the MENUITEM_STRINGLIST() and check for it, then goto show_menu; |
02:30:50 | saratoga | JdGordon|: I have to do a "rb->set_option" if I want the yes/no menu right? |
02:31:19 | JdGordon| | sounds right |
02:31:32 | JdGordon| | umm, maybe not |
02:32:16 | JdGordon| | you could just do "toggle boost" and then a splash saying "Boost on/off" |
02:33:40 | saratoga | yes/no is probably better though, since eventually i want to have othe roptions |
02:34:09 | saratoga | in the opt_items structs, what does the second column mean? its usually -1 |
02:34:10 | JdGordon| | I cant remember if set_option only works with the global_setting settings or not |
02:34:13 | JdGordon| | ... probably doesnt |
02:34:18 | JdGordon| | lang string |
02:35:23 | JdGordon| | umm, I meant it probably *does* work how you want it |
02:36:40 | saratoga | yeah i figured |
02:36:47 | saratoga | well compiling now, will bug you in probably 1 minute |
02:37:40 | saratoga | finally getting around to fixing up test_codec a little |
02:40:30 | saratoga | JdGordon|: ok it draws the menu, but it doesn't actually update teh variable |
02:40:52 | saratoga | i just did "rb->set_option("Boosting", &boost, INT, boost_settings, 2, NULL);" |
02:40:52 | JdGordon| | pastebin |
02:40:56 | saratoga | where boost is the variable |
02:41:02 | saratoga | it apparently stays set to zero |
02:41:24 | JdGordon| | did it pop up the set opiton gui? |
02:41:44 | saratoga | yeah |
02:41:52 | saratoga | and it even defaulted to the right value |
02:41:58 | saratoga | but changing it didn't seem to do anything |
02:42:11 | saratoga | http://pastebin.com/MvpmVnBB |
02:42:36 | JdGordon| | I havnt looked at set_option() is AGES, check how other plugins use it |
02:44:27 | saratoga | i'm using it the same as fireworks.c, so maybe i'm doing something else wrong |
02:44:45 | | Join enginerd [0] (~znielsen@cblmdm24-53-147-95.buckeyecom.net) |
02:46:21 | enginerd | Anybody have experience with rockbox on a Toshiba Gigabeat S? |
02:46:46 | saratoga | a little, just playing with it now |
02:47:45 | enginerd | I had 3.6 installed previously with very few issues and I tried to update to 3.7 and am having trouble |
02:48:08 | enginerd | when I plug the device into the computer it enters the "error" screen |
02:48:46 | enginerd | I was able to get it to load but as soon as I reconnected to add music it started acting up |
02:49:01 | saratoga | does rockbox actually work on it? |
02:49:17 | enginerd | it did at first but I can't get it to load now |
02:49:23 | saratoga | probably a screwed up file system |
02:49:32 | enginerd | and suggestions |
02:50:07 | saratoga | JdGordon|: any idea why test_codec doesn't update teh screen if the backlight is off? |
02:50:27 | saratoga | it means that if the backlight goes off while the plugin is running, then it finishes, theres no way to get the output |
02:50:35 | saratoga | i'tll just show the last thing blitted to the screen while it was on forever |
02:50:57 | JdGordon| | battery saving, on some targets no updates happen with the backlight off |
02:51:52 | saratoga | how do i tell the screen to update the framebuffer if the screen is off? |
02:52:01 | | Join Llorean [0] (~DarkkOne@adsl-66-142-150-38.dsl.hstntx.swbell.net) |
02:52:03 | JdGordon| | I don't know if you can |
02:52:21 | | Quit Llorean (Changing host) |
02:52:21 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
02:54:15 | *** | Saving seen data "./dancer.seen" |
02:54:29 | saratoga | JdGordon|: I think the problem is i'm not telling set_option what to put in the output correctly |
02:54:43 | saratoga | i assume it just puts the index of the option, but maybe thats not the case? |
02:54:55 | JdGordon| | thats what it should be doing |
02:55:24 | JdGordon| | whats that last NULL param? |
02:56:00 | saratoga | i'm not sure, but other things seem to do it |
02:58:21 | saratoga | could you take another look at what I have? http://pastebin.com/YjNL263V |
02:58:27 | saratoga | boost seems to be always zero |
02:58:39 | saratoga | it must be something stupid |
03:00 |
03:00:10 | JdGordon| | it looks correct :/ |
03:02:13 | saratoga | wait |
03:02:21 | saratoga | the Yes/No are shown in reverse order on the screen |
03:02:33 | saratoga | so Yes maps to 0 and No to 1 I bet |
03:04:03 | | Quit froggyman (Quit: Bye) |
03:04:20 | JdGordon| | which target? |
03:05:07 | saratoga | clip+ |
03:05:28 | JdGordon| | clip+ shouldnt be swapping things |
03:05:35 | saratoga | yeah I don't get it |
03:05:41 | saratoga | the struct has NO, then YES |
03:05:46 | saratoga | but on device its YES then NO |
03:06:09 | saratoga | i'm going to make the menu print the values it returns |
03:06:26 | | Quit Boldfilter (Quit: Boldfilter) |
03:06:47 | enginerd | saratoga: I used the gbs_update_1_2_us.exe to restore the device (which worked as it should). When I run the beastpatcher.exe and it should reboot to "bootloader USB mode" it enters the error number 2 |
03:06:53 | enginerd | any ideas? |
03:07:01 | saratoga | no, but check the wiki |
03:07:24 | saratoga | theres a lot of documentation there |
03:07:47 | enginerd | ok |
03:08:55 | saratoga | oh fucking hell how does log_text not recognize \n as new line |
03:10:00 | saratoga | does the beast not have boosting? |
03:14:39 | JdGordon| | I think yes it doesnt |
03:15:00 | saratoga | weird |
03:15:27 | | Quit DerPapst (Quit: Leaving.) |
03:16:02 | | Join eWill [0] (~chatzilla@adsl-99-139-149-70.dsl.dytnoh.sbcglobal.net) |
03:16:04 | JdGordon| | that wouldnt stop set_option() from working though |
03:17:53 | eWill | Say I install RB to a Fuze v2, and all is good. Later I upgrade RB, but some core RB boot file gets corrupted, and RB won't boot. Does this mean I will have to CRACK OPEN my player in order to shot the two pins that allow recovery mode? |
03:18:10 | eWill | *shot = short |
03:18:57 | mc2739 | eWill: no, you can still hold the left button to boot the OF |
03:19:13 | eWill | thanks a lot :) |
03:20:40 | saratoga | JdGordon|: i think its working now |
03:20:46 | saratoga | not really sure what i was doing wrong |
03:20:58 | | Quit enginerd (Quit: Leaving) |
03:22:59 | CIA-7 | New commit by saratoga (r28637): Add option to run test_codec unboosted on players with boosting. |
03:24:50 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
03:25:01 | CIA-7 | r28637 build result: All green |
03:28:03 | eWill | Just ordered a re certified Fuze v2 4gb. I'm all excited. |
03:28:14 | CIA-7 | New commit by saratoga (r28638): Fix mistake on targets without frequency scaling. |
03:30:10 | CIA-7 | r28638 build result: All green |
03:42:24 | | Quit eWill (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) |
03:43:11 | | Join Xerion_ [0] (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) |
03:45:03 | | Quit Xerion (Ping timeout: 240 seconds) |
03:45:04 | | Nick Xerion_ is now known as Xerion (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) |
03:45:23 | | Quit Rob2223 (Read error: Connection reset by peer) |
03:45:58 | | Join Rob2222 [0] (~Miranda@p4FFF1EE5.dip.t-dialin.net) |
03:51:15 | CIA-7 | New commit by saratoga (r28639): Force alignment of various data structures in libmad. Speeds up Gigabeat S decoding by about 1MHz. |
03:52:56 | CIA-7 | r28639 build result: All green |
03:57:52 | saratoga | kugel: i can't get your ruby script to parse the MHz field on my test_codec output |
03:57:59 | saratoga | i just get 0MHz |
04:00 |
04:01:56 | | Join dys` [0] (~andreas@krlh-5f727557.pool.mediaWays.net) |
04:03:59 | saratoga | with my mp3 optimizations, mp3 is now faster then vorbis on arm11 |
04:04:03 | | Quit bluebrother (Disconnected by services) |
04:04:05 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
04:06:49 | | Quit dys (Ping timeout: 276 seconds) |
04:14:13 | | Join Barahir [0] (~jonathan@frnk-590fc885.pool.mediaWays.net) |
04:14:29 | | Quit Barahir_ (Read error: Operation timed out) |
04:18:42 | | Quit Keripo (Read error: Connection reset by peer) |
04:19:20 | | Join Keripo [0] (~Keripo@eng239.wireless-resnet.upenn.edu) |
04:35:45 | | Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
04:45:43 | | Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) |
04:46:33 | | Quit Jonas29 (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101027154941]) |
04:47:58 | | Quit TheSeven (Ping timeout: 240 seconds) |
04:53:12 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
04:54:17 | *** | Saving seen data "./dancer.seen" |
04:54:43 | | Quit anewuser () |
04:55:37 | | Quit pixelma (Disconnected by services) |
04:55:39 | | Quit amiconn (Disconnected by services) |
04:55:39 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
04:55:39 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
04:55:41 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
04:55:59 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
05:00 |
05:01:53 | | Join dys`` [0] (~andreas@krlh-5f7226f8.pool.mediaWays.net) |
05:03:41 | | Quit Keripo (Quit: Leaving.) |
05:04:01 | | Quit dys` (Ping timeout: 276 seconds) |
05:06:57 | | Quit amiconn (Quit: No Ping reply in 64 seconds.) |
05:07:06 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
05:07:26 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
05:10:37 | | Join Llorean1 [0] (~DarkkOne@ppp-70-250-112-222.dsl.hstntx.swbell.net) |
05:10:38 | | Quit Llorean (Read error: Connection reset by peer) |
05:13:16 | | Nick Llorean1 is now known as Llorean (~DarkkOne@ppp-70-250-112-222.dsl.hstntx.swbell.net) |
05:13:21 | | Quit Llorean (Changing host) |
05:13:21 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
05:14:52 | | Quit saratoga (Quit: Page closed) |
05:21:16 | | Join ReimuHakurei_ [0] (~reimu@74.112.212.15) |
05:25:16 | | Quit ReimuHakurei (Ping timeout: 255 seconds) |
05:34:20 | | Quit ps-auxw (Ping timeout: 260 seconds) |
05:44:05 | | Quit Horscht (Quit: Verlassend) |
05:45:40 | | Join ps-auxw [0] (~arneb@p4FF7EFEE.dip.t-dialin.net) |
05:46:23 | | Quit factor (Quit: Leaving) |
05:46:35 | | Quit MethoS- (Remote host closed the connection) |
06:00 |
06:02:19 | | Join KiwiCam [0] (~Kiwicam@ip-118-90-117-233.xdsl.xnet.co.nz) |
06:05:25 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
06:12:21 | | Quit InsDel (Read error: Connection reset by peer) |
06:29:02 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
06:31:01 | | Part toffe82 |
06:39:40 | | Quit KiwiCam (Ping timeout: 260 seconds) |
06:50:29 | | Join Llorean1 [0] (~DarkkOne@adsl-69-153-200-83.dsl.hstntx.swbell.net) |
06:50:43 | | Quit Llorean (Disconnected by services) |
06:50:45 | | Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-69-153-200-83.dsl.hstntx.swbell.net) |
06:50:47 | | Quit Llorean (Changing host) |
06:50:47 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
06:54:19 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:11:11 | | Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) |
07:17:38 | | Quit JesusFreak316 (Ping timeout: 245 seconds) |
07:28:20 | | Quit JdGordon| (Quit: leaving) |
07:32:36 | | Join Buschel [0] (~chatzilla@p54A3A5B7.dip.t-dialin.net) |
07:34:49 | | Join KiwiCam [0] (~Kiwicam@ip-118-90-1-20.xdsl.xnet.co.nz) |
07:35:39 | | Join JdGord [0] (~jd@122.110.124.5) |
07:36:04 | | Join Topy [0] (~Topy44@f048107186.adsl.alicedsl.de) |
07:39:43 | | Quit T44 (Ping timeout: 245 seconds) |
08:00 |
08:04:35 | CIA-7 | New commit by saratoga (r28640): Align various libwma buffers. Saves about 1 MHz on the Gigabeat S. |
08:06:06 | Buschel | saratoga: stil awake? |
08:06:40 | CIA-7 | r28640 build result: All green |
08:08:23 | Buschel | saratoga: can you give this a try on your beast? -> http://pastie.org/1316790 |
08:10:49 | | Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) |
08:12:13 | saratoga | Buschel: 35.93 with that patch |
08:12:50 | Buschel | saratoga: thanks, and without? |
08:13:21 | Buschel | there is still no atrac3 sample in our test file compilation |
08:13:29 | saratoga | yes I made one tonight |
08:13:42 | saratoga | just have to find a CDR and I can make one from the official test file |
08:13:50 | saratoga | 35.84 without that patch |
08:13:50 | Buschel | perfect :) |
08:13:56 | saratoga | so basically no change |
08:13:59 | Buschel | yep. |
08:14:46 | saratoga | but it looks worth having so I say commit |
08:14:52 | saratoga | might help on android |
08:14:54 | amiconn | saratoga: Seen http://www.rockbox.org/wiki/TargetSpecificOptimization#Coldfire ? |
08:15:07 | | Quit KiwiCam (Ping timeout: 252 seconds) |
08:15:09 | saratoga | amiconn, no thanks |
08:15:43 | saratoga | did you see the patch i put up before about USB charge mode? |
08:16:47 | saratoga | Buschel: alignment mostly helps if you do ldm or load doubles to aligned buffers, so if aligning something doesn't help theres probably no multiple loads going on |
08:17:01 | saratoga | that might mean theres a chance to further optimize accessing that buffer |
08:18:09 | Buschel | yes, seems like the access to qmf_window[] is the main optimization |
08:20:21 | Buschel | need to go to work now, see you later |
08:20:23 | | Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) |
08:22:06 | saratoga | Buschel: weird that outSamples didn't make a difference, its accessed 4 words at a time |
08:22:15 | saratoga | maybe it was aligned by chance |
08:28:14 | amiconn | saratoga: The USB power button should always be chosen so that the action its long-press will trigger is not confusing or dangerous |
08:28:36 | Llorean | amiconn: If it's "all buttons" then assuming any button has a safe action, it'll always be available to the user |
08:28:46 | Llorean | Since "safe" can vary from screen to screen, or even based on the opinion of the user. |
08:29:07 | Llorean | I consider context menu generally safer than quickscreen, for example |
08:29:10 | Llorean | But not everyone agrees. |
08:29:11 | amiconn | The commit message for 7674 says why USBPOWER_BTN_IGNORE was added. |
08:30:41 | amiconn | The original ones (MODE for ondios, F1 for recorder fm/v2) are the menu buttons on their respective targets |
08:31:00 | * | Llorean doesn't see how "all buttons" introduces a new danger. |
08:31:17 | Llorean | Is the theory that users will assume that not a single button on the player will do anything other than allow USB mode when held? |
08:31:29 | amiconn | It does - for the very same reason why USBPOWER_BTN_IGNORE was introduced |
08:31:52 | Llorean | Could you explain that simply? |
08:31:55 | amiconn | That would cause devices with flashed rockbox to *always* enter usb power mode on startup |
08:32:36 | Llorean | So boot and then insert the cable? |
08:32:40 | amiconn | I.e. the button which is used to power up the device *must* be ignored |
08:33:01 | amiconn | What if you can't boot without power from USB? |
08:33:02 | Llorean | Or put in a special condition that the BTN_IGNORE button is ignore until boot "completes" safely |
08:33:24 | | Quit BHSPitMonkey (Remote host closed the connection) |
08:33:28 | amiconn | Completion is too quick for this |
08:33:31 | Llorean | If you can't boot without power from USB, isn't going into USB charging mode acceptable? You could then replug if you'd like UMS much like you have to if you're charging anyway and decide you want UMS access. |
08:33:47 | Llorean | The boot is too fast to give the user time to let go of the button? |
08:34:14 | amiconn | The Ondio can be used from USB power with no batteries inserted. If any button enters USB power mode, you would always end up there, and be unable to enter mass storage mode |
08:34:48 | Llorean | So the boot is too fast for a user to be able to let go of the button before it completes? |
08:35:17 | | Join kish_ [0] (~o2@unaffiliated/spice) |
08:35:19 | amiconn | Yes, because you need to hold it for a short while, until you can be sure that it boots |
08:35:34 | amiconn | Otherwise USBPOWER_BTN_IGNORE wouldn't have been introduced |
08:36:04 | Llorean | Things are introduced that aren't strictly speaking necessary, so I wasn't willing to make that assumption |
08:36:45 | Llorean | Even then, why not just ignore all "power" buttons? Since it's nonsense to hold down the button that shuts down the player to try to insert USB. If you're even a little slow you don't get anything |
08:37:27 | amiconn | Yes, that's what is necessary. |
08:37:27 | | Join Guest34717 [0] (~bjst@giant.haxx.se) |
08:37:27 | | Quit Guest34717 (Changing host) |
08:37:27 | | Join Guest34717 [0] (~bjst@rockbox/developer/Zagor) |
08:37:39 | | Nick Guest34717 is now known as Zagor (~bjst@rockbox/developer/Zagor) |
08:37:55 | Llorean | Or allow a button on the player to disconnect USB (if HID is not enabled) and a menu entry to enter MSC if charging from USB (these might be nice anyway) |
08:38:26 | Llorean | I'd really like a button to drop out of MSC, honestly, for my car where trying to hold down things is impractical, or where the player is waked by USB power and then enters MSC and replugging the cable is potentially unsafe while driving. |
08:38:59 | | Join esperegu [0] (~quassel@145.116.15.244) |
08:39:18 | amiconn | Yes, that might be useful. It also seems that some users would prefern an option what to do on usb insert instead of that button-hold mechanism |
08:39:56 | Llorean | My ideal would be an option to decide if the default is connect or charge, every button (or nearly every button) causing it to perform the other action, and a button that gets me out of MSC if I'm accidentally in it without having to replug. |
08:40:32 | Llorean | I think a menu would slow things down, and you'd still want it to timeout to one or the other (and which it would timeout to being probably user selected) anyway |
08:40:34 | amiconn | Something that resemples "Stop" would be the proper button for this I think |
08:40:38 | Llorean | Probably, yes. |
08:41:12 | amiconn | I'm not talking about a menu at insert (which might be impossible in the current screen) |
08:41:58 | Llorean | Ah, well some people want a menu at insert. Not me, though. |
08:42:21 | Llorean | I want a menu where I can decide what insert will do by default, then if I hold a button it does the opposite of what I've chosen. |
08:42:47 | Llorean | Since I'd much prefer the default on my in-car player to be charge, while the default on my Beast to be MSC |
08:44:43 | amiconn | -> an option |
08:44:58 | * | amiconn wonders why binsize on the Player increased so much lately |
08:45:08 | amiconn | rasher: Are you still running the binsize graphs? |
08:45:22 | | Quit xxcv (Ping timeout: 245 seconds) |
08:46:44 | | Quit JdGord (Quit: Bye) |
08:48:47 | | Join xavieran [0] (~xavieran@ppp118-209-255-13.lns20.mel6.internode.on.net) |
08:48:48 | rasher | amiconn: I am. It'll often be days between that computer is turned on though |
08:51:34 | amiconn | Player has hit the 200KB loader limit, causing it to use the self-extractor now |
08:54:23 | *** | Saving seen data "./dancer.seen" |
08:57:14 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
09:00 |
09:03:45 | | Join ender` [0] (krneki@foo.eternallybored.org) |
09:04:16 | | Join DerPapst [0] (~Alexander@p5DE5A242.dip.t-dialin.net) |
09:24:39 | | Join Rob2223 [0] (~Miranda@p4FFF23AF.dip.t-dialin.net) |
09:25:45 | | Join petur [0] (d408b802@rockbox/developer/petur) |
09:25:49 | | Quit S00row (Read error: Connection reset by peer) |
09:26:46 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
09:28:27 | | Quit Rob2222 (Ping timeout: 265 seconds) |
09:31:07 | | Join kramer3d [0] (~kramer@residents-ReservedNAT-129-174-190-10.residents.gmu.edu) |
09:31:07 | | Quit kramer3d (Changing host) |
09:31:07 | | Join kramer3d [0] (~kramer@unaffiliated/kramer3d) |
09:31:08 | | Quit S00row (Read error: Connection reset by peer) |
09:31:44 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
09:32:27 | | Join utanapischti [0] (~username@p4FF2CFEF.dip.t-dialin.net) |
09:34:42 | | Join LinusN [0] (~linus@giant.haxx.se) |
09:34:42 | | Quit LinusN (Changing host) |
09:34:42 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
09:36:53 | | Quit sasquatch (Ping timeout: 276 seconds) |
09:38:53 | | Quit liar (Read error: No route to host) |
09:39:08 | | Quit user890104 (Ping timeout: 272 seconds) |
09:40:34 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
09:49:18 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
09:52:22 | | Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) |
09:57:59 | | Quit DerPapst (Quit: Leaving.) |
09:59:06 | | Join JdGord [0] (~jd@122.110.124.5) |
10:00 |
10:10:14 | | Quit xavieran (Ping timeout: 265 seconds) |
10:15:32 | | Quit S00row (Read error: Connection reset by peer) |
10:17:08 | | Join S00row [0] (~Administr@27-33-98-164.static.tpgi.com.au) |
10:17:57 | | Quit factor (Read error: Connection reset by peer) |
10:22:07 | gevaerts | saratoga: that code isn't originally mine (although I may have accidentally removed it at some point and then readded it), but the reason for it is that (at least on MTP H10s) you have to hold the right button to get to the ROM USB mode, so in practice you have to hold the right button already before the reboot |
10:25:14 | gevaerts | Probably irrelevant now that we don't reboot for USB any more of course |
10:30:56 | | Nick dys`` is now known as dys (~andreas@krlh-5f7226f8.pool.mediaWays.net) |
10:30:59 | | Part LinusN |
10:32:22 | | Join u42p [0] (~u42p@d096239.adsl.hansenet.de) |
10:33:18 | u42p | (how) can i make rockbox start when i plug my sansa clip+ into usb? currently the original firmware loads. i am using http://www.rockbox.org/tracker/task/11664?show_task= |
10:33:31 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
10:35:20 | | Join DerPapst [0] (~Alexander@dslb-088-069-135-094.pools.arcor-ip.net) |
10:45:32 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
10:47:56 | | Quit GeekShadow (Ping timeout: 255 seconds) |
10:48:10 | TheSeven | u42p: you'll need to use a bootloader that knows about the fact that rockbox can handle USB, but I have no idea how to do that on a sansa or if there are precompiled ones available |
10:51:06 | | Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) |
10:52:49 | u42p | ah, i was guessing correctly yseterday then. well, gonna wait until that is officially done then |
10:52:50 | u42p | thanks! |
10:54:25 | *** | Saving seen data "./dancer.seen" |
10:58:24 | gevaerts | u42p: such a bootloader will be released as soon as rockbox handles USB itself |
10:58:57 | | Quit kramer3d (Ping timeout: 272 seconds) |
11:00 |
11:08:18 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
11:28:17 | | Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) |
11:30:55 | | Quit xxcv () |
11:50:58 | | Join xxcv [0] (~hello@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) |
11:52:15 | | Quit xxcv (Client Quit) |
11:56:05 | | Join Llorean1 [0] (~DarkkOne@adsl-69-153-196-187.dsl.hstntx.swbell.net) |
11:57:38 | | Quit Llorean (Ping timeout: 240 seconds) |
11:57:45 | | Join Llorean [0] (~DarkkOne@adsl-69-153-193-183.dsl.hstntx.swbell.net) |
11:57:47 | | Quit Llorean (Changing host) |
11:57:47 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
11:59:41 | | Join n1s [0] (~n1s@nl118-174-240.student.uu.se) |
11:59:41 | | Quit n1s (Changing host) |
11:59:41 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
12:00 |
12:01:12 | | Quit Llorean1 (Ping timeout: 276 seconds) |
12:05:38 | | Quit Dreamxtreme (Read error: Connection reset by peer) |
12:06:19 | | Join Keripo [0] (~Keripo@eng028.wireless-resnet.upenn.edu) |
12:08:28 | | Quit Keripo (Client Quit) |
12:15:39 | gevaerts | AlexP: did you follow commits to trunk to check for stable-suitability? |
12:15:56 | gevaerts | I'm thinking it may be time for a point release |
12:17:40 | * | TheSeven has a question about "const" |
12:19:02 | TheSeven | if i have a register that needs to be set to an address, and the data at that address won't be affected by the address being written to that register, how do i declare that? |
12:19:42 | TheSeven | #define DMAC0C0SRCADDR (*((volatile void**)(0x38200100))) will complain that the const qualifier (on the argument passed to the function that writes the address to that register) is discarded |
12:20:03 | TheSeven | #define DMAC0C0SRCADDR (*((volatile const void**)(0x38200100))) seems to tell the compiler that the register would be read-only |
12:20:16 | TheSeven | is there even a way to do that? |
12:24:20 | TheSeven | come on, there must have been similar cases before... |
12:24:36 | | Join Dreamxtreme [0] (~Dre@92.30.31.119) |
12:24:39 | TheSeven | or didn't we bother about register types at all and just casted everything to an int when writing to a reg? |
12:25:16 | n1s | TheSeven: i'm not sure i understand what you mean but i think you want volatile void* const* if i remember the syntax correctly |
12:26:21 | n1s | ie pointer to a constant pointer to volatile data |
12:27:57 | Torne | isn't it, in fact, void * volatile const * |
12:28:01 | Torne | or something similarly insane |
12:28:09 | Torne | since it's the pointer which is volatile, not the target |
12:28:17 | n1s | oh |
12:28:27 | n1s | volatile const is nice :) |
12:29:24 | Torne | personally i vote for casting it to int |
12:29:43 | Torne | and having the registers all be the same type |
12:31:34 | TheSeven | what i actually want is a pointer to a volatile pointer to constant data |
12:32:16 | n1s | const void* volatile* foo |
12:32:31 | * | n1s recommends cdecl |
12:33:01 | n1s | but basically just write it backwards |
12:34:08 | TheSeven | what does *((volatile const void**)whatever) actually do then? |
12:34:28 | TheSeven | or even &(*((volatile const void**)(whatever))) |
12:34:50 | n1s | http://www.cdecl.org/ |
12:35:47 | n1s | volatile const void** is "pointer to pointer to volatile const void" so you cast whatever to that and dereference the first pointer so you get a "pointer to volatile const" |
12:36:03 | | Quit JdGord (Quit: Bye) |
12:36:24 | TheSeven | (*((volatile const void**)(0x38200100))) = &(*((volatile uint32_t*)(0x38300040))); |
12:36:26 | TheSeven | funny, eh? :D |
12:37:03 | n1s | &(*(...)) seems pointless |
12:40:54 | Stummi | but not pointerless :) |
12:41:19 | Stummi | sry for lame joke :p |
12:42:52 | | Quit Gnea (Ping timeout: 245 seconds) |
12:42:54 | TheSeven | n1s: it isn't if the * is part of a define, but the & is outside |
12:43:07 | TheSeven | this is basically DMAC0C0DESTADDR = &LCDWDATA; |
12:44:01 | TheSeven | if "cast x into pointer to volatile pointer to const void" is what i want, that would be "(const void * volatile *)x" |
12:45:02 | n1s | yes |
12:45:20 | TheSeven | now look at http://svn.rockbox.org/viewvc.cgi/trunk/firmware/export/s5l8700.h?view=markup |
12:45:41 | TheSeven | doesn't this mean that REG32_PTR_T should actually be "uint32_t volatile*" |
12:46:15 | Torne | no, because the relative order of a (normal) typename and const/volatile is meaningless |
12:46:24 | Torne | "volatile int" and "int volatile" are the same type |
12:46:43 | TheSeven | ok, but as soon as this is void* instead of uint32_t, it isn't? |
12:46:46 | Torne | it gets complicated if the typename is actually a typedef for a composite |
12:46:50 | Torne | Yeah |
12:46:57 | Torne | this is just one of those things in C |
12:47:14 | TheSeven | urgh |
12:47:31 | Torne | it accepts both, and people tend to write volatile int, but as soon as the type isn't a primitive it may matter which you write |
12:49:38 | Torne | it would be much more sensible if the language required qualifiers to follow types always, because then the read-right-to-left rule would mostly be sufficient :) |
12:49:45 | Torne | typedefs can still fuck it up if you try hard enough |
12:51:49 | | Join Jerom [0] (~jerome@79.132.52.183) |
12:52:41 | TheSeven | yeah, those "volatile int"s were what made me think they would be generally written left-to-right |
12:53:41 | Torne | yup, but it's tough because people have been writing volatile int for too long to change their habits ;) |
12:53:59 | Torne | the cases like this are too rare |
12:54:29 | *** | Saving seen data "./dancer.seen" |
12:55:02 | TheSeven | now why does (*((void* volatile*)(0x38200104))) = &(*((uint32_t volatile*)(0x38300040))); say "assignment discards qualifiers from pointer target type"? |
12:55:48 | TheSeven | the same happens for void* test = &(*((uint32_t volatile*)(0x38300040))); |
12:56:21 | TheSeven | does it think the DMA controller might not know about its volatility? |
12:56:29 | Torne | because dereferencing it and then taking its address again eliminates the volatile |
12:56:34 | Torne | i think |
12:56:47 | TheSeven | any way to suppress that? (it's intentional) |
12:57:00 | n1s | more casting :) |
12:57:04 | Torne | no. in fact, i think that expressoin might even be required to have side effects |
12:57:23 | Torne | *((uint32_t volatile*)(address)) is supposed to issue a read |
12:57:26 | Torne | because of the volatile |
12:57:30 | TheSeven | i still want writes to *((uint32_t volatile*)(0x38300040)) (which is used as a define in there) to be volatile |
12:57:40 | Torne | I don't think you can do it |
12:58:05 | n1s | using an intermediate var to store the adress would work, no? |
12:58:16 | Torne | only with *another* cast |
12:58:47 | TheSeven | is there some way to get to the address inside that define without triggering that warning or issuing a read to it? |
12:58:51 | | Quit user890104 () |
12:58:54 | Torne | anyway, i think you'll find the type of your RHS there is uint32_t * |
12:58:57 | TheSeven | (even if it means some more casts :) ) |
12:59:09 | Torne | and the type of the LHS is void * volatile |
12:59:16 | Torne | so it is indeed discarding qualifiers |
12:59:39 | TheSeven | what's bad about (void* volatile) = (uint32_t*)? |
12:59:50 | Torne | hm |
13:00 |
13:00:06 | TheSeven | doesn't this just mean that the LHS must be written to immediately? |
13:00:16 | TheSeven | the type cast to void shouldn't matter IIUC |
13:00:16 | * | Torne repeats his earlier suggestion that you cast the address to an int |
13:00:19 | Torne | :) |
13:00:48 | TheSeven | let's say we have #define LCDWDATA (*((uint32_t volatile*)(0x38300040))) |
13:01:09 | TheSeven | int whatever = (int)&LCDWDATA; won't help, right? |
13:01:21 | Torne | why not> |
13:01:27 | TheSeven | so there's nothing I can do outside of that define to get at its address? |
13:01:47 | TheSeven | IIUC the "&LCDWDATA" part is sufficient to trigger the warning |
13:01:58 | Torne | not on its own |
13:02:06 | Torne | it's an assignment warning |
13:02:12 | * | TheSeven has misunderstood something then :) |
13:02:15 | Torne | an expression can't generate that without an assignment in it |
13:02:39 | TheSeven | so basically DMAC0C0DESTADDR = (void*)((int)LCDWDATA); might work? |
13:03:04 | Torne | (not without an &) |
13:03:07 | Torne | (and who knows) |
13:03:19 | * | Torne suggests just defining the LHS register as volatile int * |
13:03:30 | Torne | and abandoning any pretence of type safety |
13:03:52 | Torne | addresses are uint32_t. it doesn't need to actually be a pointer :) |
13:04:10 | amiconn | TheSeven: Why care about register types? So far we didn't |
13:04:42 | Torne | indeed |
13:04:43 | TheSeven | because I personally don't like casting addresses to integers all the time for DMA |
13:04:53 | amiconn | Hmm? |
13:04:55 | TheSeven | well, pointers :) |
13:05:16 | TheSeven | the code would be full of REG = (uint32_t)thing; |
13:05:17 | Torne | actual type safety is impossible in C anyway, just give up :) |
13:06:04 | amiconn | Why? The cast is implicit anyway |
13:06:22 | TheSeven | REG = thing; triggers a warning |
13:07:19 | amiconn | Look at mcf5249.h, pp5020.h etc - registers are defined as (*(volatile unsigned long*)(0xADDRESS)) (or short resp. char) all over |
13:11:04 | | Join T44 [0] (~Topy44@g227189253.adsl.alicedsl.de) |
13:11:29 | | Quit Topy (Read error: Connection reset by peer) |
13:14:12 | | Join Gnea [0] (~gnea@2610:130:112:400:225:d3ff:fe72:4512) |
13:14:19 | | Quit Gnea (Changing host) |
13:14:19 | | Join Gnea [0] (~gnea@unaffiliated/gnea) |
13:15:53 | | Join xxcv [0] (~null@c211-30-174-99.carlnfd1.nsw.optusnet.com.au) |
13:17:00 | Torne | amiconn: you can't implicitly cast from void * to uint32_t |
13:21:56 | | Quit Jerom (Quit: Leaving.) |
13:22:19 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
13:26:48 | amiconn | Torne: Well you can, but it will throw a warning |
13:27:32 | amiconn | I checked some places which I know use addresses in conjunction with registers. Casts are used where necessary, but there aren't that many places |
13:28:21 | amiconn | It's needed for public variables which need to have the correct type (e.g. lcd_framebuffer); for private variables some drivers just use an int32 even if it holds an address -> no cast necessary |
13:34:59 | Torne | well, yah, i count "with a warning" as "can't" :) |
14:00 |
14:08:02 | | Quit xxcv () |
14:18:30 | n1s | hmm, seems like the coldfire tremor slowdown with gcc 4.4 is mainly in the fft stuff, the profiling threw me off at first since gcc 3.4 basically disables inlining when profiling while 4.4 does not |
14:20:03 | n1s | maybe asming fft4/8/16 will help |
14:32:34 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
14:34:53 | | Nick benedikt93 is now known as benedikt93|AFK (~benedikt9@unaffiliated/benedikt93) |
14:38:56 | | Join kkit|sh [0] (krazykit@silenceisdefeat.com) |
14:39:19 | | Quit krazykit (Quit: awe yeeeeeee) |
14:42:11 | | Join saratoga_ [0] (42391dc9@gateway/web/freenode/ip.66.57.29.201) |
14:43:46 | saratoga_ | n1s: ive hoped someone would look at fft8 on cf for a while |
14:44:09 | saratoga_ | it accounts for a large fraction of the entire fft |
14:44:23 | saratoga_ | and its very short |
14:44:35 | n1s | saratoga_: yes, i'm taking a look now, starting with fft4 now, gcc4.4 produces significantly worse code for this than 3.4 :/ |
14:45:01 | saratoga_ | yeah it screwed up on arm too |
14:45:11 | | Quit Zambezi (Remote host closed the connection) |
14:45:46 | saratoga_ | iirc fft4 becomes a few loads adds and stores in fft8 and gcc has no idea how to do it |
14:47:56 | saratoga_ | is there any advantage to sequential loads to iram on cf, |
14:48:04 | saratoga_ | ? |
14:48:30 | n1s | not much, should be slightly faster |
14:49:24 | saratoga_ | i want to special case the 2048/512 fft case for targets with lots of iram or only dram |
14:49:44 | saratoga_ | rearrange the trig values to be sequential |
14:50:19 | saratoga_ | probably help a lot on arm11, no idea if its useful on cf targets with 128k iram |
14:50:42 | saratoga_ | would waste probably 8 kb of ram |
14:52:25 | | Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) |
14:53:02 | n1s | special lookup tables you mean? |
14:53:28 | | Join kevku [0] (~kevku@2001:7d0:0:f000::135d) |
14:53:58 | | Quit Gnea (Ping timeout: 240 seconds) |
14:54:31 | *** | Saving seen data "./dancer.seen" |
14:55:35 | n1s | hmm, in fact load multiple should save cpu cycles when done from iram too, according to the cpu user manual |
14:55:59 | n1s | movem takes 1+n cycles while regular loads take 2 cycles |
14:56:18 | saratoga_ | same as arm7 then |
14:57:03 | saratoga_ | the current mdct is extremely clever about trig values thanks to stripwx, savesa ton of memory |
14:57:18 | saratoga_ | but the access patterns are a bit weird |
14:57:18 | n1s | saratoga: and even if not using movem, sequential loads usually mean autoinc adressing modes can be used which is faster than constant offsetts |
15:00 |
15:00:02 | saratoga_ | most codecs only use the 2048 block size 95 percent of the time, so we could halve the size of the trig tables, the add a separate table for the common case of the 2048 transform |
15:00:20 | saratoga_ | then sort it for sequential acess |
15:01:50 | n1s | that would probably help cf a bit if it could be in iram, but to make full use of sequential accesses we need to write asm... |
15:04:18 | saratoga_ | well yeah but thats not my problem :) |
15:09:03 | | Join InsDel [0] (~haqr.net@c-98-231-87-43.hsd1.fl.comcast.net) |
15:12:48 | n1s | maybe we can let the codecs optionally set up the tables (copying the one(s) it wants to use to iram) |
15:13:35 | saratoga_ | probably better to just make it a compile time option |
15:14:11 | saratoga_ | there not much use in varying it per codec |
15:14:51 | n1s | if the codec or file uses a different block size |
15:15:08 | n1s | (tremor does this with its dewindowing tables already) |
15:15:15 | saratoga_ | right now theres one table used for all sizes |
15:15:37 | saratoga_ | its really quite clever |
15:16:18 | n1s | yes but if we have to chose between having the special case table or the generic table in iram, one compile time choice may not fit all codecs and files |
15:16:49 | | Quit JdGordon (Ping timeout: 245 seconds) |
15:18:03 | saratoga_ | are there codecs where we couldnt spare 8kb on cf? |
15:18:51 | n1s | several i think, at least for the targets with 96kB iram |
15:18:58 | saratoga_ | hmm |
15:19:14 | saratoga_ | i dislike the idea of having state in the fft |
15:19:22 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
15:19:26 | n1s | yes, the whole iram thing is a mess |
15:19:41 | saratoga_ | since it would make it ackward to have a plugin and codec use the fft at once |
15:20:16 | n1s | they would have their own instance, no? |
15:20:27 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
15:20:30 | n1s | codeclib is linked statically to each codec |
15:20:45 | | Quit benedikt93|AFK (Ping timeout: 276 seconds) |
15:24:23 | | Quit saratoga_ (Ping timeout: 265 seconds) |
15:40:30 | n1s | the fft seems to have been the cause of the slowdown indeed, a brain dead/naive fft4 asm implementation saved 0.3MHz |
15:40:58 | n1s | let's see it it can be made a little faster |
15:54:50 | | Join kugel [0] (~kugel@141.45.201.221) |
15:54:52 | | Quit kugel (Changing host) |
15:54:52 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
15:59:41 | | Quit InsDel (Changing host) |
15:59:42 | | Join InsDel [0] (~haqr.net@unaffiliated/insdel) |
15:59:50 | kugel | amiconn: i'd use intptr_t, IIUC it even enables implicit casts |
16:00 |
16:00:59 | | Quit CaptainKewl (Ping timeout: 252 seconds) |
16:01:03 | | Join timccc [0] (~timccc@112.166.15.141) |
16:06:39 | | Quit kugel (Read error: Connection reset by peer) |
16:06:51 | | Join MethoS- [0] (~clemens@134.102.106.250) |
16:08:01 | | Join Qbe [0] (~43ad9740@giant.haxx.se) |
16:08:14 | | Quit MethoS- (Remote host closed the connection) |
16:08:50 | | Quit Kitr88 () |
16:10:08 | | Quit tchan (Quit: WeeChat 0.3.3-dev) |
16:10:41 | Qbe | Hi all, download.rockbox.org appears to be unreachable this morning−−for me, anyway. Is anyone else having this problem? |
16:11:39 | Zagor | Qbe: indeed. use http://haxx.rockbox.org for now. |
16:12:20 | Qbe | Thanks very much. It's time to get something better on my e260. |
16:13:51 | | Join MethoS- [0] (~clemens@134.102.106.250) |
16:13:59 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
16:18:10 | Qbe | haxx.rockbox.org worked like a charm. Thanks again for the help. |
16:18:21 | Zagor | you're welcome |
16:18:23 | | Join Kitar|st [0] (Kitarist@BSN-143-99-156.dial-up.dsl.siol.net) |
16:18:34 | | Quit Qbe (Quit: CGI:IRC 0.5.9 (2006/06/06)) |
16:18:48 | | Quit evilnick_B (Quit: Page closed) |
16:19:53 | | Join ReimuHakurei__ [0] (~reimu@74.112.212.15) |
16:19:53 | | Quit ReimuHakurei_ (Read error: Connection reset by peer) |
16:27:09 | | Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) |
16:38:26 | | Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) |
16:39:26 | saratoga | i've seen a lot of people complain about building rockbox on cygwin |
16:39:46 | saratoga | is our cygwin environment broken or does it just not work with current rockbox svn? |
16:41:20 | pixelma | last I tried it worked (except −−non-eabi on arm targets) |
16:42:32 | | Join JesusFreak316 [0] (~JesusFrea@WirelessTampa1-nat-185.laptops.usf.edu) |
16:43:07 | | Join Zambezi [0] (Zulu@80.67.9.2) |
16:47:14 | | Quit benedikt93 (Quit: Bye ;)) |
16:48:05 | | Quit JesusFreak316 (Ping timeout: 245 seconds) |
16:48:46 | saratoga | i got 2 extra hours with the Fuzev1 and the lowered max clock |
16:48:48 | saratoga | not bad |
16:49:52 | Zagor | saratoga: nice |
16:50:07 | | Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
16:50:11 | saratoga | probably would get more with the lowered max voltage too |
16:50:45 | n1s | asm fft4 closed the gap between gcc 4.4 and 3.4 by 0.5MHz as it makes no speed diff on the old gcc... |
16:50:58 | n1s | so i'll probably take a stab at fft8 later |
16:51:17 | | Quit tchan1 (Read error: Connection reset by peer) |
16:52:07 | | Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
16:52:15 | | Quit tchan (Ping timeout: 250 seconds) |
16:54:33 | *** | Saving seen data "./dancer.seen" |
16:54:58 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
16:55:57 | | Part Zagor |
17:00 |
17:00:19 | n1s | hmm, this is more complicated than i thought, fft8 loads some of the values fft4 stores again, maybe that can be exploited... |
17:03:35 | | Part LinusN |
17:12:03 | saratoga | Zagor, Bagder: could one of you upload this file to the test_codecs folder on the download server: http://duke.edu/~mgg6/rockbox/atrac3_lp2_132.oma |
17:12:27 | saratoga | by the way if anyone else was thinking of trying to find the sony software needed to create atrac files, i suggest that they not do so |
17:12:31 | saratoga | nothing is worth that |
17:19:48 | | Join Topy [0] (~Topy44@g227208019.adsl.alicedsl.de) |
17:20:35 | | Quit T44 (Ping timeout: 245 seconds) |
17:26:37 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
17:27:20 | | Quit tchan (Read error: Connection reset by peer) |
17:28:09 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
17:28:43 | | Quit tchan1 (Ping timeout: 245 seconds) |
17:31:25 | | Join JesusFreak316 [0] (~JesusFrea@WirelessTampa1-nat-185.laptops.usf.edu) |
17:35:20 | | Quit tchan (Read error: Connection reset by peer) |
17:36:10 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
17:38:26 | | Join Topy44 [0] (~Topy44@g227163143.adsl.alicedsl.de) |
17:40:35 | | Quit Topy (Ping timeout: 245 seconds) |
17:41:16 | Topy44 | hm... it would be really cool to have the "compressor" available on recording |
17:41:51 | Topy44 | for recording interviews and stuff like that, where the volume is somewhat changing and unpredictable |
17:43:13 | | Quit JesusFreak316 (Remote host closed the connection) |
17:43:39 | | Join JesusFreak316 [0] (~JesusFrea@WirelessTampa1-nat-185.laptops.usf.edu) |
17:44:39 | | Quit petur (Quit: Page closed) |
17:45:19 | gevaerts | Doesn't one of the gain options help with that? |
17:53:24 | evilnick_B | Auto-Gain Control |
17:54:14 | pixelma | it's not available on all recording targets |
17:55:03 | pixelma | I even believe it's *only* there on the H100/300s, not sure though |
17:57:19 | n1s | pixelma: yes, only iriver h100/300 |
18:00 |
18:01:45 | pixelma | saratoga: FWIW, I just successfully built r28640 for all 3 of my targets under cygwin (OndioFM, M5, c200v1) |
18:05:57 | | Nick jfc^3 is now known as jfc^2 (~john@dpc6682208002.direcpc.com) |
18:12:14 | AlexP | gevaerts: yes, I've been trying to keep an eye out |
18:12:18 | AlexP | one mo |
18:14:59 | | Part u42p ("Leaving") |
18:21:57 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
18:21:57 | | Quit bertrik (Changing host) |
18:21:57 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
18:24:44 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
18:37:31 | | Quit DerPapst (Quit: Leaving.) |
18:40:23 | | Join eWill [0] (~chatzilla@adsl-99-139-147-115.dsl.dytnoh.sbcglobal.net) |
18:40:55 | eWill | Has any DAP producer ever officially acknowledged Rockbox? |
18:41:23 | n1s | don't think so, why? |
18:41:46 | gevaerts | What does "officially acknowledged" actually mean? |
18:42:39 | eWill | Just curious. I was going through some Fuze forums, and keep seeping people requesting things on the OF, that RB already does. |
18:42:52 | eWill | by "Officially acknowledged" |
18:43:19 | eWill | I mean like symbolic head-nod or something. |
18:43:37 | * | gevaerts has the same question about that :) |
18:43:59 | eWill | or suggested to some customer that they should install RB. |
18:46:01 | bertrik | We got some datasheets and a development model of some player I think |
18:46:44 | gevaerts | I don't think we got datasheets |
18:47:58 | eWill | "development model" −− does that mean the company sent RB a free player so you could start working on it? I'd love to know the company −− sounds like someone worth supporting. |
18:48:18 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
18:48:34 | gevaerts | eWill: does sending someone $50 worth of gifts really mean *that* much? |
18:48:42 | n1s | the cost of a player is rarely the roadblock preventing a port |
18:50:03 | eWill | I guess maybe not, it just sounded like "they want me to have what I want", but after thought, I guess maybe it could be an effort simply to make more money...? |
18:50:37 | eWill | "Rockbox works on our player! −− buy it!" |
18:50:47 | n1s | datasheets would be very welcome as they would make porting much easier and much less painful |
18:51:24 | alexbobP | eWill: still, I'd readily support a company that embraced rockbox on their product |
18:51:26 | eWill | But they are under contract not to disclose the datasheets −− right? |
18:51:28 | alexbobP | and actually provided useful information |
18:51:47 | eWill | Not just being difficult −− right? |
18:52:32 | n1s | the player manuafacturers are, sometimes, but the chip manufacturers are usually able to give out datasheets but they don't want to |
18:52:36 | bertrik | I'm pretty sure we got datasheets from AMS |
18:52:48 | n1s | yes, ams is an exception |
18:53:30 | n1s | some datasheets are already freely available like for the hardware in the beast |
18:53:49 | eWill | If a chip manufacturer published their datasheets, would that make it easier for competitors to steal ideas? |
18:54:08 | saratoga | probably not |
18:54:36 | *** | Saving seen data "./dancer.seen" |
18:55:54 | | Quit JesusFreak316 (Ping timeout: 252 seconds) |
18:58:23 | eWill | |teletype| |
18:58:30 | eWill | teletype |
18:58:38 | eWill | \italic\ |
18:59:02 | eWill | \/italic |
18:59:08 | eWill | \/italic/ |
19:00 |
19:00:04 | n1s | eWill: please stop that |
19:00:29 | eWill | oops sorry i have two tabs open. thought i was in the other one. |
19:01:00 | | Join Strife89 [0] (a80dbf52@gateway/web/freenode/ip.168.13.191.82) |
19:02:03 | pamaury | bertrik: I had a look at the elftosb2 program |
19:02:48 | pamaury | some strings mention Rijndael CBC MAC |
19:03:44 | pamaury | some it could be some sort of SHA-128 but I tried with zero key on some random program and it does not seem to be plain SHA-128 |
19:08:48 | bertrik | too bad, nice try anyway |
19:09:24 | pamaury | I currently trying to see if the executable section has exactly the same size as the binary. I alrzady noted that elftosb2 strips some part of the elf header |
19:09:48 | | Join KiwiCam [0] (~Kiwicam@ip-118-90-20-170.xdsl.xnet.co.nz) |
19:09:58 | pamaury | but it could also add some hashing at regular positions, which would make it even harder to understand to algorithm :) |
19:10:38 | | Join DerPapst [0] (~Alexander@p5DE5AD09.dip.t-dialin.net) |
19:10:55 | bertrik | so you've already actually added something to a .sb with elftosb? |
19:11:13 | bertrik | I tried it with some chumby binaries |
19:12:43 | pamaury | I just built a dummy executable, then add it to the command file using load and indeed, it adds the binary |
19:13:09 | pamaury | when there is no encryption, it just creates a ____ section with the content but with part of elf header stripped. |
19:13:11 | bertrik | Just some ideas: make time() always return the same value with some preload magic, stub /dev/urandom |
19:14:40 | pamaury | I also decided that it was way to difficult to reverse engineer elftosb2, it's written in C++ and even though there lots of strings out there, it would probably be a nightmare |
19:14:44 | pamaury | *too |
19:14:45 | bertrik | And with "zero-key" encryption the binary is still undecryptable? |
19:14:50 | pamaury | yes |
19:15:11 | pamaury | but I still have lots of ideas before giving up |
19:15:53 | bertrik | Unless sandisk used some kind of default key, I think it's nearly impossible to make it accept a custom image. The crypto seems solid. |
19:16:55 | * | TheSeven guesses that D1671/D1759 might be part of the chip number of the nano3g/nano4g PMU. Any ideas what this thing could be? |
19:17:02 | pamaury | well, sha-128 is quite solid indeed :( But we have to make sure first that they didn't use the default key |
19:17:45 | alexbobP | bertrik: sandisk uses firmware signing? |
19:17:52 | alexbobP | on what device? |
19:18:07 | bertrik | alexbobP, I think so, not completely sure, on the fuze+ |
19:18:48 | eWill | Are there any open source voice recognition programs (wondering if a RB voice recognition would be possible). |
19:19:11 | | Join Jerom [0] (~jerome@79.132.52.183) |
19:23:43 | alexbobP | eWill: there are, but rockbox voice recognition would probably be way too hard for embedded hardware to handle |
19:23:54 | alexbobP | bertrik: ah. well that's ironic then, because the fuze+ isn't *worth* porting to :P |
19:23:57 | alexbobP | it's just shit hardware |
19:26:49 | | Join Horscht [0] (~Horschti@p4FD4EA86.dip.t-dialin.net) |
19:26:49 | | Quit Horscht (Changing host) |
19:26:49 | | Join Horscht [0] (~Horschti@xbmc/user/horscht) |
19:31:34 | amiconn | n1s: On coldfire, loading with constant offset, no offset, autoinc and autodec are equally fast |
19:31:47 | n1s | amiconn: not in my experience |
19:31:51 | amiconn | Only indexed addressing is slower |
19:32:15 | amiconn | n1s: They all take two cycles for 32 bit, 3 cycles for 16 bit and 8 bit |
19:32:23 | n1s | what i've seen si that constant offsetts are slower |
19:32:41 | n1s | (i'd guess because they make the instructions longer) |
19:32:52 | | Join panni_ [0] (hannes@ip-178-203-101-205.unitymediagroup.de) |
19:33:15 | n1s | same with using 32 bit immediate values |
19:33:28 | amiconn | Here we're talking 16 bit offsets though |
19:34:03 | amiconn | Iirc the pipeline is able to fetch 32 bits per cycle, so even back-to-back loads with 16 bit offsets shouldn't starve the pipeline |
19:34:39 | amiconn | You may see aliasing effects caused by the icache though. These are tricky |
19:34:54 | n1s | right, not sure if i've tested with move.l but emac paralell loading was measurably faster with sequential access and postinc rather that offsetts when i made a test for Buschel on mpc |
19:35:14 | n1s | those becone 48 bit instrs when using offsetts thogh |
19:35:20 | amiconn | Well, emac parallel load is of course faster |
19:35:30 | eWill | How many revisions back are on svn? |
19:35:49 | n1s | i mean that emac parallell load with postinc is faster than emac paralell load with offsett |
19:35:55 | amiconn | And instructions using two extension words will starve if issued back-to-back |
19:35:59 | gevaerts | eWill: back to r1 |
19:36:21 | n1s | amiconn: ok, so that is maybe only true for emac paralell loads then |
19:36:47 | amiconn | It only is if you're also issuing them back-to-back |
19:37:24 | n1s | (difference in that mpc filter loop was 0.9MHz with the dct reordered so that the paralell loads were sequential) |
19:37:29 | amiconn | Actually even then it shouldn't, because emac with parallel load needs two cycles anyway |
19:37:43 | eWill | wow cool. I've got to do the "find a good revision −− then go half way between that an the bad one −− then go half way between that and the bad one...." thing. What did you call that again? |
19:38:04 | n1s | eWill: bisection |
19:38:22 | amiconn | That may be simple aliasing. Reordering functions will change speed, often by several percent, in an unpredictable way. Slower or faster... |
19:39:00 | amiconn | (unless the code involved is in iram, of course) |
19:40:09 | n1s | i know, but that loop is in iram (as it's by far the hottest in the codec AFAIU) |
19:41:57 | amiconn | Make sure it actually is... when specifying both 'inline' and ICODE_ATTR, and the parent function is not in iram, the result may be different from what's intended |
19:42:23 | amiconn | It should be obvious, but nevertheless I've seen cases of that in rockbox |
19:43:02 | n1s | the one in musepack is a real asm function so it will never be inlined |
19:43:25 | CIA-7 | New commit by Buschel (r28641): Fix typo in comment. |
19:43:32 | n1s | btw i wonder why gcc doesn't warn if a function is inlined so it ends up in another section when you explicitley specify one |
19:43:49 | | Join Buschel [0] (~chatzilla@p54A3A5DC.dip.t-dialin.net) |
19:44:14 | amiconn | Because it's gcc? </sarcasm> |
19:45:08 | n1s | true that |
19:45:27 | CIA-7 | r28641 build result: All green |
19:45:47 | n1s | spotted another bug in it yesterday that causes our workaround that makes profiling work with gcc3.4 to break in 4.4 :) |
19:46:12 | n1s | although the workaround isn't needed in 4.4 so no big problem |
19:47:08 | | Join krabador [0] (~krabador@host84-29-dynamic.251-95-r.retail.telecomitalia.it) |
19:48:41 | | Quit GeekShadow (Read error: Connection reset by peer) |
19:49:04 | | Join GeekShad0w [0] (~Antoine@ree79-1-78-237-225-34.fbx.proxad.net) |
19:49:16 | | Join piggz [0] (~piggz@78.144.114.53) |
19:49:50 | piggz | reagrding yesterdays discussion on sleep/shutdown and startup times...the quoted 3 seconds isnt right...more like 27-30 seconds! :) |
19:49:50 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-109-252.tampfl.fios.verizon.net) |
19:51:25 | gevaerts | piggz: that sounds long |
19:51:34 | n1s | piggz: what target, which version of rockbox, what settings and did you actually time it? |
19:54:11 | piggz | ipodvideo 5g |
19:54:14 | piggz | 64mb |
19:54:34 | piggz | im not aware of any special settings i have |
19:55:20 | | Quit MethoS- (Remote host closed the connection) |
19:56:53 | | Quit Strife89 (Quit: Let's see what happens when I run from the hard drive.) |
19:58:10 | gevaerts | 80GB? |
19:58:45 | gevaerts | I know I once measured 7 seconds from pressing the power button to having playing audio on my gigabeat F |
19:59:06 | gevaerts | flash targets are a lot faster still |
19:59:27 | piggz | yes |
19:59:56 | gevaerts | IIRC there are some unexplained slowdowns with that disk |
20:00 |
20:01:17 | piggz | probably why apple invented sleep mode ;) |
20:02:46 | pixelma | do you have things like dircache enabled or "load to RAM" or "auto-update" with the database? |
20:03:13 | | Join Strife89 [0] (a80dbf52@gateway/web/freenode/ip.168.13.191.82) |
20:05:11 | piggz | pixelma: maybe, what should i disable |
20:06:37 | gevaerts | Try enabling dircache |
20:07:25 | piggz | i will when i find it :) |
20:07:47 | pixelma | depends on your way of using it. I just remember reports about slowdown when all three is enabled (not sure if this is still the case). Some of these could also help decreasing boot time when enabled (as gevaerts mentioned) |
20:08:04 | gevaerts | pixelma: that one *should* be fixed |
20:08:14 | pixelma | piggz: we have a manual which probably helps you finding these options... ;) |
20:08:17 | piggz | it already is enabled |
20:08:27 | n1s | piggz: is it a recent version of rockbox? |
20:08:45 | | Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) |
20:09:39 | piggz | manuals are for wimps :) |
20:09:42 | piggz | 3.7 |
20:10:17 | phanboy4 | Is anyone here with a Fuze v1/v2 and Rockbox 3.7 that's not seeing this?: http://www.rockbox.org/tracker/task/11655 |
20:11:55 | n1s | phanboy4: fuzev1 here, i can insert several albums with no problem, more recent build than 3.7 tho |
20:12:21 | phanboy4 | Hrm. |
20:12:26 | phanboy4 | I'll try todays build |
20:12:32 | | Join freddyb [0] (~chatzilla@rrcs-24-123-234-112.central.biz.rr.com) |
20:13:06 | freddyb | Does we have a datasheet for the FuzeV2? |
20:15:43 | krabador | hi RB devs, are some of you planned to improve Fuzev1 battery duration? |
20:16:36 | phanboy4 | n1s, Aha, seems to have fixed it, works now |
20:17:20 | bertrik | krabador, yes I think there are some ideas for that |
20:18:06 | | Quit casainho (Remote host closed the connection) |
20:22:27 | pixelma | piggz: no, manuals are for us to point people to it so we don't have to answer the same questions again and again... |
20:22:56 | krabador | bertrik, great, i've fear that developers are thinking to discontinue fuzev1 rockbox development |
20:23:54 | gevaerts | krabador: so what you're saying is that someone should decide to get a great idea on how to improve fuzev1 battery life tomorrow at 17:45 or something like that? |
20:24:38 | gevaerts | phanboy4: any chance of finding out which commit fixed it? |
20:24:56 | gevaerts | If it's broken in 3.7, we might want to fix that in 3.7.1 |
20:26:50 | krabador | gevaerts, certainly not :) i'm only asking if fuzev1 developer are continuing |
20:27:25 | gevaerts | krabador: well, you keep asking this every few days, so I thought you had something specific in mind |
20:29:30 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
20:30:04 | | Quit freddyb (Ping timeout: 264 seconds) |
20:30:10 | | Quit KiwiCam (Ping timeout: 245 seconds) |
20:31:07 | | Join stoffel [0] (~quassel@91.137.68.177) |
20:31:38 | krabador | gevaerts, rockbox totally captured my interest in portable music, and by the day i rockboxed my fuzev1 , i'm only really interested with deveopment on it. I really would contribute, but i'm not a developer |
20:32:15 | gevaerts | So what you're asking is that people drop everything and concentrate on the fuzev1 at the expense of all other targets? |
20:32:38 | krabador | gevaerts, certainly not |
20:32:58 | krabador | rather |
20:33:38 | krabador | many new ports and ideas i look, are really great |
20:33:55 | | Join Kupop [0] (~Kupo@cpc2-bsfd7-2-0-cust220.5-3.cable.virginmedia.com) |
20:34:24 | phanboy4 | gevaerts, I'll look |
20:35:00 | | Quit Strife89 (Quit: Heading home.) |
20:36:31 | eWill | is the Fuze V1 RB batt life really that much different than the OF batt life? |
20:37:15 | krabador | eWill, yes, RB battery life are almost the half of OF |
20:42:15 | | Quit chattr (Ping timeout: 245 seconds) |
20:44:16 | saratoga | freddyb: no datasheet, but its pretty similar to the as3525 |
20:44:25 | saratoga | with some stuff from the as3543 |
20:46:06 | | Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) |
20:49:39 | | Join Nerdy3_14159265 [0] (~chatzilla@m20677151209.austincc.edu) |
20:50:37 | Nerdy3_14159265 | Hey guys, I'm having trouble with Rockbox on my Sansa Fuze v2 |
20:51:44 | pixelma | you need to be a bit more descriptive ;) |
20:53:04 | eWill | I have to do some bisecting. Can I just make a copy of my RB development dir, and do it all in there? I'm trying, but "svn status" result is −−−− svn: warning: '.' is not a working copy |
20:53:16 | Nerdy3_14159265 | I was just waiting to see someone respond to continue |
20:53:56 | Nerdy3_14159265 | I was outside one day so I cranked the brightness on the Fuze, ever since when it starts it shows the rockbox logo then goes to a black screen and won't display anything |
20:54:02 | alexbobP | 13:25:02 < gevaerts> krabador: so what you're saying is that someone should decide to get a great idea on how to improve fuzev1 battery life tomorrow at 17:45 or something like that? |
20:54:06 | alexbobP | gevaerts: you know what? I like that idea |
20:54:09 | alexbobP | gevaerts: someone should go ahead and do that |
20:54:19 | gevaerts | alexbobP: don't let me stop you |
20:54:39 | *** | Saving seen data "./dancer.seen" |
20:54:52 | alexbobP | gevaerts: meh, my fix is to carry a laptop and charge my mp3 player with it |
20:55:06 | alexbobP | charging the player's whole battery is a drop in the bucket to a sleeping laptop |
20:55:06 | pixelma | Nerdy3_14159265: is it possible you set the brightness to the lowest setting (wrapped around the list)? |
20:55:31 | pixelma | Nerdy3_14159265: you could try resetting your settings or have a look at it from the PC |
20:55:54 | alexbobP | gevaerts: also, on Thursday someone should go ahead and make rockbox give the clip+ a color screen, because I miss the days when sandisk made color mp3 players |
20:56:31 | alexbobP | krabador: you should become a developer! |
20:56:46 | Nerdy3_14159265 | pixelma: It shouldn't be that it looped around because I played on it for a bit before the screen started just going to black, also I have no idea how to reset the settings without being able to see the screen and I have no cord atm to hook it to my pc |
20:59:06 | pixelma | some players let you reset settings during boot by holding a specific button. I'm not sure if this is implemented on the Fuze and which button it would be if it is, you could search around in our manual |
21:00 |
21:00:36 | | Quit Jerom (Quit: Leaving.) |
21:01:50 | Nerdy3_14159265 | pixelma: I'm pretty sure that it's the brightness at max, I think I managed to navigate to brightness but changing it didn't affecct anything, I was using the rockboxed fuze simulator |
21:02:00 | Nerdy3_14159265 | pixelma: as a reference |
21:02:01 | | Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) |
21:02:25 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
21:02:31 | pixelma | that's the only idea I could contribute as I don't have a Fuze I don't know what else could be going on. If you stick around for a bit maybe someone else could help you |
21:02:42 | | Quit freddyb (Remote host closed the connection) |
21:02:49 | Nerdy3_14159265 | pixelma: BTW where would that reset button be listed in the manual |
21:03:20 | | Quit jae (Ping timeout: 276 seconds) |
21:05:56 | | Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) |
21:06:54 | pixelma | hmm, I need to look it up myself |
21:13:06 | pixelma | it's not in the Fuze (v2) manual where it would be (in "Advanced Settings > Managing Settings", a not under the description of the "Reset Settings" menu item). So it's either not implemented yet or an oversight in the manual source |
21:15:17 | | Quit krabador (Read error: Connection reset by peer) |
21:15:34 | pixelma | I meant a note |
21:17:16 | freddyb | Saratoga, thanks. |
21:28:38 | | Join edboyer93 [0] (eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) |
21:29:05 | Nerdy3_14159265 | pixelma: Well I think this max brightness must be a glitch then freaking out the display. I'll have to attempt resetting when I get home |
21:32:04 | | Quit Nerdy3_14159265 (Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]) |
21:43:31 | bertrik | I think I've read of other people having problems with the fuze v2 on max brightness |
21:50:40 | * | pixelma is reminded of the c200v1's contrast settings :\\ |
21:53:14 | eWill | Is there a longer commit list than http://www.rockbox.org/since-4weeks.html ? |
21:53:55 | bertrik | pixelma, what's wrong with it? |
21:54:19 | bertrik | I only know the bug that the screen goes off under some circumstances when changing the brightness |
21:54:38 | | Join krabador [0] (~krabador@host84-29-dynamic.251-95-r.retail.telecomitalia.it) |
21:54:58 | eWill | Nerdy3_14159265: did this happen in rockbox or the OF? |
21:55:59 | pixelma | bertrik: it goes from 0 (total black) to 255 (total white) but on mine at least it should actually only be 0 to 127 (127 is total white too and 128 is total black again), It is as if the range is there twice but I remember someone looking into some datasheet and saying 256 steps would be correct... |
21:56:02 | bertrik | eWill, you could check out the source and use svn... |
21:56:30 | bertrik | pixelma, I just tried that and it behaves the same for me (looks like a wrap at 128) |
21:56:39 | pixelma | yeah |
21:57:10 | bertrik | I'll try to check the datasheet again |
21:57:11 | eWill | bertrik: That's what I'm doing, but in between builds, I could be manually searching the list (now that I'm under 100 possible commits) |
21:57:15 | pixelma | eWill: he left |
21:57:42 | pixelma | but I think (hope) he was talking about Rockbox |
21:57:46 | eWill | pixelma: I just ordered a Fuze v2. Do you know if he screwed it up in RB mode or in the OF? |
21:58:00 | bertrik | pixelma, have you ever heard of people where 0-255 worked as described in the datasheet? |
21:58:47 | pixelma | not that I remember but I doubt anyone using settings coming close or changing it so much (despite testing as I do) |
21:59:11 | | Join mirak [0] (~mirak@81-64-223-104.rev.numericable.fr) |
22:00 |
22:01:48 | | Quit krabador (Quit: Sto andando via) |
22:03:09 | bertrik | hm, the datasheet has some confusing statements about the contrast setting |
22:03:33 | * | TheSeven wonders at which point he should start to port rockbox to the ipod classic |
22:04:50 | n1s | TheSeven: can you access the storage and display? |
22:05:00 | TheSeven | display: yes, storage: no |
22:05:03 | TheSeven | usb: yes |
22:05:10 | TheSeven | NOR flash: yes |
22:05:19 | TheSeven | clickwheel: no |
22:05:31 | n1s | i imagine rockbox will be painfull untill it can read the storage |
22:05:44 | TheSeven | ramdisk :P |
22:05:59 | n1s | ;) |
22:06:06 | TheSeven | and rockbox boots fine without a storage driver |
22:06:25 | n1s | oh, didn't think it would |
22:06:37 | TheSeven | it will fall back to the compiled-in versions of everything |
22:06:44 | TheSeven | just make each storage call return -1 |
22:07:20 | eWill | Probably a really stupid question, but can the simulator simulate the OF on any targets? |
22:07:41 | | Quit freddyb (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100723085406]) |
22:07:51 | bertrik | pixelma, 255 (or even 127) seems like a slightly ridiculous number of steps anyway |
22:07:54 | gevaerts | eWill: it's not an emulator |
22:08:24 | n1s | TheSeven: then i don't see why not start at porting rockbox straight away |
22:08:43 | pixelma | bertrik: I agree but maybe fine-grained adjustment doesn't hurt on this display ;) |
22:08:46 | TheSeven | it's mainly a question of when it becomes useful |
22:09:18 | | Join jae [0] (~jae@jaerhard.com) |
22:09:21 | n1s | i'd say whaen you have at least storage and display |
22:10:19 | | Quit GeekShad0w (Ping timeout: 272 seconds) |
22:14:49 | pixelma | bertrik: the most annoying fact of this is the wrap from "black" to "white" in the middle of this to me |
22:15:08 | | Quit mystica555_ (Ping timeout: 245 seconds) |
22:15:29 | | Quit Llorean (Quit: Leaving.) |
22:16:26 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
22:18:33 | bertrik | pixelma, I'm trying to figure out if the full range is perhaps possible by configuring some other part of the display. There is a note in the ds that says that under some circumstances the range is less. If that's not possible, I'm inclined to just reduce the range to 0-127 to avoid the wrap at 128 |
22:23:14 | bertrik | ranmachan, do you see the same effect w.r.t. contrast on the c200v2? |
22:24:14 | pixelma | I'd be fine with 128 |
22:24:43 | | Quit jae (Ping timeout: 245 seconds) |
22:24:51 | | Quit piggz (Remote host closed the connection) |
22:25:34 | | Quit mirak (Quit: Ex-Chat) |
22:30:08 | eWill | OK I've found the commit that broke a function for me (perhaps it's a "fix"?). The way it used to work on my e200v1: Location: WPS > Context Menu > Playlist Menu > Playlist > View Current Playlist. Function: Press Play/Pause button ("up" button) returned you to WPS. Since r28139 or r28140 (same author/file) this button now does nothing. Anyone care to take a look? http://svn.rockbo |
22:30:10 | eWill | x.org/viewvc.cgi?view=rev&revision=28139 |
22:30:15 | | Join mirak [0] (~mirak@81-64-223-104.rev.numericable.fr) |
22:30:18 | eWill | http://svn.rockbox.org/viewvc.cgi?view=rev&revision=28139 |
22:32:33 | | Join jae [0] (~jae@jaerhard.com) |
22:32:47 | gevaerts | eWill: the logs don't say anything about an intended change in behaviour there |
22:32:57 | gevaerts | Maybe submit a bug report? |
22:33:36 | | Join MethoS- [0] (~clemens@134.102.106.250) |
22:34:14 | eWill | r28138 works, r28139 won't compile, r28140 broke me. Ok, bug report. My first one. |
22:35:08 | | Quit liar (Quit: Leaving) |
22:36:08 | | Join bmbl [0] (~bmbl@dsl-217-167-45.pool.bitel.net) |
22:36:08 | | Quit bmbl (Changing host) |
22:36:08 | | Join bmbl [0] (~bmbl@unaffiliated/bmbl) |
22:36:46 | | Quit chattr (Ping timeout: 240 seconds) |
22:37:45 | Buschel | saratoga: you there? |
22:38:00 | saratoga | Buschel: yeah |
22:38:20 | ranmachan | bertrik: Yeah, it wraps around, 0-127 alone is enough... |
22:38:58 | Buschel | just came by the fact that r28549 broke atrac3 playback of a testfile |
22:39:03 | Buschel | in sim |
22:39:26 | Buschel | GoodbyeCaroline.rm |
22:39:33 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
22:40:06 | saratoga | Buschel: do you have a link to that file? |
22:40:10 | Buschel | I am also wondering how atrac3_iqmf_dewindowing() is defined for ARM |
22:40:15 | bertrik | ranmachan, ok thanks for confirming |
22:40:22 | | Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) |
22:40:33 | | Join GeekShadow [0] (~Antoine@ree79-1-78-237-225-34.fbx.proxad.net) |
22:40:33 | | Quit GeekShadow (Changing host) |
22:40:33 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
22:41:42 | | Quit esperegu (Read error: Connection reset by peer) |
22:41:51 | Buschel | saratoga: http://samples.mplayerhq.hu/real/AC-atrc/ |
22:43:41 | Buschel | saratoga: atrac3_iqmf_dewindowing_armv5e() is declared, but not used for AMR_ARCH>=5 |
22:44:16 | | Quit edboyer93 () |
22:44:26 | saratoga | Buschel: ? |
22:44:38 | saratoga | line 137: atrac3_iqmf_dewindowing_armv5e(out, in, win, nIn); |
22:44:59 | merbanan | love sound of atrac in the morning |
22:45:05 | merbanan | the sound |
22:45:13 | Buschel | saratoga: atrac3_iqmf_dewindowing() uses int16_t *win for ARM_ARCH<4. shouldn't this still be using int32_t? |
22:45:16 | merbanan | did you port atrac1 yet ? |
22:45:24 | saratoga | Buschel: is that an atrac3 file? |
22:45:37 | saratoga | the bitrate is very high, i thought atrac3 only support 132k and lower |
22:45:44 | saratoga | no atrac1 yet |
22:46:10 | saratoga | not much interest since theres almost no PC accessible atrac1 files |
22:46:10 | merbanan | saratoga: check with ffmpeg -i to be sure |
22:46:17 | | Quit factor (Read error: Connection reset by peer) |
22:46:25 | merbanan | saratoga: but there is |
22:46:34 | | Join anewuser [0] (anewuser@unaffiliated/anewuser) |
22:46:36 | saratoga | you have to rip them from a player right? |
22:47:39 | Buschel | saratoga: damn, forgt to sync to r28550. forget about the iqmf functions |
22:47:50 | saratoga | :) |
22:47:58 | saratoga | my bad for committing the commented out version |
22:48:04 | saratoga | was benchmarking and forgot to fix it |
22:48:17 | Buschel | well, it was faster on ARMv5e and aboce :) |
22:48:25 | Buschel | *above |
22:48:30 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
22:50:04 | | Join Xerion_ [0] (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) |
22:50:25 | merbanan | saratoga: yes, but that is no excuse for not supporting it |
22:50:33 | saratoga | well you're welcome to port it :) |
22:50:38 | saratoga | i'll optimize it |
22:50:47 | saratoga | that Goodbye track plays for a second for me, then crashes |
22:50:53 | saratoga | or gives codec failure |
22:51:06 | saratoga | the bitrate is 176k which isn't valid for atrac3 afaik |
22:51:09 | saratoga | so i don't know what it is |
22:51:09 | gevaerts | saratoga: that's somehow appropriate in a twisted way :) |
22:51:17 | merbanan | so it's not enough for me to have written a ffmpeg decoder for it ? |
22:51:18 | saratoga | ha |
22:51:27 | merbanan | I should write a rockbox version also |
22:51:40 | saratoga | write an atrac3plus decoder and i'll port that |
22:51:51 | Buschel | saratoga: yes. it plays before r28549 |
22:51:56 | saratoga | weird |
22:53:22 | saratoga | "The freely downloadable RealSystem Producer Basic (available for Linux, Mac and PC) can encode ATRAC3 audio at 352, 264, 176, 132, 105, 96, 64, 44, 32 and 20kbps. " |
22:53:43 | saratoga | i guess thats where this 176k file came from |
22:54:01 | | Quit Xerion (Ping timeout: 272 seconds) |
22:54:01 | | Nick Xerion_ is now known as Xerion (~xerion@54194281.cm-5-2b.dynamic.ziggo.nl) |
22:54:40 | *** | Saving seen data "./dancer.seen" |
22:55:23 | saratoga | Buschel: it breaks on armv4 for me and I didn't change anything for that |
22:55:26 | Buschel | saratoga: interesting. if I revert atrac3.h only, it works again. seems to be connected to the memory layout. some boundary stuff? |
22:55:30 | saratoga | are you sure it was my commit that broke it? |
22:55:36 | saratoga | hmm |
22:56:02 | Buschel | moving back outSamples[] to its former position within ATRAC3Context |
22:57:09 | saratoga | Buschel: sounds like a buffler overflow |
22:57:12 | saratoga | buffer |
22:57:23 | saratoga | merbanan: are you working on rockbox? |
22:57:36 | merbanan | no |
22:57:49 | saratoga | i wonder if this real encoder uses some combination the other encoders do not |
22:58:11 | merbanan | saratoga: hahaha, you know we have an atrac3+ decoder in the works |
22:58:38 | saratoga | merbanan: awesome |
22:58:42 | saratoga | i've been curious how that thing works |
22:59:02 | saratoga | the atrac decoders have been ... interesting to look at |
22:59:21 | saratoga | have you figured out the filterbank for it? |
23:00 |
23:01:05 | merbanan | http://wiki.multimedia.cx/index.php?title=ATRAC3plus |
23:01:11 | merbanan | short version |
23:01:12 | saratoga | Buschel: making that buffer bigger fixes the crash |
23:01:14 | merbanan | it's a bitch |
23:01:23 | saratoga | so its an overflow bug . . . |
23:01:32 | | Quit komputes (Remote host closed the connection) |
23:01:35 | saratoga | oh wow, didn't notice that had been updated |
23:01:40 | saratoga | need to watch ffmpeg more closely |
23:02:14 | Buschel | saratoga: just did the same :o) yes, it fixes the bug |
23:02:22 | merbanan | saratoga: yes the real encoder uses higher bitrates then the sony one |
23:02:26 | saratoga | going to try it with just 32 extra bytes |
23:02:42 | Buschel | saratoga: I just doubled it |
23:03:04 | merbanan | saratoga: rockbox port is going to be alot of work |
23:03:33 | saratoga | ha |
23:03:42 | saratoga | but we've got an efficient iQMF now!!! |
23:03:54 | saratoga | "The sample-frame size is 2048 samples per channe" |
23:04:08 | saratoga | oh i had heard it used 4096, was interested to see how that would work |
23:04:09 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
23:04:27 | saratoga | "gain control for reducing pre-echo artifacts" |
23:04:35 | saratoga | haha anything sony can do to avoid having different mdct block sizes |
23:05:00 | saratoga | the mpeg people must have patented that in conjunction with iqmf or something |
23:08:55 | saratoga | Buschel: just adding 32 bytes "fixes" the crash |
23:08:59 | | Quit Buschel (Ping timeout: 255 seconds) |
23:10:14 | saratoga | Buschel: adding 4 bytes fixes the crash |
23:10:19 | saratoga | so its an off by one error somewhere |
23:10:32 | eWill | Anyone remember the bug I told you guys about 20 minutes ago? (Play/Pause button doesn't return to WPS from Playlist) Would the Flyspray catagory for that be "User Interface"? |
23:10:46 | | Join Buschel [0] (~chatzilla@p54A39F59.dip.t-dialin.net) |
23:10:54 | bertrik | bah, ubuntu nautilus crashes when unmounting the c200 |
23:10:55 | gevaerts | eWill: that would work I think |
23:11:09 | merbanan | saratoga: iQMF isn't used any more |
23:11:23 | merbanan | IIRC, they use something else |
23:11:23 | JdGordon | eWill: pretty sure there is already a bug and a patch for that |
23:11:50 | * | eWill is looking again |
23:11:52 | saratoga | "Finally the QMF synthesis filter will be applied in order to sum all subbands together and reconstruct the encoded audio signal" |
23:11:58 | saratoga | sounds like atrac3? |
23:12:20 | saratoga | i hope its iQMF, i just spent an afternoon writing an optimal one in armv5 assembly |
23:12:57 | | Quit n1s (Quit: Lämnar) |
23:13:49 | saratoga | merbanan: do you know if anyone has looked at wma lossless? i'd like to complete our wma support some day |
23:16:55 | Buschel | saratoga: +1 byte fixes the crash, but the audio is broken (as if the bitstream is broken) |
23:17:04 | Buschel | saratoga: same for +4 byte |
23:17:20 | saratoga | oh 4 bytes sounded ok to me |
23:18:16 | bertrik | pixelma, is there a flyspray entry for the c200 contrast issue? |
23:18:38 | pixelma | not that I know of |
23:19:08 | saratoga | ffmpeg plays it fine, so its something we broke |
23:19:41 | bertrik | I looked a bit more into it, but can't make it work for 0-255. |
23:20:17 | saratoga | although i suppose they could just get lucky like we did |
23:20:26 | saratoga | but i'm so lazy and don't want to figure out how to compile ffmpeg |
23:23:25 | Buschel | array size +4 => +16 bytes seems fine |
23:23:47 | | Quit Llorean (Ping timeout: 272 seconds) |
23:23:52 | | Join Llorean [0] (~DarkkOne@ppp-70-250-173-17.dsl.hstntx.swbell.net) |
23:23:58 | | Quit Llorean (Changing host) |
23:23:58 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
23:24:18 | pamaury | bertrik: I changed my mind, elftosb2 does something strange with elf files. It modifies them, or reorder the sections, I don't really know what but it does something ! |
23:24:56 | | Quit mirak (Quit: Ex-Chat) |
23:27:01 | pamaury | perhaps it goes from elf to plain binary or put instructions about how to write things in memory |
23:28:57 | eWill | JdGordon: You said you think there is already a patch for the Play/Pause button not returning to WPS from "View Current Playlist". I can't find it. Were you here ~45 minutes ago when I was talking about the revision that broke me? (r28139 or 28140) Those were committed on Sept. 22, so the bug/patch you were thinking of −− is it that young? |
23:29:56 | * | eWill also searched bugs |
23:30:41 | saratoga | Buschel: ffmpeg sounds ok to me even with the moved around buffers, so we probably screwed up something |
23:33:00 | Buschel | hmm, will now check where it is screwed |
23:39:36 | | Quit bmbl (Quit: Verlassend) |
23:46:18 | TheSeven | urgh! they only allow NOR bootloader images that are either encrypted with a device-dependent key, or digitally signed |
23:46:39 | | Quit evilnick_B (Quit: Page closed) |
23:48:02 | | Quit stoffel (Remote host closed the connection) |
23:49:18 | Buschel | saratoga: it seems like decodeChannelSoundUnit() is sometimes writing beyond outSamples[] in the case of normal stereo mode or mono |
23:49:37 | | Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) |
23:49:55 | * | TheSeven just spun up the HDD of his ipod classic :) |
23:50:14 | saratoga | Buschel: do you have those benchmarks of libmad that you pastebin'ed the other day? |
23:50:45 | Buschel | saratoga: the profiling? |
23:51:10 | saratoga | yeah |
23:51:17 | saratoga | i can't remember how fast the dct32 was |
23:51:33 | Buschel | http://pastie.org/1318675 |
23:51:42 | Buschel | S5L870x |
23:51:53 | | Quit Kupop (Ping timeout: 255 seconds) |
23:54:20 | | Quit bertrik (Ping timeout: 250 seconds) |
23:57:01 | saratoga | changing the MUL macro in the dct32 to use SMMUL instead of SMULL and a shift would speed up the dct32 a good bit on arm11 |
23:57:37 | Buschel | saratoga: overwrite happens somewhere in gainCompensateAndOverlap() |