Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2017-10-12

00:02:49saratogalooking 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:07BilgusIdk maybe check for the size of bufopen and or the ticks between them and stay boosted if its rebuffering a lot?
00:03:09saratogai didn't compile with debug symbols though
00:04:50Bilgusill remove auto slow next and run them again
00:07:04 Join krabador [0] (~krabador@unaffiliated/krabador)
00:07:42Bilgusok that file NO boosted decode 568.35s 30.97% 206.65 MHZ
00:18:47saratogaBilgus: amsv2?
00:19:17Bilgusi'll check it next
00:19:18saratogaoh fuze+
00:19:23saratogayeah sorry i misread
00:20:06saratogaby the way if you haven't seen it:
00:20:19saratogathe results for AMSv2 are all out of date now that frequency scaling changed the clocks though
00:22:28Bilgushuh! nero_hev2_64.m4a117.08% realtimeDecode time - 150.34s387.74MHz
00:23:03Bilgusthat looks exactly the same as my fuze+
00:23:46BilgusI wonder why it can't keep up the codec code boosts the damn thing
00:26:43saratogamy 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:18Bilgusits a good thing that I don't have any aac-he files I guess
00:27:29saratogatest_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:39saratogaits not a great format
00:27:47saratogawell, it compresses well, but its insanely slow
00:28:15saratogaone thing that seems questionable to me is the relatively small size of the test_mem buffer
00:28:28saratogait is likely cached almost entirely on the Fuze+
00:30:19Bilgusit seems to be pretty indicative of how dogshit it runs IRL
00:30:34Bilgusso it must not make that much difference
00:30:55 Part ender`
00:31:52saratogayeah, test_mem on fuze+ is doing a 32 KB sequential memory transfer
00:32:09saratogad cache is 16KB, so half of the test should probably fit in buffer
00:35:12saratogashould 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:50saratogaits possible that the IRAM, while not actually that fast for sequential transfers, has really good random access times or something
00:36:05saratogalike a cache on a slow bus or something
00:36:49Bilgusmaybe or maybe the fuze+ is really bad at switching frequencies
00:37:16saratogahuh, the ipod classic uses the same CPU as AMSv2 and also has nearly identical speed:
00:37:23saratogaso its probably just that something is slow on the fuze
00:37:39saratogaBilgus: the test_codec plugin doesn't switch frequencies
00:38:54saratogaso 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:10saratogamem_test plugin says sequential memory speed is comparable
00:39:10Bilgushmm then how would it decide that it took 200 MhZ to decode or whatever unboosted?
00:39:24saratogait just counts how many cycles were required basically
00:39:29Bilgusthe device is running at an actual 64mhz at the time isn't it?
00:39:42saratogayou can set it to run at either boost or unboost speed in settings
00:39:50man_in_shackguessing there's no way atm to get rockbox to automagically pause on android when bluetooth disconnects?
00:39:54saratogait boosts once (before the timer starts) and then leaves it there
00:40:11saratogaor unboosts
00:40:20Bilgusof fuze+ NO auto slow boosted 96.21s 182.96% realtime 248.54Mhz
00:40:35Bilgusthat was much! better
00:40:43saratogawhat does that setting do?
00:41:11BilgusI'm pretty sure it keeps it from idling but pamaury mentioned it
00:42:58saratogabut 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:21Bilgusit didn't do much for the unboosted though
00:49:24Bilgusfuze+ No auto slow no boost 417.01 42.21% 151.62 Mhz
00:49:55*man_in_shack boosts Bilgus's slow
00:50:12saratoga206 MHz before though?
00:50:14saratogastill pretty nice
00:50:24BilgusI guess it did knock off 100 seconds
00:50:43saratogaipod classic is 101 MHz with DRAM
00:50:55saratogaprobably won't do much better than that
00:51:06Bilgusdidn't do anything for actually playing the file though
00:51:16saratogathat is surprising
00:51:22saratogaso its not related to decode speed
00:51:58saratogaanyway, pamaury needs to clarify what that setting actually does
00:52:11saratogaand if possible, see if decode performance can be increased in git
00:52:15saratogathat would likely give a nice increase in battery life
00:52:45saratogaanyway, i have to run
00:52:50BilgusI think its there to give an increase in battery life lol
00:52:50saratogawill check logs
00:53:20saratogaif it increases average clock speed so much i wonder if it does that
00:54:17__builtinuser890104: were you considering piezo PWM sound output on the ipod6g?
01:04:39 Quit petur (Remote host closed the connection)
01:07:06man_in_shackgot target=android type=sim to build but there's no rockboxui created
01:08:51man_in_shacksame deal with androidx86
01:09:53Bilgusdid you type make && make fullinstall?
01:10:10man_in_shackdid make, but not fullinstall
01:10:20Bilgusgotta do it 2x
01:10:37Bilguslike this make -j2 && make fullinstall
01:10:54Bilgusthe && only goes if the first make was without err
01:10:56man_in_shack"no rule to make target fullinstall"
01:11:11Bilgustry just install
01:14:23man_in_shacknow it can't find the android build tools cos
01:23:19man_in_shackso got that part working, now it wants javac
01:27:44man_in_shackyah it's trying to build an apk
01:30:05__builtinhmm, I don't think you need install to produce rockboxui
01:30:24__builtinit might be different for android though
01:30:54man_in_shacklooks like it's also trying to push it via adb
01:32:43man_in_shack__builtin: that's what i thought too but i'm humouring Bilgus
01:32:48man_in_shackstill no rockboxui
01:33:07man_in_shacklooks like simulator doesn't have an android target
01:40:40man_in_shackso i'll have to try running it in the android simulator
01:48:00***Saving seen data "./dancer.seen"
01:52:05__builtinugh, this is annoying
01:52:38__builtinI suspect there's an unaligned access somewhere that's being magically "fixed" when I put in splash() statements to track it down :(
02:03:58 Quit Ruhan (Quit: Connection closed for inactivity)
02:06:41 Quit krabador (Remote host closed the connection)
02:24:37man_in_shacki can't find where the .rockbox directory is on android
02:32:38man_in_shackapparently "android uses /sdcard/rockbox as the usual .rokcbox folder"
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:14:17 Join Ruhan [0] (uid76353@gateway/web/
05:14:27 Quit Marex (Ping timeout: 240 seconds)
05:48:02***Saving seen data "./dancer.seen"
05:59:18Bilgussaratoga 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: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:02:56 Quit Huntereb (Ping timeout: 260 seconds)
07:12:50 Join Huntereb [0] (
07:40:36 Quit Huntereb (Ping timeout: 258 seconds)
07:48:05***Saving seen data "./dancer.seen"
07:51:00 Join Huntereb [0] (
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:20:28 Quit Huntereb (Ping timeout: 255 seconds)
08:22:21 Join ender` [0] (
08:32:20 Join Huntereb [0] (
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] (
08:49:14 Join man_in_s1ack [0] (~chat@unaffiliated/man-in-shack/x-4279753)
09:09:36 Join wodz [0] (
09:32:04 Quit deevious (Quit: deevious)
09:48:09***Saving seen data "./dancer.seen"
10:04:10 Join deevious [0] (~Thunderbi@
10:06:34 Quit paulk-gagarine-s (Quit: Leaving)
10:07:18 Join paulk-gagarine [0] (
10:10:03 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
10:30:55pamauryBilgus: saratoga: auto slow is a hardware mecanism to automatically slow the bus frequencies when there is no activitity.
10:31:14pamauryIt can be disabled, and one can also choose by how much the frequency is reduced
10:31:34pamauryCan somone summarize your findings? It's a bit confusing
10:31:57 Join Marex [0] (~Marex@
10:46:10fs-bluebotBuild Server message: 3New 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:16fs-bluebotBuild Server message: 3Build round completed after 666 seconds.
10:57:17fs-bluebotBuild Server message: 3Revision 5eee28e result: All green
11:08:00 Join dys [0] (
11:11:48 Join deevious [0] (~Thunderbi@
11:16:06 Join PimpiN8 [0] (
11:48:11***Saving seen data "./dancer.seen"
12:07:34fs-bluebotBuild Server message: 3New 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:36fs-bluebotBuild Server message: 3Build round completed after 661 seconds.
12:18:37fs-bluebotBuild Server message: 3Revision a8e4b3a result: All green
12:29:32user890104__builtin: only square waves, but if the timer supports PWM, i'd use it
12:30:39user890104PC 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:20:45 Join robertd1 [0] (~root@
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:15:21 Quit sanchaez (Ping timeout: 264 seconds)
14:15:32 Join krabador [0] (~krabador@unaffiliated/krabador)
14:51:04 Join amayer [0] (
14:54:32 Join parchd [0] (~parchd@unaffiliated/parchd)
15:05:22BilgusPamaury 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] (
15:08:11Bilgusbut 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@
15:10:10pamauryBilgus: so the device didn't boost although the boost counter was positive?
15:10:39 Join jhMikeS [0] (
15:10:53Bilgusyeah I even tried manually ticking it up and even though the counter counted to 10 it never even touched the CPU freq
15:10:53pamauryAnd so what was the conclusion from yesterday about the auto slow feature?
15:11:22Bilgusit just made the device a bit faster on decode
15:11:44pamauryBilgus: 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:33pamauryand that was with code in trunk? No modifications?
15:12:44BilgusI suspect you would see the same issue on all platforms given the right codec taxing the device like that AAC-HE file
15:13:05pamauryoh so you think it's a problem with the generic boost code
15:13:07Bilgusyes from 3.14 to Head same behaviour
15:13:58pamauryso not my problem :-p
15:14:17pamauryexcept for this strange underperformance of the fuze+, something doesn't look right
15:14:47Bilgusit decodes the same as the codec benchmark page
15:15:00 Quit jhMikeS (Ping timeout: 240 seconds)
15:15:00Bilgusits just the device was stuck at 64MHZ
15:15:31Bilgustake a look ath AAC-HE decode times on the slow devices.. the ones that actually completed
15:16:35pamauryoh so you think the strange performance difference is because when boosted it doesn't actaulyl boost?
15:17:40pamaurywhere are the results?
15:18:17wodzI bet you can see in debug menu if manually triggering boost changes value in pll/div registers
15:19:12pamauryBilgus: 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:32BilgusYou assume you can even get there while the device is stuttering
15:19:46Bilgusyou have to be super quick
15:20:02pamaurywith logf you can see what happens though
15:20:23Bilgustrue give me a minute and I'll do that again
15:20:24pamauryjust 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:46:21Bilgusthere is HEAD not each time you see boost the system wither called cpu_boost(True) or (false)\
15:46:34 Quit krabador (Remote host closed the connection)
15:48:16***Saving seen data "./dancer.seen"
15:54:14Bilgusand after fix
15:59:48 Join TheEaterOfSouls [0] (~souls@unaffiliated/theeaterofsouls)
16:00:50Bilgusman 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:42man_in_shackfinally got the damn android emulator running right without fiddling
16:24:09man_in_shackjust uploaded the fonts to it to test
16:24:21man_in_shacktomorrow i gonna start on my theme for it (:
16:27:32pamauryBilgus: what is the "fix" you are referring to?
16:27:42 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
16:30:21BilgusJhMikeS 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:23Bilgussomething like.. if (filling) {trigger_cpu_boost();} else if ( == SYS_TIMEOUT) {cancel_cpu_boost();
16:32:03pamaurybut do you have an explanation for why the old code didn't work?
16:33:40Bilgusold code canceled boost each time the thread fired just before it was needed
16:34:09pamauryso basically it was no really asking to boost?
16:34:24pamauryBut why did the boost counter increased and cpu frequency stayed the same then?
16:37:00Bilgusonce it started being underrun I'm pretty sure the next fill event fired before the previous boost was fulfilled
16:42:07BilgusIt seems to be acting pretty sane now I think I might play with the !filling timeout though
16:47:47 Quit petur (Quit: Connection reset by beer)
16:47:49BilgusI 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:32BilgusI'll probably have to do a battery bench to really know for sure but Its probably different between devices
16:58:21pamauryInteresting, I never noticed that the imx233 programming manuals recommends two possible maximum frequencies:
16:58:21pamaurycpu at 392 MHz, HBUS at 196 MHz
16:58:21pamaurycpu at 450 MHz, HBUS at 150 Mhz
16:58:32pamauryit's a bit strange that HBUS be lower for high cpu clock!
16:59:36pamaurybut 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:41pamauryhmm, manuals says there is a fractional divider mode actually, so it's a bit ridiculous
17:02:37Bilgusit sounds like a pretty interesting chip
17:03:24BilgusI wish they had spent more time on the fuze+ design as far as buttons
17:03:25pamauryah, maximum is 205Mhz
17:03:53pamauryso probbaly I could run the HBUS at 205, that should give better performance, and I need to investigate auto slow
17:05:18BilgusIn theory it probably shouldn't have been running during that AAc decode but i'm not sure what the threshold is
17:05:48pamauryBilgus: what should not be running?
17:06:54Bilgusactivating might be a better term
17:07:42pamauryin 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:07BilgusI bet its more of a running average and there was power to be saved
17:10:37pamauryI don't think it's an avergae
17:11:08pamaurybut maybe I didn't program it correctly
17:11:28pamauryif 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] (
17:43:17 Quit copper (Remote host closed the connection)
17:44:05 Join copper [0] (~copper@unaffiliated/copper)
17:46:25edhelashello 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.
17:58:41CH23yesterday 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:22:42 Join Ruhan [0] (uid76353@gateway/web/
18:23:03BilgusI've never had it no able to be opened have you tried chmod?
18:25:21Bilgusoh 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:29CH23i've ordered 3 different ones this afternoon, a cruzer micro, cruzer blade, and cruzer edge
18:29:17CH23I hope one of them contains the SDTMNAHEM-004G or 008G chip
18:29:46CH23if not i will still try to make it work; i've ordered a NAND adapter from aliexpress
18:30:03CH23so i don't need to solder them onto the clip+
18:33:11Bilgusthe 8g drive was a sandisk cruzer SDCZ36Z-008G Bl1106XAJB
18:34:01CH23what was the flash chip?
18:34:06Bilgusso 11 years old id say lol
18:34:18Bilgusno the actual model numbers
18:34:30CH23yes i know, what was the flash chip?
18:34:38Bilguschip was the same as your data sheet
18:35:40CH23you said it was totally different, but it was the same?
18:36:06Bilgusno the 4 gb I had was totally different
18:36:36CH23oh sorry i couldn't tell you that you had multiple ones
18:36:55Bilgusit was something like SNTNA or along those lines
18:37:22CH23i wonder if it really matters
18:38:23CH23afaik dongs never tested on the clip+ with actual sandisk NAND
18:38:30BilgusI'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:25CH23he tried with other NAND TSOP48
18:39:31CH23those didn't work for him
18:47:46CH23i think the SOC might 'pre-treat' the NAND to make it work
18:48:19CH23but maybe the SOC also checks what NAND is ued
18:48:31CH23all assumptions, of course.
18:49:25BilgusI think i'd like to put the chip from the clip into the flash drive first
18:50:39CH23i'd like you to do that too. do you use windows or linux>
18:50:58 Join saratoga_ [0] (86ae6e0e@gateway/web/freenode/ip.
18:52:36saratoga_pamaury: bilgus's test_codec results showed a huge improvement in performance when boosted if the slow feature was disabled
18:52:58saratoga_387.74MHz -> 248.54Mhz
18:53:10BilgusCH23 both
18:53:25saratoga_that is over 50% faster
18:54:04saratoga_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:47saratoga_i can do a battery bench on my broken fuze+ if you want to suggest settings
18:54:56CH23Bilgus: i suggest using Linux because I don't trust windows with USB drives, it might change it
18:56:31CH23but if it works that'd be great
18:56:50Bilgusfuze+ NO auto slow boosted 96.21s 182.96% realtime 248.54Mhz
18:56:50Bilgus boosted 148.25 118.73% realtime 383 MHZ
18:56:51Bilgusfuze+ No auto slow no boost 417.01 42.21% 151.62 Mhz
18:56:51DBUGEnqueued KICK Bilgus
18:56:51Bilgus NO boost 568.35s 30.97% 206.65 MHZ
19:22:03BilgusI think its like 35% and 25% respectively
19:22:08CH23turns out nautilus gave me the finger and turned off the setting to show hidden files
19:22:25Bilgus%diff is abs(new-old) / old
19:22:40Bilgus x100
19:23:36Bilgushmm i didn't think the simdisk folder was hidden only the .rockbox folder within it
19:26:12CH23yes that's what i meant
19:26:23CH23when i tried to open simdisk it wouldn't
19:26:43CH23but i'm glad i now know it's basically a normal build in there
19:28:05 Quit parchd (Quit: Lost terminal)
19:32:44saratoga_should probably battery bench with it enabled for both boost and then unboost and see if it makes a difference
19:32:53saratoga_i suspect it is not worthwhile for at least boost though
19:36:08 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
19:36:53pamauryBilgus: saratoga: can any of you do a battery bench with and without auto slow to see the difference?
19:37:22pamauryprobably there is no need for a complete bench, run each for 10 hours and see if there is a big difference
19:39:05saratoga_probably this player's battery will die before then :)
19:39:21saratoga_what do I need to change to test?
19:39:24pamauryah, your battery is that dead?
19:39:43saratoga_its a second hand player from ebay, barely works
19:39:52pamauryin system-imx233.c, line 358, change imx233_clkctrl_enable_auto_slow(true) to imx233_clkctrl_enable_auto_slow(false)
19:39:53saratoga_should be fine for battery testing though
19:40:05saratoga_ok, will try that later tonight when i get home
19:42:56BilgusI have a nearly fully charged battery
19:44:36saratoga_for what its worth, Mihale found that adjusting the clock settings had a large impact on performance and battery life for amsv1
19:44:38saratoga_sorry v2
19:45:01saratoga_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:26saratoga_although i guess battery life for imx233 is already incredible right?
19:47:14 Join Jinx [0] (~Jinx@unaffiliated/jinx)
19:47:29pamauryit's already quite good, I think over 50 hours
19:48:20***Saving seen data "./dancer.seen"
19:48:28saratoga_how big is the battery?
19:48:42pamauryit'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:12saratoga_oh 550 mah, so about 11 ma
19:49:20saratoga_actually very similar to amsv2
19:56:10pamauryso without auto slow, how does the performance compare to the amsv2?
19:58:02saratoga_it is still slower
19:58:45pamauryI'll try to increase the frequency of the hbus
19:58:49saratoga_no boost is 151.62 Mhz, whereas AMSv2 is probably more like 90-100 at that clock speed
19:59:12saratoga_the CPU does get a lot less efficient when running at 450 mhz
19:59:22saratoga_so faster memory might help
19:59:50saratoga_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:01:01saratoga_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:04pamaurymemory is still running at maximum speed on the imx233, just hbus isn't
20:03:55saratoga_what is the hbus?
20:04:15pamauryit's the internal ahb bus frequency
20:05:09saratoga_oh ok, just assumed it was running at memory frequency
20:12:39 Join petur [0] (~petur@rockbox/developer/petur)
20:15:09CH23Bilgus: what's required to replace the image used in the emulator upstream?
20:18:01CH23are there any standards it has to comply to or would this do
20:20:07Bilgusoh you mean the actual emulator device pic?
20:20:53saratoga_i believe its a bitmap in the uisim folder
20:21:29CH23yes it is, i replaced it locally, but i think this one is much clearer than the one currently in the source
20:21:49CH23the default one is too dark
20:22:45Bilgusyour has some dithering and strange lighting
20:23:40CH23let me fix that
20:23:40Bilgusmight be better to morph them together
20:29:28Bilgusits 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] (
20:36:25CH23it was a screenshot of it in use
20:37:02CH23i'm cleaning up now
20:41:15Bilgusah ok
20:45:04 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42)
20:58:33CH23is ARGB 32bit BMP okay?
21:01:40CH23it seems to work
21:01:58Bilgusjudging by the rest of the image code probably
21:02:57Bilgusno sorry I think the rest is 24bit
21:03:18 Join JanC_ [0] (~janc@lugwv/member/JanC)
21:03:32Bilgusbut if it works nbd
21:04:39 Nick JanC is now known as Guest46476 (~janc@lugwv/member/JanC)
21:04:39 Quit Guest46476 (Killed ( (Nickname regained by services)))
21:04:39 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC)
21:06:28CH23sorry wrong link
21:07:25Bilguslooks better screen is still a bit off
21:07:39Bilguslike 3 px shifted to left
21:09:33CH23the coloured pixels, the screen "viewport", or the device compared to the window?
21:10:28Bilgusthe device / window
21:10:37Bilguswell device / screen
21:11:09Bilgusthe screen is shifted slightly left meaning the image needs moved `3px left
21:11:48Bilgusand probably +width by the same
21:11:59Bilgusit looks like the right side matches right
21:15:07 Join CH23_ [0] (5594df77@gateway/web/freenode/ip.
21:16:42 Join alexweissman [0] (
21:16:43 Quit CH23 (Ping timeout: 260 seconds)
21:17:43 Nick CH23_ is now known as CH23 (5594df77@gateway/web/freenode/ip.
21:21:06CH23the simulator simulates the screen off-center, 42px on left, 35 px on right
21:21:58Bilgushmm never noticed
21:22:18Bilgusprobably bc the original image is murky enough
21:23:23BilgusI'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:12CtcpIgnored 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:25pamauryis there any good reason in lib/rbcodecs/lib/codecs.h to only define DEBUGF on if defined(CODEC) ?
21:31:35pamaurywhy is it not always defined?
21:32:40Bilgusmaybe 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:46pamauryit looks like it has more to do with encoders
21:35:29pamauryhmmm, or maybe it's because of metadata
21:37:42pamauryhmm, now this is very odd. Even a normal build fails!!!
21:38:31Bilgusthe sandisk logo is holographic
21:39:20CH23is that important?
21:39:57Bilgusbut 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:52CH23ah that's why i asked if there were standards or anything required
21:44:26BilgusI was thinking you meant like sizes formats masks
21:45:18Bilgusanything that goes into rockbox needs to be I believe compatible with GNU GPL v2 >
21:46:00Bilgusplayer images might be a grey area but IDK
21:48:24***Saving seen data "./dancer.seen"
21:48:46CH23it seems like sandisk website doesn't mention any license at all for their stock images
21:55:54 Join lebellium [0] (
22:03:45pamaurythe test_mem plugin is kind of useless
22:03:55pamauryit's so cpu intensive my device is completely unresponsive!
22:08:46 Quit Slasheri (Ping timeout: 240 seconds)
22:09:13saratoga_yes that is really annoying
22:09:26saratoga_(see my comments about it last night)
22:10:20Bilgusyou'd think the button loop would slow it down enough
22:14:14 Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri)
22:16:23pamauryhere are test_mem results: pamaury/cf20e5877da1008c37a584082eb6a3c7">
22:16:54pamauryI modified the code to use a bigger buffer
22:17:24pamaurynow I will try when changing HBUS
22:33:06saratoga_can you commit the buffer change?
22:33:13saratoga_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:35pamaurysaratoga_: well the problem is it depends on the plugin buffer size
22:39:43pamaurythe size I chose is probably too big for many players
22:39:51pamauryI think it should be allocated dynamically
22:39:58pamauryto get a big buffer
22:41:22saratoga_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:30pamaurysaratoga_: yeah but if we go that way, we would need to expand that check for like 4 or 5 different sizes
22:44:57pamauryand 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:02saratoga_can you just check for 128KB and use that if available? I think that should be enough
22:46:49pamauryok let me try
22:51:13 Join wodz [0] (
22:52:51wodzWhy 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@
22:53:38wodzAnd if we need to measure raw ram speed we should use uncached alias
23:00:57pamaurywell uncached is not very realistic though
23:01:13pamaurymost of rockbox is cached, I guess it depends on what we want to measure
23:02:46 Join jhMikeS [0] (
23:04:48 Quit alexweissman (Remote host closed the connection)
23:05:28 Join alexweissman [0] (
23:13:02saratoga_i think cached sequential access and cached random access would be most informative
23:13:17saratoga_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/
23:29:24*pamaury wrote the code to set HBUS with a fractional divider correct on the first try \o/
23:30:51wodzyou are wizard!
23:33:06pamauryresults here: pamaury/cf20e5877da1008c37a584082eb6a3c7">
23:33:32pamauryvery modest improvement
23:34:05 Join tchan [0] (
23:34:05 Quit tchan (Changing host)
23:34:05 Join tchan [0] (~tchan@lunar-linux/developer/tchan)
23:35:22wodzpamaury: what freq is HBUS already?
23:37:40pamauryout of curiosity I tried to push it more, it works until 230Mhz but after that it crash
23:38:04pamaurythe datasheet says 205Mhz max, but it doesn't seem to give more performance, problaly the ram is the main factor
23:38:54wodzhuh, ~28% increase in HBUS speed gives ~5% improvement
23:39:18wodzso yeah, ram is limiting factor
23:40:43 Join bray90820 [0] (
23:42:20 Quit bray90820 (Client Quit)
23:43:29 Join [Saint] [0] (~sinner@rockbox/staff/saint)
23:45:09pamauryit 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:17pamauryg#1694, g#1695, g#1696, g#1697
23:46:24fs-bluebot3Gerrit review #1694 at : 3nwztools/upgtools: make the tool print the whole kas, not just 16 bytes by Amaury Pouly
23:46:24fs-bluebot3Gerrit review #1695 at : 3test_mem: increase dram buffer if possible, cap number of iterations by Amaury Pouly
23:46:25fs-bluebot3Gerrit review #1696 at : 3imx233: make clkctrl code aware of hbus fractional divider by Amaury Pouly
23:46:26DBUGEnqueued KICK fs-bluebot
23:46:26fs-bluebot3Gerrit review #1697 at : 3imx233: disable auto-slow feature by Amaury Pouly
23:47:55pamauryhmm, I'm missing one
23:48:28***Saving seen data "./dancer.seen"
23:48:44fs-bluebot3Gerrit review #1698 at : 3imx233: switch hbus to 200Mhz when boosting by Amaury Pouly
23:49:13CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
23:49:13*pamaury goes to bed
23:49:28wodzpamaury: Do you have actions Media Player Product Tool utility (the one you disassembled before) or should I send it to you?
23:49:52pamaurywodz: I can't find it, can you send it to me again?/
23:50:01wodzpamaury: sure
23:50:10pamaurysomeone should benchmark those imx233 changes with codecs to see the influence of auto slow and hbus
23:53:37 Quit sanchaez (Quit: ZNC -
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)

Previous day | Next day