| 00:06:42 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 00:11:00 | | Quit dconrad (Ping timeout: 256 seconds) |
| 00:41:09 | *** | Saving seen data "./dancer.seen" |
| 00:53:48 | rb-bluebot | Build Server message: New build round started. Revision 57293f1fd9, 303 builds, 9 clients. |
| 01:00 |
| 01:03:31 | rb-bluebot | Build Server message: Build round completed after 583 seconds. |
| 01:03:35 | rb-bluebot | Build Server message: Revision 57293f1fd9 result: All green |
| 01:55:33 | | Quit massiveH (Quit: Leaving) |
| 02:00 |
| 02:11:56 | | Quit akaWolf (Ping timeout: 258 seconds) |
| 02:41:10 | *** | Saving seen data "./dancer.seen" |
| 02:42:37 | | Join pablocastellanos [0] (~pidgin@user/pablocastellanos) |
| 03:00 |
| 03:58:55 | | Join akaWolf [0] (~akaWolf@akawolf.org) |
| 04:00 |
| 04:00:09 | | Quit michaelni (Quit: Leaving) |
| 04:03:22 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 04:03:28 | | Quit tchan (Read error: Connection reset by peer) |
| 04:04:09 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 04:06:50 | | Quit ufdm (Ping timeout: 272 seconds) |
| 04:13:00 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 04:41:13 | *** | Saving seen data "./dancer.seen" |
| 04:47:03 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:e912:d593:92b9:d6a8) |
| 06:00 |
| 06:18:21 | | Join lebellium [0] (~lebellium@2a01cb080996530039b9fe75bbd8a07a.ipv6.abo.wanadoo.fr) |
| 06:31:49 | | Quit Piece_Maker (Quit: ZNC 1.8.2 - https://znc.in) |
| 06:41:17 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:06:46 | | Quit danwellby (Ping timeout: 272 seconds) |
| 07:06:55 | | Join danwellby-1 [0] (~danwellby@88.97.8.245) |
| 07:07:10 | | Nick danwellby-1 is now known as danwellby (~danwellby@88.97.8.245) |
| 07:24:51 | | Quit danwellby (Ping timeout: 252 seconds) |
| 07:25:20 | | Join danwellby [0] (~danwellby@88.97.8.245) |
| 07:47:37 | | Join tomato [0] (~tomato@user/tomato) |
| 08:00 |
| 08:02:25 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 08:02:26 | | Quit dconrad (Remote host closed the connection) |
| 08:02:37 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 08:09:27 | | Join IPG [0] (~IPG@176.248.232.29) |
| 08:10:04 | dconrad | on the 32-bit software scaling patch, is the #define approach ok, or should the code do some logic based on passing around sizes/bit depths? |
| 08:10:26 | dconrad | I think its faster with it hardcoded with #defines probably |
| 08:11:07 | speachy | definitely #defines, since we won't have any reason to switch at runtime. |
| 08:11:16 | dconrad | ok, sweet |
| 08:11:33 | dconrad | I wasn't sure if there was a future-proofing reason you might want it more complex than that |
| 08:16:02 | dconrad | if you want to take a look at it, I think it's good to start review - it seems to work well for me |
| 08:16:44 | dconrad | I think I aught to look at the output on a scope just to double check it's not doing something wacky, but it sounds good to my ears |
| 08:17:03 | dconrad | very clean all the way down to subaudible |
| 08:20:26 | _bilgus | so what it end up being (noise) was it the shifted samples or a group effort? |
| 08:21:39 | speachy | you still have at 16-bit clip in pcm_scale_buffer_boost() |
| 08:22:19 | speachy | d'oh, looking at the wrong set |
| 08:22:29 | dconrad | yeah, I've hardcoded the scaling function to the pcm_scale_buffer_cut() |
| 08:22:48 | speachy | so why the /20 instead of /10 in pcm_set_master_volume? |
| 08:22:49 | dconrad | since, to my understanding, we're limited to <= 0 dB |
| 08:23:32 | dconrad | that goes back to my testing on the eros Q hosted, it was guess-and-check until the output level made sense if I recall |
| 08:23:52 | speachy | we're telling the UI one scale but telling the volume code another |
| 08:24:14 | speachy | ought to get to the root of that and fix it properly |
| 08:25:17 | dconrad | bilgus: on eros q? |
| 08:27:01 | speachy | I'd get rid of a bunch of #ifdefs related to sample size with something like #define PCM_SIZE_T int32_t |
| 08:27:38 | braewoods | speachy: isn't that better done with a typedef? |
| 08:27:39 | speachy | and instead of (size * 2) (sizeof (PCM_SIZE_T)/sizeof(int16_t) |
| 08:28:15 | dconrad | will that multiply/divide properly? |
| 08:28:21 | dconrad | or will it just truncate? |
| 08:28:22 | braewoods | i sometimes see macros defined that could be done with an enum or typedef |
| 08:28:24 | braewoods | it's weird |
| 08:28:39 | speachy | since we only use 32-bit or 16-bit sizes, no issues there |
| 08:29:01 | speachy | makes the logic in the code more apparent since we describe teh general case instead of multiple special cases |
| 08:29:15 | dconrad | hm, I'll give it a shot |
| 08:29:46 | speachy | and the compiler will optimize away those constant expressions at compile time |
| 08:31:18 | dconrad | so if I understand correctly, on pcm_sw_volume.c line 343, instead of doing a define check, just do src_buf_rem = sizeof (PCM_SIZE_T)? |
| 08:31:28 | dconrad | I don't think that's right |
| 08:32:12 | speachy | also, in pcm_sync_pcm_factors() we want to use the UNITY case too, so the #ifdef should only exclude the boost mode. |
| 08:32:48 | speachy | (IMO we should include boost in this too, since the 16-bit code does, but that's a separate discussion) |
| 08:32:58 | dconrad | will unity work correctly, given we need to multiply it up to 32 bits? |
| 08:33:08 | dconrad | or will it jump down to 16 bit levels? |
| 08:33:34 | speachy | FACTOR_UNITY is 1.0 ie a no-op ie memcpy(). |
| 08:33:48 | speachy | but boost can cause clipping in 16-bit too; depends on the input signal. |
| 08:34:09 | speachy | not something that's generally recommended if you care about audio quality :) |
| 08:34:18 | dconrad | right, and we need to upscale each sample from 16-bit to 32, so I don't think memcpy() is going to do what we want? |
| 08:34:35 | speachy | oooh yeah you're right |
| 08:34:51 | speachy | document that in a comment please. |
| 08:34:58 | dconrad | will do |
| 08:35:19 | dconrad | also, complete side note, it looks like memcpy is commented out? or it's defined somewhere else |
| 08:35:29 | speachy | (ie document this for the next idiot that comes along and wonders wtf the code is written that way) |
| 08:35:43 | dconrad | haha yeah |
| 08:36:11 | speachy | commented out where? |
| 08:36:31 | dconrad | uh, line 82 |
| 08:36:50 | dconrad | it must be defined in another file? |
| 08:37:10 | speachy | yeah, it's part of string.h |
| 08:37:29 | speachy | which I guess is pulled in as part some other header |
| 08:37:47 | speachy | just nuke that please |
| 08:38:00 | dconrad | will do |
| 08:38:51 | speachy | awesome work btw |
| 08:39:09 | dconrad | so what was that about using PCM_SIZE_T? I didn't quite understand |
| 08:39:12 | dconrad | (thank you!) |
| 08:39:40 | dconrad | you want to cast it instead of multiplying/dividing? |
| 08:39:49 | speachy | #ifdef USE_SW_VOL32 #define PCM_SIZE_T int32_t #else #define PCM_SIZE_T int16_t #endif |
| 08:40:17 | speachy | so you can get rid of the stuff like L85 or L127 |
| 08:40:39 | speachy | and do a simple 'PCM_SIZE_T *d =dst;' for all cases |
| 08:40:40 | dconrad | oh I see |
| 08:41:09 | dconrad | I thought you meant for the multiplying/dividing of the size variable for a minute |
| 08:41:10 | speachy | in this case we can use a typedef I suppose. I'm _really_ not a fan of typedefs for complex types. |
| 08:41:20 | *** | Saving seen data "./dancer.seen" |
| 08:42:06 | speachy | well, that too. eg L254 becomes int count = size * ((sizeof(PCM_SIZE_T)/sizeof(uint16_t)) / samplesize |
| 08:42:45 | dconrad | oh, I think I get it |
| 08:43:03 | speachy | that sizeof/sizeof will get compile-time optimized to a static 4/2 or 2/2 ie * 2 or * 1, the latter of which will get optimized out completely. |
| 08:43:05 | dconrad | if they're equal, it's 1, if not it's 2 |
| 08:43:27 | dconrad | potentially expandable to an arbitrary value |
| 08:43:54 | speachy | there's that but it's mostly to try and cut down on #ifdef proliferation |
| 08:44:31 | speachy | hmm |
| 08:44:52 | speachy | actually with update_frame_params, won't samplesize be constant at compile-time? |
| 08:45:51 | speachy | why not just just PCM_VOL_SAMPLE_SIZE in that function instead of adding it as a parameter? |
| 08:45:51 | dconrad | yeah, though I thought that might be useful in the future |
| 08:46:02 | speachy | we're never going to switch at runtime |
| 08:46:07 | dconrad | alright |
| 08:46:19 | dconrad | yeah it can be hardcoded |
| 08:48:45 | speachy | sorry if this comes off as nitpicking, but code clarity/maintainability usually important than cleverness |
| 08:49:01 | dconrad | no I get it |
| 08:49:33 | speachy | and as has been demonstrated many times over by now, the original authors of <whatever> don't stick around forever.. |
| 08:50:45 | speachy | heh, and to echo gevaerts from yesterday, I've been doing this sort of crap long enough that the answer to "what idiot wrote this pile of garbage?" has been me, more times than I'm comfortable admitting |
| 08:51:09 | dconrad | hah |
| 08:51:58 | speachy | it doesn't help that rockbox is genuinely complex in many places and has required a _lot_ of cleverness to make things fit in/work with the available resources. |
| 08:52:27 | dconrad | yeah I imagine some of the early devices didn't give a lot of options |
| 08:52:58 | braewoods | speachy: is there a reason rockbox uses its own memcpy when we could use the smart version GCC provides? |
| 08:53:00 | speachy | the erosq has several orders of magnitude more resources than original targets |
| 08:54:37 | braewoods | __builtin_memcpy is capable of inlining simple memcpy jobs and such instead of calling the function |
| 08:54:42 | speachy | braewoods: size and performance. I don't know if it still matters |
| 08:55:29 | braewoods | i was reading some libraries use memcpy for small unaligned copies, relying on the compiler to optimize it into native instructions for small loads of <= the largest integer size it can handle |
| 08:55:40 | braewoods | or something like that |
| 08:55:49 | speachy | keep in mind we have asm-optimized memcpy for most (all?) of our CPUs too |
| 08:56:14 | braewoods | indeed but this could be useful for small copy operations |
| 08:56:19 | braewoods | <= 4 bytes at a time |
| 08:56:34 | braewoods | question is, how common is that? |
| 08:56:53 | braewoods | this is how glibc works, it have a library version and a compiler version. |
| 08:56:55 | speachy | pretty rare, I'd wager. |
| 08:57:06 | braewoods | which gets used depends on the circumstances |
| 08:57:29 | speachy | optimized memcpys only really help at larger sizes, at small sizes the overhead of the checks to see if things can be optimized is slower than just doing it the naive way. |
| 08:57:53 | speachy | (and what constitutes large/small is highly implementation-dependent) |
| 08:58:21 | braewoods | i imagine my deflate code will probably run best on newer SOCs than coldfire |
| 08:58:28 | braewoods | coldfire runs it pretty slow |
| 08:58:31 | braewoods | no idea why |
| 08:58:51 | speachy | no D$ makes a huge difference. |
| 08:59:20 | braewoods | yea, plan9's inflate has a lot of lookup tables that help with speed but... |
| 08:59:27 | speachy | but remember performace isn't the primary consideration here; it just has to be "fast enough" |
| 08:59:46 | braewoods | well it's probably about as good as coldfire is going to be. |
| 09:00 |
| 09:00:03 | braewoods | it was getting maybe 500 kilobytes a second of decompression |
| 09:00:45 | braewoods | not worth optimizing when most of our users are prefering newer hardware |
| 09:01:08 | braewoods | i'll work on finishing the ZIP integration later |
| 09:01:10 | braewoods | add some UI stuff |
| 09:01:49 | braewoods | speachy: yea true. it took awhile to fine tune the inflate code enough. it's very fast on x86 but x86 also has a lot more caching. |
| 09:02:06 | braewoods | the ram requirements make it usable everywhere which was my primary concern |
| 09:02:23 | braewoods | like 76k at most of non-code memory |
| 09:03:24 | speachy | where/when will this decompression be taking place? during playback? |
| 09:03:48 | braewoods | that wasn't planned. |
| 09:03:49 | speachy | if we can guarantee no playback at the time, you can use the codec or primary buffer space for tables |
| 09:04:00 | speachy | static tables can be loaded from disk |
| 09:04:13 | braewoods | the static tables don't occupy that much space. |
| 09:04:18 | braewoods | maybe 500 bytes |
| 09:04:28 | braewoods | most of them are generated on the fly |
| 09:04:34 | braewoods | from the input stream |
| 09:04:57 | braewoods | and even that can be reduced by using smaller integers |
| 09:05:09 | braewoods | most of the table contents can be shoved into 16 bits or less |
| 09:05:47 | braewoods | the huffman tables are the main lookup tables that are generated on the fly |
| 09:06:00 | braewoods | the rest are fast lookup for values that don't vary with the input stream |
| 09:06:20 | braewoods | the static tables, some people cache them but i don't bother because it's rare to find them in actual deflate streams. |
| 09:06:28 | braewoods | static huffman tables* |
| 09:06:37 | braewoods | that saves about 8k of space. |
| 09:07:10 | braewoods | most real compressed streams use the dynamic tables which always have to be recreated |
| 09:08:11 | braewoods | speachy: originally i envisioned this for support of extracting to disk. which technically has no performance requirements. |
| 09:08:24 | braewoods | it's just whatever we can manage. |
| 09:08:36 | speachy | there ya have it. |
| 09:08:55 | braewoods | i optimized it a bit on x86 but not elsewhere |
| 09:09:13 | braewoods | mostly some general stuff to reduce time spend on pointless checks |
| 09:09:24 | speachy | the point being that we can't statically pre-allocate lots of space or rely on the stack |
| 09:09:39 | braewoods | yes, i designed with that in mind |
| 09:09:40 | speachy | but we can pull it from the codec or buffer heaps |
| 09:09:55 | braewoods | the inflate allocates all its larger objects in a single large allocation chunk |
| 09:10:02 | braewoods | the rest is stack allocated |
| 09:10:03 | speachy | and reliably have a whopping MEGABYTE (!!) to play with |
| 09:10:19 | braewoods | how that gets allocated is up to the caller |
| 09:10:49 | braewoods | i thought that a wise implementation choice |
| 09:11:00 | braewoods | since this code might be used by more than my original intention |
| 09:11:25 | braewoods | it may just be this algorithm is going to be slow on coldfire just by its very nature |
| 09:11:44 | braewoods | deflate requires a lot of hard to optimize stuff like a software "shift register" |
| 09:11:49 | braewoods | since part of the stream is bit packed |
| 09:12:21 | braewoods | the main improvement i did was to the byte copying loops |
| 09:12:29 | braewoods | significant speed up |
| 09:12:33 | speachy | there aren't a lot of coldfire devices out there (eg in comparison to ipods) |
| 09:12:50 | speachy | c |
| 09:13:01 | braewoods | indeed |
| 09:13:02 | speachy | hence "good enough" |
| 09:13:28 | braewoods | i was also considering adding an option for rockbox to decompress ZIP payloads for upgrades |
| 09:13:31 | speachy | the newest one was made what, fifteen years ago? |
| 09:13:42 | speachy | if not longer |
| 09:14:11 | braewoods | zip support could be useful since we ship most of our files in zip files |
| 09:14:29 | braewoods | in any case the bare minimum is going to be UI zip extraction |
| 09:14:44 | braewoods | i made the parts modular so we could use inflate elsewhere and such |
| 09:14:53 | braewoods | independent of zip |
| 09:15:16 | braewoods | make it a plugin API at some point perhaps? |
| 09:15:19 | * | braewoods shrugs. |
| 09:15:26 | speachy | putting on my "infrascture maintainer" hat the notion of growing our distributed zip file sizes isn't appealing |
| 09:15:35 | speachy | (ie by using less efficient compression) |
| 09:15:43 | braewoods | like deflate? |
| 09:16:03 | braewoods | i already know a simple way we can reduce our ZIP files |
| 09:16:34 | braewoods | our zip files include extra stuff we don't strictly need |
| 09:16:50 | braewoods | with some extra args to zip we can stop generating them. |
| 09:16:54 | braewoods | that'll help a small bit |
| 09:17:09 | braewoods | speachy: i assume we already use -9? |
| 09:17:34 | braewoods | there's advzip for recompressing zip files. that could be useful for our archives. |
| 09:17:57 | braewoods | -4z uses the very slow zopfli engine for optimizing the deflate stream |
| 09:18:15 | braewoods | it can achieve better rates. |
| 09:18:38 | speachy | ok, deflate is what everyone uses, I was thinking of somehing else. |
| 09:19:03 | braewoods | deflate is convenient for compatibility. |
| 09:19:20 | braewoods | if you want to reduce the size of existing zip archives without losing that |
| 09:19:27 | braewoods | zopfli is pretty much the only option |
| 09:19:53 | braewoods | let me try advzip on a 3.15 zip |
| 09:20:37 | speachy | I wonder how common bzip2 support is for zip decompressors |
| 09:20:54 | speachy | given it was formally part of the spec a decade ago. |
| 09:21:01 | speachy | two decades ago I mean |
| 09:21:08 | braewoods | well in my experience DEFLATE is the only one that's guaranteed |
| 09:21:15 | braewoods | plus bzip2 is even slower. |
| 09:21:35 | braewoods | i just started advzip. |
| 09:21:38 | braewoods | i'll see how well it does. |
| 09:21:44 | braewoods | it's very slow obviously. |
| 09:22:07 | braewoods | it tries to brute force more optimal compressed representations |
| 09:22:12 | braewoods | or so i understand |
| 09:22:41 | braewoods | speachy: https://dpaste.com/2EK68UJF2 |
| 09:22:57 | braewoods | might be worth trying on our archives if you want to squeeze out a few more % |
| 09:22:58 | speachy | hah! bzip2 made the archive larger. |
| 09:23:22 | braewoods | i wouldn't use it for anything but production builds though |
| 09:23:31 | braewoods | it's too slow for regular use. |
| 09:25:03 | speachy | a straight tar.gz (with gzip-9) is about 5% smaller. |
| 09:27:11 | braewoods | speachy: we can't use xz on device; ram requirements |
| 09:27:17 | speachy | gz, not xz |
| 09:27:21 | braewoods | i know |
| 09:27:27 | braewoods | but if you were considering it or lzma |
| 09:27:47 | braewoods | there's one major drawback to tar though |
| 09:27:56 | braewoods | you can't seek through it |
| 09:28:25 | speachy | but tar.xz is only 60% the size of zip. :) |
| 09:29:05 | speachy | but if we're only using these archives in a "extract everything" mode then seeking doesn't matter |
| 09:29:11 | braewoods | zip has one major speed advantage. you can seek through it. |
| 09:29:17 | braewoods | indeed |
| 09:29:25 | braewoods | we do have microtar in the base now. |
| 09:29:29 | speachy | zip'd design _requires_ seeking |
| 09:29:46 | braewoods | with the inflate algorithm, we can support tar.gz now |
| 09:30:10 | braewoods | i included support for both the zlib and gzip containers |
| 09:30:29 | braewoods | gzip is slower to extract due to involving crc32 |
| 09:30:35 | braewoods | zlib uses the faster adler option |
| 09:31:25 | braewoods | zip's main advantage is its ubiquity |
| 09:31:39 | braewoods | it is used as the basis of a lot of file types that need to store multiple files |
| 09:31:50 | braewoods | but two easy options we could do to reduce archive size... |
| 09:32:08 | speachy | we already do zip -9 in our build script btw |
| 09:32:41 | braewoods | indeed |
| 09:33:03 | braewoods | we could use zopfli to further optimize space usage but that's not too effective for zip |
| 09:33:09 | braewoods | it's far more effective on PNG in my experience |
| 09:35:22 | dconrad | speachy: I think g#3669 is all up to spec now if you want to look through again, it works A-OK for me |
| 09:35:24 | rb-bluebot | Gerrit review #3669 at https://gerrit.rockbox.org/r/c/rockbox/+/3669 : Higher bitdepth software volume scaling by Dana Conrad |
| 09:35:46 | braewoods | speachy: if you add -X to the zip command, you strip out 24 bytes per entry |
| 09:36:04 | braewoods | saving like 8k on the total size for our typical archives |
| 09:36:25 | braewoods | it's unix timestamps or so, something we don't really need. |
| 09:36:49 | speachy | will that cause any issues with $random_zip_decompressors? |
| 09:38:28 | braewoods | speachy: probably not? it's part of the extra fields which i actually ignore in my code since it's nothing i need. |
| 09:38:41 | braewoods | this just tells zip not to generate them. |
| 09:38:50 | braewoods | or add them |
| 09:39:08 | braewoods | i can't see why it would cause issues, being absent. |
| 09:41:13 | speachy | dconrad: ok, one more thing −− PCM_SW_VOLUME_BITDEPTH/HAVE_SWVOL_32 probably need to be renamed |
| 09:41:34 | speachy | the former is perhaps better called PCM_NATIVE_BITDEPTH |
| 09:41:38 | braewoods | i stand corrected. -X reduces the size by about 20k |
| 09:42:03 | braewoods | depends how many entries you have. |
| 09:42:05 | dconrad | hm, yeah I can do that, though the originals make sense to me |
| 09:42:08 | braewoods | oh right, it gets doubled. |
| 09:42:12 | * | braewoods facepalms. |
| 09:43:01 | speachy | and you might be able to just drop HAVE_SWVOL_32 altogether, and key off PCM_NATIVE_BITDEPTH? |
| 09:43:13 | braewoods | speachy: so you can save around 22k if you use -X and -D together it seems. |
| 09:43:24 | speachy | that's 22K out of 3.8MB. :) |
| 09:43:26 | braewoods | -D eliminates directory listings since you don't strictly need them |
| 09:43:37 | braewoods | -X eliminates extra metadata info |
| 09:43:52 | braewoods | speachy: yea but it adds up. lol |
| 09:44:07 | braewoods | i'd only enable -X though if i was being serious |
| 09:44:18 | dconrad | my thought was that it would limit confusion if the whole functionality was expressly turned on/off with a single HAVE_SWVOL_32 define |
| 09:44:43 | dconrad | just to make it obvious how to use it? |
| 09:45:33 | dconrad | the bit depth is set by default to 32 if not set in the port-specific code |
| 09:47:02 | dconrad | maybe HAVE_SWVOL_32 could be HAVE_SOFTWARE_VOL_32BIT? |
| 09:47:38 | dconrad | or HAVE_SWVOL_NATIVE_BITDEPTH even, though that seems weird |
| 09:48:10 | speachy | trying to think what makes the most sense in the medium term |
| 09:49:04 | speachy | ie when we have >16bit capabilities at the mixer/dsp layer |
| 09:50:46 | speachy | I can't see a scenario where we'd use one without the other |
| 09:51:36 | dconrad | well, excepting bypassing the whole thing because the target has hardware volume control |
| 09:51:52 | speachy | then we'd not use swvol at all. |
| 09:51:56 | dconrad | right |
| 09:52:05 | speachy | so it would be both, or none |
| 09:52:24 | dconrad | yeah I suppose I could drop HAVE_SWVOL_32 |
| 09:52:54 | dconrad | just need people to know that if they define PCM_NATIVE_BITDEPTH it's going to switch them over completely to this system |
| 09:53:03 | dconrad | rather than the normal scaling |
| 09:53:03 | speachy | if the hardware hs native 24/32-bit PCM, and hwvol, some other code path would have to do the upscaling/conversion |
| 09:53:50 | speachy | I'd make it so that #indef PCM_NATIVE_BITDEPTH #define PCM_NATIVE_BITDEPTH 16 |
| 09:54:27 | dconrad | I suppose that makes sense |
| 09:54:30 | speachy | and #if (PCM_NATIVE_BITDEPTH > 16) #define HAVE_SWVOL_32 (ie keeping the define purely within pcm_sw_volume.c) |
| 09:54:53 | dconrad | hm, ok yeah let me try that |
| 09:55:06 | speachy | since pcm_sw_volume won't even get compiled if HAVE_SW_VOLUME_CONTROL is not set |
| 09:57:04 | * | speachy is looking forward to ripping the 16-32-bit scaling out of the alsa driver in favor of this stuff |
| 09:57:19 | dconrad | lol |
| 09:58:09 | speachy | oh, and L70 in pcm-x1000.c should be keyed off PCM_NATIVE_VITDEPTH intead |
| 09:58:14 | speachy | BITDEPTH |
| 09:59:19 | dconrad | ok, I think I got all that |
| 09:59:27 | dconrad | testing |
| 10:00 |
| 10:00:20 | dconrad | oh, and I've been testing g#3633 all week and it's been a click-free experience |
| 10:00:22 | rb-bluebot | Gerrit review #3633 at https://gerrit.rockbox.org/r/c/rockbox/+/3633 : ErosQ Native: Add DC Offset to PCM data by Dana Conrad |
| 10:00:38 | dconrad | excepting turning on and off the device, intermittently |
| 10:05:48 | dconrad | looks like it's working, uploading a new patchset... |
| 10:06:55 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 10:10:15 | dconrad | speachy: newest patchset is uploaded, take a look |
| 10:11:35 | speachy | dconrad: hmm. make the change in pcm-x1000.c PCM_NATIVE_BITDEPTH > 16 |
| 10:11:59 | speachy | otherwise I tihnk it's sane |
| 10:12:04 | dconrad | alright |
| 10:12:17 | speachy | amachronic: any thoughts from you? |
| 10:12:24 | dconrad | maybe I should do == 24, because 18 is also an option? |
| 10:12:36 | amachronic | gave it a once over, looks sane to me |
| 10:12:52 | speachy | hmm. realistically, I don't think we'll ever do anyting other than 16/24/32 |
| 10:13:13 | speachy | or 16/24 in the case of the x1000 |
| 10:13:25 | dconrad | alright, though this patch should be able to cover anything as long as it's ok in a 32-bit container |
| 10:14:23 | speachy | I need to run to get some groceries; I'll commit the change (with that final fix) when I get back (unless amachronic wants to do it for me instead) |
| 10:14:40 | dconrad | sounds good |
| 10:15:53 | amachronic | speachy, no problem I'll do it |
| 10:18:20 | amachronic | dconrad, is g#3663 supposed to be a prereq? |
| 10:18:22 | rb-bluebot | Gerrit review #3663 at https://gerrit.rockbox.org/r/c/rockbox/+/3663 : Fix hosted glibc backtrace by Aidan MacDonald |
| 10:18:37 | dconrad | actually I was gonna ask you about that haha |
| 10:18:50 | amachronic | whoops that's wrong |
| 10:18:56 | amachronic | i mean 3633 |
| 10:19:06 | dconrad | I'm not sure if git would do it correctly if you didn't merge 3633 first |
| 10:19:18 | dconrad | but it does basically overwrite that functionality I suppose |
| 10:19:27 | dconrad | personally I would do 3633 first |
| 10:19:49 | dconrad | well, it has soft mute stuff in it too so probably should |
| 10:20:04 | amachronic | ok then |
| 10:21:05 | amachronic | any more last minute changes needed or should I merge now? |
| 10:21:15 | dconrad | I think I'm done |
| 10:21:27 | dconrad | gotta call it at some point |
| 10:21:49 | rb-bluebot | Build Server message: New build round started. Revision 56b0dde545, 303 builds, 10 clients. |
| 10:22:15 | amachronic | there it goes, that's both of them |
| 10:22:21 | dconrad | sweet, thanks |
| 10:22:32 | dconrad | does that queue them up, so it will build one after the other? |
| 10:23:03 | amachronic | lemme see |
| 10:23:45 | amachronic | apparently not, it's skipping 3633 |
| 10:24:04 | amachronic | must be 'cause I submitted the whole chain |
| 10:24:24 | dconrad | must be smarter than we give it credit for |
| 10:32:04 | rb-bluebot | Build Server message: Build round completed after 615 seconds. |
| 10:32:07 | rb-bluebot | Build Server message: Revision 56b0dde545 result: 0 errors 4 warnings |
| 10:32:18 | dconrad | hm |
| 10:33:29 | dconrad | oh, that should be easy to fix |
| 10:36:40 | * | braewoods fines dconrad for each warning. |
| 10:36:42 | braewoods | P |
| 10:36:44 | braewoods | ::P |
| 10:36:46 | dconrad | lol |
| 10:36:47 | braewoods | anyway |
| 10:37:02 | dconrad | I'll give you a nickel, max |
| 10:38:07 | braewoods | https://assets.amuniversal.com/6b08abb09fbb012f2fe600163e41dd5b |
| 10:38:55 | dconrad | and I stand by it! |
| 10:41:22 | *** | No seen item changed, no save performed. |
| 10:42:50 | dconrad | m3k is taking a lot longer to build than I remember |
| 10:43:00 | dconrad | there we go |
| 10:45:08 | dconrad | amachronic: could you look at g#3674? it should fix the warnings from 3669 |
| 10:45:10 | rb-bluebot | Gerrit review #3674 at https://gerrit.rockbox.org/r/c/rockbox/+/3674 : Fix warnings from 56b0dde545 by Dana Conrad |
| 10:47:36 | rb-bluebot | Build Server message: New build round started. Revision a2bbd1a549, 303 builds, 10 clients. |
| 10:47:55 | amachronic | got it, thanks |
| 10:58:32 | rb-bluebot | Build Server message: Build round completed after 656 seconds. |
| 10:58:34 | rb-bluebot | Build Server message: Revision a2bbd1a549 result: All green |
| 10:59:07 | dconrad | woohoo |
| 11:00 |
| 11:04:25 | rb-bluebot | Build Server message: New build round started. Revision eeb0aaf36f, 303 builds, 10 clients. |
| 11:09:12 | | Quit Moriar (Quit: Leaving.) |
| 11:12:44 | speachy | ok, back, breakfast in the oven. |
| 11:13:28 | rb-bluebot | Build Server message: Build round completed after 543 seconds. |
| 11:13:32 | rb-bluebot | Build Server message: Revision eeb0aaf36f result: All green |
| 11:14:44 | speachy | dconrad: the waning fix should have gone into config.h instead, see g#3677 |
| 11:14:46 | rb-bluebot | Gerrit review #3677 at https://gerrit.rockbox.org/r/c/rockbox/+/3677 : move PCM_NATIVE_BITDEPTH definiton into global config code by Solomon Peachy |
| 11:15:13 | speachy | hmm, or audiohw.h now that I think about it. |
| 11:15:40 | dconrad | ah, sorry about that |
| 11:16:35 | speachy | no worries |
| 11:17:32 | amachronic | and get rid of the one from pcm_sw_volume.c too |
| 11:18:27 | speachy | roger that, take three uploaded |
| 11:19:04 | speachy | doing quick sanity builds |
| 11:20:31 | speachy | ok, seems clean |
| 11:20:47 | rb-bluebot | Build Server message: New build round started. Revision 39fff5cb53, 303 builds, 10 clients. |
| 11:30:53 | rb-bluebot | Build Server message: Build round completed after 607 seconds. |
| 11:30:55 | rb-bluebot | Build Server message: Revision 39fff5cb53 result: All green |
| 11:36:51 | amachronic | g#3678, pretty certain it's an ancient 'typo' from this: https://github.com/Rockbox/rockbox/commit/eab7e747788bd633104019ab82bc75b384a95eff |
| 11:36:53 | rb-bluebot | Gerrit review #3678 at https://gerrit.rockbox.org/r/c/rockbox/+/3678 : tagcache: Don't treat tag_virt_basename as a numeric tag by Aidan MacDonald |
| 11:37:32 | speachy | seems so |
| 11:37:38 | amachronic | I'm not familiar with tagcache so I have no idea if there might be other breakage lurking. |
| 11:38:08 | speachy | ... given the persistent reports of seemingly random issues with the tagcache, it's possible this is one of the causes |
| 11:38:27 | speachy | (puttiting aside the iflash-induced corruption anyway..) |
| 11:39:45 | amachronic | the comment above TAGCACHE_NUMERIC suggests only numeric tags can be used in tagnavi conditionals so I'm thinking maybe this needs to be added to wherever the conditionals are handled |
| 11:41:35 | speachy | there are a lot of places TAGCACHE_IS_NUMERIC is checked |
| 11:43:16 | amachronic | that comment might be wrong since it looks like strings _are_ handled if I'm not mistaken |
| 11:44:10 | speachy | numeric comparisons don't make sense for strings |
| 11:45:14 | amachronic | check_against_clause() in tagcache.c |
| 11:46:32 | speachy | strings are handled, yes −− but clause->numeric is what determines how things are handled |
| 11:46:48 | speachy | ->numeric is set based on TAGCACHE_IS_NUMERIC |
| 11:47:21 | speachy | also check out tagcache.c L1113 |
| 11:47:57 | speachy | the comparison to tag_virt_basename is checked only if !IS_NUMERIC |
| 11:48:12 | amachronic | i know my concern was somebody added it there thinking 'this is needed to use it in comparisons' based on that comment |
| 11:48:36 | amachronic | but it looks like everything is already handled properly |
| 11:52:20 | rb-bluebot | Build Server message: New build round started. Revision cf3fa437fc, 303 builds, 10 clients. |
| 11:54:43 | speachy | ok, fixed the front page recent wiki stuff so it ignores internal administrative crap |
| 12:00 |
| 12:02:01 | rb-bluebot | Build Server message: Build round completed after 581 seconds. |
| 12:02:04 | rb-bluebot | Build Server message: Revision cf3fa437fc result: All green |
| 12:03:22 | rb-bluebot | Build Server message: New build round started. Revision 5311ff0173, 303 builds, 10 clients. |
| 12:13:10 | | Quit yosafbridge (Quit: Leaving) |
| 12:19:12 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 12:19:19 | rb-bluebot | Build Server message: Build round completed after 956 seconds. |
| 12:19:21 | rb-bluebot | Build Server message: Revision 5311ff0173 result: All green |
| 12:23:04 | dconrad | speachy: could I add some info about the eros Q native to wiki? |
| 12:24:02 | dconrad | it's nearly done (for my purposes), and the only big thing missing is dual boot |
| 12:24:55 | dconrad | but it should be genuinely useable for someone who doesn't care about dual boot |
| 12:40:58 | dconrad | and now that my patches are merged, I do think the audio situation is better on native |
| 12:41:26 | *** | Saving seen data "./dancer.seen" |
| 12:48:21 | speachy | dconrad: I think the audio situatiou will be comparable once the alsa driver picks up the improved swvol stuff, but absolutely, document away |
| 12:49:03 | dconrad | sweet - could you make an account for me? I believe registrations are disabled |
| 12:49:19 | speachy | unlike the m3k (whose OF was a raging dumpster fire) the erosq is decent enough, and I can see why folks would want to retain dual-booting (or at least have a path back to a dual-boot solution) |
| 12:49:31 | speachy | ok to use the email address in your commits? |
| 12:49:37 | dconrad | yeah |
| 12:49:59 | speachy | ok, gimme a little bit, alternating back and forth with meatspace tasks |
| 12:50:06 | dconrad | no hurry |
| 12:50:14 | dconrad | lol meatspace |
| 12:51:29 | | Quit yosafbridge (Quit: Leaving) |
| 12:52:33 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 12:55:20 | spork | could you not borrow dual-boot inspiration from the m3k/q1 ? |
| 12:55:33 | spork | or are not all x1000's created alike |
| 12:56:03 | dconrad | as I understand it, it will follow the same idea, but it needs to be specific to the device |
| 12:56:39 | dconrad | I guess the original firmwares in both use different loaders, so it might get weird |
| 12:57:49 | spork | eros-q is uboot ? |
| 12:58:59 | dconrad | hm, I think? can't remember haha |
| 12:59:15 | dconrad | I remember it was different from m3k |
| 13:00 |
| 13:00:07 | dconrad | yeah according to the old disassembly thread it was u-boot |
| 13:03:59 | spork | dual boot is nice as long as there are features in the of that rockbox does bot support like usb-dac functionality |
| 13:04:05 | spork | *not |
| 13:04:58 | dconrad | I agree - I think the two real killer features are usb-dac and bluetooth. Someday maybe rockbox will support them. Someday... |
| 13:06:01 | spork | for regular music playback rockbox is so much nicer on m3k/q1 |
| 13:06:05 | dconrad | I'm just not super eager to delve back into the linux binary haha |
| 13:06:35 | spork | one of the biggest differende imo is the playlist handling |
| 13:07:45 | dconrad | you know how everybody has that /one/ killer feature that brings them to some piece of software? That feature in rockbox for me was... bookmarking |
| 13:08:06 | dconrad | something so simple, yet it makes a huge difference, and no other firmwares seem to care to implement it |
| 13:08:40 | spork | true, i used it all the time for audio books |
| 13:10:14 | spork | too bad it is not working properly on the q1 |
| 13:10:46 | dconrad | how so? |
| 13:11:01 | dconrad | I don't think there's much there that's port-specific |
| 13:11:14 | spork | bookmarking works, the touchscreen 'prompt' does not |
| 13:11:24 | dconrad | the yes/no screen? |
| 13:11:26 | spork | ye |
| 13:11:30 | dconrad | ah |
| 13:11:39 | dconrad | I think you can turn that off if you wanted |
| 13:11:48 | spork | the buttons briefly flash on the screen and then dissapear |
| 13:12:18 | spork | i like the prompt feature |
| 13:12:24 | dconrad | did you try pressing "ok" anyway? that happens on erosq and m3k for me as well, but it will still accept yes or no inputs |
| 13:12:35 | dconrad | not sure what "ok" is on a touchscreen though |
| 13:12:36 | spork | press where ? |
| 13:12:46 | dconrad | yeah not sure |
| 13:13:14 | spork | pressing anywhere on screen is 'yes', luckily pressing the volume wheel button is 'no' |
| 13:13:23 | spork | so there is a way to manage |
| 13:13:44 | dconrad | so it doesn't accept a 'yes'? |
| 13:13:55 | spork | amachronic has even more problems with that yes/no screen |
| 13:14:14 | dconrad | haha I've had my own problems with it too |
| 13:14:14 | spork | for me only in that bookmark prompt |
| 13:14:35 | spork | everywhere else, i.e. deleting a file, it renders/works fine |
| 13:16:42 | spork | i have a fistfull of sansa's that have more buttons and where it works fine |
| 13:16:46 | spork | while they last |
| 13:17:19 | dconrad | yeah rip good sansas |
| 13:17:37 | dconrad | I still have my clip+, though now it's half broken I think |
| 13:23:54 | | Quit amachronic (Ping timeout: 276 seconds) |
| 13:33:08 | | Join anon [0] (~goose@user/anon) |
| 13:37:51 | | Quit dconrad (Remote host closed the connection) |
| 13:53:36 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 13:57:59 | | Quit dconrad (Ping timeout: 252 seconds) |
| 14:00 |
| 14:32:05 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 14:41:29 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:13:50 | | Join sadjhflj333 [0] (~sadjhflj3@097-088-119-211.res.spectrum.com) |
| 15:44:49 | | Quit dconrad (Remote host closed the connection) |
| 16:00 |
| 16:00:33 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 16:04:55 | | Quit dconrad (Ping timeout: 258 seconds) |
| 16:15:52 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 16:26:51 | | Quit dconrad (Remote host closed the connection) |
| 16:35:04 | | Quit sadjhflj333 (Remote host closed the connection) |
| 16:36:22 | | Join sadjhflj333 [0] (~sadjhflj3@097-088-119-211.res.spectrum.com) |
| 16:37:45 | | Quit sadjhflj333 (Remote host closed the connection) |
| 16:41:30 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:08:43 | rb-bluebot | Build Server message: New build round started. Revision da778a1783, 303 builds, 10 clients. |
| 17:20:09 | | Join sadjhflj333 [0] (~sadjhflj3@097-088-119-211.res.spectrum.com) |
| 17:22:47 | rb-bluebot | Build Server message: Build round completed after 845 seconds. |
| 17:22:50 | rb-bluebot | Build Server message: Revision da778a1783 result: All green |
| 17:22:55 | rb-bluebot | Build Server message: New build round started. Revision 0a6d7abd13, 303 builds, 10 clients. |
| 17:23:17 | | Quit sadjhflj333 (Client Quit) |
| 17:31:40 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 17:33:52 | rb-bluebot | Build Server message: Build round completed after 656 seconds. |
| 17:33:54 | rb-bluebot | Build Server message: Revision 0a6d7abd13 result: All green |
| 17:37:00 | anon | Is it possible to customize centre frequencies on the equalizer of the clip+? The selector goes in intervals of 10, but I am following an AutoEQ for my headphones. If I made a file with custom amounts and imported that to the clip+ would that work? What is the formatting of that file? |
| 17:42:46 | | Quit dconrad (Remote host closed the connection) |
| 17:56:36 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 17:56:43 | | Quit dconrad (Client Quit) |
| 17:57:29 | _bilgus | it probably is but that is more specialized than i know anon |
| 17:57:48 | _bilgus | personally I do everything flat |
| 18:00 |
| 18:27:18 | | Quit lebellium (Quit: Leaving) |
| 18:41:32 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:18:04 | | Join S|h|a|w|n [0] (~shawn156@c-76-25-73-212.hsd1.co.comcast.net) |
| 19:18:04 | | Quit S|h|a|w|n (Changing host) |
| 19:18:04 | | Join S|h|a|w|n [0] (~shawn156@user/shawn/x-4432647) |
| 19:23:41 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:46:45 | | Join sadjhflj333 [0] (~sadjhflj3@097-088-119-211.res.spectrum.com) |
| 20:00 |
| 20:40:19 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 20:41:34 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:04:14 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:17:13 | | Quit dconrad (Remote host closed the connection) |
| 21:21:08 | speachy | dconrad: wiki account created |
| 21:32:56 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:37:06 | | Quit dconrad (Ping timeout: 240 seconds) |
| 21:49:44 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 22:00 |
| 22:38:50 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 22:39:22 | dconrad | speachy: thanks |
| 22:41:35 | *** | Saving seen data "./dancer.seen" |
| 22:45:44 | | Quit massiveH (Quit: Leaving) |
| 22:46:04 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 23:00 |
| 23:02:24 | | Quit skipwich (Read error: Connection reset by peer) |
| 23:20:41 | | Quit _bilgus (Quit: Leaving) |
| 23:27:07 | | Quit Maxdamantus (Ping timeout: 268 seconds) |
| 23:28:24 | | Join Maxdamantus [0] (~Maxdamant@user/maxdamantus) |
| 23:35:49 | | Quit dconrad (Remote host closed the connection) |
icon identifies that the person is a core developer (has commit access).