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).

#rockbox log for 2019-08-07

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:00
01:08:14 Join krabador [0] (~krabador@unaffiliated/krabador)
01:14:59 Quit mendelmunkis (Ping timeout: 272 seconds)
02:00
02:45:48***Saving seen data "./dancer.seen"
02:46:33 Join Bilgus [0] (~Bilgus@unaffiliated/bilgus)
03:00
03:32:32 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com)
04:00
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:00
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:00
06:45:54***Saving seen data "./dancer.seen"
07:00
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:00
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:00
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
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
11:00:19 Quit mendelmunkis (Ping timeout: 258 seconds)
11:57:54 Join ZincAlloy [0] (~Adium@ip5f5acea4.dynamic.kabel-deutschland.de)
12:00
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:08feet0fclayping
12:54:15 Part feet0fclay
13:00
13:14:29_Bilguspong 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:00
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:00
15:44:49 Quit massiveH (Quit: Leaving)
15:49:49 Join speachy [0] (40eebded@64.238.189.237)
15:55:11fs-bluebotBuild Server message: New build round started. Revision 2ebb8da, 280 builds, 10 clients.
16:00
16:10:16 Quit michaelni (Ping timeout: 244 seconds)
16:19:58fs-bluebotBuild Server message: Build round completed after 1487 seconds.
16:19:59fs-bluebotBuild Server message: Revision 2ebb8da result: All green
16:21:23fs-bluebotBuild 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:59fs-bluebotBuild Server message: Build round completed after 1416 seconds.
16:45:00fs-bluebotBuild Server message: Revision b1f2c79 result: All green
16:46:11***Saving seen data "./dancer.seen"
16:47:12speachyPlugins really should have their own independent language files. But that's a pretty thorny technical problem..
17:00
17:02:28fs-bluebotBuild Server message: New build round started. Revision 5ace14b, 280 builds, 11 clients.
17:23:26fs-bluebotBuild 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:05fs-bluebotBuild Server message: Build round completed after 1178 seconds.
17:43:06fs-bluebotBuild Server message: Revision 4b12b68 result: All green
17:45:48speachyyikes.. didn't expect a translation-only commit to bump the memory size by 3k.
17:48:25gevaertsThat's an interesting one
17:52:21gevaertsBut yes, apparently Russian is the biggest language now, with a margin of around 3k
17:57:17gevaertsLanguages that aren't mostly-ascii "win" here by a fair margin
17:58:26 Quit Jinx (Ping timeout: 248 seconds)
18:00
18:00:34*gevaerts wonders about that commit. Many strings are now longer, which can be bad on small screens
18:02:26gevaertsspeachy: is this the first of the non-western-european language updates that does plugins?
18:04:37gevaertsBasically 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:45speachyyeah, 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:14speachySo I take it that the "string size" basically is a max(each string, each language) affair?
18:26:37gevaertsIt is, yes
18:27:44speachybeen idly thinking how to pull per-plugin strings out of the core, but it keeps descending into madness.
18:27:59gevaertsWell, 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:29speachysince 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:07speachywith 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:36speachys/translation/translator/
18:46:14***Saving seen data "./dancer.seen"
19:00
19:07:10gevaertsI 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_Bilgushey gevaerts thanks for being a Rb pok`e-zagor facilitator
19:22:40gevaertsI 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:00
20:07:37fs-bluebotBuild Server message: New build round started. Revision cd77d92, 280 builds, 11 clients.
20:22:35fs-bluebotBuild Server message: Build round completed after 897 seconds.
20:22:36fs-bluebotBuild Server message: Revision cd77d92 result: All green
20:46:17***Saving seen data "./dancer.seen"
20:51:45user890104how do i check the current status of specific translation, and is there a tool to help translating?
20:56:05user890104also, 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:33user890104s/in bulgarian//
20:58:47 Join ulmutul [0] (~ulmutul@rockbox/developer/ulmutul)
21:00
21:00:07__builtinThere's a web-based tool somewhere on the site
21:01:44__builtinhttp://translate.rockbox.org/
21:05:14 Quit deevious (Ping timeout: 246 seconds)
21:05:43speachyyeah, the web tool is a good staring point. Bulgarian is in pretty good shape, but doens't have the newest additions.
21:10:28gevaertsWe 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:41ulmutulspeachy: I deplore the bump to 44kHz for the MIDI plugin, because it actually inhibits better sound quality on slower targets.
21:25:58ulmutulIMO 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:29ulmutulThe 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:43ulmutulA 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:00ulmutulHere's the graphic: https://pasteboard.co/IrD9cXH.png
21:37:56ulmutulThe top picture shows the frequency analysis of the 22kHz output, the lower picture the output of 44kHz MIDI.
21:40:45ulmutulThe 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:13ulmutulThe drop off in the lower picture (midi playback @ 44kHz!) is at ~14kHz.
21:43:18ulmutul(and the absolute zero dip at around 16kHz IIRC)
21:44:07speachyhey, 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:37speachyif 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:10ulmutulI'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:44speachyColdfire 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__builtinI know it's possible to run threads on the coprocessor.
21:56:32__builtinNot sure if it's actually used, though
21:57:04speachyAnother change that hurts performance is that the MOD and MIDI plugins get routed through the "DSP/Mixer"
21:57:40ulmutulAs 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:49speachywhich allows full hookup to the rockbox audio pipeline..
21:58:01speachywith EQ and other benefits.
22:00
22:02:33speachyBTW, I question the FFT analysis a bit −− with a 22KHz output rate, anything over 11KHz is going to be pretty crummy.
22:02:46ulmutulI 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:46ulmutulbecause 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:04ulmutulYes, 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:17ulmutulThe 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__builtinI've put exactly zero optimization work into it
22:08:47speachysound quality is probably better, even with the same patch set.
22:08:56__builtinit's only used by Duke3D to play the in-game music, I think
22:10:22speachyso 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:45speachyto this day I use two Duke3D files to compare midi synths. :)
22:12:42speachyoh, can you tell if the mikmod plugin suffers the same way with respect to performance on your PP5020?
22:14:32ulmutulI never used it, but sure.
22:15:09 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com)
22:16:14ulmutulAnd: 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:53speachyeverything I have here varies between "fast" and "very fast" :)
22:17:23*__builtin thinks his ipod6g is dying
22:17:42__builtinweird clicking noises and extremely slow file transfers :(
22:18:33ulmutulBTW 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:52speachyeven 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:18speachyheh, 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:47speachymeaning we're not likely to see any midi files actually take advantage of the additional voices
22:23:33ulmutulDon't confuse voices with midi channels. You can have dozens of voices in one channel.
22:23:51speachyI'm not.
22:26:33speachyby the time the DOS era came to an end, synths with >32 voices were still rare.
22:28:53speachyAny 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:47speachyheh. 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__builtinwe could then "easily" get ScummVM and DOSBox
22:37:24__builtinespecialyl since we've already got an SDL port
22:37:52speachyWithout 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__builtinyep, clicks and all :)
22:42:59*__builtin has two 6Gs, actually
22:44:58speachy__builtin, speaking of sampling rates, using HW_SAMPR_MIN where _22 isn't available might result in 8KHz instead.
22:45:12__builtinin SDL?
22:46:01speachyyeah, looks like at least some of the PP targets go from 32 to 8.
22:46:18***Saving seen data "./dancer.seen"
22:46:33speachybut they don't support color anyway so no SDL.
22:47:21__builtinMy idea was to fall back to HW_SAMPR_MIN if it's greater than 22
22:48:21__builtinI suppose if HW_SAMPR_MIN is less than 22 it should pick the greatest rate < 22
22:48:53speachyyeah, 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__builtinthat means a bunch of macro ickery, though
22:50:11speachyeh, I'll hack something together.
22:50:32*speachy is still waiting on Xilinx tools to ... very... slowly... "work" ...
22:56:45_Bilgusspeachy 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_Bilgusto be not too bad*
22:58:38_BilgusI guess it'd have to be the end of the PB buffer not the front to not break it
22:59:27speachyso I now have a HW_SAMPR_MIN_QUAL macro defined. aka 22KHz or better.
23:00
23:03:06__builtinspeachy: or the greatest rate less than 22?
23:08:40speachyminimum rate at least 22
23:15:55speachythink there's any point in using >22 for SDL on fast targets?
23:17:34*__builtin doesn't think so
23:17:53__builtinall SDL plays is explosions and screams :P
23:19:54speachyokay, g#2214
23:19:56fs-bluebotGerrit review #2214 at http://gerrit.rockbox.org/r/2214 : Introduce HW_SAMPR_MIN_QUAL macro (DO NOT MERGE YET) by Solomon Peachy
23:20:07speachyit compiles, therefore it's good.
23:21:19speachyone assumption I made is that all targets support 44KHz as the highest MIN rate.
23:21:24_Bilgushuh is that all it takes?
23:22:25speachyyep, a whopping +16 in pcm_sampr.h
23:22:35_Bilgusulmutul, does your pp play opus?
23:22:41*_Bilgus suspects not
23:23:14speachycould 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:25ulmutulHm, I think I never tried.
23:23:39*ulmutul is looking for test files on the rockbox site.
23:24:21_BilgusI think there are a few
23:28:15_Bilgushttp://download.rockbox.org/test_files/
23:28:31_BilgusI'm so tired of hearing those test tracks lol
23:29:16speachykinda how I feel about printing color targets. :P
23:33:15speachyulmutul, if you're feeling inclined, give 2214 a whirl and see if it is acceptible on your slow PPs.
23:35:32speachydmesg
23:36:58*user890104 just discovered mikmod in rockbox
23:43:36ulmutulAll opus files play fine except for "opus_64k_5ms".
23:44:46_Bilgusdoes it skip crash or other?
23:44:59ulmutulAnd 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:00fs-bluebotGerrit 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_Bilgusthanks for playin :P
23:45:30speachyI'll probably have another revision by then anyway.
23:45:46ulmutulIt plays with dropouts every few seconds.
23:46:14_Bilgusok so strictly a lack of cycles
23:49:06ulmutulWhat 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:22speachyit's a thought.
23:55:45*Bilgus thinks thats an idea prone to failure personally but I suspect thats aimed at speachy
23:56:28ulmutulThis could also be used for boomshine :)
23:56:30speachywe already have a benchmark, codec_bench.
23:56:49__builtinJust using CPUFREQ is probably good enough for coarse stuff
23:56:51speachymidi/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:50BilgusI 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:24ulmutulResults 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).

Previous day | Next day