| 00:09:22 | *** | No seen item changed, no save performed. |
| 00:37:11 | | Quit m01 (Quit: Konversation terminated.) |
| 00:39:39 | | Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) |
| 02:00 |
| 02:09:24 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:09:26 | *** | No seen item changed, no save performed. |
| 06:00 |
| 06:04:13 | | Quit yosafbridge (Quit: Leaving) |
| 06:06:20 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 06:09:30 | *** | Saving seen data "./dancer.seen" |
| 06:42:18 | | Join Pico4u [0] (~Pico4u@85.174.206.100) |
| 06:46:32 | Pico4u | Is Hifiman port https://www.rockbox.org/wiki/HifimanPort not native? How can it has "USB DAC working" status? |
| 07:00 |
| 07:42:42 | spork | native is rockbox, non-native is rockbox-as-an-app |
| 07:44:07 | spork | but you are right, that port seems native so usb-dac seems unlikely |
| 08:00 |
| 08:09:31 | *** | No seen item changed, no save performed. |
| 09:00 |
| 09:02:28 | speachy | uh, that's definitely out of date. |
| 09:03:34 | speachy | I'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:13 | speachy | (I have a HM-601 here, and it essentially works) |
| 09:39:11 | speachy | over 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:22 | speachy | And 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:00 |
| 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:00 |
| 11:15:34 | | Quit spork (Quit: leaving) |
| 11:49:28 | | Join spork [0] (topic@i121118.upc-i.chello.nl) |
| 12:00 |
| 12:09:34 | *** | Saving seen data "./dancer.seen" |
| 12:26:26 | braewoods | speachy, apparently not considered a bug. |
| 12:26:32 | braewoods | speachy, https://gcc.gnu.org/onlinedocs/gcc/Standards.html |
| 12:26:47 | braewoods | "GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp." |
| 12:27:43 | speachy | Oh, I know. What's frustrating is that this _only_ happens with LTO. |
| 12:28:22 | braewoods | I wonder if we could force gcc to just inline the necessary function instead. |
| 12:28:31 | speachy | and there's no way to disable that specific behavior without massively affecting optimization. |
| 12:28:58 | speachy | nope, it's being inserted during an optimization pass; the actual sources being compiled don't call memset/memcpy at all. |
| 12:29:25 | speachy | (ie it's doing soemthing like convering a (i=0 ; i < foo; i++) bar[i] = 0; |
| 12:29:25 | braewoods | We can either rewrite the effected source code or... |
| 12:29:31 | braewoods | something else. |
| 12:29:55 | speachy | into a memset(bar, 0, foo); |
| 12:30:13 | braewoods | rewriting blocks into explicit usage of memset or memcpy that we can use is one option. |
| 12:30:22 | speachy | so the only way out is to add a minimimal memset/etc stub that calls the plugin memset. |
| 12:30:23 | braewoods | Is it too widespread of a problem? |
| 12:30:41 | speachy | half a dozen plugins affected so far, and that's just on a mini2g |
| 12:31:12 | speachy | I'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:28 | braewoods | I see. So much trouble just for LTO. |
| 12:31:45 | braewoods | I can see why some projects don't even mess with it. |
| 12:31:48 | speachy | (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:29 | speachy | LTO can make a pretty big difference with compile sizes and runtime performance, but most stuff doesn't benefit (enough) from that. |
| 12:33:34 | braewoods | I'm kinda surprised GCC still supports codegen for m68k and some other arguably obsolete processor archs. |
| 12:34:25 | braewoods | Is there anything modern that still uses m68k? |
| 12:34:26 | speachy | m68k is still very widely used. |
| 12:34:48 | braewoods | I guess not too surprising as it was one of the first 32 bit cpus. |
| 12:35:03 | braewoods | It was high end for its day. |
| 12:35:43 | braewoods | Just kinda funny that x86, despite its legacy baggage, basically destroyed powerpc and m68k in the home computer market. |
| 12:35:47 | speachy | the MCU (coldfire) line is still commercially relevant, though ultimately it's a matter of there being maintainers. |
| 12:36:38 | braewoods | And ARM may be the one to finally kill x86 eventually. |
| 12:36:52 | speachy | x86 "won" due to windows more than anything else. Well, combined with Intel's process advantage vs IBM at the time. |
| 12:37:04 | braewoods | Yea, it was enough to make apple abandon powerpc. |
| 12:37:31 | braewoods | Today there's not really any Linux distributions even for 32 bit ppc. |
| 12:38:02 | braewoods | Gentoo is probably it. |
| 12:38:19 | speachy | "ARM" is still a fragmented vendor-specific mess, despite Arm's best efforts. |
| 12:38:27 | braewoods | Yep. |
| 12:38:56 | braewoods | And not all chips are equal. Allwinner is low cost and has generally good Linux compatibility but isn't super fast. |
| 12:38:58 | speachy | there's also pretty much zero general purpose ARM gear between embedded-focused toys and ginormous servers. |
| 12:40:05 | speachy | Apple'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:31 | braewoods | Yea, and I don't consider M1 a massive game changer because of the vendor it is from. |
| 12:40:38 | braewoods | It's not a PC. |
| 12:40:42 | braewoods | It never will be a PC. |
| 12:41:11 | braewoods | It would be more significant if that kind of performance came out in the form of a windows on arm device. |
| 12:41:36 | speachy | eh, "PC" is really just a set of APIs −− eg Intel Macs were mostly indistinguisable from PCs from a hardware perspective. |
| 12:41:45 | speachy | they even booted using UEFI. |
| 12:41:57 | braewoods | Maybe we'll see desktop boards eventually with ARM. |
| 12:42:08 | speachy | the higher-end ARM gear (==servers) also all use UEFI. |
| 12:42:09 | braewoods | as in like ATX form factor. |
| 12:42:43 | speachy | but 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:21 | speachy | even in the "PC" realm the volume is laptops and SFF systems; [mu ]ATX systems are a minority. |
| 12:43:23 | braewoods | yea. i think it only makes sense for embedded devices. |
| 12:44:00 | speachy | and 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:55 | speachy | any 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:21 | speachy | Apple's pretty much the only one to do it (other than folks targeting hyperscale server applications) |
| 12:46:54 | braewoods | speachy, so it faces the same problem that powerpc attempts at the same thing face? |
| 12:47:15 | braewoods | Talos for example. |
| 12:47:16 | speachy | yep −− not enough volume to make it remotely cost-competitive. |
| 12:47:43 | speachy | one point −− Talos is POWER, not PPC. They literally use the same CPU modules that IBM shoves into their servers. |
| 12:47:55 | braewoods | Oh. |
| 12:48:06 | speachy | (PPC is effectively dead; it was a subset of POWER) |
| 12:48:19 | braewoods | I was thinking of what is now called ppc64 though. |
| 12:48:36 | braewoods | I've been following this whole powerpc laptop project too. |
| 12:48:45 | braewoods | No idea if they'll ever deliver anything. |
| 12:48:46 | braewoods | https://www.powerpc-notebook.org/en/ |
| 12:48:57 | braewoods | It looks plausible on the surface at least. |
| 12:49:02 | speachy | (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:09 | braewoods | But it'll probably cost over 1k if they do. |
| 12:50:38 | speachy | so going around full-circle, this is also why so many modern DAPs use what are essentially smartphone SoCs. |
| 12:51:05 | speachy | (and run android) |
| 12:51:37 | speachy | and also why they're all essentially the same, tube amps and diamond-studded volume knobs not withstanding. |
| 12:57:02 | braewoods | speachy, just with some parts left disconnected? |
| 12:57:58 | speachy | the main difference is that instead of a radio that does cellular+wifi+bt they just use one that does wifi+bt. |
| 12:59:08 | speachy | (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:00 |
| 13:01:37 | | Join lebellium [0] (~lebellium@2a01cb040610e0002124b6f692fb0022.ipv6.abo.wanadoo.fr) |
| 13:09:54 | buZz | speachy: 3G is still on in most nations globally |
| 13:09:57 | buZz | 2G too |
| 13:27:37 | speachy | 2G is, but 3G has been systematically turned off because 4G is _much_ more spectrally efficient. |
| 13:33:48 | | Join Pico4u [0] (~Pico4u@85.174.206.100) |
| 14:00 |
| 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 |
| 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:32 | buZz | speachy: sure, its still on though |
| 15:26:40 | buZz | in most of europe, africa, asia |
| 15:26:53 | buZz | southamerica too |
| 15:27:21 | speachy | well, 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:09 | spork | 3g will be off here but 2g left on for iot |
| 15:28:11 | spork | for now |
| 15:28:12 | speachy | point being that one can't rely on it being on for much longer, which makes non-4G basebands a lot less useful. |
| 15:28:16 | buZz | which still isnt the majority of nations :D |
| 15:28:27 | buZz | netherlands has 2G till 2026 |
| 15:28:34 | buZz | and likely will get extended |
| 15:28:39 | spork | most nations are made up |
| 15:29:04 | buZz | by humans, obviously |
| 15:29:16 | buZz | borders arent natural :) |
| 15:29:29 | speachy | sure, but what coverage? a couple of years ago I'd noticed that 2G coverage was way crappier than it used to be |
| 15:29:49 | buZz | in netherlands they've even made Edge faster the last 2 years |
| 15:30:00 | buZz | getting 50-60KB/s on 2G , not too bad |
| 15:33:01 | | Quit advcomp2019 (Ping timeout: 240 seconds) |
| 15:33:09 | speachy | ...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:00 |
| 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:00 |
| 17:07:37 | | Join rogeliodh8 [0] (~rogeliodh@rogeliodh.dev) |
| 17:10:49 | | Join Trzyzet_ [0] (~Trzyzet@cpc110919-live30-2-0-cust650.17-2.cable.virginm.net) |
| 17:11:17 | | Join genpaku_ [0] (~waldner@107.191.100.185) |
| 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 (~Trzyzet@cpc110919-live30-2-0-cust650.17-2.cable.virginm.net) |
| 17:16:05 | | Nick rogeliodh8 is now known as rogeliodh (~rogeliodh@rogeliodh.dev) |
| 17:17:19 | | Join JanC_ [0] (~janc@user/janc) |
| 17:17:33 | | Quit JanC (Killed (lithium.libera.chat (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] (Nyaaori@cyberia.club/meow/nyaaori) |
| 18:00 |
| 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:00 |
| 19:04:49 | | Quit advcomp2019_ (Ping timeout: 250 seconds) |
| 19:28:45 | | Quit Trzyzet (Quit: http://site.3zet.net/) |
| 19:29:57 | | Join Trzyzet [0] (~Trzyzet@cpc110919-live30-2-0-cust650.17-2.cable.virginm.net) |
| 19:33:08 | | Quit m01 (Ping timeout: 240 seconds) |
| 19:34:19 | | Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) |
| 20:00 |
| 20:04:01 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 20:09:43 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:18:06 | | Join jacobk [0] (~quassel@47-186-122-163.dlls.tx.frontiernet.net) |
| 21:18:42 | | Join amiconn_ [0] (jens@p200300ea87453f00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 21:18:43 | | Nick amiconn is now known as Guest1816 (jens@p200300ea87064a00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 21:18:43 | | Quit Guest1816 (Killed (mercury.libera.chat (Nickname regained by services))) |
| 21:18:43 | | Nick amiconn_ is now known as amiconn (jens@p200300ea87453f00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 21:19:34 | | Join pixelma_ [0] (marianne@p200300ea87453f00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 21:19:34 | | Nick pixelma is now known as Guest6302 (marianne@p200300ea87064a00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 21:19:34 | | Quit Guest6302 (Killed (mercury.libera.chat (Nickname regained by services))) |
| 21:19:34 | | Nick pixelma_ is now known as pixelma (marianne@p200300ea87453f00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 21:50:22 | | Quit jacobk (Ping timeout: 250 seconds) |
| 21:58:14 | | Join jacobk [0] (~quassel@47-186-122-163.dlls.tx.frontiernet.net) |
| 22:00 |
| 22:09:44 | *** | Saving seen data "./dancer.seen" |
| 22:19:31 | | Quit massiveH (Quit: Leaving) |
icon identifies that the person is a core developer (has commit access).