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 2018-10-09

00:00:43 Quit benedikt93 (Quit: - Chat comfortably. Anywhere.)
00:00:54 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93)
00:07:47 Quit fs-bluebot_ (Ping timeout: 246 seconds)
00:09:15 Quit bluebrother (Ping timeout: 268 seconds)
00:14:30 Join fs-bluebot [0] (
00:15:24 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
00:16:02 Quit alexweissman (Ping timeout: 268 seconds)
00:16:28 Quit foolsh (Ping timeout: 250 seconds)
00:24:15 Join foolsh [0] (~foolsh@2601:249:4100:c338:1ce3:977f:3eaa:f29a)
00:29:31***Saving seen data "./dancer.seen"
00:31:07 Quit amofiuhr_ (Remote host closed the connection)
01:01:43*Bilgus wonders if speachy is aware he broke a bunch of targets with his opus patch
01:10:10foolshyep lots of red looks like two problems one is an undeclared instruction two looks like some targets don't have enough ram to fit the stack
01:32:51 Join this_is_a_nick [0] (
01:48:20 Join Soap [0] (~Soap@rockbox/staff/soap)
02:29:34***Saving seen data "./dancer.seen"
02:41:22 Quit krabador (Remote host closed the connection)
03:30:26 Join alexweissman [0] (
03:36:07 Quit alexweissman (Ping timeout: 252 seconds)
04:29:37***Saving seen data "./dancer.seen"
04:32:33 Quit foolsh (Read error: Connection reset by peer)
05:38:46 Join alexweissman [0] (
05:43:25 Quit alexweissman (Ping timeout: 260 seconds)
06:23:05 Join alexweissman [0] (
06:29:41***Saving seen data "./dancer.seen"
06:56:16 Quit pR0Ps (Ping timeout: 268 seconds)
07:01:28 Join pR0Ps [0] (~pR0Ps@
08:26:38 Quit mikroflops (Ping timeout: 252 seconds)
08:28:50 Join mikroflops [0] (~yogurt@
08:29:43***Saving seen data "./dancer.seen"
08:43:29 Join petur [0] (~petur@
08:43:29 Quit petur (Changing host)
08:43:30 Join petur [0] (~petur@rockbox/developer/petur)
09:21:42 Quit this_is_a_nick (Remote host closed the connection)
09:44:15 Join this_is_a_nick [0] (
09:57:27 Join dandels [0] (~dandels@unaffiliated/dandels)
10:15:32 Quit defterade (Ping timeout: 252 seconds)
10:29:46***Saving seen data "./dancer.seen"
11:00:45 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:20:40 Quit this_is_a_nick (Read error: Connection reset by peer)
11:23:18 Join this_is_a_nick [0] (
12:04:27 Quit dandels (Ping timeout: 244 seconds)
12:29:49***Saving seen data "./dancer.seen"
13:01:54 Join defterade [0] (
13:32:57 Join defterade_ [0] (
13:33:19 Quit defterade (Ping timeout: 244 seconds)
13:58:13 Join defterade [0] (
13:59:09 Quit defterade_ (Ping timeout: 244 seconds)
14:24:31 Quit petur (Read error: Connection reset by peer)
14:24:59 Join petur [0] (~petur@
14:24:59 Quit petur (Changing host)
14:24:59 Join petur [0] (~petur@rockbox/developer/petur)
14:29:50***Saving seen data "./dancer.seen"
14:55:05 Join dandels [0] (~dandels@unaffiliated/dandels)
15:09:25 Quit dandels (Ping timeout: 244 seconds)
15:17:56 Join dandels [0] (~dandels@unaffiliated/dandels)
15:39:29 Quit michaelni (Ping timeout: 252 seconds)
15:41:48 Quit petur (Quit: Connection reset by beer)
15:46:41 Quit defterade (Read error: Connection reset by peer)
15:51:35 Join michaelni [0] (
16:02:27 Join defterade [0] (
16:29:53***Saving seen data "./dancer.seen"
16:38:51 Join speachy [0] (d98c6f87@gateway/web/freenode/ip.
16:39:36speachyBilgus: nope, I wasn't aware that it broke anything
16:41:53speachyhad a clean review and was only supposed to affect targets with RAM to spare. Was the test wrong?
16:42:56gevaertsspeachy: has the build results
16:43:19speachyyeah, it's.. taking a long time to load.
16:43:45gevaertsIt's quick for me. Yay for the internet :)
16:43:46 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
16:43:56gevaertsWell, wait
16:44:41gevaertsno, everything is quick, but some logs are empty
16:45:30speachyyeah.. it's coming up now, but no build logs that I can see
16:45:48speachyeverything I look at is empty, including successful ones
16:46:05gevaerts;type=iriverh120 is one that works for me
16:47:16speachywe also need to update the mips toolchian used by the builders
16:49:05speachyhmm. so we're overflowing IRAM due to the bumped stack size. \
16:49:28gevaertswell yes, someone needs to add the new version to in rockbox-www first so the build clients can actually declare that they support the new version, and then the builds file (same repo) can be updated to require it
16:50:47speachyis that something I can do?
16:51:27gevaertsShould be. It's the rockbox-www repo on the same server as rockbox, with the same access rights
16:52:02gevaertsThen a quick mail to the build clients mailing list (that people running a client should be on...) so people know about it
16:52:21*gevaerts tries to remember the address
16:53:47 Quit dandels (Ping timeout: 272 seconds)
16:54:11Bilgusspeachy some of those targets are down to the wire (clearly) :)
16:55:28speachyrockbox-www kicks me back with a "make sure you have correct access rights and the repository exists"
16:56:10gevaertsoh, wait, it's plain www, not rockbox-www
16:56:38speachyso.. is there a sane way to determine which targets have IRAM down to the wire? I guess the underlying problem is that opus is still too stack hungry when seeking..
16:57:23speachybut putting in a pile of #ifndefs around that stack bump seems wrong. as does simply reverting it altogether
16:57:51gevaertsAh, rockbox-rbclient at Not sure if everyone can send to that, but we'll see
16:57:59speachycool, cloning it now.
16:59:18gevaertsBuild stuff in in the buildserver/ directory in there
17:01:32gevaertsThe toolchains are "defined" in there in, around line 550. In the old days we just used "m68k" or "arm" as the name, which is not very handy if updates are involved, so for newer toolchains we try to add some sort of version in there
17:02:02gevaertsoh, wait
17:02:09gevaertsthe new mips may already be there
17:03:17gevaertsIn which case, only the "builds" file needs to be updated to actually use it for all relevant targets. That's the first column (: separated) in there
17:04:06speachyno.. that's a linux toolchain
17:04:43speachyI added 'mipsel-gcc494'
17:04:58gevaertssounds reasonable
17:05:08speachymaybe it sould be called 'mipsel-baremetal-gcc494' or something like that instead
17:05:46gevaertsI'd say mipsel-gcc494 is fine
17:05:50speachythe naming converion is a bit of a historical mess. :)
17:05:54gevaertsIt gets long otherwise :)
17:06:17speachyin the builds file, what's the number after
17:06:44speachyand before the configure line
17:07:05gevaertsThe estimated build cost, used for build allocation to clients
17:07:20speachylarger number is more, essentially?
17:07:54gevaertsIt's milliseconds on my laptop when I last calibrated, with guesses for newer targets
17:10:36 Join dys [0] (~dys@2a01:598:b001:93db:226:5eff:fee9:68d2)
17:11:38speachyokay, add the toolchain, bump the version to 59..
17:11:59speachycommit, and ping the mailing list?
17:12:32gevaertsyes. Actually, also ping zagor to update the server. I'll try to catch him in #rockbox-community
17:12:39speachythen wait for a day or two, and commit the updated mips builds?
17:13:27gevaertsWell, wait until at least one client is updated, preferably more. I'm trying to update mine now, so hopefully it's quicker than two days
17:15:28gevaertsok, I pinged zagor
17:19:12gevaertsIf the toolchain builds properly, I'll update the clients manually so they won't depend on zagor. Just two clients for mips might be a bit slow, but it's workable
17:19:44speachymail sent to rockbox-rbclient
17:19:48*gevaerts never expects toolchains to build properly first time. There's always something missing :)
17:20:21speachyyeah, I remember the first time I compiled a rb toolchain. I was impressed that it just worked. :P
17:21:43speachyI guess I also need to create/define an X3 simulator build too
17:23:43gevaertsIdeally yes I think. Not sure how important it really is, but we do have a tradition to have a sim build for all targets
17:26:03speachythere;s also that ihifi 770/770c/800 megapatch sitting in gerrit.
17:27:02speachynot motivated enough to spend nearly $300 to test it out.
17:27:37gevaertsYes, that's one common issue
17:28:28speachymy reverse-engineering-printers habit is already expensive enough.
17:28:44 Quit pamaury (Ping timeout: 250 seconds)
17:29:06gevaertsIf you find one with something resembling audio, put rockbox on it :)
17:31:23speachyit's nice that the Chinese market is seeing such a DAP resurgence.
17:32:03speachybut getting meaningful info out of them is worse than pulling teeth.
17:38:53Bilgus those old dot matrix form feed printers would have something resembling audio :p
17:40:21speachyI remember some 8-bit atari games (on floppy) mucked with the data on disk so it would be quasi-melodic
17:40:52speachyso, suggestions on how to fix this build b0rkage from the opus patch?
17:41:25speachybeyond just reverting it completely, I mean
17:44:34Bilgusyou are going to either need to find add a section in the crt file to decide if you have enough space; make something else smaller;add a tag to the config file for the targets that work; or fix opus
17:45:01Bilgusthats find/add not find & add
17:45:47Bilguswodz and pamaury are far better at the low level stuff
17:48:03speachyhmm. the file siZe deltas on the build page seem a little wonky. like a 1K bump from a commit that did nothing more log the creation of the zipfile when building. :)
17:48:15Bilgusthe tag in the config file is nearly as bad as the ifdefs but works you could do something like OPUS_BIG_STACK for example and then the idea would be to make targets that don't have it skip the opus files that crash
17:48:47speachyit's seeking in that crashes, not normal playback.
17:49:40speachyIRAM is fixed on indivual targets, so I don't think there's anything to be gained by mucking with crt0 or the linker scripts.
17:56:29Bilgusassuming you have a baseline minimum amount of IRAM just check that there is enough with IRAMSIZE
18:06:50BilgusIt is defined in firmware/target/???/???/
18:21:30gevaertsspeachy: both my clients should have the new toolchain, so feel free to update builds
18:29:57***Saving seen data "./dancer.seen"
18:31:24 Join foolsh [0] (~foolsh@2601:249:4100:c338:142a:33ad:2a51:5246)
18:56:47speachyoh, another question −− any special mojo to generating a player pic?
18:57:31speachyjust take a pic and scale it down?
18:59:20gevaertsThey're svg, usually drawn by someone who knows what they're doing (i.e. not me!)
18:59:28*gevaerts doesn't remember the details
19:01:25speachythe ones in the www directory are tiny pngs, 80px at the long axis.
19:03:18gevaertsYes, I think they're generated from the ones in manual/rockbox_interface/images/ in the main repo
19:03:20speachy....generated from the svgs. yuck.
19:03:35*gevaerts hasn't really contributed to new ports, so he isn't too sure about these things
19:04:43speachythat much inkscaping with my hand is going to be an exercise in frustration. typing is bad enough
19:05:36gevaertsIIRC most of those were drawn by other people than the ones who did the code side of the port. Maybe ask the dev ML for volunteers?
19:06:12speachypushed new builds.
19:07:17gevaertsNow we just wait for the next regular commit to see what that does for us :)
19:08:40speachyalso fixed a FTB regression on the jz4740 targets. could have sworn I build-tested before pushing the commit that broke it..
19:09:58speachyhmm. I can host a builder if that will help.
19:10:25gevaertsThat's always helpful. We naver have too many of them!
19:11:06gevaerts has the documentation
19:12:22speachymight as well keep those idle cores doing something useful
19:13:30speachyso the toolchains need to be installed manually. okay.
19:14:19gevaertsWell, depends
19:14:32gevaertsThe client doesn't install them for you, if that's what you mean
19:20:15speachywould be really cool if this could be tied into gerrit.
19:29:18 Join lebellium [0] (
19:35:06 Join terminalator [0] (terminalat@gateway/vpn/privateinternetaccess/terminalator)
19:36:15Bilgusits hard enough to keep the status quo let alone add more :p
19:41:01 Quit speachy (Ping timeout: 256 seconds)
19:43:31 Join dandels [0] (~dandels@unaffiliated/dandels)
19:53:51 Quit mikroflops (Ping timeout: 250 seconds)
19:55:51 Join mikroflops [0] (
19:58:01 Quit lebellium (Quit: Leaving)
19:58:59 Quit dandels (Ping timeout: 252 seconds)
20:13:18 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
20:15:22 Join lebellium [0] (
20:20:07 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
20:25:35 Join speachy [0] (d98c6f87@gateway/web/freenode/ip.
20:26:39speachyhere's a rather ugly patch that I think should fix all of the FTBs due to the codec stack size bump.
20:27:08speachyblanket exclude coldfire, and anything that has small IRAM.
20:27:46speachybuild tested on a couple of arm (some formerly working, some broken) and mips
20:29:58***Saving seen data "./dancer.seen"
20:40:03Bilgusspeachy why not just #if defined(IRAMSIZE) && IRAMSIZE > (32 * 1024)?
20:47:27Bilgusor even #if !defined(CPU_COLDFIRE) && (MEMORYSIZE < 8) && defined(IRAMSIZE) && IRAMSIZE > (32 * 1024)
20:47:27Bilgus #define WORKAROUND_FS13060 0x800
20:47:27DBUGEnqueued KICK Bilgus
20:47:27Bilgus #define WORKAROUND_FS13060 0
20:47:46 Quit foolsh (Remote host closed the connection)
20:47:57BilgusI still don't like it but its not as ugly
20:51:23Bilgus..(MEMORYSIZE >= 8)
20:55:50speachyI had soemthign similar earlier but iirc if IRAMSIZE wasn't defined it generated a warning
20:56:56 Quit this_is_a_nick (Remote host closed the connection)
20:57:27speachywill try that again
20:57:36Bilgusparens then (defined(IRAMSIZE) && IRAMSIZE > (32 * 1024))
21:00:22speachyso far so good. I think that will work.
21:00:34Bilgusmm pamaury gave me a build script that builds all or select targets for building against all targets when I was messing with the action system
21:00:59Bilgusthat way I could run it on my end before pushing it to the build system
21:01:34speachyI don't have the m68k toolchain built yet
21:02:03speachythe limitation here is cpu cores. doing this on my laptop.
21:02:16speachyso it just takes time to do the builds I want.
21:02:28speachyupdated patch pushed
21:03:02Bilgusahh well here it is anyways its been altered a bit
21:05:00 Quit lebellium (Read error: Connection reset by peer)
21:05:03speachyI keep build trees for all hardware I own, plus a couple of problematic builds
21:05:17speachyheh, whether or not the hardware still _works_.
21:05:31CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
21:05:31*speachy glares at the pile of broken dreams.
21:05:56Bilgussame it comes in handy from time to time
21:07:50Bilgusmy beast quad core rig died a few weeks ago so I went back to a core2 quad I had lying around so builds take ages now or at least what feels like ages
21:12:28 Join krabador [0] (~krabador@unaffiliated/krabador)
21:15:38speachyso the patch looks sane, for what it is?
21:16:24Bilgusoh I hate it but yeah I mean one way to know for sure right?
21:18:05BilgusI tried looking into opus a while back and other codecs for that matter they have a steep learning curve to say the least
21:18:26Bilgusso I guess a hack is better than crashing..
21:20:47speachyyeah, it seems to be the last worst option
21:20:53speachyer, least
21:22:07speachycodec code is its own special kind of hell.
21:33:03speachya lot of places in the opus code where gcc claims stack usage could be unbounded
21:38:46 Nick tomb is now known as tomf (~tomflint@unaffiliated/tomflint)
21:42:28 Quit krabador (Remote host closed the connection)
21:43:18 Join krabador [0] (~krabador@unaffiliated/krabador)
21:51:05speachythere are 648 bytes of stack usage that can be easily saved. shouldn't hurt performance by an apprciable amount either as it's not in hot code paths
22:00:29*Bilgus wonders whats changed in opus since 2012
22:05:59speachywell, for one opus has gone through IETF standardization..
22:07:01speachyour snapshot was at the opus 1.0.1 timeframe.
22:07:22speachyshortly after the libopus 1.0.1 release
22:09:05 Join this_is_a_nick [0] (~amofiuhr_@
22:29:59***Saving seen data "./dancer.seen"
22:33:24speachyhmm. looks like we really didn't change much in libopus. partially done with a re-import.
22:33:28speachyanyway. gotta scoot.
22:33:31 Quit speachy ()
22:47:48 Join foolsh [0] (~foolsh@2601:249:4100:c338:142a:33ad:2a51:5246)
22:57:59 Quit krabador (Remote host closed the connection)
22:58:47 Join krabador [0] (~krabador@unaffiliated/krabador)
23:16:31 Quit pamaury (Ping timeout: 252 seconds)
23:17:45 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
23:18:21 Join lebellium [0] (
23:23:22 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
23:23:32 Quit pamaury (Ping timeout: 268 seconds)
23:24:52 Quit lebellium (Quit: Leaving)
23:44:05 Join dandels [0] (~dandels@unaffiliated/dandels)
23:46:35 Quit pamaury_ (Ping timeout: 244 seconds)

Previous day | Next day