| 00:02:49 | saratoga | looking at the binaries of the fuze+ and fuzev2 AAC decoder, they are nearly identical aside from a handful of bytes (probably due to different memory base address) |
| 00:03:07 | Bilgus | Idk maybe check for the size of bufopen and or the ticks between them and stay boosted if its rebuffering a lot? |
| 00:03:09 | saratoga | i didn't compile with debug symbols though |
| 00:04:50 | Bilgus | ill remove auto slow next and run them again |
| 00:07:04 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 00:07:42 | Bilgus | ok that file NO boosted decode 568.35s 30.97% 206.65 MHZ |
| 00:18:47 | saratoga | Bilgus: amsv2? |
| 00:19:17 | Bilgus | i'll check it next |
| 00:19:18 | saratoga | oh fuze+ |
| 00:19:23 | saratoga | yeah sorry i misread |
| 00:20:06 | saratoga | by the way if you haven't seen it: https://www.rockbox.org/wiki/CodecPerformanceComparison#Freescale_imx233_40454MHz_ARM926EJ_45S_44_Fuze_43_41 |
| 00:20:19 | saratoga | the results for AMSv2 are all out of date now that frequency scaling changed the clocks though |
| 00:22:28 | Bilgus | huh! nero_hev2_64.m4a117.08% realtimeDecode time - 150.34s387.74MHz |
| 00:23:03 | Bilgus | that looks exactly the same as my fuze+ |
| 00:23:46 | Bilgus | I wonder why it can't keep up the codec code boosts the damn thing |
| 00:26:43 | saratoga | my guess is that this is come corner case that only occurs when a codec is just barely fast enough for real time playback |
| 00:27:18 | Bilgus | its a good thing that I don't have any aac-he files I guess |
| 00:27:29 | saratoga | test_mem on AMSv2 is in IRAM if I understand correctly (I think all plugins are?), so it should be testing the same memory as the codecs use |
| 00:27:39 | saratoga | its not a great format |
| 00:27:47 | saratoga | well, it compresses well, but its insanely slow |
| 00:28:15 | saratoga | one thing that seems questionable to me is the relatively small size of the test_mem buffer |
| 00:28:28 | saratoga | it is likely cached almost entirely on the Fuze+ |
| 00:30:19 | Bilgus | it seems to be pretty indicative of how dogshit it runs IRL |
| 00:30:34 | Bilgus | so it must not make that much difference |
| 00:30:55 | | Part ender` |
| 00:31:52 | saratoga | yeah, test_mem on fuze+ is doing a 32 KB sequential memory transfer |
| 00:32:09 | saratoga | d cache is 16KB, so half of the test should probably fit in buffer |
| 00:35:12 | saratoga | should probably increase that buffer size to at least 256KB on devices with a large plugin buffer, and then also add a test that does nonsequential IO to test the memory itself |
| 00:35:50 | saratoga | its possible that the IRAM, while not actually that fast for sequential transfers, has really good random access times or something |
| 00:36:05 | saratoga | like a cache on a slow bus or something |
| 00:36:49 | Bilgus | maybe or maybe the fuze+ is really bad at switching frequencies |
| 00:37:16 | saratoga | huh, the ipod classic uses the same CPU as AMSv2 and also has nearly identical speed: https://www.rockbox.org/wiki/CodecPerformanceComparison#iPod_Classic_40ARM926EJ_45S_41 |
| 00:37:23 | saratoga | so its probably just that something is slow on the fuze |
| 00:37:27 | saratoga | + |
| 00:37:39 | saratoga | Bilgus: the test_codec plugin doesn't switch frequencies |
| 00:38:54 | saratoga | so to summarize, the same CPU in AMSv2, Ipod6G and Fuze+, the fuze+ is about 3x slower, while the others are about the same |
| 00:39:10 | saratoga | mem_test plugin says sequential memory speed is comparable |
| 00:39:10 | Bilgus | hmm then how would it decide that it took 200 MhZ to decode or whatever unboosted? |
| 00:39:24 | saratoga | it just counts how many cycles were required basically |
| 00:39:29 | Bilgus | the device is running at an actual 64mhz at the time isn't it? |
| 00:39:42 | saratoga | you can set it to run at either boost or unboost speed in settings |
| 00:39:50 | man_in_shack | guessing there's no way atm to get rockbox to automagically pause on android when bluetooth disconnects? |
| 00:39:54 | saratoga | it boosts once (before the timer starts) and then leaves it there |
| 00:40:11 | saratoga | or unboosts |
| 00:40:20 | Bilgus | of fuze+ NO auto slow boosted 96.21s 182.96% realtime 248.54Mhz |
| 00:40:35 | Bilgus | that was much! better |
| 00:40:43 | saratoga | what does that setting do? |
| 00:41:11 | Bilgus | I'm pretty sure it keeps it from idling but pamaury mentioned it |
| 00:42:58 | saratoga | but it makes the cpu 2x as fast? |
| 00:43:48 | | Join Soap [0] (~Soap@rockbox/staff/soap) |
| 00:44:09 | | Quit wodz (Quit: Leaving) |
| 00:48:21 | Bilgus | it didn't do much for the unboosted though |
| 00:49:24 | Bilgus | fuze+ No auto slow no boost 417.01 42.21% 151.62 Mhz |
| 00:49:55 | * | man_in_shack boosts Bilgus's slow |
| 00:50:12 | saratoga | 206 MHz before though? |
| 00:50:14 | saratoga | still pretty nice |
| 00:50:24 | Bilgus | I guess it did knock off 100 seconds |
| 00:50:43 | saratoga | ipod classic is 101 MHz with DRAM |
| 00:50:55 | saratoga | probably won't do much better than that |
| 00:51:06 | Bilgus | didn't do anything for actually playing the file though |
| 00:51:16 | saratoga | that is surprising |
| 00:51:22 | saratoga | so its not related to decode speed |
| 00:51:58 | saratoga | anyway, pamaury needs to clarify what that setting actually does |
| 00:52:11 | saratoga | and if possible, see if decode performance can be increased in git |
| 00:52:15 | saratoga | that would likely give a nice increase in battery life |
| 00:52:45 | saratoga | anyway, i have to run |
| 00:52:50 | Bilgus | I think its there to give an increase in battery life lol |
| 00:52:50 | saratoga | will check logs |
| 00:52:56 | Bilgus | thanks |
| 00:53:20 | saratoga | if it increases average clock speed so much i wonder if it does that |
| 00:54:17 | __builtin | user890104: were you considering piezo PWM sound output on the ipod6g? |
| 01:00 |
| 01:04:39 | | Quit petur (Remote host closed the connection) |
| 01:06:32 | man_in_shack | huh |
| 01:07:06 | man_in_shack | got target=android type=sim to build but there's no rockboxui created |
| 01:08:51 | man_in_shack | same deal with androidx86 |
| 01:09:53 | Bilgus | did you type make && make fullinstall? |
| 01:10:10 | man_in_shack | did make, but not fullinstall |
| 01:10:20 | Bilgus | gotta do it 2x |
| 01:10:37 | Bilgus | like this make -j2 && make fullinstall |
| 01:10:54 | Bilgus | the && only goes if the first make was without err |
| 01:10:56 | man_in_shack | "no rule to make target fullinstall" |
| 01:11:11 | Bilgus | try just install |
| 01:14:23 | man_in_shack | now it can't find the android build tools cos |
| 01:23:19 | man_in_shack | so got that part working, now it wants javac |
| 01:27:44 | man_in_shack | yah it's trying to build an apk |
| 01:30:05 | __builtin | hmm, I don't think you need install to produce rockboxui |
| 01:30:24 | __builtin | it might be different for android though |
| 01:30:38 | man_in_shack | yah |
| 01:30:54 | man_in_shack | looks like it's also trying to push it via adb |
| 01:32:43 | man_in_shack | __builtin: that's what i thought too but i'm humouring Bilgus |
| 01:32:48 | man_in_shack | still no rockboxui |
| 01:33:07 | man_in_shack | looks like simulator doesn't have an android target |
| 01:40:40 | man_in_shack | so i'll have to try running it in the android simulator |
| 01:48:00 | *** | Saving seen data "./dancer.seen" |
| 01:52:05 | __builtin | ugh, this is annoying |
| 01:52:38 | __builtin | I suspect there's an unaligned access somewhere that's being magically "fixed" when I put in splash() statements to track it down :( |
| 02:00 |
| 02:03:58 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 02:06:41 | | Quit krabador (Remote host closed the connection) |
| 02:24:23 | man_in_shack | bleh |
| 02:24:37 | man_in_shack | i can't find where the .rockbox directory is on android |
| 02:32:38 | man_in_shack | apparently "android uses /sdcard/rockbox as the usual .rokcbox folder" |
| 03:00 |
| 03:27:29 | | Quit kugel_ (Ping timeout: 255 seconds) |
| 03:28:37 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 03:48:01 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:14:17 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-vwewikqhikjvkwiv) |
| 05:00 |
| 05:14:27 | | Quit Marex (Ping timeout: 240 seconds) |
| 05:48:02 | *** | Saving seen data "./dancer.seen" |
| 05:59:18 | Bilgus | saratoga I finally got it fixed it seems what would happen is it would underrun, attempt to boost, fill unboost, then underrun again and again. Sure sounds like a race condition. I moved a filling == true{ cpu_boost } to the beginning of buffering.c and made the cancel on SYS_TIMEOUT of the queue and now it recovers even when artificially inducing an underrun (by the cpu freq debug menu) |
| 06:00 |
| 06:06:41 | | Quit [7] (Ping timeout: 258 seconds) |
| 06:09:21 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:26:27 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 06:26:49 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:27:28 | | Quit man_in_shack (Read error: Connection reset by peer) |
| 06:29:26 | | Join man_in_s1ack [0] (~chat@unaffiliated/man-in-shack/x-4279753) |
| 07:00 |
| 07:02:56 | | Quit Huntereb (Ping timeout: 260 seconds) |
| 07:12:50 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
| 07:40:36 | | Quit Huntereb (Ping timeout: 258 seconds) |
| 07:48:05 | *** | Saving seen data "./dancer.seen" |
| 07:51:00 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
| 07:53:46 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 07:54:04 | | Nick man_in_s1ack is now known as man_in_shack (~chat@unaffiliated/man-in-shack/x-4279753) |
| 08:00 |
| 08:20:28 | | Quit Huntereb (Ping timeout: 255 seconds) |
| 08:22:21 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:32:20 | | Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) |
| 08:35:28 | | Part ender` |
| 08:42:25 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:45:22 | | Quit man_in_shack (Read error: Connection reset by peer) |
| 08:49:00 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:49:14 | | Join man_in_s1ack [0] (~chat@unaffiliated/man-in-shack/x-4279753) |
| 09:00 |
| 09:09:36 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 09:32:04 | | Quit deevious (Quit: deevious) |
| 09:48:09 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:04:10 | | Join deevious [0] (~Thunderbi@193.226.142.214) |
| 10:06:34 | | Quit paulk-gagarine-s (Quit: Leaving) |
| 10:07:18 | | Join paulk-gagarine [0] (~paulk-gag@gagarine.paulk.fr) |
| 10:10:03 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:30:55 | pamaury | Bilgus: saratoga: auto slow is a hardware mecanism to automatically slow the bus frequencies when there is no activitity. |
| 10:31:14 | pamaury | It can be disabled, and one can also choose by how much the frequency is reduced |
| 10:31:34 | pamaury | Can somone summarize your findings? It's a bit confusing |
| 10:31:57 | | Join Marex [0] (~Marex@195.140.253.167) |
| 10:46:10 | fs-bluebot | Build Server message: New build round started. Revision 5eee28e, 273 builds, 12 clients. |
| 10:51:03 | | Quit deevious (Quit: deevious) |
| 10:51:58 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 10:56:26 | | Quit pamaury (Ping timeout: 240 seconds) |
| 10:57:16 | fs-bluebot | Build Server message: Build round completed after 666 seconds. |
| 10:57:17 | fs-bluebot | Build Server message: Revision 5eee28e result: All green |
| 11:00 |
| 11:08:00 | | Join dys [0] (~dys@x5f71d80a.dyn.telefonica.de) |
| 11:11:48 | | Join deevious [0] (~Thunderbi@193.226.142.214) |
| 11:16:06 | | Join PimpiN8 [0] (~textual@ip51cd65d5.speed.planet.nl) |
| 11:48:11 | *** | Saving seen data "./dancer.seen" |
| 12:00 |
| 12:07:34 | fs-bluebot | Build Server message: New build round started. Revision a8e4b3a, 273 builds, 12 clients. |
| 12:12:37 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 12:18:36 | fs-bluebot | Build Server message: Build round completed after 661 seconds. |
| 12:18:37 | fs-bluebot | Build Server message: Revision a8e4b3a result: All green |
| 12:29:32 | user890104 | __builtin: only square waves, but if the timer supports PWM, i'd use it |
| 12:30:39 | user890104 | PC speaker is monophonic square wave, right? |
| 12:34:03 | | Quit Tony_ (Ping timeout: 260 seconds) |
| 12:35:24 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 13:00 |
| 13:20:45 | | Join robertd1 [0] (~root@201.242.176.168) |
| 13:48:14 | *** | Saving seen data "./dancer.seen" |
| 13:48:48 | | Quit robertd1 (Quit: Leaving.) |
| 13:51:12 | | Nick man_in_s1ack is now known as man_in_shack (~chat@unaffiliated/man-in-shack/x-4279753) |
| 14:00 |
| 14:15:21 | | Quit sanchaez (Ping timeout: 264 seconds) |
| 14:15:32 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 14:51:04 | | Join amayer [0] (~amayer@107-1-97-172-ip-static.hfc.comcastbusiness.net) |
| 14:54:32 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 15:00 |
| 15:05:22 | Bilgus | Pamaury so what I observed was when loading the AAC-HE file if the device was already boosted it didn't have any issue and hence the reason it seemed almost random |
| 15:05:27 | | Quit jhMikeS (Ping timeout: 255 seconds) |
| 15:05:44 | | Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:07:17 | | Quit Rower (Read error: Connection reset by peer) |
| 15:07:40 | | Join Rower [0] (~husvagn@m83-182-86-189.cust.tele2.se) |
| 15:08:11 | Bilgus | but when the device wasn't already boosted it went into a cycle of boost cpu, load buffer, play buffer boost cpu, load buffer....... I was watching the boost counter and cpu frequency and it never even registered the boost |
| 15:08:33 | | Join robertd1 [0] (~root@201.242.176.168) |
| 15:10:10 | pamaury | Bilgus: so the device didn't boost although the boost counter was positive? |
| 15:10:39 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 15:10:53 | Bilgus | yeah I even tried manually ticking it up and even though the counter counted to 10 it never even touched the CPU freq |
| 15:10:53 | pamaury | And so what was the conclusion from yesterday about the auto slow feature? |
| 15:11:22 | Bilgus | it just made the device a bit faster on decode |
| 15:11:44 | pamaury | Bilgus: that sounds weird, I mean it's the same code for all platforms, I simply wrote the code to actually change the frequency, I expect that if it gets called, it changes the frequency! |
| 15:12:33 | pamaury | and that was with code in trunk? No modifications? |
| 15:12:44 | Bilgus | I suspect you would see the same issue on all platforms given the right codec taxing the device like that AAC-HE file |
| 15:13:05 | pamaury | oh so you think it's a problem with the generic boost code |
| 15:13:07 | Bilgus | yes from 3.14 to Head same behaviour |
| 15:13:58 | pamaury | so not my problem :-p |
| 15:14:17 | pamaury | except for this strange underperformance of the fuze+, something doesn't look right |
| 15:14:47 | Bilgus | it decodes the same as the codec benchmark page |
| 15:15:00 | | Quit jhMikeS (Ping timeout: 240 seconds) |
| 15:15:00 | Bilgus | its just the device was stuck at 64MHZ |
| 15:15:31 | Bilgus | take a look ath AAC-HE decode times on the slow devices.. the ones that actually completed |
| 15:16:35 | pamaury | oh so you think the strange performance difference is because when boosted it doesn't actaulyl boost? |
| 15:17:40 | pamaury | where are the results? |
| 15:18:17 | wodz | I bet you can see in debug menu if manually triggering boost changes value in pll/div registers |
| 15:19:12 | pamaury | Bilgus: regarding cpu frequency, you can always look in HW Info > clock, to see the actual frequency. Normally it the one reported by the code but you never know. It would be usefult to debug the boost code path with logf() to see if there is an actual problem there |
| 15:19:32 | Bilgus | You assume you can even get there while the device is stuttering |
| 15:19:46 | Bilgus | you have to be super quick |
| 15:20:02 | pamaury | with logf you can see what happens though |
| 15:20:23 | Bilgus | true give me a minute and I'll do that again |
| 15:20:24 | pamaury | just put a logf() in imx233_set_cpu_frequency, maybe some other logf in the code to see when it triggers boot and so on |
| 15:25:33 | | Quit wodz (Ping timeout: 264 seconds) |
| 15:45:37 | Bilgus | https://pastebin.com/B47yrQJw |
| 15:46:21 | Bilgus | there is HEAD not each time you see boost the system wither called cpu_boost(True) or (false)\ |
| 15:46:27 | Bilgus | either* |
| 15:46:34 | | Quit krabador (Remote host closed the connection) |
| 15:48:16 | *** | Saving seen data "./dancer.seen" |
| 15:54:14 | Bilgus | and after fix https://pastebin.com/eeRRPMdX |
| 15:59:48 | | Join TheEaterOfSouls [0] (~souls@unaffiliated/theeaterofsouls) |
| 16:00 |
| 16:00:50 | Bilgus | man my typing is terrible note** each time you see boost_counter it should increment or decrement HEAD (line 66 + 67) |
| 16:07:47 | | Join edhelas [0] (~edhelas@2a01:7c8:aab8:6b9:5054:ff:fec9:fd84) |
| 16:14:16 | * | man_in_shack flails |
| 16:23:30 | man_in_shack | ok |
| 16:23:42 | man_in_shack | finally got the damn android emulator running right without fiddling |
| 16:24:09 | man_in_shack | just uploaded the fonts to it to test |
| 16:24:21 | man_in_shack | tomorrow i gonna start on my theme for it (: |
| 16:27:32 | pamaury | Bilgus: what is the "fix" you are referring to? |
| 16:27:42 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 16:29:20 | Bilgus | http://gerrit.rockbox.org/r/#/c/1693/ |
| 16:30:21 | Bilgus | JhMikeS made a good point of not canceling boost if filling returned to true so there will be another commit when I have a chance to think about the best way to handle it |
| 16:31:23 | Bilgus | something like.. if (filling) {trigger_cpu_boost();} else if (ev.id == SYS_TIMEOUT) {cancel_cpu_boost(); |
| 16:31:23 | Bilgus | } |
| 16:32:03 | pamaury | but do you have an explanation for why the old code didn't work? |
| 16:33:40 | Bilgus | old code canceled boost each time the thread fired just before it was needed |
| 16:34:09 | pamaury | so basically it was no really asking to boost? |
| 16:34:24 | pamaury | But why did the boost counter increased and cpu frequency stayed the same then? |
| 16:37:00 | Bilgus | once it started being underrun I'm pretty sure the next fill event fired before the previous boost was fulfilled |
| 16:42:07 | Bilgus | It seems to be acting pretty sane now I think I might play with the !filling timeout though |
| 16:42:21 | Bilgus | (HZ/2) |
| 16:47:47 | | Quit petur (Quit: Connection reset by beer) |
| 16:47:49 | Bilgus | I guess my question would be over a second or so is it more efficient to boost/unboost the cpu or just to leave it boosted |
| 16:48:32 | Bilgus | I'll probably have to do a battery bench to really know for sure but Its probably different between devices |
| 16:58:21 | pamaury | Interesting, I never noticed that the imx233 programming manuals recommends two possible maximum frequencies: |
| 16:58:21 | pamaury | cpu at 392 MHz, HBUS at 196 MHz |
| 16:58:21 | pamaury | cpu at 450 MHz, HBUS at 150 Mhz |
| 16:58:32 | pamaury | it's a bit strange that HBUS be lower for high cpu clock! |
| 16:59:36 | pamaury | but I guess it needs to be synchronous with the cpu clock, thus the option is to divide by 2 or by 3. And 450/2 > 200MHz, the maximum frequency of HBUS |
| 17:00 |
| 17:00:41 | pamaury | hmm, manuals says there is a fractional divider mode actually, so it's a bit ridiculous |
| 17:02:37 | Bilgus | it sounds like a pretty interesting chip |
| 17:03:24 | Bilgus | I wish they had spent more time on the fuze+ design as far as buttons |
| 17:03:25 | pamaury | ah, maximum is 205Mhz |
| 17:03:53 | pamaury | so probbaly I could run the HBUS at 205, that should give better performance, and I need to investigate auto slow |
| 17:05:18 | Bilgus | In theory it probably shouldn't have been running during that AAc decode but i'm not sure what the threshold is |
| 17:05:48 | pamaury | Bilgus: what should not be running? |
| 17:06:27 | Bilgus | auto_slow |
| 17:06:54 | Bilgus | activating might be a better term |
| 17:07:42 | pamaury | in theory it should only slow things if there are no HBUS accesses, so I'm a bit surprised that it reduces the performace |
| 17:10:07 | Bilgus | I bet its more of a running average and there was power to be saved |
| 17:10:37 | pamaury | I don't think it's an avergae |
| 17:11:08 | pamaury | but maybe I didn't program it correctly |
| 17:11:28 | pamaury | if it doesn't hurt the battery life too much, we may as well disable it |
| 17:26:04 | | Quit Rower (Ping timeout: 240 seconds) |
| 17:26:27 | | Join Rower [0] (~husvagn@m83-182-86-189.cust.tele2.se) |
| 17:43:17 | | Quit copper (Remote host closed the connection) |
| 17:44:05 | | Join copper [0] (~copper@unaffiliated/copper) |
| 17:46:25 | edhelas | hello everyone :) |
| 17:46:26 | | Quit pamaury (Ping timeout: 240 seconds) |
| 17:48:19 | *** | Saving seen data "./dancer.seen" |
| 17:56:56 | | Join CH23 [0] (3e48c14b@gateway/web/freenode/ip.62.72.193.75) |
| 17:58:41 | CH23 | yesterday i managed to set up the simulator, and one of the directories it uses is 'simdisk'; now for me, in nautilus, it won't open this directory, while 'ls' in terminal does show its contents. is this some error on my side, or is this normal behaviour? |
| 18:00 |
| 18:22:42 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-lycugybdmdexfevc) |
| 18:23:03 | Bilgus | I've never had it no able to be opened have you tried chmod? |
| 18:25:21 | Bilgus | oh and CH23 I found a flash drive laying around with that NAND chip unfortunately the sandisk 4gb one was totally different even though they are both from same era |
| 18:26:29 | CH23 | i've ordered 3 different ones this afternoon, a cruzer micro, cruzer blade, and cruzer edge |
| 18:29:17 | CH23 | I hope one of them contains the SDTMNAHEM-004G or 008G chip |
| 18:29:46 | CH23 | if not i will still try to make it work; i've ordered a NAND adapter from aliexpress |
| 18:30:03 | CH23 | so i don't need to solder them onto the clip+ |
| 18:33:11 | Bilgus | the 8g drive was a sandisk cruzer SDCZ36Z-008G Bl1106XAJB |
| 18:34:01 | CH23 | what was the flash chip? |
| 18:34:06 | Bilgus | so 11 years old id say lol |
| 18:34:18 | Bilgus | no the actual model numbers |
| 18:34:30 | CH23 | yes i know, what was the flash chip? |
| 18:34:38 | Bilgus | chip was the same as your data sheet |
| 18:35:40 | CH23 | you said it was totally different, but it was the same? |
| 18:35:51 | Bilgus | SDTPNAHEM-008G |
| 18:36:06 | Bilgus | no the 4 gb I had was totally different |
| 18:36:36 | CH23 | oh sorry i couldn't tell you that you had multiple ones |
| 18:36:55 | Bilgus | it was something like SNTNA or along those lines |
| 18:37:22 | CH23 | i wonder if it really matters |
| 18:38:00 | Bilgus | SDTNNNAHSM-004G |
| 18:38:23 | CH23 | afaik dongs never tested on the clip+ with actual sandisk NAND |
| 18:38:30 | Bilgus | I'm sure it probably does but might not if the pin out matches |
| 18:39:14 | | Quit MrZeus (Read error: Connection reset by peer) |
| 18:39:25 | CH23 | he tried with other NAND TSOP48 |
| 18:39:31 | CH23 | those didn't work for him |
| 18:47:46 | CH23 | i think the SOC might 'pre-treat' the NAND to make it work |
| 18:48:19 | CH23 | but maybe the SOC also checks what NAND is ued |
| 18:48:22 | CH23 | used* |
| 18:48:31 | CH23 | all assumptions, of course. |
| 18:49:25 | Bilgus | I think i'd like to put the chip from the clip into the flash drive first |
| 18:50:39 | CH23 | i'd like you to do that too. do you use windows or linux> |
| 18:50:58 | | Join saratoga_ [0] (86ae6e0e@gateway/web/freenode/ip.134.174.110.14) |
| 18:52:36 | saratoga_ | pamaury: bilgus's test_codec results showed a huge improvement in performance when boosted if the slow feature was disabled |
| 18:52:58 | saratoga_ | 387.74MHz -> 248.54Mhz |
| 18:53:10 | Bilgus | CH23 both |
| 18:53:25 | saratoga_ | that is over 50% faster |
| 18:54:04 | saratoga_ | i suspect that when we are boosted the bus is never really idle (we boost when the codec thread falls behind), and so whatever mechanism they use to save power slows down memory accesses a lot |
| 18:54:47 | saratoga_ | i can do a battery bench on my broken fuze+ if you want to suggest settings |
| 18:54:56 | CH23 | Bilgus: i suggest using Linux because I don't trust windows with USB drives, it might change it |
| 18:56:31 | CH23 | but if it works that'd be great |
| 18:56:50 | Bilgus | fuze+ NO auto slow boosted 96.21s 182.96% realtime 248.54Mhz |
| 18:56:50 | Bilgus | boosted 148.25 118.73% realtime 383 MHZ |
| 18:56:51 | Bilgus | fuze+ No auto slow no boost 417.01 42.21% 151.62 Mhz |
| 18:56:51 | DBUG | Enqueued KICK Bilgus |
| 18:56:51 | Bilgus | NO boost 568.35s 30.97% 206.65 MHZ |
| 19:00 |
| 19:22:03 | Bilgus | I think its like 35% and 25% respectively |
| 19:22:08 | CH23 | turns out nautilus gave me the finger and turned off the setting to show hidden files |
| 19:22:25 | Bilgus | %diff is abs(new-old) / old |
| 19:22:40 | Bilgus | x100 |
| 19:23:36 | Bilgus | hmm i didn't think the simdisk folder was hidden only the .rockbox folder within it |
| 19:26:12 | CH23 | yes that's what i meant |
| 19:26:23 | CH23 | when i tried to open simdisk it wouldn't |
| 19:26:43 | CH23 | but i'm glad i now know it's basically a normal build in there |
| 19:28:05 | | Quit parchd (Quit: Lost terminal) |
| 19:32:44 | saratoga_ | should probably battery bench with it enabled for both boost and then unboost and see if it makes a difference |
| 19:32:53 | saratoga_ | i suspect it is not worthwhile for at least boost though |
| 19:36:08 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 19:36:53 | pamaury | Bilgus: saratoga: can any of you do a battery bench with and without auto slow to see the difference? |
| 19:37:22 | pamaury | probably there is no need for a complete bench, run each for 10 hours and see if there is a big difference |
| 19:39:05 | saratoga_ | probably this player's battery will die before then :) |
| 19:39:21 | saratoga_ | what do I need to change to test? |
| 19:39:24 | pamaury | ah, your battery is that dead? |
| 19:39:43 | saratoga_ | its a second hand player from ebay, barely works |
| 19:39:52 | pamaury | in system-imx233.c, line 358, change imx233_clkctrl_enable_auto_slow(true) to imx233_clkctrl_enable_auto_slow(false) |
| 19:39:53 | saratoga_ | should be fine for battery testing though |
| 19:40:05 | saratoga_ | ok, will try that later tonight when i get home |
| 19:42:56 | Bilgus | I have a nearly fully charged battery |
| 19:44:36 | saratoga_ | for what its worth, Mihale found that adjusting the clock settings had a large impact on performance and battery life for amsv1 |
| 19:44:38 | saratoga_ | sorry v2 |
| 19:45:01 | saratoga_ | amsv1 actually has a similar problem now, where everything is really slow compared to what i would expect for an arm9 core with IRAM |
| 19:45:26 | saratoga_ | although i guess battery life for imx233 is already incredible right? |
| 19:47:14 | | Join Jinx [0] (~Jinx@unaffiliated/jinx) |
| 19:47:29 | pamaury | it's already quite good, I think over 50 hours |
| 19:48:20 | *** | Saving seen data "./dancer.seen" |
| 19:48:28 | saratoga_ | how big is the battery? |
| 19:48:42 | pamaury | it's possible we could do better but I didn't bother too much since it's really good, except on some players like the NWZ E380 where for some reason we can't go past 20 hours |
| 19:49:12 | saratoga_ | oh 550 mah, so about 11 ma |
| 19:49:20 | saratoga_ | actually very similar to amsv2 |
| 19:56:10 | pamaury | so without auto slow, how does the performance compare to the amsv2? |
| 19:58:02 | saratoga_ | it is still slower |
| 19:58:45 | pamaury | I'll try to increase the frequency of the hbus |
| 19:58:49 | saratoga_ | no boost is 151.62 Mhz, whereas AMSv2 is probably more like 90-100 at that clock speed |
| 19:59:12 | saratoga_ | the CPU does get a lot less efficient when running at 450 mhz |
| 19:59:22 | saratoga_ | so faster memory might help |
| 19:59:50 | saratoga_ | its slightly tricky to compare since we capped boost on amsv2 at 192 MHz, so even boosted the memory will be relatively faster on AMSv2 |
| 20:00 |
| 20:01:01 | saratoga_ | FWIW Mihale found that increasing the memory speed but capping the CPU clock speed below max increased battery life for roughly the same performance |
| 20:02:04 | pamaury | memory is still running at maximum speed on the imx233, just hbus isn't |
| 20:03:55 | saratoga_ | what is the hbus? |
| 20:04:15 | pamaury | it's the internal ahb bus frequency |
| 20:05:09 | saratoga_ | oh ok, just assumed it was running at memory frequency |
| 20:12:39 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 20:15:09 | CH23 | Bilgus: what's required to replace the image used in the emulator upstream? |
| 20:15:53 | Bilgus | hmm? |
| 20:16:35 | CH23 | https://imgur.com/8WZ7R4i.jpg |
| 20:18:01 | CH23 | are there any standards it has to comply to or would this do |
| 20:20:07 | Bilgus | oh you mean the actual emulator device pic? |
| 20:20:53 | saratoga_ | i believe its a bitmap in the uisim folder |
| 20:21:27 | Bilgus | yeah |
| 20:21:28 | Bilgus | rockbox/uisimulator/bitmaps |
| 20:21:29 | CH23 | yes it is, i replaced it locally, but i think this one is much clearer than the one currently in the source |
| 20:21:49 | CH23 | the default one is too dark |
| 20:22:45 | Bilgus | your has some dithering and strange lighting |
| 20:23:40 | CH23 | let me fix that |
| 20:23:40 | Bilgus | might be better to morph them together |
| 20:29:28 | Bilgus | its also .5 degree skewed CCW and a jpg |
| 20:31:19 | | Quit ender` (Ping timeout: 240 seconds) |
| 20:32:14 | | Quit ender| (Ping timeout: 246 seconds) |
| 20:33:55 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 20:36:25 | CH23 | it was a screenshot of it in use |
| 20:37:02 | CH23 | i'm cleaning up now |
| 20:41:15 | Bilgus | ah ok |
| 20:45:04 | | Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) |
| 20:58:33 | CH23 | is ARGB 32bit BMP okay? |
| 21:00 |
| 21:00:49 | Bilgus | idk |
| 21:01:40 | CH23 | it seems to work |
| 21:01:58 | Bilgus | judging by the rest of the image code probably |
| 21:02:57 | Bilgus | no sorry I think the rest is 24bit |
| 21:03:18 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 21:03:32 | Bilgus | but if it works nbd |
| 21:04:39 | | Nick JanC is now known as Guest46476 (~janc@lugwv/member/JanC) |
| 21:04:39 | | Quit Guest46476 (Killed (weber.freenode.net (Nickname regained by services))) |
| 21:04:39 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 21:06:04 | CH23 | https://imgur.com/Xp3CTbc.jpg |
| 21:06:22 | CH23 | https://i.imgur.com/Xp3CTbc.png |
| 21:06:28 | CH23 | sorry wrong link |
| 21:07:25 | Bilgus | looks better screen is still a bit off |
| 21:07:39 | Bilgus | like 3 px shifted to left |
| 21:09:33 | CH23 | the coloured pixels, the screen "viewport", or the device compared to the window? |
| 21:10:28 | Bilgus | the device / window |
| 21:10:37 | Bilgus | well device / screen |
| 21:11:09 | Bilgus | the screen is shifted slightly left meaning the image needs moved `3px left |
| 21:11:48 | Bilgus | and probably +width by the same |
| 21:11:59 | Bilgus | it looks like the right side matches right |
| 21:15:07 | | Join CH23_ [0] (5594df77@gateway/web/freenode/ip.85.148.223.119) |
| 21:16:42 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 21:16:43 | | Quit CH23 (Ping timeout: 260 seconds) |
| 21:17:43 | | Nick CH23_ is now known as CH23 (5594df77@gateway/web/freenode/ip.85.148.223.119) |
| 21:21:06 | CH23 | the simulator simulates the screen off-center, 42px on left, 35 px on right |
| 21:21:58 | Bilgus | hmm never noticed |
| 21:22:18 | Bilgus | probably bc the original image is murky enough |
| 21:23:23 | Bilgus | I'll take a pic of my mint clip+ tonight and give you that so the rainbow stays intact and so we don't run into any attribution issues |
| 21:27:12 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 21:27:12 | * | pamaury is mystified by a stupid undefined debugf() linker error on fuze+ with logf |
| 21:31:25 | pamaury | is there any good reason in lib/rbcodecs/lib/codecs.h to only define DEBUGF on if defined(CODEC) ? |
| 21:31:35 | pamaury | why is it not always defined? |
| 21:32:40 | Bilgus | maybe something to do with the standalone codecs? |
| 21:33:59 | * | pamaury finds the whole debugf/logf situation in codecs to be incredibly messy. Everything get defined an redefined and redefined, it's impossible to track it |
| 21:34:46 | pamaury | it looks like it has more to do with encoders |
| 21:35:29 | pamaury | hmmm, or maybe it's because of metadata |
| 21:37:42 | pamaury | hmm, now this is very odd. Even a normal build fails!!! |
| 21:38:18 | CH23 | rainbow? |
| 21:38:31 | Bilgus | the sandisk logo is holographic |
| 21:39:20 | CH23 | is that important? |
| 21:39:57 | Bilgus | but more so I noticed the image you are using is a stock image if there isn't a proper license on it, not a good idea to use it |
| 21:43:52 | CH23 | ah that's why i asked if there were standards or anything required |
| 21:44:26 | Bilgus | I was thinking you meant like sizes formats masks |
| 21:45:18 | Bilgus | anything that goes into rockbox needs to be I believe compatible with GNU GPL v2 > |
| 21:46:00 | Bilgus | player images might be a grey area but IDK |
| 21:48:24 | *** | Saving seen data "./dancer.seen" |
| 21:48:46 | CH23 | it seems like sandisk website doesn't mention any license at all for their stock images |
| 21:55:54 | | Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) |
| 22:00 |
| 22:03:45 | pamaury | the test_mem plugin is kind of useless |
| 22:03:55 | pamaury | it's so cpu intensive my device is completely unresponsive! |
| 22:08:46 | | Quit Slasheri (Ping timeout: 240 seconds) |
| 22:09:13 | saratoga_ | yes that is really annoying |
| 22:09:26 | saratoga_ | (see my comments about it last night) |
| 22:10:20 | Bilgus | you'd think the button loop would slow it down enough |
| 22:14:14 | | Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri) |
| 22:16:23 | pamaury | here are test_mem results: https://gist.github.com/pamaury/cf20e5877da1008c37a584082eb6a3c7 |
| 22:16:54 | pamaury | I modified the code to use a bigger buffer |
| 22:17:24 | pamaury | now I will try when changing HBUS |
| 22:33:06 | saratoga_ | can you commit the buffer change? |
| 22:33:13 | saratoga_ | no reason to have it that small |
| 22:35:11 | | Part edhelas |
| 22:37:09 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 22:39:35 | pamaury | saratoga_: well the problem is it depends on the plugin buffer size |
| 22:39:43 | pamaury | the size I chose is probably too big for many players |
| 22:39:51 | pamaury | I think it should be allocated dynamically |
| 22:39:58 | pamaury | to get a big buffer |
| 22:41:22 | saratoga_ | pamaury: isn't there a check for buffer size already at the top of the plugin? |
| 22:42:11 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 22:44:30 | pamaury | saratoga_: yeah but if we go that way, we would need to expand that check for like 4 or 5 different sizes |
| 22:44:57 | pamaury | and I feel it's still a poor test, just because the plugin buffer is small doesn't mean you should only use a 16k buffer that fits in cache |
| 22:45:02 | saratoga_ | can you just check for 128KB and use that if available? I think that should be enough |
| 22:46:49 | pamaury | ok let me try |
| 22:51:13 | | Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) |
| 22:52:51 | wodz | Why not steal audiobuf if we need big buffer? I think original reasoning behind buffer size was that it makes results for iram/dram comparable. Iram is small usually. |
| 22:53:34 | | Join sanchaez [0] (~sanchaez@95.67.87.200) |
| 22:53:38 | wodz | And if we need to measure raw ram speed we should use uncached alias |
| 23:00 |
| 23:00:57 | pamaury | well uncached is not very realistic though |
| 23:01:13 | pamaury | most of rockbox is cached, I guess it depends on what we want to measure |
| 23:02:46 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 23:04:48 | | Quit alexweissman (Remote host closed the connection) |
| 23:05:28 | | Join alexweissman [0] (~alexweiss@c-68-50-12-70.hsd1.in.comcast.net) |
| 23:13:02 | saratoga_ | i think cached sequential access and cached random access would be most informative |
| 23:13:17 | saratoga_ | at least in terms of trackign down weird things like codec performance differences |
| 23:17:38 | | Quit amayer (Quit: Leaving) |
| 23:20:03 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) |
| 23:20:26 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 23:23:28 | | Quit tchan (Quit: WeeChat 1.6) |
| 23:23:47 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-wdntzgokhbcmuhlk) |
| 23:29:24 | * | pamaury wrote the code to set HBUS with a fractional divider correct on the first try \o/ |
| 23:30:51 | wodz | you are wizard! |
| 23:33:06 | pamaury | results here: https://gist.github.com/pamaury/cf20e5877da1008c37a584082eb6a3c7 |
| 23:33:32 | pamaury | very modest improvement |
| 23:34:05 | | Join tchan [0] (~tchan@c-98-206-136-82.hsd1.il.comcast.net) |
| 23:34:05 | | Quit tchan (Changing host) |
| 23:34:05 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 23:35:22 | wodz | pamaury: what freq is HBUS already? |
| 23:36:05 | wodz | s/already/currently/ |
| 23:36:49 | pamaury | 156Mhz |
| 23:37:40 | pamaury | out of curiosity I tried to push it more, it works until 230Mhz but after that it crash |
| 23:38:04 | pamaury | the datasheet says 205Mhz max, but it doesn't seem to give more performance, problaly the ram is the main factor |
| 23:38:54 | wodz | huh, ~28% increase in HBUS speed gives ~5% improvement |
| 23:39:18 | wodz | so yeah, ram is limiting factor |
| 23:40:43 | | Join bray90820 [0] (~bray90820@50-83-217-236.client.mchsi.com) |
| 23:42:20 | | Quit bray90820 (Client Quit) |
| 23:43:29 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 23:45:09 | pamaury | it might still be useful to increase it because real-life performance is not just one big reader/writer to dram, the hbus is shared by everything |
| 23:46:17 | pamaury | g#1694, g#1695, g#1696, g#1697 |
| 23:46:24 | fs-bluebot | Gerrit review #1694 at http://gerrit.rockbox.org/r/1694 : nwztools/upgtools: make the tool print the whole kas, not just 16 bytes by Amaury Pouly |
| 23:46:24 | fs-bluebot | Gerrit review #1695 at http://gerrit.rockbox.org/r/1695 : test_mem: increase dram buffer if possible, cap number of iterations by Amaury Pouly |
| 23:46:25 | fs-bluebot | Gerrit review #1696 at http://gerrit.rockbox.org/r/1696 : imx233: make clkctrl code aware of hbus fractional divider by Amaury Pouly |
| 23:46:26 | DBUG | Enqueued KICK fs-bluebot |
| 23:46:26 | fs-bluebot | Gerrit review #1697 at http://gerrit.rockbox.org/r/1697 : imx233: disable auto-slow feature by Amaury Pouly |
| 23:47:55 | pamaury | hmm, I'm missing one |
| 23:48:28 | *** | Saving seen data "./dancer.seen" |
| 23:48:42 | pamaury | g#1698 |
| 23:48:44 | fs-bluebot | Gerrit review #1698 at http://gerrit.rockbox.org/r/1698 : imx233: switch hbus to 200Mhz when boosting by Amaury Pouly |
| 23:49:13 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 23:49:13 | * | pamaury goes to bed |
| 23:49:28 | wodz | pamaury: Do you have actions Media Player Product Tool utility (the one you disassembled before) or should I send it to you? |
| 23:49:52 | pamaury | wodz: I can't find it, can you send it to me again?/ |
| 23:50:01 | wodz | pamaury: sure |
| 23:50:10 | pamaury | someone should benchmark those imx233 changes with codecs to see the influence of auto slow and hbus |
| 23:50:17 | pamaury | thanks |
| 23:53:37 | | Quit sanchaez (Quit: ZNC - http://znc.in) |
| 23:54:19 | | Quit ender` (Quit: Intelligence is the ability to avoid doing work, yet getting the work done. — Linus Torvalds) |
| 23:54:26 | | Quit pamaury (Ping timeout: 240 seconds) |
icon identifies that the person is a core developer (has commit access).