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 2020-09-25

00:51:41***Saving seen data "./dancer.seen"
00:54:00 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
01:06:55 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
01:12:24 Quit _3dsv (Ping timeout: 240 seconds)
01:15:57 Quit pixelma (Quit: .)
01:15:57 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
01:18:46 Join amiconn [0] (jens@rockbox/developer/amiconn)
01:18:46 Join pixelma [0] (marianne@rockbox/staff/pixelma)
01:21:02 Join ZincAlloy [0] (
01:25:28 Quit ZincAlloy (Ping timeout: 256 seconds)
01:34:02 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:dcd9:60d7:43b1:6910)
01:38:31 Quit ZincAlloy (Ping timeout: 272 seconds)
01:40:40 Join _3dsv [0] (
01:43:22 Join mendel_munkis_ [0] (
01:43:42 Quit pamaury (Ping timeout: 272 seconds)
01:46:25 Quit mendel_munkis (Ping timeout: 264 seconds)
02:08:11 Join MonTaGaTnoM [0] (~shawn156@unaffiliated/shawn156)
02:09:33 Quit S|h|a|w|n (Ping timeout: 260 seconds)
02:11:28 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
02:12:37 Quit MonTaGaTnoM (Ping timeout: 246 seconds)
02:22:22 Quit Moarc (Quit: i znowu NADMUCHAƁ BALONA)
02:25:47 Join Moarc [0] (
02:29:40 Join pamaury [0] (
02:29:41 Quit pamaury (Changing host)
02:29:41 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
02:51:43***Saving seen data "./dancer.seen"
04:09:20 Nick mendel_munkis_ is now known as mendel_munkis (
04:51:46***No seen item changed, no save performed.
05:24:12 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
05:38:34 Quit S|h|a|w|n (Read error: Connection reset by peer)
06:51:49***Saving seen data "./dancer.seen"
06:58:04 Quit mendel_munkis (Ping timeout: 240 seconds)
08:16:34 Join Rower [0] (
08:46:13 Quit Topy44 (Ping timeout: 244 seconds)
08:51:51***Saving seen data "./dancer.seen"
09:07:58 Quit mikroflops (Ping timeout: 258 seconds)
09:08:57 Join mikroflops [0] (
09:14:43 Quit koniu (Ping timeout: 240 seconds)
09:22:02 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
09:23:44 Quit t0mato (Quit: Ping timeout (120 seconds))
09:27:52 Join petur [0] (~petur@rockbox/developer/petur)
09:40:35 Join t0mato [0] (~t0mato@
09:50:01 Join Topy44 [0] (
10:41:51 Quit pamaury (Quit: Konversation terminated!)
10:44:02 Quit Topy44 (Ping timeout: 260 seconds)
10:48:57 Join Topy44 [0] (
10:51:53***Saving seen data "./dancer.seen"
11:55:54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
12:06:40 Join ZincAlloy [0] (
12:07:28 Quit _3dsv (Remote host closed the connection)
12:07:54 Join _3dsv [0] (
12:11:07 Quit ZincAlloy (Ping timeout: 246 seconds)
12:19:34 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:fcae:47fe:b196:fdd1)
12:20:51 Join mendelmunkis [0] (
12:24:31 Quit ZincAlloy (Ping timeout: 272 seconds)
12:48:21 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:f1a5:dfbd:c0a4:72b1)
12:51:54***Saving seen data "./dancer.seen"
13:33:28 Quit pamaury (Ping timeout: 256 seconds)
13:45:03 Join fs-bluebot_ [0] (
13:45:14 Quit bluebrother (Disconnected by services)
13:45:19 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
13:46:20 Quit fs-bluebot (Ping timeout: 272 seconds)
13:52:12bluebrother^hmm, seems my internet reconnected just as I was writing some thoughts ...
13:52:21bluebrother^so I've been thinking about the rbutil elevation thing. My current thought is to leave the implementation in rbutil as-is, and if it does find external patcher binaries (ipodpatcher / sansapatcher) it'll call them. That way it can still work using sudo, and we don't need to bundle the patchers, which should simplify things a bit.
13:52:27bluebrother^we'd ship the patchers as part of the release though. On Mac they'd be simply part of the dmg, on Windows part of the zip.
13:52:27mendelmunkissounds aboutright on the timing
13:52:49bluebrother^Linux ... not sure how exactly that would work with the appimage, but I guess it will work in some way.
13:53:09bluebrother^so we can get the best of both worlds. Thoughts?
13:54:28genevinois there some kind of probability the surfans f20 gets rockbox at some point?
13:55:07mendelmunkisthat reminds me. I should really get around to packaging rbutil for debian.
13:57:28bluebrother^genevino: there's always probability. But it might be 0 ;-)
14:13:24speachygenevino: looks like another hibyplayer unit. probably wouldn't be hard to do
14:21:18bluebrother^speachy: I've added a sticky topic in the Rockbox Utility forum with the link to the development binaries. Seems this is coming up again and again :)
14:21:58speachyhow much of a PITA is rbutil to cross-compile for windows? is that even possible?
14:22:15speachyI'm thinking maybe we could add it to the dev build list
14:22:48bluebrother^it's rather simple with mxe.
14:23:26bluebrother^if using the cross compiler as offered by your distro: depends on the distro :)
14:23:50bluebrother^I hope to get some progress soonish on that elevation thing.
14:24:11speachylet's see if mingw64 on fedora builds it cleanly...
14:24:14bluebrother^and then merge the libtomcrypt stuff, and try to get 1.5.0 done.
14:25:13bluebrother^in theory you'd only need to have the used packages installed. Right now Qt5 and crypto++ should be the main ones.
14:30:30speachyhuh, it built... execept for cryptopp
14:32:23speachyrebuilding with the libtom stuff applied
14:44:17bluebrother^since we have a github mirror I was wondering if it would make sense to use travis for Rockbox Utility CI builds.
14:45:02bluebrother^might even allow us to build for macos.
14:46:25speachydunno if it makes sense or not, but it's worth considering
14:46:51speachyhaving automated builds is a GoodThing(tm)
14:47:36bluebrother^we did consider automated builds for Rockbox Utility years back. Never happened though, since most work was on Rockbox anyway. But with CI services like travis these days ...
14:47:53bluebrother^maybe I should give it a shot. I have a fork on my github anyway.
14:51:41speachycan rbutil compile out-of-tree? it doesn't 'make clean' properly..
14:51:56***Saving seen data "./dancer.seen"
14:52:48speachyhuh, the Surfans F20 looks like a very close cousin to the HIFI WALKER H2.
14:55:51genevinospeachy: well i already had a look at the firmware update file and it's just some iso9660 image with some 3.10 linux kernel and some other magic
14:56:09 Join skx_ [0] (~r0b0t@unaffiliated/r0b0t)
14:56:19speachygenevino: it's 98% identical to the rocker, x3ii, and x20.
14:56:28genevinospeachy: unfortunately the current firmware has no real shuffle-all mode, which is annoying.
14:56:35 Quit sakax (Quit: Leaving)
14:56:39 Quit skx_ (Client Quit)
14:56:40genevinospeachy: yeah i also ordered a rocker, should arrive next days. :)
14:56:55 Join sakax [0] (~r0b0t@unaffiliated/r0b0t)
14:57:08bluebrother^speachy: yes. In fact I always build out-of-tree.
14:57:22bluebrother^mkdir build; cd build; qmake .. && make
14:59:49genevinospeachy: i'm actually surprised, i would have expected some original china cheapo-player firmware to much worse than what the original f20 fw is.
15:53:57 Quit Skyrider (Quit: ZNC - 1.6.0 -
15:55:57 Quit jerwin (Quit: bye)
16:00:05 Join jerwin [0] (~flippy-fl@unaffiliated/flippy)
16:00:47 Join johnb2 [0] (
16:07:03 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
16:12:08 Quit johnb2 (Ping timeout: 256 seconds)
16:52:00***Saving seen data "./dancer.seen"
17:02:43 Quit sakax (Remote host closed the connection)
17:24:28braewoodsspeachy: do they provide the kernel source at least? if not they're technically breaking the GPL...
17:25:17speachybraewoods: no idea if any of them do. Probably not.
17:25:29speachythere's nothing "technical" about it.
17:25:38speachyand we can't do anything about it either.
17:25:57speachyI can say there's no source code download link posted anywhere for those units.
17:26:18speachy(as well as the Linux kernel itself, there's also u-boot)
17:28:07braewoodsand whatever userspace stuff they use
17:28:16braewoodsit may also have busybox or so
17:28:58braewoodsGPLv2 is clearly violated in any case
17:29:19braewoodsif you could get source release that could be beneficial to rockbox on some targets but i wouldn't count on it
17:30:10speachyit would be a great boon for doing native ports, but putting that aside it would allow for some needed bugfixing in the kernel.
17:30:51braewoodsperhaps best outcome is if rockbox could get its own device.
17:31:08braewoodsinstead of always have to use someone else's designed hardware
17:31:27braewoodswould be interesting to see something like that from pine microsystems
17:31:50speachyeh, piggybacking on other hardware isn't inherently bad.
17:32:10braewoodsi know but it does make it easier
17:32:21braewoodsthere's no need for reverse engineering (in theory)
17:32:26speachybut doing our own would probably take a couple hundred grand worth of funding before the first unit rolls off the line.
17:32:58speachywith proper docs/sources on exisitng hardware, we wouldn't need to RE things either.
17:33:21braewoodswhich reminds me
17:33:27braewoodsdoes RB support bluetooth on anything?
17:33:28speachywe'd still need to write our own drivers for new/unique hardware, regardless of anything else.
17:34:05speachynope. on the rocker and other hiby-based targets, the OS-level stuff is all there though, and just needs an appropriate UI written
17:34:30speachyon native targets, it's a lot more involved, as we'd have to port over a bluetooth stack and all that jazz.
17:34:34braewoodsso if it ever does it would be through another subsystem
17:34:52braewoodshow much RAM does the rocker have even?
17:34:54speachyno inherent reason why not; just man-hours
17:34:57braewoodsI thought it was 32MB
17:35:05speachy32MB, embedded into the main SoC package.
17:35:19braewoodsso how do you fit rockbox and the linux kernel into it?
17:35:20speachybut only ~6-7MB is really usable by rockbox.
17:35:35braewoodsso very tight fit compared to older ports
17:36:04braewoodssheesh. too bad it wasn't 64MB.
17:36:43speachyyes and no; the underlying Linux OS does most of the heavy lifting; rockbox is "just" an application on top of it.
17:37:15braewoodsso main issue is memory for decoding buffers and such?
17:37:19 Quit petur (Quit: Leaving)
17:37:22speachyThe X1000e does come in a 64MB version I believe, but I don't recall seeing anything
17:37:33speachyanything with that version, I mean.
17:38:00braewoodsthis may be the future rockbox has to deal with... fewer native ports and more piggybacking off Linux or so
17:38:12speachyyeah; playlist management, UI stuffs, voiced menus, codecs and codec buffers, etc..
17:38:43speachyit's plenty for "normal" use; only becoming tight when some of the more memory-hungry plugins are used. ie various games/emulators.
17:39:07braewoodsoui. if i were you i'd want to do most of the allocations statically to reduce waste from heap usage
17:39:17speachy(the X1000 is a 1GHz MIPS32r2 core. _Plenty_ of raw oomph!)
17:39:40speachyrockbox is already mostly static. max RAM used is a compile-time option.
17:39:48braewoodsI see.
17:40:18braewoodsI just realized some time ago that dynamic allocations are heavily used but they're a liability in resource cramped devices.
17:40:56braewoodspointers can consume precious memory
17:41:12braewoodsi wonder though, do these targets have MMUs?
17:41:20braewoodsthey're embedded so I don't know.
17:41:21speachymost of the rockbox targets don't.
17:41:35speachybut the jz4760 and x1000 does.
17:41:38braewoodsthere's less need for MMUs in this kind of application
17:42:42speachyrockbox doesn't natively use the MMUs on anything though.
17:45:39speachyI've toyed with taking a devkit based on a high-end STM32 microcontroller and porting rockbox over to it as a proof of concept, but there's no real path forward from taking that into something that resembles a DAP.
17:48:50speachyHeh. if we had enough cash on hand to commit to a sufficiently-large order we could probably get (for example) AGPTek/Benjie hand over the full source code in the process, and we could use that to do a native port to that hardware.
17:49:40speachydon't know what "sufficiently large" would be in this context but it's likely in the ~10K unit range.
17:58:19braewoodsI'd probably ask pine microsystems first if they'd have any interest.
17:58:29braewoodsthey've already been producing ARM based phones and tablets
17:59:49speachydesigning new hardware will drive up the cost, as that NRE has to be amortized across the production run.
18:00:24speachyand without working software, it would be a design-to-spec
18:00:48speachy(and we really couldn't do the sw port until we get at least an initial prototype)
18:01:30speachy... that 10K unit production run really is the minimum for reasonable per-unit costs
18:02:36speachystill, probably wouldn't hurt to drop 'em a line, but I suspect we're going to need a kickstarter with a couple hundred grand raised to make this viable.
18:04:11 Quit Rower (Ping timeout: 240 seconds)
18:05:12speachy(and we have to be somewhat competitively priced compared to commercially-revelant devices)
18:07:57 Quit Oksana (Read error: Connection reset by peer)
18:20:10 Join ac_laptop [0] (~ac_laptop@
18:20:48 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
18:25:04 Join Rower [0] (
18:36:57 Quit ac_laptop (Quit: WeeChat 2.9)
18:37:23 Join ac_laptop [0] (~ac_laptop@
18:40:23_bilgus__$60 - 100 is competive but not realistic
18:50:40speachythat's why I was thinking it may be smarter to talk someone into cranking out a big order of an existing product that was (presumably) already competitively priced.
18:51:35speachythe only engineering investment would be the actual rockbox port.
18:51:55speachyand since we're swimming in developers, that'll be simple!
18:52:02***Saving seen data "./dancer.seen"
19:44:00 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
19:45:03 Join fs-bluebot [0] (
19:46:59 Quit bluebrother^ (Ping timeout: 240 seconds)
19:47:35 Quit fs-bluebot_ (Ping timeout: 265 seconds)
19:47:45speachyjust reached out to the pine64 folks.
19:58:31 Join smoke_fumus [0] (~smoke_fum@
20:18:18 Quit ZincAlloy (Quit: Leaving.)
20:52:03***Saving seen data "./dancer.seen"
20:53:39braewoodsspeachy: well they develop products around their ARM boards.
20:54:03braewoodsit's more niche than usual though so who knows if there's any interest
20:54:26braewoodsbut if they did go for it the devices would probably have a ton more RAM than rockbox usually does
21:11:35 Quit braewoods (Quit: WeeChat 2.8)
21:11:56 Join pacman [0] (~braewoods@learnprogramming/staff/braewoods)
21:11:58 Nick pacman is now known as braewoods (~braewoods@learnprogramming/staff/braewoods)
21:23:42speachythey started out with Allwinner SoCs but I think all of their recent stuff has been on various Rockchip parts.
21:26:55speachyas for RAM, it'll be whatever the cheapest is for a given technology. For example I think the _smallest_ LPDDR4 part one can get is 64MB. :)
21:28:11speachywait, that's LPDDR2. smallest LPDDR4 part Micron makes is 512MiB
21:38:15 Quit smoke_fumus (Quit: KVIrc 5.0.0 Aria
22:00:29speachybut one of the reasons the injenic parts are so popular are because they embed the RAM into the package, greatly reducing the necessary pincount of the SoC, and the resulting improvements to pcm size/complexity/bom cost
22:00:31braewoodsspeachy: and the smallest modules are 4GB
22:00:44speachyGb, not GB.
22:01:07braewoodsin terms of standard DDR4 memory modules
22:03:49speachyah yes
22:04:56speachyA 64-bit memory bus does mean you'll need 8 8-bit parts.
22:11:05braewoodsgiven how fast they are you'd probably be underclocking it to keep the heat down
22:11:19braewoodsjust how much cpu does rockbox need? i can't see it needing much
22:11:53speachycouple hundred mhz on even an ARM7TDMI are plenty for all of our codecs.
22:16:23speachywe're more sensitive to latency though.
22:19:57speachyso even a semi-modern microcontroller
22:20:02speachyis plenty
22:20:11 Quit cockroach (Quit: leaving)
22:26:29braewoodsspeachy: is it common for codecs to be implemented in software or via ASICs these days?
22:26:47braewoodsi've never seen an ASIC for audio codecs but that doesn't mean they don't exist.
22:27:14speachyit's pretty common to put various accelerators into ASICs.
22:27:44braewoodswas just wondering whether it'd be all software or not since modern cpus may be a lot more efficient than they used to be
22:27:48braewoodsmaybe good enough for rockbox
22:28:23speachythe accelerators are often (usually?) under various NDAs that preclude public source code distribution
22:28:36braewoodshow typical
22:28:42braewoodsi can't see what the point of that would be
22:28:46braewoodsoh well
22:29:23speachytake the ATJ2127, for example −− it has nearly no RAM, because the hardware can DMA data off the SD card, into the HW decoder engine, and out to the DAC without any CPU intervention
22:29:33speachyno need to buffer anything
22:31:18speachythe usual reason for locking down the decoders are patents and DRM.
22:31:51braewoodsI see
22:31:55speachymp3's fully in the public domain now, but the mpeg4-derived stuff isn't, for example.
22:32:10speachyand of course DRM is a festering pile of swill that ruins everything it touches.
22:33:43speachybut we don't generally care because the CPU is more than powerful enough −− and the analog portions of the system draw more juice than the CPU anyway.
22:34:01braewoodsi wonder if there's asics for the non-patented codecs like vorbis and opus
22:34:11speachy(we can't turn off the clocks, or the RAM, or the audio codec...
22:35:03speachypretty sure both can be had in hardware form, but how widespread they are is unknown.
22:35:31braewoodsit's simpler just to put it in software
22:35:45braewoodswe're not talking stuff that's incredibly demanding like video codecs
22:36:29speachydefinitely is simpler, but one-off NRE more than pays for itself if you can shrink your unit costs across a large production run
22:36:59speachyor it enables you to get 30 minutes more battery life than the competition for the same battery
22:37:25braewoodsor the same with smaller battery
22:38:17speachyon aliexpress there are quite a few DAPs priced under $2.
22:39:18speachyprobably clones of a reference design from the ASIC maker.
22:39:51braewoodsdon't cpus with their own embedded memory have lower latency to access it?
22:39:56braewoodsi would think so
22:40:06speachydepends on how the memory was embedded
22:40:35braewoodsi see.
22:40:53braewoodsis it always DRAM? I know SRAM has lower power requirements and such
22:41:11speachyDRAM is much denser (and therefore cheaper) on a bit-by-bit basis.
22:41:45speachyDRAM loses on the power front becuase it needs to be constantly refreshed.
22:42:02speachywhereas SRAM will hold its contents as long as power remains applied.
22:43:04braewoodsi know SRAM is still used.
22:43:09braewoodsafaik x86 cpu cache is SRAM
22:43:15speachybut SRAM can get tightly coupled −− the last gig I had we had 12K of SRAM that had zero-cycle latency. :)
22:43:40speachy(running at 32MHz)
22:44:11speachybut the overriding priority for that design was obscenely low sleep current
22:49:02speachyon a typical MCU you'll have some TCRAM / IRAM that's effectively zero-cycle access (and relatively tiny), possibly additional (and slower) on-chip SRAM, and possibly external DRAM. and perhaps flash too, for devices that allow exeuction from flash, but that can have some relatively heinous random access latencies.
22:50:12speachyyou'll want to put the most performance-critical code in the fastest, lowest-latency RAM.
22:50:41speachy(as well as any code that needs to run before you have initialized your DRAM controller...)
22:51:06speachyoh, if I'm prattling on about stuff you already know please tell me
22:52:07***Saving seen data "./dancer.seen"
22:56:51braewoodsnot really; i've never needed to care about any of this other than when installing components
23:00:19speachyall the stuff Linux (and low-level boot code!) normally does for us we have to do ourselves.
23:04:16 Quit Acou_Bass (Ping timeout: 256 seconds)
23:07:08 Join Acou_Bass [0] (
23:08:49braewoodsspeachy: though not all of it; Linux needs its own bootloader after all
23:08:55braewoodsgrub, etc
23:09:22speachyI was actually thinking more like uboot or the BIOS/UEFI layer
23:09:55braewoodsafaik Linux is only self-booting on UEFI if built as an application
23:10:12braewoodsotherwise it needs something between the firmware and itself to boot
23:12:28speachythings like setting up the DRAM controller and the SoC clocks
23:12:50fs-bluebotBuild Server message: New build round started. Revision 0f23cad, 280 builds, 7 clients.
23:13:42_bilgus__and with that the lua file browser has sort by name, size, date
23:14:19speachyheh. I find myself idly wondering if it rewriting our UI in LUA makes sense.
23:15:11_bilgus__see there are things I really like about lua but there are things I REALLY HATE
23:18:40_bilgus__I only 'improved' our version because I see it as a way to put the onus on users to do their own expansion Fs#13226 for instance :p
23:18:41fs-bluebot Allow for per-directory sort settings (feature requests, closed)
23:19:59_bilgus__though pamaury said he probes devices with lua and it is surely a good lang for those quick kinda scripts
23:21:34_bilgus__then again it wouldn't be that hard to do what you are saying and it sorta jives with a project I was toying with namely uncoupling the WPS from the core
23:25:27_bilgus__your lang in plugins open both possibilities
23:26:11_bilgus__I suppose that also depends if all our targets could run the lua core
23:26:26speachyyeah, we still have several 2MB targets.
23:30:52_bilgus__theres several tens of kb that can be freed by excising unused builtins and such but lua is a very good at fragging ram
23:31:40_bilgus__i was gonna say memory hungry and its that too but its more of the way it pigs up what it does have
23:33:43speachymuch lower-hanging fruit than that to deal with.
23:33:53speachylike, say, bluetooth support
23:34:38fs-bluebotBuild Server message: Build round completed after 1308 seconds.
23:34:44_bilgus__yeah I do have a few more examples at home that I need to remember to commit a music player in lua and maybe some more rlimage examples
23:34:50fs-bluebotBuild Server message: Revision 0f23cad result: All green
23:36:41_bilgus__that would be pretty easily handled by lua actually
23:37:28_bilgus__how do you talk to the bluetooth controller? file handles I assume
23:38:16_bilgus__and with the open plugin stuff I added it also wouldn't be too hard to integrate into the menu somewhere
23:44:55braewoods_bilgus__: is this on Linux?
23:45:12braewoodsi might be able to help with bluez as it's the same crap used on desktop Linux
23:45:13_bilgus__pretty sure the hosted devices are linux
23:45:45_bilgus__I don't even have a rocker to test do you?
23:45:54braewoodsno i don't
23:46:02braewoodsi thought you did lol
23:46:43 Quit TheSeven (Disconnected by services)
23:46:53 Join [7] [0] (~quassel@rockbox/developer/TheSeven)
23:47:11_bilgus__hehe no I really like sansa and I recently traded a clipzip for a xduoo with speachy
23:50:41_bilgus__otherwise its really hard to dev without having a device in hand
23:50:56_bilgus__not that I haven't done so..

Previous day | Next day