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 | 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 2023-05-30

00:09:22***No seen item changed, no save performed.
00:37:11 Quit m01 (Quit: Konversation terminated.)
00:39:39 Join m01 [0] (
02:09:24***Saving seen data "./dancer.seen"
04:09:26***No seen item changed, no save performed.
06:04:13 Quit yosafbridge (Quit: Leaving)
06:06:20 Join yosafbridge [0] (
06:09:30***Saving seen data "./dancer.seen"
06:42:18 Join Pico4u [0] (~Pico4u@
06:46:32Pico4uIs Hifiman port not native? How can it has "USB DAC working" status?
07:42:42sporknative is rockbox, non-native is rockbox-as-an-app
07:44:07sporkbut you are right, that port seems native so usb-dac seems unlikely
08:09:31***No seen item changed, no save performed.
09:02:28speachyuh, that's definitely out of date.
09:03:34speachyI'm not sure WTF was meant by "USB DAC" in that context, as there was never any code committed to implement USB DAC functionality (at least not in the generic USB audio class sense)
09:05:13speachy(I have a HM-601 here, and it essentially works)
09:39:11speachyover the weekend I was experimenting with trying to enable LTO with the new toolchains, focusing initially on the plugins since they're self-contained. That went well... except apparently the optimizer replaces some assignments with memsets/memcpys, which we can't use in a plugin environment. :/
09:40:22speachyAnd there appears to be no way of turning that off. Even setting -fno-builtin -ffreestanding (etc) doesn't work. I suppose one option would be to add a stub that turns around and invokes rb->memset.
10:04:10 Join JanC_ [0] (~janc@user/janc)
10:04:15 Quit JanC (Read error: Connection reset by peer)
10:04:24 Nick JanC_ is now known as JanC (~janc@user/janc)
10:09:32***Saving seen data "./dancer.seen"
10:48:47 Quit Pico4u (Ping timeout: 240 seconds)
10:58:52 Quit JanC (Remote host closed the connection)
10:59:10 Join JanC [0] (~janc@user/janc)
11:15:34 Quit spork (Quit: leaving)
11:49:28 Join spork [0] (
12:09:34***Saving seen data "./dancer.seen"
12:26:26braewoodsspeachy, apparently not considered a bug.
12:26:47braewoods"GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp."
12:27:43speachyOh, I know. What's frustrating is that this _only_ happens with LTO.
12:28:22braewoodsI wonder if we could force gcc to just inline the necessary function instead.
12:28:31speachyand there's no way to disable that specific behavior without massively affecting optimization.
12:28:58speachynope, it's being inserted during an optimization pass; the actual sources being compiled don't call memset/memcpy at all.
12:29:25speachy(ie it's doing soemthing like convering a (i=0 ; i < foo; i++) bar[i] = 0;
12:29:25braewoodsWe can either rewrite the effected source code or...
12:29:31braewoodssomething else.
12:29:55speachyinto a memset(bar, 0, foo);
12:30:13braewoodsrewriting blocks into explicit usage of memset or memcpy that we can use is one option.
12:30:22speachyso the only way out is to add a minimimal memset/etc stub that calls the plugin memset.
12:30:23braewoodsIs it too widespread of a problem?
12:30:41speachyhalf a dozen plugins affected so far, and that's just on a mini2g
12:31:12speachyI'm sure it's happening on the codecs too but they have a bunch of other LTO problems that need to be solved first.
12:31:28braewoodsI see. So much trouble just for LTO.
12:31:45braewoodsI can see why some projects don't even mess with it.
12:31:48speachy(I'm starting with the plugins and codecs as they're self-contained and not supposed to call anything outside of the functions that rockbox provides through the plugin/codec handle)
12:32:29speachyLTO can make a pretty big difference with compile sizes and runtime performance, but most stuff doesn't benefit (enough) from that.
12:33:34braewoodsI'm kinda surprised GCC still supports codegen for m68k and some other arguably obsolete processor archs.
12:34:25braewoodsIs there anything modern that still uses m68k?
12:34:26speachym68k is still very widely used.
12:34:48braewoodsI guess not too surprising as it was one of the first 32 bit cpus.
12:35:03braewoodsIt was high end for its day.
12:35:43braewoodsJust kinda funny that x86, despite its legacy baggage, basically destroyed powerpc and m68k in the home computer market.
12:35:47speachythe MCU (coldfire) line is still commercially relevant, though ultimately it's a matter of there being maintainers.
12:36:38braewoodsAnd ARM may be the one to finally kill x86 eventually.
12:36:52speachyx86 "won" due to windows more than anything else. Well, combined with Intel's process advantage vs IBM at the time.
12:37:04braewoodsYea, it was enough to make apple abandon powerpc.
12:37:31braewoodsToday there's not really any Linux distributions even for 32 bit ppc.
12:38:02braewoodsGentoo is probably it.
12:38:19speachy"ARM" is still a fragmented vendor-specific mess, despite Arm's best efforts.
12:38:56braewoodsAnd not all chips are equal. Allwinner is low cost and has generally good Linux compatibility but isn't super fast.
12:38:58speachythere's also pretty much zero general purpose ARM gear between embedded-focused toys and ginormous servers.
12:40:05speachyApple's much-lauded M1/M2 gets most of its speed advantage from (1) memory stacked directly on the CPU package and (2) a bunch of specialized accelarators that the OS is tightly integrated with.
12:40:31braewoodsYea, and I don't consider M1 a massive game changer because of the vendor it is from.
12:40:38braewoodsIt's not a PC.
12:40:42braewoodsIt never will be a PC.
12:41:11braewoodsIt would be more significant if that kind of performance came out in the form of a windows on arm device.
12:41:36speachyeh, "PC" is really just a set of APIs −− eg Intel Macs were mostly indistinguisable from PCs from a hardware perspective.
12:41:45speachythey even booted using UEFI.
12:41:57braewoodsMaybe we'll see desktop boards eventually with ARM.
12:42:08speachythe higher-end ARM gear (==servers) also all use UEFI.
12:42:09braewoodsas in like ATX form factor.
12:42:43speachybut RISC-V that everyone's so gung-ho about is a massive step backwards in that respect, with even more fragmentation than what ARM was like at its worst.
12:43:21speachyeven in the "PC" realm the volume is laptops and SFF systems; [mu ]ATX systems are a minority.
12:43:23braewoodsyea. i think it only makes sense for embedded devices.
12:44:00speachyand even most of those never get upgraded beyond what they're shipped with. Why pay the BOM (and performance!) penalty for upgraeability when most of the market doesn't care?
12:45:55speachyany decently-performant ARM SoC is targetted towards phones. So very limited I/O options. Without a relatively large volume to amortize your costs across, it's very hard to justify the investment needed to building a PC-esque ARM design.
12:46:21speachyApple's pretty much the only one to do it (other than folks targeting hyperscale server applications)
12:46:54braewoodsspeachy, so it faces the same problem that powerpc attempts at the same thing face?
12:47:15braewoodsTalos for example.
12:47:16speachyyep −− not enough volume to make it remotely cost-competitive.
12:47:43speachyone point −− Talos is POWER, not PPC. They literally use the same CPU modules that IBM shoves into their servers.
12:48:06speachy(PPC is effectively dead; it was a subset of POWER)
12:48:19braewoodsI was thinking of what is now called ppc64 though.
12:48:36braewoodsI've been following this whole powerpc laptop project too.
12:48:45braewoodsNo idea if they'll ever deliver anything.
12:48:57braewoodsIt looks plausible on the surface at least.
12:49:02speachy(but there's still a metric f-ton of stuff out there running PPC cores, so we have to support PPC well into the 2030s...)
12:49:09braewoodsBut it'll probably cost over 1k if they do.
12:50:38speachyso going around full-circle, this is also why so many modern DAPs use what are essentially smartphone SoCs.
12:51:05speachy(and run android)
12:51:37speachyand also why they're all essentially the same, tube amps and diamond-studded volume knobs not withstanding.
12:57:02braewoodsspeachy, just with some parts left disconnected?
12:57:58speachythe main difference is that instead of a radio that does cellular+wifi+bt they just use one that does wifi+bt.
12:59:08speachy(or heck, they might even use the one with a built in cell modem, just don't turn it on. There's probably containers full of 3G-era chips that are useless for modern phones...)
13:01:37 Join lebellium [0] (
13:09:54buZzspeachy: 3G is still on in most nations globally
13:09:57buZz2G too
13:27:37speachy2G is, but 3G has been systematically turned off because 4G is _much_ more spectrally efficient.
13:33:48 Join Pico4u [0] (~Pico4u@
14:09:36***No seen item changed, no save performed.
14:45:08 Quit advcomp2019 (Ping timeout: 240 seconds)
14:47:53 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
15:00:00 Quit advcomp2019 (Ping timeout: 250 seconds)
15:01:06 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
15:20:45 Quit advcomp2019 (Ping timeout: 240 seconds)
15:22:44 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
15:26:32buZzspeachy: sure, its still on though
15:26:40buZzin most of europe, africa, asia
15:26:53buZzsouthamerica too
15:27:21speachywell, yes and no −− most of the places that have turned off 2G completely are in asia, and a good chunk of Europe will have 3G (and 2G) off by the end of this year.
15:28:09spork3g will be off here but 2g left on for iot
15:28:11sporkfor now
15:28:12speachypoint being that one can't rely on it being on for much longer, which makes non-4G basebands a lot less useful.
15:28:16buZzwhich still isnt the majority of nations :D
15:28:27buZznetherlands has 2G till 2026
15:28:34buZzand likely will get extended
15:28:39sporkmost nations are made up
15:29:04buZzby humans, obviously
15:29:16buZzborders arent natural :)
15:29:29speachysure, but what coverage? a couple of years ago I'd noticed that 2G coverage was way crappier than it used to be
15:29:49buZzin netherlands they've even made Edge faster the last 2 years
15:30:00buZzgetting 50-60KB/s on 2G , not too bad
15:33:01 Quit advcomp2019 (Ping timeout: 240 seconds)
15:33:09speachy...kinda along the lines of how we had a major batch of low-end Chinese DAPs that used an old Spreadtrum flipphone-era SoC.
15:48:08 Quit jacobk (Ping timeout: 240 seconds)
16:03:13 Join dys [0] (~dys@user/dys)
16:04:04 Quit Pico4u (Quit: Leaving)
16:09:37***Saving seen data "./dancer.seen"
16:40:10 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
17:07:37 Join rogeliodh8 [0] (
17:10:49 Join Trzyzet_ [0] (
17:11:17 Join genpaku_ [0] (~waldner@
17:16:04 Quit rogeliodh (*.net *.split)
17:16:04 Quit Trzyzet (*.net *.split)
17:16:05 Quit genpaku (*.net *.split)
17:16:05 Nick Trzyzet_ is now known as Trzyzet (
17:16:05 Nick rogeliodh8 is now known as rogeliodh (
17:17:19 Join JanC_ [0] (~janc@user/janc)
17:17:33 Quit JanC (Killed ( (Nickname regained by services)))
17:17:33 Nick JanC_ is now known as JanC (~janc@user/janc)
17:20:27 Quit JanC (Excess Flood)
17:20:46 Join JanC [0] (~janc@user/janc)
17:22:08 Quit Nyaa (Ping timeout: 250 seconds)
17:29:43 Join Nyaa [0] (
18:09:40***Saving seen data "./dancer.seen"
18:29:54 Quit lebellium (Quit: Leaving)
18:38:06 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019)
18:38:50 Quit advcomp2019 (Ping timeout: 250 seconds)
18:52:55 Join massiveH [0] (~massiveH@2600:4040:a99f:1f00:c43c:bfd1:c1:2427)
19:04:49 Quit advcomp2019_ (Ping timeout: 250 seconds)
19:28:45 Quit Trzyzet (Quit:
19:29:57 Join Trzyzet [0] (
19:33:08 Quit m01 (Ping timeout: 240 seconds)
19:34:19 Join m01 [0] (
20:04:01 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
20:09:43***Saving seen data "./dancer.seen"
21:18:06 Join jacobk [0] (
21:18:42 Join amiconn_ [0] (
21:18:43 Nick amiconn is now known as Guest1816 (
21:18:43 Quit Guest1816 (Killed ( (Nickname regained by services)))
21:18:43 Nick amiconn_ is now known as amiconn (
21:19:34 Join pixelma_ [0] (
21:19:34 Nick pixelma is now known as Guest6302 (
21:19:34 Quit Guest6302 (Killed ( (Nickname regained by services)))
21:19:34 Nick pixelma_ is now known as pixelma (
21:50:22 Quit jacobk (Ping timeout: 250 seconds)
21:58:14 Join jacobk [0] (
22:09:44***Saving seen data "./dancer.seen"
22:19:31 Quit massiveH (Quit: Leaving)

Previous day | Next day