--- Log for 08.08.119 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 17 days ago 00.00.34 # I think the backend is so complex you'd have to re run benchmarks for every code change 00.00.54 # Bilgus: Yes, I know, but for other games (or other things) it could be good estimation what's possible and what not (e.g. numnber of simultanous voices for midi) 00.01.16 # Do you think result would vary so much? 00.02.06 # for the slower targets, yeah. for the faster targets, it probably doesn't matter. 00.02.33 # every time there was less buffer it would push those slower targets further and further 00.02.43 # fast targets yeah no problem 00.03.12 # then you have IRAM-constrained targets, where even a tiny change can have a big effect if it means hot code gets put in or evicted. 00.03.58 # now some kind of sensible benchmark that runs at install maybe 00.04.30 # like do a system test with some bitcoin mining /s 00.04.58 # * speachy chuckles. 00.05.26 # the benchmark can generate a number that is "how many times faster we are than the apollo guidance computer" 00.05.31 # something that you could get some scores on cpu mem maybe disk 00.05.55 # int overflow. 00.07.04 # :) 00.07.08 # But this wouldn't make too much sense, because it would mean that we must keep everything variable (e.g. max midi voices). And if it's variable, you could set it by hand if you have problems with playback. 00.07.46 # variable = no go been there tried that 00.09.03 # best bet is probably just a good error message like sorry your device doesn't support this 00.10.08 # yep. granted, I'm sure that there are some substantial optimization opportunities available for the midi and mikmod codebases but I don't personally think optimizing that is worth the effort 00.10.13 # not to say the idea wouldn't work with your midi voices 00.10.17 # versus hardwre enablement tinkering 00.10.39 # we need a midi guy iow 00.11.51 # more like algorighm rewriting for the CPU's capabilities including handrolled asm 00.12.21 # the midi side of things is comparitively simple 00.12.34 Join krabador [0] (~krabador@unaffiliated/krabador) 00.12.59 # lua could be used to patch binaries 00.13.54 # don't know how much of my code remains in scummvm today, but I did write quite a lot of the sci0 music code.. 00.14.06 # given a nice magic set of bytes to look for it wouldn't be too hard to roll a byte patcher to change some configs 00.16.55 # ludwig von speachy? 00.17.16 # well, since the midi and mikmod plugins are now using the mixer infrastructure, it would be relatively straightforward to change the sample rate on the fly. midi voice count could be optimized to ignore unused voices or somthing like that. 00.21.29 # or, looking at the code, making the upper voice cap dynamic would be pretty easy. Not sure how we'd detect that we're running too slow though. 00.22.24 # thats the problem with being in the matrix 00.24.09 # and on that note, time to bail from here. 00.25.28 # ciao 00.25.35 Quit speachy (Remote host closed the connection) 00.27.28 Quit ZincAlloy (Quit: Leaving.) 00.30.07 # * ulmutul is going to bed now. 00.30.10 # bye! 00.30.15 Quit ulmutul (Quit: Leaving) 00.35.05 Join Saratoga [0] (185d14ef@cpe-24-93-20-239.rochester.res.rr.com) 00.35.20 # PP does use the co processor for some things, mp3 for instance splits decoding across cores 00.35.37 # Api is there if anyone wants to use it 00.38.36 # Rewriting critical loops in asm tends to help arm7/9 performance a lot, so profiling is a good idea in case there is some trivial function using a lot of time 00.39.15 Quit Saratoga (Remote host closed the connection) 00.39.29 # If you have one to test that is 00.46.22 *** Saving seen data "./dancer.seen" 01.00.12 Join bremner [0] (~bremner@debian/developer/bremner) 01.11.01 Join mendelmunkis [0] (~mendelmun@cpe-67-245-165-61.nyc.res.rr.com) 01.17.42 Quit mendelmunkis (Ping timeout: 272 seconds) 01.35.27 Quit Acou_Bass (Ping timeout: 258 seconds) 01.45.08 Join Acou_Bass [0] (~Acou_Bass@cpc97736-bolt17-2-0-cust152.10-3.cable.virginm.net) 02.43.46 Join deevious [0] (~Thunderbi@193.226.142.214) 02.46.24 *** Saving seen data "./dancer.seen" 03.11.50 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 03.24.17 Quit mendelmunkis (Ping timeout: 248 seconds) 03.34.27 Join speachy [0] (d102414d@209.2.65.77) 03.34.29 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 03.38.46 Quit krabador (Remote host closed the connection) 03.54.46 Quit mendelmunkis (Ping timeout: 272 seconds) 04.37.12 Quit yosafbridge (Quit: Leaving) 04.46.28 *** Saving seen data "./dancer.seen" 04.47.28 Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) 04.54.43 # <__builtin> Yep, ipod6g #2 is officially dead 04.54.48 # * __builtin is back to #1 04.56.38 # somewhere I have an ipod video that I inherited from an ex girlfriend. hard drive's defective. not sure if it's worth the trouble to do a flashmod to it. 04.57.01 Quit yosafbridge (Ping timeout: 244 seconds) 04.57.04 # one of the many things I have yet to find after my recent move.. 04.58.17 # * __builtin wouldn't mind some more hardware :) 04.58.19 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 04.58.58 Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) 05.01.16 # it has the CF-like connector on the hard drive. 05.05.22 # it probably eloped with my busted-screen Fuze+ 05.05.50 # Just found a Sony PSP, minus a power supply but with a Sims 2 disc in it. 05.06.20 # now that would be a fun rockbox target. :P 05.07.03 # what about my DS phat :P 05.11.25 Quit mendelmunkis (Ping timeout: 246 seconds) 05.13.02 # thing is I found the hard drive a couple of days ago. 05.13.08 # and now I can't figure out wher eI put it. 05.19.50 # just found its battery. 05.30.28 Quit TheSeven (Disconnected by services) 05.30.37 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.31.34 # iirc the DS had a woefully slow cpu 05.31.55 # <__builtin> fast enough to run Quake, apparently :) 05.32.21 # https://en.wikipedia.org/wiki/Nintendo_DS#Technical_specifications 05.32.41 # hmm. the rocker's keymap for mikmod is all jacked. 05.33.02 # 67 mhz with a 33mhz co processor I guess the co processor might be the saving grace 05.33.54 # the keymaps for the rocker were all funky probably no one recognized mikmod's 05.34.28 # the psp would be a good target for the sdl app 05.34.46 # I think somebody exposed / ran linux on it 05.34.48 # exactly! 05.35.09 # plus with actual controls it would be fun to play 05.35.50 # huh, hit an out of memory error on a couple of midi files. 05.36.12 # hell yeah minus the proprietary mem stick card duo thingie 05.37.48 # wonder what the audio hardware was like in the PSP 05.39.28 # it's basically a portable PS2, so it's pretty capable. 05.39.52 # now whether or not anyone knows how to drive anything other than basic PCM out of it is another matter. :) 05.40.16 # Wolfson Microelectronics WM8973G 05.41.03 # hih, there's a native PSP port of mikmod 05.41.34 Join eevan [0] (~eevan@tls.chat.sum7.eu) 05.42.38 # mikmod doesn't have any ARM asm. but it has ALTIVEC and SSE2 stuff 05.50.17 Quit tchan (Quit: WeeChat 2.4) 05.52.26 # you'd have thought arm would be more common than altivec well I suppose that shows its age.. 05.53.04 # yeah. guess nobody thought it was worth optimizing by the time android make arm relevant.. 05.53.52 # hmm. wonder what it will take to give the midi plugin more RAM on the Rocker. 05.55.46 # <__builtin> does it grab the audio buffer? 05.55.58 # probably 05.56.24 # I haven't dug that far into how that stuff bolts together. 05.57.27 # 1MB. 05.57.43 # this thing has plenty of RAM. time to bump it. :) 06.01.46 # how much ram does the rocker have? 06.01.58 # wonder if that will help the SDL allocation failures too 06.03.45 # <__builtin> the SDL code could use some serious cleanup... 06.05.03 # <__builtin> there's some ickery with overlay loading into the audio buffer that I haven't documented that well 06.07.21 Join tchan [0] (~tchan@c-98-206-136-82.hsd1.il.comcast.net) 06.07.21 Quit tchan (Changing host) 06.07.21 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 06.07.25 # <__builtin> ah, I remember how it works now 06.07.27 # Rocker has 32MB, with about 9MB free for OS buffers/etc. 06.07.36 # * __builtin should probably document it while he remembers it 06.09.23 # wolf3d still hangs up hard, with whatever it's doing triggering lots of -ENOMEM errors. 06.09.42 # <__builtin> do duke/quake work? 06.09.44 # plenty of OS memory free (~6MB) 06.10.00 # rebooting 06.10.27 # oh the midi still runs out of memory, but this time when it's loading drums. so it's definitely a matter of patches being too large for the available space. 06.10.40 # duke hangs too 06.10.56 # Build Server message: New build round started. Revision 1dabca6, 280 builds, 10 clients. 06.11.21 # quake too. 06.11.35 # <__builtin> all because of OOM? 06.12.04 # how are you grabbing the audio buffer are you specifying a fixed(non movable) allocation? 06.12.58 # if I believe strace the system is trying to set signal masks and getting -ENOMEM. 06.13.31 # so it might be the SDL init code that inserts its SIGSEGV etc handlers into the fray. 06.13.52 # <__builtin> Bilgus: it grabs the audio buffer subtracts it from the plugin load address (in audio buffer) to get the remaining buffer size 06.14.22 # so using the plugin.h function 06.14.33 # <__builtin> which function do you mean? 06.14.55 # <__builtin> it's doing buffer = rb->plugin_get_audio_buffer() 06.15.19 # void* (*plugin_get_audio_buffer)(size_t *buffer_size); 06.15.20 # <__builtin> and buffer_len = plugin_start_addr - buffer 06.15.42 # <__builtin> yes, it's using that, but it must subtract afterwards or else corruption might occur 06.16.11 # that should do it auytomatically? 06.16.45 # <__builtin> does it? 06.17.05 # As far as I can tell it does 06.17.26 # plugin_get_buffer is the one that needs all the reword 06.17.31 # rework* 06.17.37 # on the pointers 06.17.43 # * __builtin doesn't know... all the low-level stuff is essentially voodoo to him 06.20.00 # yeah see here this is wodz' doing https://github.com/Rockbox/rockbox/blob/master/apps/plugins/lua/tlsf_helper.c 06.21.09 # <__builtin> so no subtraction? 06.21.37 # no 06.21.59 # <__builtin> but is lua loaded as an overlay? 06.22.08 # not generally 06.22.14 # but is on some targets 06.22.36 # <__builtin> I think subtracting must be done when a plugin is an overlay + grabs audio buffer 06.23.09 # if so lua is in for a world of hurt on some targets 06.23.22 # and that code is OLDDDD 06.23.42 # I think we'd have heard something by now 06.24.03 # <__builtin> Pictureflow does the subtraction too, and plugins/lib/overlay.c hints at it 06.25.26 # hmmm that could be bad 06.25.47 # <__builtin> "If the overlayed plugin *does* use the audiobuffer itself, it needs to make sure not to overwrite itself." 06.26.37 # yeah just read that I wonder if it still is true 06.26.56 # <__builtin> some stuff has happened since that was written, I'm guessing 06.27.02 # <__builtin> there is a way we can test it, though 06.27.22 # <__builtin> load an overlay, grab audio buffer, and memset the whole thing with bogus 06.27.24 # I think the buflib stuff was after 2006\ 06.27.50 # <__builtin> if buflib/whatever isn't adjusting for the overlay then we'll get a crash 06.28.19 Quit Jinx (Ping timeout: 248 seconds) 06.30.01 # it would almost have to not I mean how would it decide that something was loaded as an ovl? 06.30.25 # <__builtin> buflib *magic*? 06.30.33 # Build Server message: Build round completed after 1177 seconds. 06.30.35 # Build Server message: Revision 1dabca6 result: All green 06.32.40 # buflib is magical but it isn't that magical lol 06.35.22 # * __builtin really needs some sleep 06.35.30 # <__builtin> g'night! 06.36.44 # night 06.38.13 Join Jinx [0] (~Jinx@unaffiliated/jinx) 06.46.30 *** Saving seen data "./dancer.seen" 07.11.32 # Build Server message: New build round started. Revision d61ea6c, 280 builds, 11 clients. 07.26.36 # Build Server message: Build round completed after 904 seconds. 07.26.37 # Build Server message: Revision d61ea6c result: All green 08.21.10 Quit flabrus (Quit: #InstallGentoo) 08.23.08 Join flabrus [0] (~beard@flab.tech) 08.23.08 Quit flabrus (Changing host) 08.23.08 Join flabrus [0] (~beard@unaffiliated/flabrus) 08.26.27 Quit [7] (Ping timeout: 264 seconds) 08.28.48 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 08.39.03 Quit TheSeven (Ping timeout: 264 seconds) 08.40.31 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 08.46.32 *** Saving seen data "./dancer.seen" 09.04.38 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.05.32 Join petur [0] (~petur@80.169.83.226) 09.05.32 Quit petur (Changing host) 09.05.32 Join petur [0] (~petur@rockbox/developer/petur) 10.31.45 Quit wodz (Ping timeout: 258 seconds) 10.46.35 *** Saving seen data "./dancer.seen" 12.46.37 *** No seen item changed, no save performed. 13.45.30 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 14.28.46 Quit dys (Ping timeout: 245 seconds) 14.32.06 Join massiveH [0] (~massiveH@ool-4352e615.dyn.optonline.net) 14.40.42 Quit deevious (Quit: deevious) 14.41.29 # Build Server message: New build round started. Revision 8d77ec8, 280 builds, 11 clients. 14.46.39 *** Saving seen data "./dancer.seen" 14.58.15 # Build Server message: Build round completed after 1006 seconds. 14.58.16 # Build Server message: Revision 8d77ec8 result: 545 errors 0 warnings 15.05.40 # every time we're almost fully green, something comes along and goes BOOM. 15.06.23 # this time it wasn't me! :) 15.08.41 # one-line fix 15.09.20 # Build Server message: New build round started. Revision a430e27, 280 builds, 11 clients. 15.14.20 Quit speachy (Remote host closed the connection) 15.23.27 Join deevious [0] (~Thunderbi@193.226.142.214) 15.24.32 # Build Server message: Build round completed after 911 seconds. 15.24.33 # Build Server message: Revision a430e27 result: All green 15.45.18 Join speachy [0] (40eebded@64.238.189.237) 15.50.27 Quit wodz (Ping timeout: 272 seconds) 16.04.36 Quit massiveH (Quit: Leaving) 16.08.02 Quit mikroflops (Ping timeout: 248 seconds) 16.46.41 *** Saving seen data "./dancer.seen" 16.48.38 # <__builtin> speachy: Bilgus: have either of you received your stickers? 16.51.02 # not as of yesterday but since it has to be forwarded it will be a few extra days 16.56.26 Quit petur (Quit: Connection reset by beer) 17.03.50 Join mikroflops [0] (~yogurt@188.150.209.46) 17.04.07 # finally got my Model M keyboard plugged in at $dayjob 17.05.29 # it's been with me my whole career. :) 18.41.48 Join dys [0] (~dys@tmo-104-224.customers.d1-online.com) 18.45.58 Join ZincAlloy [0] (~Adium@ip5f5acea4.dynamic.kabel-deutschland.de) 18.46.44 *** Saving seen data "./dancer.seen" 18.51.46 Quit Jinx (Ping timeout: 248 seconds) 19.25.49 Join lebellium [0] (~lebellium@89-92-69-110.hfc.dyn.abo.bbox.fr) 19.32.18 # __builtin I'll look tonight 20.14.19 Join MrZeus [0] (~MrZeus@2a02:c7f:70d4:cd00:d87c:7c80:5c8e:1cdb) 20.36.19 Quit dys (Ping timeout: 268 seconds) 20.46.45 *** Saving seen data "./dancer.seen" 21.18.55 Join dys [0] (~dys@tmo-106-21.customers.d1-online.com) 21.50.20 Join ulmutul [0] (~ulmutul@rockbox/developer/ulmutul) 21.51.30 Quit pixelma (Quit: .) 21.51.30 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 21.52.43 Join amiconn [0] (jens@rockbox/developer/amiconn) 21.52.43 Join pixelma [0] (marianne@rockbox/staff/pixelma) 21.58.39 # speachy: g#2214 looks good so far exept for the typo in midiutil.h line 51. I haven't tried it out however. 21.58.41 # Gerrit review #2214 at http://gerrit.rockbox.org/r/2214 : Introduce HW_SAMPR_MIN_GE_22 macro by Solomon Peachy 21.59.36 # whoops. missed that one.. 21.59.46 # I didn't build test every permutation 22.00.50 # new version uploaded 22.01.52 # I've tried out several mikmod files and all played flawless on my PP target. However it's hard to find "the most challenging one"(TM) 22.03.00 # I also repeated the midi frequency analysis test with the old code. 22kHz looks now exactly like expected. Let me upload the picture... 22.04.38 # It's here: https://pasteboard.co/IrMUMk4.png 22.05.00 # some of the tracker files out of deux ex ought to be stressful 22.05.06 # but.. they probably are too large to load. :) 22.11.25 # I'll give it a whirl. 22.11.52 # that new 22K target looks like I'd expect, yeah 22.12.01 # that dip on the 44K target is interesting 22.12.44 # is it a function of the particular midi file or instruments? I wonder if a HPF is warranted.. 22.19.49 # Maybe related to the original sampling frequency of the patch set. If I try another MIDI files it looks similar, but not as symmetric. I think this is because the displayed one is drums only, and these samples are always played as-is and not pitched higher or lower. 22.21.29 # well, one of these 26-channel 2MB IT files doesn't bring the rocker to its knees. 22.22.44 # appears to suck down about 75% of the system resources 22.23.13 # with reverb & interpolation @ 44K. 22.24.27 # but this thing has a 1GHz MIPS core in it. 22.24.35 # probably the most powerful DAP rockbox runs on.. 22.29.04 # Hm, can't complain. Deus Ex title song takes ages to load, but plays fine (1.8MB and 23 channels max). 22.29.21 # Is "channels" in IT files the number of voices? 22.30.30 # yeah, number of active/max voices. 22.31.14 # huh, the rocker has a dbus broker running 22.31.38 # and hte filesystem has mkfs.ext2/3/4 but not the library they depend on. 22.35.08 # wifi and airport support too 22.37.40 # Build Server message: New build round started. Revision 5b23c9e, 280 builds, 12 clients. 22.38.37 # merged the patch in. Now I'll find if I missed any permutation... 22.46.47 *** Saving seen data "./dancer.seen" 22.57.10 # Build Server message: Build round completed after 1170 seconds. 22.57.11 # Build Server message: Revision 5b23c9e result: 157 errors 0 warnings 22.57.30 # oh jeez. 23.04.50 # Build Server message: New build round started. Revision 7737327, 280 builds, 12 clients. 23.07.29 Quit speachy (Remote host closed the connection) 23.11.55 Quit lebellium (Quit: Leaving) 23.16.13 Quit ZincAlloy (Quit: Leaving.) 23.21.16 # Build Server message: Build round completed after 986 seconds. 23.21.17 # Build Server message: Revision 7737327 result: All green