--- Log for 11.10.117 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 10 days and 16 hours ago 00.05.03 Quit petur (Remote host closed the connection) 00.05.34 Quit mikroflops (Ping timeout: 240 seconds) 00.06.06 # i think it still showed the same 00.10.32 Join mikroflops [0] (~yogurt@178.174.137.46) 00.13.54 # ok 00.16.16 # lsusb says "Sandisk Corp." and block device reports as " UNDEF " 00.16.28 # the UNDEF is proably an indicator of death 00.31.12 # what does sudo fdisk -l && lsblk report? 00.34.42 Quit ender` (Quit: In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.) 00.41.27 # oh sorry just saw you already did 00.43.53 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 00.51.12 Quit man_in_shack (Ping timeout: 248 seconds) 01.04.32 Quit pamaury (Ping timeout: 248 seconds) 01.04.53 Quit Tony_ (Ping timeout: 260 seconds) 01.09.58 Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) 01.17.33 Join Tony_ [0] (ae3638f0@gateway/web/freenode/ip.174.54.56.240) 01.28.45 Quit krabador (Quit: Leaving) 01.47.29 *** Saving seen data "./dancer.seen" 01.59.13 Quit Ruhan (Quit: Connection closed for inactivity) 02.33.04 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 02.36.14 Quit JdGordon_ (Ping timeout: 248 seconds) 02.48.02 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 03.03.56 Quit dys (Ping timeout: 264 seconds) 03.13.14 Quit Aldem (Read error: Connection reset by peer) 03.18.06 Quit prof_wolfff (Ping timeout: 260 seconds) 03.19.15 Join prof_wolfff [0] (~prof_wolf@120.red-83-54-195.dynamicip.rima-tde.net) 03.19.23 Join Aldem [0] (~Aldem@unaffiliated/aldem) 03.30.26 # <__builtin> pamaury (logs): yes 03.30.40 # <__builtin> I see, so ARM926 wouldn't support it then 03.30.46 # <__builtin> too bad :( 03.31.02 # <__builtin> at least I can set the A bit and root out the crashes 03.38.40 Quit _meg (Ping timeout: 255 seconds) 03.39.22 Join _meg [0] (~notsure@211.25.203.45) 03.47.14 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 03.47.33 *** Saving seen data "./dancer.seen" 03.47.35 # Bilgus: I get 250 MHz needed for real time decode of my AAC-HE test file 03.47.57 # i tried unboosted, its still running :) 03.49.19 # on the fuze+? 03.50.03 # yeah 03.50.17 # damn it, plugin has this bug where it doesn't show the speed if the plugin finishes with the screen off 03.50.24 # so i lost the results for the unboosted test 03.52.01 # aac in general is really slow on the fuze 03.52.12 # maybe slow RAM? 03.53.50 # yeah its weird that locking the frequency even at 64 mhz and it works properly so IDK whats up but i'll look into it more 03.55.41 # if you have the test plugins configured, double check that the speed is correct for unboosted 03.56.01 # long select the file and run it with boost enabled, and with the boost disabled (test plugin can do both) 03.56.11 # should make it obvious if something is wrong 03.59.02 Quit man_in_shack (Read error: Connection reset by peer) 04.00.09 Join man_in_shack [0] (~chat@unaffiliated/man-in-shack/x-4279753) 04.01.51 Quit CrashBash-Kun (Read error: Connection reset by peer) 04.03.26 # strange that it is so slow given the 16KB cache and the ARM9e core 04.19.53 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 04.22.34 Quit advcomp2019_ (Ping timeout: 240 seconds) 04.43.51 Quit scorche|sh (Ping timeout: 260 seconds) 04.45.44 Join scorche|sh [0] (~scorche@squisch.net) 04.45.45 Quit scorche|sh (Changing host) 04.45.45 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 05.05.37 Quit Strife89 (Ping timeout: 255 seconds) 05.06.06 Join Strife89 [0] (~quassel@adsl-98-80-181-168.mcn.bellsouth.net) 05.47.34 *** Saving seen data "./dancer.seen" 06.06.07 Quit TheSeven (Ping timeout: 258 seconds) 06.06.31 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.27.31 Quit TheSeven (Ping timeout: 246 seconds) 06.27.43 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 07.47.38 *** Saving seen data "./dancer.seen" 08.28.03 Join ender` [0] (krneki@foo.eternallybored.org) 08.44.57 # rockbox to the rescue! 08.46.27 # my dad has given me an old android phone and rockbox works nicely on it :D 08.46.34 # https://www.ebay.com.au/itm/sansa-fuze-/272877700719? << means i don't need to buy these now :P 08.49.48 # sansa fuzes are awesome though :P rockbox for android is a different experience 08.49.51 # but long as you're happy! 08.51.21 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.51.36 # yah they awesome but also cost more than $0 08.51.38 Join petur [0] (~petur@91.183.48.77) 08.51.38 Quit petur (Changing host) 08.51.38 Join petur [0] (~petur@rockbox/developer/petur) 08.51.54 # also bluetooth audio is nice 08.52.03 # one fewer cable to run 09.02.48 Join JanC_ [0] (~janc@lugwv/member/JanC) 09.03.43 # one more battery to charge :P 09.04.05 Nick JanC is now known as Guest86327 (~janc@lugwv/member/JanC) 09.04.05 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 09.05.11 Quit Guest86327 (Ping timeout: 260 seconds) 09.05.33 # wodz: not really. running a dedicated music player in my car one way or another 09.05.48 # has been sansa clip+ but the flash in it is dead 09.46.13 Join p3tur [0] (~petur@rockbox/developer/petur) 09.46.13 Quit petur (Read error: Connection reset by peer) 09.47.40 *** Saving seen data "./dancer.seen" 09.54.53 Nick p3tur is now known as petur (~petur@rockbox/developer/petur) 10.03.09 Quit tchan (Quit: WeeChat 1.6) 10.22.32 Quit dfkt (Quit: SIC GORGIAMVS ALLOS SVBJECTATOS NVNC.) 10.23.05 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 10.29.52 Quit mc2739 (Ping timeout: 248 seconds) 10.29.54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.35.43 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.40.51 Quit Moarc (Ping timeout: 260 seconds) 10.42.12 Join Moarc [0] (~chujko@a105.net128.okay.pl) 10.49.33 Quit pamaury (Ping timeout: 264 seconds) 10.51.59 Join p3tur [0] (~petur@rockbox/developer/petur) 10.54.43 Quit petur (Ping timeout: 255 seconds) 11.19.41 Nick p3tur is now known as petur (~petur@rockbox/developer/petur) 11.23.29 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:ed48:8e3f:8a7d:94dc) 11.35.41 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.47.41 *** Saving seen data "./dancer.seen" 12.20.12 Join CH23 [0] (4dfa0218@gateway/web/freenode/ip.77.250.2.24) 12.20.46 # is the clip+ recovery mode run from the internal flash, or from the SOC? 12.26.19 # man_in_shack: are you willing to sell me your broken clip+ ? i have some things i want to test 12.28.28 # CH23: from SoC rom AFAIK 12.29.08 # wodz: just spoke with dongs, yeah it is. 12.29.41 # dongs, the person. not the body part. 12.29.46 Quit yosafbridge (Quit: Leaving) 12.30.36 # CH23: consult pamaury, he tried disassembling recovery mode on amsv2 12.31.32 # i have most of the info i need; now i just need a matching NAND chip, and broken device. 12.31.45 Join robertd1 [0] (~root@201.242.176.168) 12.33.48 # Anyway I am pretty sure recover mode runs from rom and not from nand (there might be 2 recovery modes actually). You can force amsv2 device into recovery mode by shorting nand address lines and creating flash fault. How would it load recovery image then? 12.33.58 Join yosafbridge [0] (~yosafbrid@68.ip-149-56-14.net) 12.34.48 # as i said, it runs from SOC 12.54.20 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 12.54.52 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:ed48:8e3f:8a7d:94dc) 12.54.57 Quit PimpiN8 (Client Quit) 13.01.04 Quit robertd1 (Remote host closed the connection) 13.11.11 # saratoga pamaury I did the test codec for boost/unboosted at normal, locked 64MHz and Locked 454Mhz the results jive with the observations still not sure what it means though http://forums.rockbox.org/index.php/topic,52018.msg240757.html#msg240757 13.17.44 # man_in_shack: are you willing to sell me your broken clip+ ? i have some things i want to test << sure 13.18.02 # what country you in? 13.18.06 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 13.18.48 Quit TheLemonMan (Client Quit) 13.20.31 # man_in_shack: netherlands 13.20.51 # australia here 13.20.55 # oh boy 13.20.59 # (: 13.21.08 # that's gonna be heaps in shipping cost 13.21.14 # could be 13.24.41 Join robertd1 [0] (~root@201.242.176.168) 13.26.35 # au$21.50 shipping 13.28.59 # and how much do you want for the device itself? 13.36.34 # CH23: wodz: I once tried to disassemble the ROM from amsv2 but it's very complicated, I never finished. My impression though was that the ROM supports two modes, one mode where the flash is accessible but does not contain valid code (I guess that's the 900MB partition thing) and one mode where the NAND is not accessible (the 30MB probably-ram-disk) 13.37.45 # but the thing that is not clear to me, and the code is too complicated to follow, is what would happen if you had a valid flash but not formatted. On a related question, we still don't know what exactly is responsible for the flash FTL and if it's possible to recreate/format it. 13.39.06 # previously i pulled a full disk image from my 4gb clip+, when in recovery though? 13.39.23 # but that doesn't have any of the nand stuff 13.40.14 # I have those images btw up on the forum and a build with them that allows you to access the 'hidden' part of the drive without recovery mode 13.41.04 # see basically the sansa OF and rockbox block the first 0xF000 sectors from you to protect the firmware 13.41.28 # its not special in any way except not being a valid partition 13.41.50 # and that's not writable in recovery 13.41.58 # sure it is 13.42.22 # isn't that all you need to make it work then? 13.42.23 # its writable in those special builds that I unblocked it as well 13.42.44 # It doesn't have anything needed for the nand init 13.43.35 # i'm a bit confused. the recovery is 'directed' from the SOC rom, then gives access to the NAND, right? 13.43.48 # directed/run 13.44.12 # it gives you access to the NAND only if the NAND is accessible 13.44.31 # when the NAND is dead, it seems to switch to this 30MB ram disk 13.44.47 # which we don't know how to use afaik? 13.44.53 # so if you were to completely blank out the NAND, would it still give access? 13.45.06 # like basically what recovery is for is if you screw the image up and the device no longer boots because bad code but hardware is still working fine 13.45.45 # it seems the 30MB soesn't persist writes so not sure if its even a ram disk 13.45.50 # doesn't* 13.46.09 # i want man_in_shack's device to see if i can transplant an equal NAND chip onto it, then via recovery DD an image to it 13.46.54 # but I could take my device that works now erase the whole drive and it would be a brick.. put the device in 'recovery' write back the image reboot and all would work 13.47.16 # the equal nand chip is the issue 13.47.23 # maybe not 13.47.43 *** Saving seen data "./dancer.seen" 13.47.44 # the same flash chip was used in the sandisk cruzer 4gb and 8gb drives 13.47.44 # maybe pigs can fly with enough thrust 13.47.54 # and some others 13.48.33 # I for one hope thats the case but I'm not sure how likely it is but in theory yes that should work 13.50.27 # speaking of johnb is going to try brute forcing an image to his readonly clip+ this weekend 13.50.28 # Bilgus: we don't really know what this "ram disk" is for, that's the main problem, and I never was able to figure it out 13.50.32 # but I could have another try 13.50.36 # from what dongs told me, it seems that these sandisk NAND chips aren't writable with those normal NAND flashing modules 13.50.49 # it doesn't accept writes either so maybe some init that missing 13.50.50 # that's why i had the idea of doing it via recovery 13.51.34 # CH23 dongs seems far more versed in NAND technology I can't say one way or another 13.51.44 # my readonly clip+ decided that readonly sucks and it's writable again 13.51.50 # well one thing we don't really know is whether those NAND are really NANDS 13.51.57 # or so SD with NAND "interface" 13.52.06 # according to the datasheet they seem to be 13.52.29 # btw CH23 you said you found that datasheet could you upload it somewhere 13.52.58 # how far dongs went in his exploration of the NAND? Can he read/send command to the NAND chip? 13.53.16 # also if its writable again why not put the multiboot bootloader on it and never touch the internal memory again? 13.53.24 # https://www.rockbox.org/irc/log-20170822 Bilgus we've been here before ;) 13.53.59 # also i already put the multiboot on it, because within rockbox it was always writable, so i copied it from the µSD card 13.55.35 # what does lsusb shows on recovery? There is the UNDEF with 30 MB, and the other one? 13.55.44 # I'm saying the actual bootloader? 13.56.14 # also I can't download that data sheet I'm sure most of that has to do with my lack of chinese 13.56.27 # oh hold on i have a mega link 13.57.37 # * pamaury starts looking at the ROM again 13.58.11 # https://mega.nz/#!aVwBDSrT!eDbUOvYfuBnQKY-oUnS_uoQISGvtY2CSoQJeXJD8ElI 13.58.24 # Thanks 13.58.31 # this is for the SDTNPNAHEM-008G 14.03.22 Quit jhMikeS (Ping timeout: 258 seconds) 14.05.09 Quit deevious (Ping timeout: 255 seconds) 14.05.21 Join deevious [0] (~Thunderbi@193.226.142.214) 14.13.03 # I always knew NAND was a scary thing to trust your data to but wow 14.13.11 # uery CH23 14.17.01 # i had one SSD fail on me, flash memory is scary stuff 14.19.30 # I was scarred when I discovered that perfectly working nand chip reported 4 bits of error in some cells (still corrected by BCH). 14.28.20 # :O 14.28.29 # so are there docs on writing themes? 14.30.11 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 14.34.24 # https://www.rockbox.org/wiki/CustomWPS man_in_shack there's this 14.34.46 Quit jhMikeS (Ping timeout: 255 seconds) 14.37.48 # man_in_shack, do be aware while mostly correct there are some errors in there 14.38.37 # thanks :) 14.38.39 # so if you just can't something to work it might not be you 14.38.47 # ^get* 14.39.28 # so next, is there some sort of emulator for testing themes? :D 14.39.53 # yep 14.40.51 # ahha, right at the bottom of the CustomWPS page 14.41.01 # http://rasher.dk/rockbox/simulator/ 14.41.37 # Not sure how up to date those are but I've not heard any complaints 14.42.06 # If you have linux we can give you more recent builds 14.45.35 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 14.47.18 # well it's for a 320x480 android target ... :P 14.48.50 # hmm, reminds me of my phone, but that one has a too "new" Android version for Rockbox 14.49.39 # * man_in_shack lords his 2.3.7 cyanogenmod over pixelma 14.49.46 Join amayer [0] (~amayer@107-1-97-172-ip-static.hfc.comcastbusiness.net) 14.50.54 # it's so old it doesn't do google 2-phase auth 14.51.03 # so i can't get to play store :P 14.51.10 # you could use a sim for any target thats 320x240 with a touchscreen 14.51.40 # execpt that's half the height :P 14.52.52 # sorry I ignored the 480 conveniently? 14.53.02 # yes, yes you did 14.53.16 # for that matter grab a bluetooth kb and dev on the device 14.53.29 # you can build a sim for any size RaaA target, I might even have one of the exact resolution from 2 years ago or so (probably cross-compiled for Windows but can't check right now) 14.53.37 # pfffffffffffffffffffftttttttttt 14.53.47 # ew windows 14.54.13 # back when my phone could still run Rockbox 14.54.20 # oh yeah you do have linux duh hey you could just build your own 14.58.50 # about that i never got the simulator to work for me 15.00.30 # ok 15.00.38 # so is there a way to just build the simulator? 15.01.37 # https://www.rockbox.org/wiki/UiSimulator#A_2._Build_UIsimulator 15.01.43 # oh target=sdlapp type=sim 15.02.21 # i was trying target=android :) 15.02.58 # i believe target should be a number 15.03.16 # it also allows the string name 15.03.27 # oh didn't know that 15.03.28 # wheeeeee lots of warnings :D 15.03.38 # CH23: read the help more :P 15.03.45 # i get 3 error messages 15.04.19 # :/usr/bin/ld: cannot find -lXrandr 15.04.26 # :/usr/bin/ld: cannot find -lXrendr 15.04.33 # collect2: error: ld returned 1 exit status 15.04.34 # that's cos you're missing libs :) 15.04.54 # apparently but i have xrandr 15.06.09 # so i'm not sure what libraries those would be 15.08.01 Join dys [0] (~dys@2a01:598:a084:182f:eab1:fcff:fe36:4b0b) 15.08.25 Quit sielicki (Quit: WeeChat 1.9.1) 15.08.51 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 15.10.56 # you need libxrandr-dev 15.11.01 # and libxrender-dev 15.14.31 Quit sielicki (Quit: WeeChat 1.9.1) 15.14.59 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 15.18.25 # thanks, now it works. 15.19.18 Quit sielicki (Client Quit) 15.20.05 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 15.25.39 Quit sielicki (Quit: WeeChat 1.9.1) 15.27.36 Join sielicki [0] (~sielicki@unaffiliated/n1cky) 15.46.53 # looking at the amsv2 bootloader code, I suspect there is a pin to select whether it boots from internal SD or microsd 15.47.01 # I think it's XPB[5] 15.47.18 # but I'm not entirely sure 15.47.30 # ok 15.47.46 *** Saving seen data "./dancer.seen" 15.49.07 # mmh, or maybe not, I see that in rockbox code this is used to determine the "variant" 15.49.40 # got simulator running ok now 15.52.00 # I need to disassemble more code 15.58.56 Quit wodz (Ping timeout: 248 seconds) 16.06.56 # except i built it wrong :D 16.07.09 # no disassemble number pamaury! 16.11.07 # * pamaury cannot parse this sentence 16.12.59 # syntax error 16.15.30 Quit CH23 (Quit: Page closed) 16.23.01 Quit Aldem (Remote host closed the connection) 16.23.30 Join Aldem [0] (~Aldem@unaffiliated/aldem) 16.34.46 Join krabador [0] (~krabador@unaffiliated/krabador) 16.54.24 Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-xqzkmtvykiofrgus) 17.02.55 Quit prof_wolfff (Ping timeout: 248 seconds) 17.16.02 Quit petur (Quit: Connection reset by beer) 17.24.52 Quit krabador (Remote host closed the connection) 17.31.34 Quit prg318 (Quit: ZNC 1.6.5 - http://znc.in) 17.34.07 Join prg318 [0] (~prg@deadcodersociety/prg318) 17.37.34 Quit Huntereb (Ping timeout: 248 seconds) 17.41.38 # ok I'm pretty sure it isn't the fuze+ causing the problems with the AAC-HE file 17.42.42 # also pamaury for future reference you can't change the CPU speeds in system-target.h the tables in system-imx233.h need to be changed 17.43.40 # I'm pretty sure the AAC-HE bug is either in the init of the buffer or something to do with watermark 17.47.48 *** Saving seen data "./dancer.seen" 17.49.06 Quit dys (Ping timeout: 240 seconds) 17.49.06 # Bilgus: I wrote the code so I'm pretty damn sure one can ;) 17.50.57 # Bilgus: imx233_set_cpu_frequency looks up the given cpu frequency in the table and simply applies what is listed. imx233_set_cpu_frequency is called only with CPUFREQ_DEFAULT_{SLEEP,NORMAL,MAX} 17.51.16 # just experienced it first hand I set all defines to IMX233_CPUFREQ_64_MHz in system-target, then it looks up the setting by key in system-imx233 and 454 MHZ is the first one looked at, it then matches and returns the settings for 454 MHZ 17.51.19 # sorry CPUFREQ_{DEFAULT,SLEEP,MAX} 17.51.50 # huh, unless you changed something, there is no way IMX233_CPUFREQ_454_MHz =IMX233_CPUFREQ_64_MHz 17.54.23 # thats exactly what I did lol 17.55.29 # I didn't say you were wron I said for future reference 17.59.03 # now the next question is where CPUFREQ_MAX is actually used 18.00.35 # what did you do? 18.01.11 # Bilgus: firmware/system.c 18.04.24 Join Halamix2 [0] (~Halamix2@unaffiliated/halamix2) 18.13.01 Join Huntereb [0] (~Huntereb@d-209-42-136-145.cpe.metrocast.net) 18.15.53 Join PimpiN8 [0] (~textual@ip51cd65d5.speed.planet.nl) 18.18.58 # ok so I'm back to not knowing WTF is the problem my clipzip plays the file fine it must be this fuze+ 18.27.17 Join krabador [0] (~krabador@unaffiliated/krabador) 18.31.18 Quit Huntereb (Ping timeout: 258 seconds) 18.43.29 Quit Halamix2 (Quit: Leaving) 18.46.13 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 18.49.19 Quit Huntereb (Client Quit) 18.50.08 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 18.51.46 Quit robertd1 (Ping timeout: 240 seconds) 19.03.23 Quit Huntereb (Read error: Connection reset by peer) 19.03.42 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 19.04.37 Join petur [0] (~petur@78-23-23-252.access.telenet.be) 19.04.39 Quit petur (Changing host) 19.04.39 Join petur [0] (~petur@rockbox/developer/petur) 19.09.52 # Pamaury I fixed it, moved cancel_cpu_boost(); from before the queue wait to after it and it works fine now the question is how much more time will devices spend boosted with that change or is there some other way to fix it like maybe checking how often the buffer needs filled in a time period 19.09.53 Quit Huntereb (Read error: Connection reset by peer) 19.10.15 # https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/apps/codec_thread.c#L581 19.12.48 # maybe change the queue wait to queue_wait_w_tmo and set it to a hz/2 or so 19.23.29 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 19.29.01 Quit Huntereb (Read error: Connection reset by peer) 19.33.27 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 19.36.37 Quit Huntereb (Read error: Connection reset by peer) 19.39.56 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 19.42.39 Quit michaelni (Ping timeout: 240 seconds) 19.47.49 *** Saving seen data "./dancer.seen" 19.50.44 Quit Huntereb (Read error: Connection reset by peer) 19.52.45 Join dys [0] (~dys@46.183.103.8) 19.54.33 Join Huntereb [0] (~Huntereb@d-65-99-122-176.cpe.metrocast.net) 19.56.10 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 20.03.26 Quit Huntereb (Ping timeout: 240 seconds) 20.09.46 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 20.09.55 Join prof_wolfff [0] (~prof_wolf@120.red-83-54-195.dynamicip.rima-tde.net) 20.13.02 Join lebellium [0] (~chatzilla@89-93-177-206.hfc.dyn.abo.bbox.fr) 20.13.20 # ok Fixed the issue g#1693 20.13.22 # 3Gerrit review #1693 at http://gerrit.rockbox.org/r/1693 : 3Move cpu_boost for codec_thread & Fix AAC-HE Fuze+ (others?) by William Wilgus 20.14.22 Quit Huntereb (Ping timeout: 248 seconds) 20.19.21 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 20.29.44 Quit Huntereb (Read error: Connection reset by peer) 20.33.32 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 20.43.33 Quit _meg (Ping timeout: 240 seconds) 20.44.14 Quit pamaury (Ping timeout: 246 seconds) 20.46.30 Join _meg [0] (~notsure@211.25.203.45) 20.53.47 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 20.57.43 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 56.0/20170926190823]) 20.57.45 # JhMikeS I see you've done quite a bit of work in codec_thread.c does this ^ look sane to you?? 21.05.58 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.19.36 Quit alexweissman () 21.33.21 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 21.34.09 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 21.36.39 Quit dys (Ping timeout: 240 seconds) 21.43.45 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 21.43.59 Quit kugel (Ping timeout: 248 seconds) 21.47.53 *** Saving seen data "./dancer.seen" 22.10.09 Quit Huntereb (Read error: Connection reset by peer) 22.13.30 # Nope I spoke too soon It still happens just happens to have a specific scenario to make it happen you have to start the song and not press any buttons 22.16.45 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 22.19.27 # pressing any buttons will enable boost 22.19.41 # to trouble shoot this you may want to disable the GUI boost feature if you haven't 22.19.46 # makes things more reproducible 22.20.45 # oh does it not have it? it felt like it did when i was using the UI 22.21.17 # It does 22.21.51 # starting to piss me off 22.23.44 Quit Huntereb (Ping timeout: 255 seconds) 22.26.15 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 22.28.19 # lol and it doesn't do it with a debug build 22.28.36 # I wonder if its some kind of a race condition 22.33.02 # * pamaury now remembers why the amsv2 rom is absolutely horrible to disassemble 22.36.32 Quit Huntereb (Quit: See ya!) 22.37.21 Join Huntereb [0] (~Huntereb@d-209-42-136-23.cpe.metrocast.net) 22.41.51 Join wodz [0] (~wodz@89-79-40-110.dynamic.chello.pl) 22.41.58 # pamaury: why? 22.42.30 # just about everything is an object 22.42.33 # like everything 22.43.46 # a buffer? It's an object. A queue? It's vector (object) of buffers (object). An OS queue? It's queue (object) with a semaphore (object) 22.44.10 # c++ to the extreme? 22.44.12 # Now I let you imagine what a usb driver can be. I've got at least 10 levels of objects imbrications, and I'm not done 22.44.30 # yeah, very extreme 22.44.44 # with vtables everywhere 22.45.27 # oh also they do things like: A USB queue? It's a OS queue, but let's subclass it just in case, even though we don't actually change it 22.45.57 # They even have an object to represent the hardware registers of USB ?! 22.46.20 # It's too hard to do USB_REG_BLA = x; no no no, USB_REG::get()->write_reg(BLA, x) 22.46.50 # probably there is going to be an allocation in this call for good measure 22.47.21 # thats the type of code when PC programmer starts to do embedded with c++ 22.47.39 # lets abstract everything attitude 22.48.10 # I swear they even abstract thing that are clearly going to be unique 22.48.41 # maybe they did this as RE countermeasure 22.48.44 # I'm sure the main code is: 22.48.44 # (new BootCode())->boot() 22.49.27 # I've heard of one product where firmware was intentionally rewritten in c++ to make RE much harder 22.50.09 # well I guess that's successful. But I wonder if it's worth it. I suspect the C++ code is also impossible to follow 22.52.20 # * wodz is seriously pissed off by the lack of documentation and comments in qemu 23.07.24 # still don't understand why the fuze+ is so much slower than the same arm core in a fuzev2 23.11.38 # is it? is it the cpu or the ram? 23.14.16 # so are you able to reproduce the AAC-HE bug on your fuze+ saratoga? you power on, set screen timeout to on, go to files, choose file and don't press a button and it skips within 5 secs? 23.14.42 # if its just my device i'm fine with leaving it be at this point 23.22.15 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 23.25.27 Quit bray90820 () 23.26.40 # pamaury: not sure what the cause is, but codecs need much higher boost frequency 23.26.51 # Bilgus: can i use any AACHE file? 23.27.09 # idk maybe? 23.27.25 # i can link you to the one i've been testing with 23.27.50 Quit amayer (Quit: Leaving) 23.28.08 # my fuze+ apparently just makes loud electronic static noises when powered on 23.28.18 # i don't think i'd ever tried using it for music actually 23.29.02 # something must be wrong with the headphone circuit 23.29.24 # :| 23.30.19 # yeah sorry 23.30.23 # i just used it for benchmarking really 23.33.40 # saratoga: how do you compare? You mean that even at top frequency the fuzev2 is faster than the fuze+? 23.34.21 # pamaury: test_codec for the same files gives much lower MHZ required for real-time decode 23.35.38 # is it an average frequency of boost/unboost? 23.35.50 # you can do it either fully boosted or fully unboosted 23.36.13 # it decodes the file as fast as possible using either setting, then gives you the % realtime and the frequency required for 100% decode 23.36.49 # I see 23.36.49 Quit Soap_ (Read error: Connection reset by peer) 23.36.58 # is it possible that the core is actually different? 23.37.16 # ie the core in amsv2 is not what we think it is? 23.37.36 # IIRC it was identified from the ARM version bits 23.37.45 # but in any case, it is some kind of ARM9E core 23.37.50 # i don't think there is much variety there 23.38.04 # i guess some difference in memory or cache is most likely 23.38.07 # could it be the ram speed? That would be the obvious difference 23.39.29 # i'm testing the files now to compare 23.40.54 # AAC-HE needs 73 MHz on AMSv2 vs. 260 MHz on Fuze+ 23.41.25 # wow that's huge 23.41.39 # is that boosted? 23.41.42 # yeah it seems like something isn't right 23.41.44 # yeah boosted 23.42.06 # huh when I ran it on my clipzip I got ~150 23.42.14 # boosted AMSv2 for AAC-HE-PS takes 92 MHz 23.42.26 # I'm pretty sure thats amsv2 23.42.27 # what mem_test plugin says? 23.42.29 # compare to bilgus here: http://forums.rockbox.org/index.php/topic,52018.msg240757.html#msg240757 23.42.41 # it might be worth checking if the auto scaling function has a negative impact 23.42.42 # Bilgus: interesting, what build? 23.43.32 # changing imx233_clkctrl_enable_auto_slow(true) to imx233_clkctrl_enable_auto_slow(false) in system-imx233.c 23.43.56 # part of the difference is due to the lower clock on AMSv2 (38 MHz and 192 MHz), so memory latency will be lower 23.44.43 # but boosted AMSv2 (192 MHz) is still way faster per clock than unboosted imx233 (64 MHz) 23.45.02 # its the multiboot build so like dev from july? 23.45.09 # huh, which file? 23.46.09 # i got 384 MHz on fuze+ a couple months ago with this file: https://download.rockbox.org/test_files/nero_hev2_64.m4a 23.46.21 # and 92 MHz just now 23.46.31 # o_O 23.46.57 # build on amsv2 is from last april 23.47.01 Quit krabador (Remote host closed the connection) 23.47.03 # stock dev build 23.47.12 # oh ok fuze+ vs amsv2 23.47.12 # but with test plugins enabled 23.47.18 # yeah 23.47.40 # wodz: i tried test_mem a while back but it didn't clear much up for me 23.47.56 *** Saving seen data "./dancer.seen" 23.48.23 # i'm not sure if the plugin is very accurate 23.50.42 # * pamaury goes to bed 23.51.08 # ill try that test file nero on the fuze+ so we get some apples to apples comparison 23.51.53 # test_mem says that boosted fuze+ memory has similar read speed but double write speed as amsv2 boosted 23.51.56 # for whatever that is worth 23.53.13 # could there be a difference due to iram? 23.53.19 # yes, likely 23.53.26 # hmm, not sure what test_mem tests 23.53.34 # the fuze+ has basically no iram 23.53.59 # ok so first it skips the same as the other one 23.55.44 # pamaury could you do a test on your fuze+ when you get a chance I'd hate to be hunting a bug that was unique to my player 23.56.36 # it tests the plugin buffer 23.57.41 # ok that file boosted decode 148.25 118.73% 383 MHZ 23.58.46 # Running unboosted now