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

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: 3New build round started. Revision 57293f1fd9, 303 builds, 9 clients.
01.03.31 #       <rb-bluebot> Build Server message: 3Build round completed after 583 seconds.
01.03.35 #       <rb-bluebot> Build Server message: 3Revision 57293f1fd9 result: All green
01.55.33 Quit    massiveH (Quit: Leaving)
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.58.55 Join    akaWolf [0] (~akaWolf@akawolf.org)
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.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.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.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.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> 3Gerrit review #3669 at https://gerrit.rockbox.org/r/c/rockbox/+/3669 : 3Higher 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.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> 3Gerrit review #3633 at https://gerrit.rockbox.org/r/c/rockbox/+/3633 : 3ErosQ 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> 3Gerrit review #3663 at https://gerrit.rockbox.org/r/c/rockbox/+/3663 : 3Fix 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: 3New 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: 3Build round completed after 615 seconds.
10.32.07 #       <rb-bluebot> Build Server message: 3Revision 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> 3Gerrit review #3674 at https://gerrit.rockbox.org/r/c/rockbox/+/3674 : 3Fix warnings from 56b0dde545 by Dana Conrad
10.47.36 #       <rb-bluebot> Build Server message: 3New build round started. Revision a2bbd1a549, 303 builds, 10 clients.
10.47.55 #       <amachronic> got it, thanks
10.58.32 #       <rb-bluebot> Build Server message: 3Build round completed after 656 seconds.
10.58.34 #       <rb-bluebot> Build Server message: 3Revision a2bbd1a549 result: All green
10.59.07 #       <dconrad> woohoo
11.04.25 #       <rb-bluebot> Build Server message: 3New 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: 3Build round completed after 543 seconds.
11.13.32 #       <rb-bluebot> Build Server message: 3Revision 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> 3Gerrit review #3677 at https://gerrit.rockbox.org/r/c/rockbox/+/3677 : 3move 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: 3New build round started. Revision 39fff5cb53, 303 builds, 10 clients.
11.30.53 #       <rb-bluebot> Build Server message: 3Build round completed after 607 seconds.
11.30.55 #       <rb-bluebot> Build Server message: 3Revision 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> 3Gerrit review #3678 at https://gerrit.rockbox.org/r/c/rockbox/+/3678 : 3tagcache: 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: 3New 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.02.01 #       <rb-bluebot> Build Server message: 3Build round completed after 581 seconds.
12.02.04 #       <rb-bluebot> Build Server message: 3Revision cf3fa437fc result: All green
12.03.22 #       <rb-bluebot> Build Server message: 3New 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: 3Build round completed after 956 seconds.
12.19.21 #       <rb-bluebot> Build Server message: 3Revision 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.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.32.05 Join    dconrad [0] (~dconrad@208.38.228.17)
14.41.29 ***     Saving seen data "./dancer.seen"
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.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.08.43 #       <rb-bluebot> Build Server message: 3New 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: 3Build round completed after 845 seconds.
17.22.50 #       <rb-bluebot> Build Server message: 3Revision da778a1783 result: All green
17.22.55 #       <rb-bluebot> Build Server message: 3New 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: 3Build round completed after 656 seconds.
17.33.54 #       <rb-bluebot> Build Server message: 3Revision 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.27.18 Quit    lebellium (Quit: Leaving)
18.41.32 ***     Saving seen data "./dancer.seen"
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.40.19 Join    Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
20.41.34 ***     Saving seen data "./dancer.seen"
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.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.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)