--- Log for 07.08.119 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 16 days ago 00.45.45 *** Saving seen data "./dancer.seen" 00.53.32 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 01.08.14 Join krabador [0] (~krabador@unaffiliated/krabador) 01.14.59 Quit mendelmunkis (Ping timeout: 272 seconds) 02.45.48 *** Saving seen data "./dancer.seen" 02.46.33 Join Bilgus [0] (~Bilgus@unaffiliated/bilgus) 03.32.32 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 04.05.33 Quit mendelmunkis (Ping timeout: 258 seconds) 04.11.51 Quit krabador (Remote host closed the connection) 04.45.51 *** Saving seen data "./dancer.seen" 05.31.29 Quit TheSeven (Ping timeout: 250 seconds) 05.31.38 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.43.30 Quit Jinx (Ping timeout: 248 seconds) 05.44.31 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 05.53.24 Join Jinx [0] (~Jinx@unaffiliated/jinx) 05.55.12 Quit mendelmunkis (Ping timeout: 268 seconds) 06.45.54 *** Saving seen data "./dancer.seen" 07.03.06 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 07.09.19 Quit mendelmunkis (Ping timeout: 244 seconds) 07.15.03 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 07.18.32 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:109c:6f45:1fc8:500) 07.21.49 Quit mendelmunkis (Ping timeout: 258 seconds) 07.23.07 Quit ZincAlloy (Ping timeout: 252 seconds) 07.39.54 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 08.16.15 Quit [7] (Ping timeout: 264 seconds) 08.18.03 Quit mendelmunkis (Ping timeout: 246 seconds) 08.24.54 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 08.45.57 *** Saving seen data "./dancer.seen" 09.01.28 Join petur [0] (~petur@80.169.83.226) 09.01.28 Quit petur (Changing host) 09.01.28 Join petur [0] (~petur@rockbox/developer/petur) 09.02.24 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.13.57 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 09.21.45 Quit mendelmunkis (Ping timeout: 246 seconds) 09.55.54 Join ZincAlloy [0] (~Adium@ip5f5acea4.dynamic.kabel-deutschland.de) 10.00.02 Quit ZincAlloy (Ping timeout: 245 seconds) 10.24.22 Join _Bilgus [0] (~Bilgus@unaffiliated/bilgus) 10.28.31 Quit Bilgus (Ping timeout: 272 seconds) 10.33.06 Quit dys (Ping timeout: 248 seconds) 10.39.56 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 10.46.01 *** Saving seen data "./dancer.seen" 11.00.19 Quit mendelmunkis (Ping timeout: 258 seconds) 11.57.54 Join ZincAlloy [0] (~Adium@ip5f5acea4.dynamic.kabel-deutschland.de) 12.02.07 Quit ZincAlloy (Ping timeout: 245 seconds) 12.33.44 Join vmx [0] (~vmx@ip5f5ac62a.dynamic.kabel-deutschland.de) 12.33.50 Quit wodz (Remote host closed the connection) 12.34.18 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 12.46.05 *** Saving seen data "./dancer.seen" 12.47.01 Join dys [0] (~dys@tmo-081-71.customers.d1-online.com) 12.54.02 Join feet0fclay [0] (8d62ff99@141.98.255.153) 12.54.08 # ping 12.54.15 Part feet0fclay 13.14.29 # <_Bilgus> pong the last leg of that journey has terrible latency 13.15.15 # * gevaerts doesn't like contextless pings on irc (or anywhere, really, except for icmp ones) 14.02.00 Join massiveH [0] (~massiveH@ool-4352e615.dyn.optonline.net) 14.07.27 Join krabador [0] (~krabador@unaffiliated/krabador) 14.46.09 *** Saving seen data "./dancer.seen" 14.58.42 Quit wodz (Ping timeout: 248 seconds) 15.44.49 Quit massiveH (Quit: Leaving) 15.49.49 Join speachy [0] (40eebded@64.238.189.237) 15.55.11 # Build Server message: New build round started. Revision 2ebb8da, 280 builds, 10 clients. 16.10.16 Quit michaelni (Ping timeout: 244 seconds) 16.19.58 # Build Server message: Build round completed after 1487 seconds. 16.19.59 # Build Server message: Revision 2ebb8da result: All green 16.21.23 # Build Server message: New build round started. Revision b1f2c79, 280 builds, 10 clients. 16.21.58 Part bremner ("Using Circe, the loveliest of all IRC clients") 16.23.24 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 16.26.32 # * speachy continues to do his part to grow the binary size. 16.32.39 Quit krabador (Remote host closed the connection) 16.44.59 # Build Server message: Build round completed after 1416 seconds. 16.45.00 # Build Server message: Revision b1f2c79 result: All green 16.46.11 *** Saving seen data "./dancer.seen" 16.47.12 # Plugins really should have their own independent language files. But that's a pretty thorny technical problem.. 17.02.28 # Build Server message: New build round started. Revision 5ace14b, 280 builds, 11 clients. 17.23.26 # Build Server message: New build round started. Revision 4b12b68, 280 builds, 11 clients. 17.34.03 Quit petur (Read error: Connection reset by peer) 17.43.05 # Build Server message: Build round completed after 1178 seconds. 17.43.06 # Build Server message: Revision 4b12b68 result: All green 17.45.48 # yikes.. didn't expect a translation-only commit to bump the memory size by 3k. 17.48.25 # That's an interesting one 17.52.21 # But yes, apparently Russian is the biggest language now, with a margin of around 3k 17.57.17 # Languages that aren't mostly-ascii "win" here by a fair margin 17.58.26 Quit Jinx (Ping timeout: 248 seconds) 18.00.34 # * gevaerts wonders about that commit. Many strings are now longer, which can be bad on small screens 18.02.26 # speachy: is this the first of the non-western-european language updates that does plugins? 18.04.37 # Basically assume that any English string-based increase will be doubled as soon as non-western catches up 18.08.22 Join Jinx [0] (~Jinx@unaffiliated/jinx) 18.10.11 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:3d13:394b:b3bf:f9) 18.14.40 Quit ZincAlloy (Ping timeout: 252 seconds) 18.23.45 # yeah, Russian is the first translation that has any strings for the plugins 18.26.03 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:3d13:394b:b3bf:f9) 18.26.14 # So I take it that the "string size" basically is a max(each string, each language) affair? 18.26.37 # It is, yes 18.27.44 # been idly thinking how to pull per-plugin strings out of the core, but it keeps descending into madness. 18.27.59 # Well, I don't know exactly how it works. I think it's basically the largest languages regardless of how strings are distributed, but it could be a max per string 18.30.01 # * speachy nods. 18.30.29 # since the string table is an array of pointers into the buffer, I guess that's reasonable. 18.33.25 Quit vmx (Remote host closed the connection) 18.36.07 # with respect to the longer strings thing, IIRC the primary target for the RUS translation is actually the X3, which has a tiny monochrome screen. 18.36.36 # s/translation/translator/ 18.46.14 *** Saving seen data "./dancer.seen" 19.07.10 # I actually noticed it with a remote: string 19.13.42 Join lebellium [0] (~lebellium@89-92-69-110.hfc.dyn.abo.bbox.fr) 19.19.38 # <_Bilgus> hey gevaerts thanks for being a Rb pok`e-zagor facilitator 19.22.40 # I just noticed that he was there :) 19.27.46 Join bremner [0] (~bremner@debian/developer/bremner) 19.49.45 Quit danielp3344 (Quit: irc_error) 19.49.53 Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-viaguktfydiojeup) 20.07.37 # Build Server message: New build round started. Revision cd77d92, 280 builds, 11 clients. 20.22.35 # Build Server message: Build round completed after 897 seconds. 20.22.36 # Build Server message: Revision cd77d92 result: All green 20.46.17 *** Saving seen data "./dancer.seen" 20.51.45 # how do i check the current status of specific translation, and is there a tool to help translating? 20.56.05 # also, i have a bulgarian translation of the sansa clip plus manual in bulgarian, not sure how to integrate it in the current source files 20.56.33 # s/in bulgarian// 20.58.47 Join ulmutul [0] (~ulmutul@rockbox/developer/ulmutul) 21.00.07 # <__builtin> There's a web-based tool somewhere on the site 21.01.44 # <__builtin> http://translate.rockbox.org/ 21.05.14 Quit deevious (Ping timeout: 246 seconds) 21.05.43 # yeah, the web tool is a good staring point. Bulgarian is in pretty good shape, but doens't have the newest additions. 21.10.28 # We don't have any infrastructure for translations of the manual, unfortunately 21.23.00 # * ulmutul frowns at people who think that a higher higher sampling rate equates higher quality 21.24.41 # speachy: I deplore the bump to 44kHz for the MIDI plugin, because it actually inhibits better sound quality on slower targets. 21.25.58 # IMO the number of simultaneous voices should be increased for PP targets (it works with 24 voices - the GM minimum - and 22kHz, but chokes extremely with 44kHz) 21.26.27 Quit tchan (Ping timeout: 244 seconds) 21.29.29 # The comments in midiutil.h states that the number of voices was reduced because higher numbers can't be handled with 44 kHz. The better way would be to reduce the number of voices only for those targets that can't handle 22kHz (only slow targets, of course). 21.31.34 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 21.36.14 Quit ArneB (Disconnected by services) 21.36.15 Join ps-auxw [0] (~arneb@p548D5F17.dip0.t-ipconnect.de) 21.36.43 # A propos sound quality: somebody here who can interpret a FFT frequency analysis? I recorded the MIDI output from one rockbox target into the line out of another one and checked the output with audacity's frequency analyser. I hoped to find the actual sample frequency of our patchset, but I was a bit puzzled when I recorded the same thing with 22kHz output frequency. 21.37.00 # Here's the graphic: https://pasteboard.co/IrD9cXH.png 21.37.56 # The top picture shows the frequency analysis of the 22kHz output, the lower picture the output of 44kHz MIDI. 21.40.45 # The mimi file was some sort of drum loop as I expected it to have a lot of high frequencies from HiHat and Cymbals. Recording was done with 44kHz. As you can see, the files are not equally levelled. 21.42.13 # The drop off in the lower picture (midi playback @ 44kHz!) is at ~14kHz. 21.43.18 # (and the absolute zero dip at around 16kHz IIRC) 21.44.07 # hey, it's good to have feedback. 21.44.15 Quit ps-auxw (Disconnected by services) 21.44.26 Join ps-auxw [0] (~arneb@p548D5F6B.dip0.t-ipconnect.de) 21.46.37 # if we can come up with some sort of heuristic to determine what is "fast" vs "slow" I can put that into the code. One could claim it should be configurable but I'd really prefer to have it be "highest quality possible for the target" 21.54.10 # I'd like to have something like a "bogomips" define for the targets :) I don't like the "if this processor or that core" either. I would declare the ARM7TDMI (PortalPlayer; I don't know if we have others) targets as slow, as well as maybe Coldfire ones (I don't own any of these). 21.55.44 # Coldfire is probably the slowest we have, yeah. AMD7TDMI depends mostly on the clock speed. Does rockbox still only use one core of the PP SoC? 21.56.21 # <__builtin> I know it's possible to run threads on the coprocessor. 21.56.32 # <__builtin> Not sure if it's actually used, though 21.57.04 # Another change that hurts performance is that the MOD and MIDI plugins get routed through the "DSP/Mixer" 21.57.40 # As for "highest quality": in terms of midi I think the playback frequency is the least hearable parameter. As I stated the number of simultanueous voices is much more important. I also notices clicky artefacts during playback (I suspect controler events). 21.57.49 # which allows full hookup to the rockbox audio pipeline.. 21.58.01 # with EQ and other benefits. 22.02.33 # BTW, I question the FFT analysis a bit -- with a 22KHz output rate, anything over 11KHz is going to be pretty crummy. 22.02.46 # I don't think this hurts too much (no objections against it) (and if you don't use the DSP effects of course. But you can switch them off if performance drops too much). I compiled with 22kHz setting and 24 Voices enabled, and had only 1 short drop (with your patch otherwise). The same file with 44kHz was plain unlistenable. With your patch as-is (44kHz but only 16 voices enabled) I didn't hear any audio drops, but it sounded like crap, 22.02.46 # because some voices got cut off, even destroing melody lines. Target is PP5020 btw. 22.02.54 Part bremner ("Using Circe, the loveliest of all IRC clients") 22.06.04 # Yes, that frequency analysis puzzled me also... I would doubt myself and think I'd switched both frequencies if not the 44kHz one dropps down at 16kHz instead of the expected 11. 22.06.59 Quit speachy (Remote host closed the connection) 22.07.17 # The crazy stuff beyond 16 kHz is by the way the mirror of the frequency below, mirrored at more or less exactly 16.5 kHz (is easily visible in audacity in linear mode) 22.08.04 Join speachy [0] (40eebded@64.238.189.237) 22.08.07 # * speachy wonders how the SDL-based timidity port compares, performance-wise... 22.08.21 # * __builtin doesn't want to know 22.08.35 # <__builtin> I've put exactly zero optimization work into it 22.08.47 # sound quality is probably better, even with the same patch set. 22.08.56 # <__builtin> it's only used by Duke3D to play the in-game music, I think 22.10.22 # so 24 channels @22KHz is the baseline. next step would be to bump to 32 channels, and after that, bump to higher sampling freq? 22.10.45 # to this day I use two Duke3D files to compare midi synths. :) 22.12.42 # oh, can you tell if the mikmod plugin suffers the same way with respect to performance on your PP5020? 22.14.32 # I never used it, but sure. 22.15.09 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 22.16.14 # And: yes, as 24 voices are the minimum for GM standard I would definitely go for this first. "Slow" targets that can't handle 22kHz should reduce it to 16 (like before), and fast ones can do whatever they want :) 22.16.53 # everything I have here varies between "fast" and "very fast" :) 22.17.23 # * __builtin thinks his ipod6g is dying 22.17.42 # <__builtin> weird clicking noises and extremely slow file transfers :( 22.18.33 # BTW it would be nice if we could disable DSP time stretch and pitch for MIDI and let this do the midi engine for free. 22.18.52 # even today you don't tend to see tracker files over 16 channels. 22.19.35 # * ulmutul has mostly PP5020 targets, and only a few fast ones. Namely Fuze+, Creative Zen and recently iPod 6G 22.21.18 # heh, the sim build targets 48 voices. don't think I've ever seen a GM synth that goes over 32 voices on a single MIDI bus. 22.21.47 # meaning we're not likely to see any midi files actually take advantage of the additional voices 22.23.33 # Don't confuse voices with midi channels. You can have dozens of voices in one channel. 22.23.51 # I'm not. 22.26.33 # by the time the DOS era came to an end, synths with >32 voices were still rare. 22.28.53 # Any midi file targeting polyphony that high is all but guaranteed to use synth-specific sysex or whatnot, which probably won't play well on a generic patchset. 22.29.47 # heh. an exercise in masochism would be to port the mt-32 emulator to rockbox. 22.34.11 Quit dys (Ping timeout: 268 seconds) 22.34.13 # * __builtin has been thinking about porting g++ 22.35.45 Quit mendelmunkis (Ping timeout: 248 seconds) 22.37.13 # <__builtin> we could then "easily" get ScummVM and DOSBox 22.37.24 # <__builtin> especialyl since we've already got an SDL port 22.37.52 # Without a native screen >= 320x200 there's probably no point. 22.42.28 # <_Bilgus> __builtin, are you still spinning rust in your 6G? 22.42.41 # <__builtin> yep, clicks and all :) 22.42.59 # * __builtin has two 6Gs, actually 22.44.58 # __builtin, speaking of sampling rates, using HW_SAMPR_MIN where _22 isn't available might result in 8KHz instead. 22.45.12 # <__builtin> in SDL? 22.46.01 # yeah, looks like at least some of the PP targets go from 32 to 8. 22.46.18 *** Saving seen data "./dancer.seen" 22.46.33 # but they don't support color anyway so no SDL. 22.47.21 # <__builtin> My idea was to fall back to HW_SAMPR_MIN if it's greater than 22 22.48.21 # <__builtin> I suppose if HW_SAMPR_MIN is less than 22 it should pick the greatest rate < 22 22.48.53 # yeah, that's what I was wanting to do with the midi/mikmod plugins too. 22.49.16 Join dys [0] (~dys@tmo-096-141.customers.d1-online.com) 22.49.35 # <__builtin> that means a bunch of macro ickery, though 22.50.11 # eh, I'll hack something together. 22.50.32 # * speachy is still waiting on Xilinx tools to ... very... slowly... "work" ... 22.56.45 # <_Bilgus> speachy I think pulling plugin lang strings out of core is going to not too bad, unfortunately you need them to be in ram and the plugin buffer needs to be known at compile time so youl'll have to probably malloc a place for them out of the playback buffer 22.57.01 # <_Bilgus> to be not too bad* 22.58.38 # <_Bilgus> I guess it'd have to be the end of the PB buffer not the front to not break it 22.59.27 # so I now have a HW_SAMPR_MIN_QUAL macro defined. aka 22KHz or better. 23.03.06 # <__builtin> speachy: or the greatest rate less than 22? 23.08.40 # minimum rate at least 22 23.15.55 # think there's any point in using >22 for SDL on fast targets? 23.17.34 # * __builtin doesn't think so 23.17.53 # <__builtin> all SDL plays is explosions and screams :P 23.19.54 # okay, g#2214 23.19.56 # Gerrit review #2214 at http://gerrit.rockbox.org/r/2214 : Introduce HW_SAMPR_MIN_QUAL macro (DO NOT MERGE YET) by Solomon Peachy 23.20.07 # it compiles, therefore it's good. 23.21.19 # one assumption I made is that all targets support 44KHz as the highest MIN rate. 23.21.24 # <_Bilgus> huh is that all it takes? 23.22.25 # yep, a whopping +16 in pcm_sampr.h 23.22.35 # <_Bilgus> ulmutul, does your pp play opus? 23.22.41 # * _Bilgus suspects not 23.23.14 # could probably be done in fewer lines if I wanted to consolidate the HW_SAMPR_MIN and _QUAL decision macros into a meta-macro 23.23.25 # Hm, I think I never tried. 23.23.39 # * ulmutul is looking for test files on the rockbox site. 23.24.21 # <_Bilgus> I think there are a few 23.28.15 # <_Bilgus> http://download.rockbox.org/test_files/ 23.28.31 # <_Bilgus> I'm so tired of hearing those test tracks lol 23.29.16 # kinda how I feel about printing color targets. :P 23.33.15 # ulmutul, if you're feeling inclined, give 2214 a whirl and see if it is acceptible on your slow PPs. 23.35.32 # dmesg 23.36.58 # * user890104 just discovered mikmod in rockbox 23.43.36 # All opus files play fine except for "opus_64k_5ms". 23.44.46 # <_Bilgus> does it skip crash or other? 23.44.59 # And yes, I'll try g#2214, but maybe tomorrow, it's getting late here and my players are not the only slow things that I have ;) 23.45.00 # Gerrit review #2214 at http://gerrit.rockbox.org/r/2214 : Introduce HW_SAMPR_MIN_QUAL macro (DO NOT MERGE YET) by Solomon Peachy 23.45.28 # <_Bilgus> thanks for playin :P 23.45.30 # I'll probably have another revision by then anyway. 23.45.46 # It plays with dropouts every few seconds. 23.46.14 # <_Bilgus> ok so strictly a lack of cycles 23.49.06 # What do you think about some kind of benchmark for rockbox and hardcode the result in the config files? Maybe we could use some of the demos, this would give them some meaning :) 23.49.26 Quit lebellium (Quit: Leaving) 23.54.02 Join Bilgus [0] (~Bilgus@unaffiliated/bilgus) 23.55.22 # it's a thought. 23.55.45 # * Bilgus thinks thats an idea prone to failure personally but I suspect thats aimed at speachy 23.56.28 # This could also be used for boomshine :) 23.56.30 # we already have a benchmark, codec_bench. 23.56.49 # <__builtin> Just using CPUFREQ is probably good enough for coarse stuff 23.56.51 # midi/mikmod don't fall under the codec framework so we can't use them there.. 23.57.19 Quit _Bilgus (Ping timeout: 258 seconds) 23.57.50 # I already have a benchmark in it that decideds how much to slow it down and a patch that obivates the need for it as far as I can tell 23.58.24 # Results may change if a codec is updated, but otherwise it should be good enough. We could pick a number from the codec comparison table (e.g. mp3 128).