--- Log for 25.07.121  Server: molybdenum.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 2 days and 14 hours ago

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.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.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.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.21.20 ***     Saving seen data "./dancer.seen"
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.04.56 Quit    Guest541 (Quit: Leaving)
07.21.23 ***     Saving seen data "./dancer.seen"
07.58.48 Quit    ZincAlloy1 (Quit: Leaving.)
08.14.05 Join    ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
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: 3New build round started. Revision 77ec752248, 303 builds, 9 clients.
10.05.08 #       <rb-bluebot> Build Server message: 3Build round completed after 651 seconds.
10.05.10 #       <rb-bluebot> Build Server message: 3Revision 77ec752248 result: All green
10.07.43 #       <rb-bluebot> Build Server message: 3New 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: 3Build round completed after 633 seconds.
10.18.19 #       <rb-bluebot> Build Server message: 3Revision 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: 3New 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: 3Build round completed after 635 seconds.
10.33.31 #       <rb-bluebot> Build Server message: 3Revision 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: 3New 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> 3Gerrit review #3603 at https://gerrit.rockbox.org/r/c/rockbox/+/3603 : 3Start 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: 3Build round completed after 596 seconds.
10.46.47 #       <rb-bluebot> Build Server message: 3Revision 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> 3Gerrit review #3623 at https://gerrit.rockbox.org/r/c/rockbox/+/3623 : 3HACK: 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: 3New 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.06.00 #       <rb-bluebot> Build Server message: 3Build round completed after 624 seconds.
11.06.03 #       <rb-bluebot> Build Server message: 3Revision 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.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.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.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.21.35 ***     Saving seen data "./dancer.seen"
15.59.55 Quit    dconrad (Remote host closed the connection)
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.43.28 Quit    ZincAlloy (Quit: Leaving.)
19.21.40 ***     Saving seen data "./dancer.seen"
20.59.20 Join    dconrad [0] (~dconrad@208.38.228.17)
21.21.44 ***     No seen item changed, no save performed.
22.01.01 Quit    cockroach (Quit: leaving)
23.21.45 ***     Saving seen data "./dancer.seen"
23.32.58 Quit    dconrad ()