| 01:00 |
| 01:20:34 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:3df2:389f:6929:6355) |
| 01:35:55 | *** | No seen item changed, no save performed. |
| 01:46:52 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 02:00 |
| 02:57:24 | | Quit lebellium (Quit: Leaving) |
| 03:00 |
| 03:35:57 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:32:35 | | Quit blbro[m] (Ping timeout: 252 seconds) |
| 05:32:47 | | Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) |
| 05:35:58 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:01:22 | | Quit hook54321 () |
| 06:01:52 | | Join hook54321 [0] (sid149355@user/hook54321) |
| 06:04:21 | | Quit _bilgus (Quit: Leaving) |
| 06:47:02 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 07:00 |
| 07:21:03 | | Quit Moriar (Quit: Leaving.) |
| 07:36:02 | *** | Saving seen data "./dancer.seen" |
| 07:53:14 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:04:52 | | Quit massiveH (Quit: Leaving) |
| 09:36:04 | *** | Saving seen data "./dancer.seen" |
| 11:00 |
| 11:36:05 | *** | No seen item changed, no save performed. |
| 12:00 |
| 12:14:10 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:442e:90cb:b9dc:2e1e) |
| 13:00 |
| 13:36:08 | *** | No seen item changed, no save performed. |
| 14:00 |
| 14:11:19 | speachy | a question for [semi-]active folks: Putting aside the question of migration, Any thoughts about moving from our mismash of services to a sourcehut instance? |
| 14:13:23 | speachy | I'm planning on setting up a private instance for my own use (to possibly replace gitolite+flyspray+mailman+dokuwiki+misc) and it occurred to me it might be a good fit for rockbox too |
| 14:48:17 | __builtin | can we really just "ignore" the issue of migration though? |
| 14:48:56 | __builtin | there's a _lot_ of wiki pages and web miscellany that would have to get moved |
| 14:49:34 | __builtin | and in doing so, we'd (probably) break all the links pointing to everything we've ever touched |
| 14:50:26 | __builtin | just my $0.02, of course |
| 15:00 |
| 15:14:24 | | Quit tchan (Ping timeout: 256 seconds) |
| 15:14:59 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 15:26:47 | braewoods | __builtin: depends how it's done. if they move services as is it may preserve all that. |
| 15:36:11 | *** | Saving seen data "./dancer.seen" |
| 16:00 |
| 16:10:04 | _bilgus_ | my concern would be depending on it and they go belly up or price us out |
| 16:11:02 | _bilgus_ | it says they are open source so does that mean we could host it ourselves if it had to be done or would it be a big ol mess? |
| 16:11:52 | _bilgus_ | If priced out that would be the MO i'm sure −− big hassle to leave == more paying customers |
| 16:13:21 | | Nick edward_ is now known as edward (~edward@user/edward) |
| 16:16:28 | __builtin | I (tangentially) know the guy that runs sr.ht |
| 16:16:48 | __builtin | very much a hardcore open-source guy like ourselves |
| 16:19:06 | __builtin | he also created KnightOS, which is basically rockbox for graphing calculators |
| 16:50:30 | braewoods | i would sooner trust someone that has actually contributed to the project over a random third party |
| 16:51:47 | braewoods | speaking of which i have available resources on my rented server |
| 16:52:48 | braewoods | i can arrange something if asked to, a container or something perhaps |
| 16:53:55 | braewoods | i have some public IPs available for container use |
| 16:54:15 | braewoods | would be hosted on a Canadian SYS server |
| 16:59:25 | munkis | my 2 cent is that although I like src.ht I much prefer gerrit (although the js requirement is annoying.) |
| 17:00 |
| 17:36:12 | *** | No seen item changed, no save performed. |
| 19:00 |
| 19:34:09 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:36:13 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:00:03 | | Quit _bilgus_ (*.net *.split) |
| 20:00:03 | | Quit Solanacean (*.net *.split) |
| 20:00:03 | | Quit akaWolf (*.net *.split) |
| 20:00:03 | | Quit dys (*.net *.split) |
| 20:00:12 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 20:00:20 | | Join Solanacean [0] (solanacean@31.44.51.141) |
| 20:01:55 | | Join _bilgus_ [0] (~bilgus@162.154.213.134) |
| 20:05:29 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 20:36:41 | speachy | __builtin: oh, to be sure migration will be a real bitch regardless. |
| 20:37:05 | speachy | but my question was more about workflow & tools vs what we're using today |
| 20:37:37 | speachy | and self-hosting is eminently doable |
| 20:37:59 | speachy | (as I mentioned, I'm going to try and spin up an instance for my own use..) |
| 21:00 |
| 21:13:12 | | Join borkitall [0] (~kyon@static-n58-105-201-24.bla4.nsw.optusnet.com.au) |
| 21:21:10 | speachy | __builtin: it's probably more accurate to charactarize him as a hardcore free software guy. :D |
| 21:21:44 | borkitall | hey just wanna point out a bug introduced in daily 2021-08-13 (6de6e1459d) for the hifi walker h2 |
| 21:22:30 | borkitall | the changelog says it should remove clicking sounds, however it intoduces clicking sounds for me when using an external dac |
| 21:23:04 | speachy | uh.. rockbox doesn't support external dacs, unless I've really missed something |
| 21:24:56 | borkitall | okay maybe im calling it a different thing, im using a fiio e07k |
| 21:27:16 | speachy | rockbox opens the "default" ALSA device. If the DAC works at all, it's purely accidental. Rockbox has no ability to switch output devices and is hardcoded to the capabilities of the built-in DAC. |
| 21:27:57 | speachy | assuming you have this thing connected to the H2 via the USB port (rather than the analog AUX port) |
| 21:30:27 | borkitall | okay its an amp/dac, im using it through the aux port on the h2 |
| 21:36:16 | *** | Saving seen data "./dancer.seen" |
| 21:37:20 | speachy | ok. so when do the clicks occur? |
| 21:41:35 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:44:04 | dconrad | I'm curious when clicking might occur, I definitely thought I had eliminated it in my testing |
| 21:44:54 | dconrad | headphone out I would think is quite a bit more susceptible than line out |
| 21:57:41 | borkitall | just when playing music normally |
| 21:58:38 | dconrad | not play/pause actions, but /while/ music is playing? |
| 22:00 |
| 22:01:29 | dconrad | is it a specific track? |
| 22:03:17 | borkitall | yeah, while playing music |
| 22:03:59 | borkitall | it happens on most songs i have, heavier ones like metal are more affected |
| 22:04:25 | speachy | volume affects it at all? |
| 22:04:55 | dconrad | ok, do me a favor, go into sound settings -> maximum volume limit and turn it to -14 dB, does it go away? |
| 22:05:18 | rb-bluebot | Build Server message: New build round started. Revision 3e52c7c734, 303 builds, 10 clients. |
| 22:05:50 | speachy | yeah, the H2's line out is _very_ hot |
| 22:06:24 | dconrad | I'm wondering if it's tracks that are so hot a 1 sample offset could clip them |
| 22:06:36 | dconrad | er, 1 "quantization unit" |
| 22:06:41 | speachy | yeah |
| 22:07:37 | dconrad | question is, if that is indeed the case, are we overloading the input to the amp or is it the track is clipping the 32-bit range |
| 22:08:57 | borkitall | clicking is still present when changing volume |
| 22:09:15 | dconrad | via the maximum volume limit? |
| 22:09:16 | borkitall | changing maximum volume limit to -14dB however seems to work |
| 22:09:24 | dconrad | ok, that's what I wondered |
| 22:09:47 | dconrad | normal volume doesn't have any effect when using line out |
| 22:09:53 | dconrad | but maximum volume does |
| 22:10:07 | dconrad | ok, so now increase it one step at a time. when does the problem occur? |
| 22:10:50 | | Quit j-r (Ping timeout: 250 seconds) |
| 22:12:35 | borkitall | sound is fine up to -2dB, changing it to 0dB introduces clicking |
| 22:12:44 | dconrad | yep, that's what I figured |
| 22:13:21 | dconrad | so, I would say for the time being -2dB would be the solution, but I suppose we'll have to fine-tune it so it doesn't occur at 0dB |
| 22:13:46 | dconrad | just not quite sure how to do that |
| 22:14:02 | borkitall | yeah thanks for the help |
| 22:14:14 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 22:14:26 | dconrad | for sure |
| 22:16:56 | dconrad | is there any chance you could specify a track it occurs for you on? I thought I tested it with a full-scale sine wave at 0dB, but maybe a dynamic "actual music" track would let me reproduce it here |
| 22:17:34 | rb-bluebot | Build Server message: Build round completed after 736 seconds. |
| 22:17:36 | rb-bluebot | Build Server message: Revision 3e52c7c734 result: All green |
| 22:24:32 | dconrad | looks like we don't have a 32-bit version of clip_sample_16(), that would have been the easy solution |
| 22:25:10 | | Quit _bilgus_ (Ping timeout: 240 seconds) |
| 22:25:28 | | Join j-r [0] (~j-r@p20030006215e7b47404207fffefd0a65.dip0.t-ipconnect.de) |
| 22:26:11 | borkitall | track 3 from this album https://classichiprock.bandcamp.com/album/coachella-valley-syndrome |
| 22:26:28 | borkitall | im using flac |
| 22:26:39 | dconrad | ok sweet, thanks |
| 22:31:34 | dconrad | wow, yeah that track uses ALL the pcm range |
| 22:33:28 | dconrad | pretty dope too, ngl |
| 22:33:29 | speachy | hmm. Given that we only actually care about the DC offset for "silent" samples, perhaps the DC offset hack should get pushed deeper into the PCM layer (eg the mixer?) so that it only affects "muted" output. |
| 22:34:33 | dconrad | so like, limit it to samples below a certain amplitude? |
| 22:34:36 | speachy | yeah |
| 22:34:58 | speachy | we should only need it at a literal zero sample. |
| 22:35:12 | dconrad | makes sense, though I'd be wary that the affected/not affected transition would cause a problem |
| 22:35:15 | speachy | anything non-zero won't trigger the DAC's auto-mute/shutdown |
| 22:35:37 | speachy | well, a 0-1/64K transition ought to not be audible anyway? |
| 22:35:49 | speachy | er, 1/32K |
| 22:36:24 | dconrad | hopefully, but I can't say I know one way or another |
| 22:38:18 | dconrad | why would it be beneficial to move it to the mixer? we could, I would think, do the same logic in the volume code |
| 22:38:39 | dconrad | if 0 do -1, otherwise unaffected |
| 22:39:06 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 22:39:29 | speachy | so a bandaid for the bandaid |
| 22:39:39 | dconrad | the other side of the coin is, we could try to handle overflow gracefully and clip it |
| 22:39:58 | dconrad | well, yeah, but the first bandaid is for something we don't have control over :-P |
| 22:40:10 | speachy | ..or just make the max vol -1 |
| 22:40:36 | dconrad | haha yeah that too |
| 22:40:47 | dconrad | well, -2 given the step size |
| 22:44:08 | dconrad | that does remind me though, we probably don't have any guarantee of 64-bit integer support on multiple targets, right? for example, the 16-bit volume code had a 32-bit integer to put the result into in case it needed clipping |
| 22:45:29 | dconrad | newer stuff I imagine is fine, but older, I could see it not being supported |
| 22:47:37 | | Quit massiveH (Ping timeout: 245 seconds) |
| 23:00 |
| 23:10:06 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 23:10:22 | speachy | the toolchain has int64_t (aka long long) but that's obviously going to be emulated |
| 23:11:00 | dconrad | probably not something you want performance-critical code using, in other words? |
| 23:11:09 | speachy | yeah |
| 23:12:10 | dconrad | not an issue at the moment, but I think it might be if we push high-bit-depth farther up into the mixer like you were thinking, because the volume code will (I think?) have to more resemble the original 16-bit method |
| 23:14:40 | dconrad | unless we drop the samples down to 16-bit before scaling, which... defeats the whole purpose |
| 23:31:53 | dconrad | we could do "if already at max range, don't add offset", though that has the potential for artifacts, I think... or maybe it's so small nobody would realistically hear it |
| 23:32:12 | dconrad | eh limiting the volume is probably the best way |
| 23:36:17 | *** | Saving seen data "./dancer.seen" |
| 23:48:22 | | Quit Moriar (Quit: Leaving.) |
| 23:51:55 | _bilgus | figure this was done on the supported devices long ago using an oscilloscope I'm sure geaverts or saratoga could spill the gest I always get the two mixed up |
icon identifies that the person is a core developer (has commit access).