| 00:09:19 | | Quit dconrad () |
| 00:13:15 | | Quit JanC (Remote host closed the connection) |
| 00:15:14 | | Join JanC [0] (~janc@user/janc) |
| 00:20:38 | | Quit akaWolf (Ping timeout: 265 seconds) |
| 01:00 |
| 01:05:38 | braewoods | speachy: something else that's been available since C99... array declarators. it's an alternate way of managing pointers via array syntax. but it only works in function parameter lists afaik. |
| 01:05:58 | braewoods | it might be useful to use |
| 01:06:16 | braewoods | one example... |
| 01:06:32 | braewoods | int test(char arr[static 45]); |
| 01:06:56 | braewoods | you can also apply storage modifiers like const, volatile, restrict, etc to it |
| 01:07:23 | braewoods | the 45 allows the compiler to check a static sized array contains at least the stated number of elements |
| 01:07:31 | braewoods | gcc supports this in 11 but no earlier |
| 01:07:56 | braewoods | this could help with managing complex pointer arrangements being passed to functions |
| 01:08:11 | braewoods | but otherwise limited use case that i can tell |
| 01:08:53 | braewoods | it lacks the flexibility of being able to work with both dynamic and static arrays |
| 01:09:01 | braewoods | so i'm honestly not sure the point of it |
| 01:09:35 | braewoods | just pointer salad is a giant mess to deal with |
| 01:09:37 | braewoods | :D |
| 01:21:16 | *** | Saving seen data "./dancer.seen" |
| 01:25:03 | | Quit massiveH (Quit: Leaving) |
| 02:00 |
| 02:53:32 | | Join i [0] (~i@109-252-37-53.nat.spd-mgts.ru) |
| 02:53:56 | | Nick i is now known as Guest541 (~i@109-252-37-53.nat.spd-mgts.ru) |
| 03:00 |
| 03:12:14 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:39a0:d3f4:c82f:13b7) |
| 03:20:14 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 03:21:18 | *** | Saving seen data "./dancer.seen" |
| 03:52:34 | | Quit ZincAlloy (Quit: Leaving.) |
| 03:52:51 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9fc:edf4:35fc:55d5) |
| 03:53:28 | Guest541 | hi, i am trying to unbrick my partially bricked sansa clip+ from fs corruption, player can boot but can not read or write anything from internal storage (can't save settings, can't shutdown without home+power), it also cant be mounted as storage device on win or linux (mount as ?media remote? instead). Player sometimes can resume last track and can play anything from SD card but only one file per boot. I followed this https://www.rockbox.org/w |
| 03:53:28 | Guest541 | iki/SansaAMSUnbrick guide and now i can see internal storage in fdisk but what to do next is unclear. Is there any way to solve this? rockbox version some 3.15+ daily. |
| 03:54:31 | | Quit ZincAlloy (Client Quit) |
| 03:55:24 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 05:00 |
| 05:21:20 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:17:00 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 06:19:42 | | Join ZincAlloy1 [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 06:19:43 | | Quit ZincAlloy (Read error: Connection reset by peer) |
| 06:33:19 | | Join johnb2 [0] (~johnb2@p4fd10fc0.dip0.t-ipconnect.de) |
| 06:34:37 | johnb2 | Guest541 This sounds like your internal storage is dying. I'd advise to not touch it anymore, but boot from and only use a sdcard from now on. |
| 06:35:30 | johnb2 | see https://download.rockbox.org/daily/manual/rockbox-sansaclipplus/rockbox-buildch13.html#x16-36500013.3.2 |
| 06:36:55 | johnb2 | Assuming you have a somewhat recent (last two years) bootloader installed. |
| 06:58:41 | | Quit johnb2 (Ping timeout: 255 seconds) |
| 07:00 |
| 07:04:56 | | Quit Guest541 (Quit: Leaving) |
| 07:21:23 | *** | Saving seen data "./dancer.seen" |
| 07:58:48 | | Quit ZincAlloy1 (Quit: Leaving.) |
| 08:00 |
| 08:14:05 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 09:00 |
| 09:15:09 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 09:15:09 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 09:21:26 | *** | Saving seen data "./dancer.seen" |
| 09:33:31 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 09:53:29 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 09:54:16 | rb-bluebot | Build Server message: New build round started. Revision 77ec752248, 303 builds, 9 clients. |
| 10:00 |
| 10:05:08 | rb-bluebot | Build Server message: Build round completed after 651 seconds. |
| 10:05:10 | rb-bluebot | Build Server message: Revision 77ec752248 result: All green |
| 10:07:43 | rb-bluebot | Build Server message: New build round started. Revision e532714d1f, 303 builds, 9 clients. |
| 10:17:14 | speachy | amachronic: I could have sworn something was using the get_peak_buffer() crap. I remember checking and being quite grumpy at having to implement it. |
| 10:17:34 | speachy | (and ended up nuking a few other pcm_() API functions around the same time |
| 10:17:41 | amachronic | i did a quick grep and nobody seemed to be using it |
| 10:17:52 | speachy | but maybe the final user was in the hwcodec code and that's why it's all gone now |
| 10:18:16 | rb-bluebot | Build Server message: Build round completed after 633 seconds. |
| 10:18:19 | rb-bluebot | Build Server message: Revision e532714d1f result: 0 errors 13 warnings |
| 10:18:33 | amachronic | well that wasn't totally unexpected |
| 10:18:42 | speachy | all MIPS |
| 10:18:54 | speachy | no wait, not all |
| 10:19:09 | speachy | it's nice seeing green in the delta table |
| 10:21:56 | speachy | oh, I bet this was obsoleted by the pcm->dsp migration way back in the olden times |
| 10:22:54 | rb-bluebot | Build Server message: New build round started. Revision 148fac6f34, 303 builds, 9 clients. |
| 10:23:16 | amachronic | it was just unused function + variable warnings, that should fix it |
| 10:23:22 | speachy | yep |
| 10:24:59 | amachronic | what's it even for? peak meters? (must be a hwcodec thing) |
| 10:25:04 | speachy | yeah |
| 10:26:39 | amachronic | speachy, could you update the download site? i uploaded a new version of jztool which supports the Q1 and Eros Q. |
| 10:26:41 | amachronic | https://drive.google.com/drive/folders/1F4OhAVqKPcp879CykFCN5WL9ncYfPrvm |
| 10:26:54 | amachronic | and the q1 bootloader too |
| 10:28:52 | speachy | universal macos or still intel-only? |
| 10:29:32 | amachronic | dconrad built it, pretty sure it's intel only |
| 10:30:00 | dconrad | tested on brand new m1 macbook air, works there as well |
| 10:30:14 | dconrad | can't vouch for very old osx, however |
| 10:31:36 | dconrad | like I said before (and it turned surprisingly contentious), apple did a good job with making the transition seamless from intel to arm |
| 10:32:12 | speachy | I only asked because the current directory is called 'macos_intel' |
| 10:32:35 | speachy | so is it a fat binary, or does it require rosetta installed? |
| 10:33:12 | dconrad | oh, yeah probably |
| 10:33:24 | dconrad | probably rosetta |
| 10:33:29 | rb-bluebot | Build Server message: Build round completed after 635 seconds. |
| 10:33:31 | rb-bluebot | Build Server message: Revision 148fac6f34 result: 0 errors 1 warnings |
| 10:33:36 | dconrad | I'll have to ask what's on that laptop |
| 10:33:48 | speachy | ok, all binaries updated. |
| 10:35:20 | amachronic | whoops, I missed the jz4760 |
| 10:35:53 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 10:36:48 | rb-bluebot | Build Server message: New build round started. Revision 05d4d6a4f2, 303 builds, 9 clients. |
| 10:39:13 | speachy | sweet, the q1 and m3k manuals were generated overnight. |
| 10:40:19 | amachronic | dconrad, may I ask what was wrong with g#3603 approach? why move it to pcm-x1000? |
| 10:40:21 | rb-bluebot | Gerrit review #3603 at https://gerrit.rockbox.org/r/c/rockbox/+/3603 : Start of 32-bit software volume for native players by Dana Conrad |
| 10:41:36 | dconrad | tbh, I think either could work |
| 10:41:43 | dconrad | or rather, I think that could work |
| 10:42:04 | spork | thanks amachronic and speachy, with the bootloader/jztool available the q1 manual is even more correct |
| 10:42:16 | dconrad | but I don't know if that could be reasonably done without transitioning the rest of the generic pcm stuff to 32 bit |
| 10:42:34 | dconrad | so I guess the thought was doing it in the driver is "safer" |
| 10:42:59 | dconrad | speachy might have a better grasp on why? |
| 10:43:31 | amachronic | hmm I see what you mean, it's the callback hell that makes it tricky. |
| 10:43:39 | speachy | basically there's a ton of hardcoded assumptions in the core around 16-bit sample sizes, especially with respect to buffer sizing. |
| 10:43:54 | speachy | all of the internal pcm/dsp routines also assume 16bpp |
| 10:44:20 | amachronic | my only concern is that the HW PCM code runs totally in interrupt context so scaling there might be unworkable |
| 10:44:53 | speachy | amachronic: yeah, that's most likely going to be a major issue. but going to double-buffering _might_ help there. |
| 10:45:55 | amachronic | buffering is done in the mixer afaict, so probably not |
| 10:46:16 | dconrad | pardon my ignorance, but why would it work fine in the hosted port but not the native? is that code in the hosted port not run in interrupt context? |
| 10:46:18 | amachronic | with scaling in the interrupt we actually want a lot of small buffers |
| 10:46:39 | speachy | all hosted code is running in userspace |
| 10:46:45 | rb-bluebot | Build Server message: Build round completed after 596 seconds. |
| 10:46:47 | rb-bluebot | Build Server message: Revision 05d4d6a4f2 result: 4 errors 0 warnings |
| 10:46:58 | dconrad | I see |
| 10:47:14 | speachy | double-buffering in the x1000 pcm driver; ie triple-buffering from the core's perspective |
| 10:47:45 | amachronic | and I suppose that's why the linux driver uses double buffering −− to cover the huge latency of calling back to userspace |
| 10:48:03 | speachy | that way we will always have something to hand to the hardware while we're processing the data from the callback |
| 10:48:17 | speachy | ok, another random build glitch. |
| 10:48:26 | amachronic | yep |
| 10:48:29 | speachy | on my builder too |
| 10:48:33 | speachy | hmm. |
| 10:48:57 | | Quit ZincAlloy (Quit: Leaving.) |
| 10:48:57 | speachy | we _might_ have some sort of dependency issue in the build that doesn't manifest itself unless you have a ton of cores.. |
| 10:49:20 | speachy | but I've not been able to get this to break when firing it up manually |
| 10:49:37 | speachy | (16c/32t on that box) |
| 10:49:49 | amachronic | maybe CODECS_LIBS vs CODEC_LIBS |
| 10:50:42 | amachronic | yeah CODECLIB=libcodec.a is in CODEC_LIBS, it's just a typo in the makefile |
| 10:50:46 | speachy | yeah, you're right |
| 10:50:53 | dconrad | just as a curiosity, it would appear the 32-bit volume scaling method works better than the current 16-bit scaling method, even when truncated back down to 16-bit |
| 10:51:01 | dconrad | g#3623 |
| 10:51:02 | rb-bluebot | Gerrit review #3623 at https://gerrit.rockbox.org/r/c/rockbox/+/3623 : HACK: Improved 16-bit volume scaling by Dana Conrad |
| 10:52:01 | speachy | dconrad: so.. perhaps the solution is to scrap all of this and make the core pcm_volume stuff work using 32-bit math, and re-truncate.. |
| 10:52:16 | dconrad | well, I'm unsure |
| 10:52:18 | amachronic | I see. I don't understand the math well enough to understand why one is better than the other. |
| 10:52:31 | dconrad | (me neither, amachronic haha) |
| 10:52:33 | amachronic | the thing is, both are doing 32bit math |
| 10:53:12 | speachy | 16-bit intermediates |
| 10:53:14 | dconrad | I swear it still distorts audibly at the low end of the volume, but it doesn't pop/click |
| 10:53:32 | speachy | amachronic: you want to fix that dependency typo or should I? |
| 10:53:41 | amachronic | i'll do it |
| 10:54:19 | speachy | crazy how it's managed to mostly work for so long.. |
| 10:55:10 | * | speachy feeds his good little builder a byte of bits. |
| 10:55:36 | rb-bluebot | Build Server message: New build round started. Revision 2e9443104f, 303 builds, 9 clients. |
| 10:56:22 | amachronic | it's weird how it managed to work at all :D |
| 10:58:18 | speachy | crap. just broke the wiki. |
| 11:00 |
| 11:06:00 | rb-bluebot | Build Server message: Build round completed after 624 seconds. |
| 11:06:03 | rb-bluebot | Build Server message: Revision 2e9443104f result: All green |
| 11:07:22 | yang | Is it possible to flash fiio m3k rockbox firmware without SD card inserted? or does the rockbox firmware sits on SD card? |
| 11:07:44 | amachronic | yes, you need the SD card. |
| 11:07:59 | speachy | ok, wiki should be back up now. |
| 11:08:47 | speachy | (for future reference, next time, double-check 'rm -Rf fos<tab>' *before* pressing <enter> |
| 11:09:59 | | Quit Maxdamantus (Ping timeout: 258 seconds) |
| 11:12:05 | | Join johnb2 [0] (~johnb2@p4fd10fc0.dip0.t-ipconnect.de) |
| 11:18:45 | yang | amachronic: is your first entry in the forum the accurate flashing description ? https://forums.rockbox.org/index.php/topic,53858.msg248529.html#msg248529 |
| 11:18:54 | yang | or were any later changes to it |
| 11:19:11 | amachronic | that's still correct |
| 11:20:08 | dconrad | speachy: I just asked, the macos jztool does require rosetta for arm macs (though I doubt many don't already have rosetta anyway) |
| 11:20:27 | speachy | okeydokey. so I'll leave he directory names as-is |
| 11:21:29 | *** | Saving seen data "./dancer.seen" |
| 11:24:02 | braewoods | dconrad: i assume that's just until we compile a native version? |
| 11:25:43 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 11:36:10 | yang | amachronic: so, the rockbox firmware is then residing on SD card? asking because I would likely replace SD card with a bigger one in a few days. |
| 11:36:34 | spork | you can copy the .rockbox folder to your new card |
| 11:36:42 | yang | ok |
| 11:44:53 | dconrad | braewoods: I imagine so, but it seems to work pretty seamlessly anyway |
| 11:45:57 | | Join Maxdamantus [0] (~Maxdamant@user/maxdamantus) |
| 11:50:42 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:39f0:1b64:1df7:1a3c) |
| 12:00 |
| 12:19:42 | speachy | rosetta isn't installed/active out of the box on the new macs |
| 12:19:51 | | Quit pixelma (Ping timeout: 252 seconds) |
| 12:19:52 | speachy | one has to take steps to install/enable it, including a click-through agreement of sorts |
| 12:20:26 | | Quit amiconn (Ping timeout: 255 seconds) |
| 12:22:00 | | Join amiconn [0] (jens@p200300ea874bea00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 12:22:00 | | Join pixelma [0] (marianne@p200300ea874bea00305e95fffec66ff3.dip0.t-ipconnect.de) |
| 12:26:13 | braewoods | speachy: what's stopping us from cross-compiling for mac? |
| 12:26:17 | braewoods | proper toolchain? |
| 12:30:42 | speachy | pretty much ahve to use xcode in order to do anything these days. |
| 12:42:18 | dconrad | more in the saga of software volume: the "improved 16-bit" hack is distorted and noisy at minimum volume, whereas the hosted port is (mostly) clean and noise-free at minimum volume, so there's definitely an advantage to having the better resolution going to the hardware |
| 12:42:28 | dconrad | (from actual testing) |
| 12:43:30 | dconrad | the (mostly) is that podcasts in particular for some reason, tend to pop at the end of an edited-in silence, for instance between segments |
| 12:45:08 | dconrad | as well as between/starting/stopping songs, but we already knew that (and the native does that too, another thing to iron out) |
| 12:57:47 | | Quit Maxdamantus (Ping timeout: 255 seconds) |
| 13:00 |
| 13:00:25 | | Quit ZincAlloy (Quit: Leaving.) |
| 13:06:56 | | Quit amachronic (Ping timeout: 256 seconds) |
| 13:09:47 | | Join Maxdamantus [0] (~Maxdamant@user/maxdamantus) |
| 13:21:33 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:24:00 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 14:32:56 | | Quit dconrad (Remote host closed the connection) |
| 14:41:33 | | Part dbohdan |
| 14:59:57 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 15:00 |
| 15:21:35 | *** | Saving seen data "./dancer.seen" |
| 15:59:55 | | Quit dconrad (Remote host closed the connection) |
| 17:00 |
| 17:00:19 | | Quit lebellium (Quit: Leaving) |
| 17:00:20 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 17:04:57 | | Quit dconrad (Ping timeout: 258 seconds) |
| 17:10:04 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 17:15:33 | | Quit dconrad (Remote host closed the connection) |
| 17:21:39 | *** | Saving seen data "./dancer.seen" |
| 17:36:31 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 17:53:03 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 17:57:11 | | Quit dconrad () |
| 18:00 |
| 18:43:28 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:00 |
| 19:21:40 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:59:20 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:00 |
| 21:21:44 | *** | No seen item changed, no save performed. |
| 22:00 |
| 22:01:01 | | Quit cockroach (Quit: leaving) |
| 23:00 |
| 23:21:45 | *** | Saving seen data "./dancer.seen" |
| 23:32:58 | | Quit dconrad () |
icon identifies that the person is a core developer (has commit access).