Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-08-07

00:06:42 Join dconrad [0] (~dconrad@
00:11:00 Quit dconrad (Ping timeout: 256 seconds)
00:41:09***Saving seen data "./dancer.seen"
00:53:48rb-bluebotBuild Server message: New build round started. Revision 57293f1fd9, 303 builds, 9 clients.
01:03:31rb-bluebotBuild Server message: Build round completed after 583 seconds.
01:03:35rb-bluebotBuild Server message: Revision 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] (
04:00:09 Quit michaelni (Quit: Leaving)
04:03:22 Join ufdm_ [0] (
04:03:28 Quit tchan (Read error: Connection reset by peer)
04:04:09 Join tchan [0] (
04:06:50 Quit ufdm (Ping timeout: 272 seconds)
04:13:00 Join michaelni [0] (
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] (
06:31:49 Quit Piece_Maker (Quit: ZNC 1.8.2 -
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@
07:07:10 Nick danwellby-1 is now known as danwellby (~danwellby@
07:24:51 Quit danwellby (Ping timeout: 252 seconds)
07:25:20 Join danwellby [0] (~danwellby@
07:47:37 Join tomato [0] (~tomato@user/tomato)
08:02:25 Join dconrad [0] (~dconrad@
08:02:26 Quit dconrad (Remote host closed the connection)
08:02:37 Join dconrad [0] (~dconrad@
08:09:27 Join IPG [0] (~IPG@
08:10:04dconradon 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:26dconradI think its faster with it hardcoded with #defines probably
08:11:07speachydefinitely #defines, since we won't have any reason to switch at runtime.
08:11:16dconradok, sweet
08:11:33dconradI wasn't sure if there was a future-proofing reason you might want it more complex than that
08:16:02dconradif 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:44dconradI 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:03dconradvery clean all the way down to subaudible
08:20:26_bilgusso what it end up being (noise) was it the shifted samples or a group effort?
08:21:39speachyyou still have at 16-bit clip in pcm_scale_buffer_boost()
08:22:19speachyd'oh, looking at the wrong set
08:22:29dconradyeah, I've hardcoded the scaling function to the pcm_scale_buffer_cut()
08:22:48speachyso why the /20 instead of /10 in pcm_set_master_volume?
08:22:49dconradsince, to my understanding, we're limited to <= 0 dB
08:23:32dconradthat 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:52speachywe're telling the UI one scale but telling the volume code another
08:24:14speachyought to get to the root of that and fix it properly
08:25:17dconradbilgus: on eros q?
08:27:01speachyI'd get rid of a bunch of #ifdefs related to sample size with something like #define PCM_SIZE_T int32_t
08:27:38braewoodsspeachy: isn't that better done with a typedef?
08:27:39speachyand instead of (size * 2) (sizeof (PCM_SIZE_T)/sizeof(int16_t)
08:28:15dconradwill that multiply/divide properly?
08:28:21dconrador will it just truncate?
08:28:22braewoodsi sometimes see macros defined that could be done with an enum or typedef
08:28:24braewoodsit's weird
08:28:39speachysince we only use 32-bit or 16-bit sizes, no issues there
08:29:01speachymakes the logic in the code more apparent since we describe teh general case instead of multiple special cases
08:29:15dconradhm, I'll give it a shot
08:29:46speachyand the compiler will optimize away those constant expressions at compile time
08:31:18dconradso 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:28dconradI don't think that's right
08:32:12speachyalso, in pcm_sync_pcm_factors() we want to use the UNITY case too, so the #ifdef should only exclude the boost mode.
08:32:48speachy(IMO we should include boost in this too, since the 16-bit code does, but that's a separate discussion)
08:32:58dconradwill unity work correctly, given we need to multiply it up to 32 bits?
08:33:08dconrador will it jump down to 16 bit levels?
08:33:34speachyFACTOR_UNITY is 1.0 ie a no-op ie memcpy().
08:33:48speachybut boost can cause clipping in 16-bit too; depends on the input signal.
08:34:09speachynot something that's generally recommended if you care about audio quality :)
08:34:18dconradright, 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:35speachyoooh yeah you're right
08:34:51speachydocument that in a comment please.
08:34:58dconradwill do
08:35:19dconradalso, complete side note, it looks like memcpy is commented out? or it's defined somewhere else
08:35:29speachy(ie document this for the next idiot that comes along and wonders wtf the code is written that way)
08:35:43dconradhaha yeah
08:36:11speachycommented out where?
08:36:31dconraduh, line 82
08:36:50dconradit must be defined in another file?
08:37:10speachyyeah, it's part of string.h
08:37:29speachywhich I guess is pulled in as part some other header
08:37:47speachyjust nuke that please
08:38:00dconradwill do
08:38:51speachyawesome work btw
08:39:09dconradso what was that about using PCM_SIZE_T? I didn't quite understand
08:39:12dconrad(thank you!)
08:39:40dconradyou want to cast it instead of multiplying/dividing?
08:39:49speachy#ifdef USE_SW_VOL32 #define PCM_SIZE_T int32_t #else #define PCM_SIZE_T int16_t #endif
08:40:17speachyso you can get rid of the stuff like L85 or L127
08:40:39speachyand do a simple 'PCM_SIZE_T *d =dst;' for all cases
08:40:40dconradoh I see
08:41:09dconradI thought you meant for the multiplying/dividing of the size variable for a minute
08:41:10speachyin 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:06speachywell, that too. eg L254 becomes int count = size * ((sizeof(PCM_SIZE_T)/sizeof(uint16_t)) / samplesize
08:42:45dconradoh, I think I get it
08:43:03speachythat 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:05dconradif they're equal, it's 1, if not it's 2
08:43:27dconradpotentially expandable to an arbitrary value
08:43:54speachythere's that but it's mostly to try and cut down on #ifdef proliferation
08:44:52speachyactually with update_frame_params, won't samplesize be constant at compile-time?
08:45:51speachywhy not just just PCM_VOL_SAMPLE_SIZE in that function instead of adding it as a parameter?
08:45:51dconradyeah, though I thought that might be useful in the future
08:46:02speachywe're never going to switch at runtime
08:46:19dconradyeah it can be hardcoded
08:48:45speachysorry if this comes off as nitpicking, but code clarity/maintainability usually important than cleverness
08:49:01dconradno I get it
08:49:33speachyand as has been demonstrated many times over by now, the original authors of <whatever> don't stick around forever..
08:50:45speachyheh, 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:58speachyit 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:27dconradyeah I imagine some of the early devices didn't give a lot of options
08:52:58braewoodsspeachy: is there a reason rockbox uses its own memcpy when we could use the smart version GCC provides?
08:53:00speachythe erosq has several orders of magnitude more resources than original targets
08:54:37braewoods__builtin_memcpy is capable of inlining simple memcpy jobs and such instead of calling the function
08:54:42speachybraewoods: size and performance. I don't know if it still matters
08:55:29braewoodsi 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:40braewoodsor something like that
08:55:49speachykeep in mind we have asm-optimized memcpy for most (all?) of our CPUs too
08:56:14braewoodsindeed but this could be useful for small copy operations
08:56:19braewoods<= 4 bytes at a time
08:56:34braewoodsquestion is, how common is that?
08:56:53braewoodsthis is how glibc works, it have a library version and a compiler version.
08:56:55speachypretty rare, I'd wager.
08:57:06braewoodswhich gets used depends on the circumstances
08:57:29speachyoptimized 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:53speachy(and what constitutes large/small is highly implementation-dependent)
08:58:21braewoodsi imagine my deflate code will probably run best on newer SOCs than coldfire
08:58:28braewoodscoldfire runs it pretty slow
08:58:31braewoodsno idea why
08:58:51speachyno D$ makes a huge difference.
08:59:20braewoodsyea, plan9's inflate has a lot of lookup tables that help with speed but...
08:59:27speachybut remember performace isn't the primary consideration here; it just has to be "fast enough"
08:59:46braewoodswell it's probably about as good as coldfire is going to be.
09:00:03braewoodsit was getting maybe 500 kilobytes a second of decompression
09:00:45braewoodsnot worth optimizing when most of our users are prefering newer hardware
09:01:08braewoodsi'll work on finishing the ZIP integration later
09:01:10braewoodsadd some UI stuff
09:01:49braewoodsspeachy: 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:06braewoodsthe ram requirements make it usable everywhere which was my primary concern
09:02:23braewoodslike 76k at most of non-code memory
09:03:24speachywhere/when will this decompression be taking place? during playback?
09:03:48braewoodsthat wasn't planned.
09:03:49speachyif we can guarantee no playback at the time, you can use the codec or primary buffer space for tables
09:04:00speachystatic tables can be loaded from disk
09:04:13braewoodsthe static tables don't occupy that much space.
09:04:18braewoodsmaybe 500 bytes
09:04:28braewoodsmost of them are generated on the fly
09:04:34braewoodsfrom the input stream
09:04:57braewoodsand even that can be reduced by using smaller integers
09:05:09braewoodsmost of the table contents can be shoved into 16 bits or less
09:05:47braewoodsthe huffman tables are the main lookup tables that are generated on the fly
09:06:00braewoodsthe rest are fast lookup for values that don't vary with the input stream
09:06:20braewoodsthe static tables, some people cache them but i don't bother because it's rare to find them in actual deflate streams.
09:06:28braewoodsstatic huffman tables*
09:06:37braewoodsthat saves about 8k of space.
09:07:10braewoodsmost real compressed streams use the dynamic tables which always have to be recreated
09:08:11braewoodsspeachy: originally i envisioned this for support of extracting to disk. which technically has no performance requirements.
09:08:24braewoodsit's just whatever we can manage.
09:08:36speachythere ya have it.
09:08:55braewoodsi optimized it a bit on x86 but not elsewhere
09:09:13braewoodsmostly some general stuff to reduce time spend on pointless checks
09:09:24speachythe point being that we can't statically pre-allocate lots of space or rely on the stack
09:09:39braewoodsyes, i designed with that in mind
09:09:40speachybut we can pull it from the codec or buffer heaps
09:09:55braewoodsthe inflate allocates all its larger objects in a single large allocation chunk
09:10:02braewoodsthe rest is stack allocated
09:10:03speachyand reliably have a whopping MEGABYTE (!!) to play with
09:10:19braewoodshow that gets allocated is up to the caller
09:10:49braewoodsi thought that a wise implementation choice
09:11:00braewoodssince this code might be used by more than my original intention
09:11:25braewoodsit may just be this algorithm is going to be slow on coldfire just by its very nature
09:11:44braewoodsdeflate requires a lot of hard to optimize stuff like a software "shift register"
09:11:49braewoodssince part of the stream is bit packed
09:12:21braewoodsthe main improvement i did was to the byte copying loops
09:12:29braewoodssignificant speed up
09:12:33speachythere aren't a lot of coldfire devices out there (eg in comparison to ipods)
09:13:02speachyhence "good enough"
09:13:28braewoodsi was also considering adding an option for rockbox to decompress ZIP payloads for upgrades
09:13:31speachythe newest one was made what, fifteen years ago?
09:13:42speachyif not longer
09:14:11braewoodszip support could be useful since we ship most of our files in zip files
09:14:29braewoodsin any case the bare minimum is going to be UI zip extraction
09:14:44braewoodsi made the parts modular so we could use inflate elsewhere and such
09:14:53braewoodsindependent of zip
09:15:16braewoodsmake it a plugin API at some point perhaps?
09:15:19*braewoods shrugs.
09:15:26speachyputting on my "infrascture maintainer" hat the notion of growing our distributed zip file sizes isn't appealing
09:15:35speachy(ie by using less efficient compression)
09:15:43braewoodslike deflate?
09:16:03braewoodsi already know a simple way we can reduce our ZIP files
09:16:34braewoodsour zip files include extra stuff we don't strictly need
09:16:50braewoodswith some extra args to zip we can stop generating them.
09:16:54braewoodsthat'll help a small bit
09:17:09braewoodsspeachy: i assume we already use -9?
09:17:34braewoodsthere's advzip for recompressing zip files. that could be useful for our archives.
09:17:57braewoods-4z uses the very slow zopfli engine for optimizing the deflate stream
09:18:15braewoodsit can achieve better rates.
09:18:38speachyok, deflate is what everyone uses, I was thinking of somehing else.
09:19:03braewoodsdeflate is convenient for compatibility.
09:19:20braewoodsif you want to reduce the size of existing zip archives without losing that
09:19:27braewoodszopfli is pretty much the only option
09:19:53braewoodslet me try advzip on a 3.15 zip
09:20:37speachyI wonder how common bzip2 support is for zip decompressors
09:20:54speachygiven it was formally part of the spec a decade ago.
09:21:01speachytwo decades ago I mean
09:21:08braewoodswell in my experience DEFLATE is the only one that's guaranteed
09:21:15braewoodsplus bzip2 is even slower.
09:21:35braewoodsi just started advzip.
09:21:38braewoodsi'll see how well it does.
09:21:44braewoodsit's very slow obviously.
09:22:07braewoodsit tries to brute force more optimal compressed representations
09:22:12braewoodsor so i understand
09:22:57braewoodsmight be worth trying on our archives if you want to squeeze out a few more %
09:22:58speachyhah! bzip2 made the archive larger.
09:23:22braewoodsi wouldn't use it for anything but production builds though
09:23:31braewoodsit's too slow for regular use.
09:25:03speachya straight tar.gz (with gzip-9) is about 5% smaller.
09:27:11braewoodsspeachy: we can't use xz on device; ram requirements
09:27:17speachygz, not xz
09:27:21braewoodsi know
09:27:27braewoodsbut if you were considering it or lzma
09:27:47braewoodsthere's one major drawback to tar though
09:27:56braewoodsyou can't seek through it
09:28:25speachybut tar.xz is only 60% the size of zip. :)
09:29:05speachybut if we're only using these archives in a "extract everything" mode then seeking doesn't matter
09:29:11braewoodszip has one major speed advantage. you can seek through it.
09:29:25braewoodswe do have microtar in the base now.
09:29:29speachyzip'd design _requires_ seeking
09:29:46braewoodswith the inflate algorithm, we can support tar.gz now
09:30:10braewoodsi included support for both the zlib and gzip containers
09:30:29braewoodsgzip is slower to extract due to involving crc32
09:30:35braewoodszlib uses the faster adler option
09:31:25braewoodszip's main advantage is its ubiquity
09:31:39braewoodsit is used as the basis of a lot of file types that need to store multiple files
09:31:50braewoodsbut two easy options we could do to reduce archive size...
09:32:08speachywe already do zip -9 in our build script btw
09:33:03braewoodswe could use zopfli to further optimize space usage but that's not too effective for zip
09:33:09braewoodsit's far more effective on PNG in my experience
09:35:22dconradspeachy: 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:24rb-bluebotGerrit review #3669 at : Higher bitdepth software volume scaling by Dana Conrad
09:35:46braewoodsspeachy: if you add -X to the zip command, you strip out 24 bytes per entry
09:36:04braewoodssaving like 8k on the total size for our typical archives
09:36:25braewoodsit's unix timestamps or so, something we don't really need.
09:36:49speachywill that cause any issues with $random_zip_decompressors?
09:38:28braewoodsspeachy: probably not? it's part of the extra fields which i actually ignore in my code since it's nothing i need.
09:38:41braewoodsthis just tells zip not to generate them.
09:38:50braewoodsor add them
09:39:08braewoodsi can't see why it would cause issues, being absent.
09:41:13speachydconrad: ok, one more thing −− PCM_SW_VOLUME_BITDEPTH/HAVE_SWVOL_32 probably need to be renamed
09:41:34speachythe former is perhaps better called PCM_NATIVE_BITDEPTH
09:41:38braewoodsi stand corrected. -X reduces the size by about 20k
09:42:03braewoodsdepends how many entries you have.
09:42:05dconradhm, yeah I can do that, though the originals make sense to me
09:42:08braewoodsoh right, it gets doubled.
09:42:12*braewoods facepalms.
09:43:01speachyand you might be able to just drop HAVE_SWVOL_32 altogether, and key off PCM_NATIVE_BITDEPTH?
09:43:13braewoodsspeachy: so you can save around 22k if you use -X and -D together it seems.
09:43:24speachythat's 22K out of 3.8MB. :)
09:43:26braewoods-D eliminates directory listings since you don't strictly need them
09:43:37braewoods-X eliminates extra metadata info
09:43:52braewoodsspeachy: yea but it adds up. lol
09:44:07braewoodsi'd only enable -X though if i was being serious
09:44:18dconradmy 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:43dconradjust to make it obvious how to use it?
09:45:33dconradthe bit depth is set by default to 32 if not set in the port-specific code
09:47:02dconradmaybe HAVE_SWVOL_32 could be HAVE_SOFTWARE_VOL_32BIT?
09:47:38dconrador HAVE_SWVOL_NATIVE_BITDEPTH even, though that seems weird
09:48:10speachytrying to think what makes the most sense in the medium term
09:49:04speachyie when we have >16bit capabilities at the mixer/dsp layer
09:50:46speachyI can't see a scenario where we'd use one without the other
09:51:36dconradwell, excepting bypassing the whole thing because the target has hardware volume control
09:51:52speachythen we'd not use swvol at all.
09:52:05speachyso it would be both, or none
09:52:24dconradyeah I suppose I could drop HAVE_SWVOL_32
09:52:54dconradjust need people to know that if they define PCM_NATIVE_BITDEPTH it's going to switch them over completely to this system
09:53:03dconradrather than the normal scaling
09:53:03speachyif the hardware hs native 24/32-bit PCM, and hwvol, some other code path would have to do the upscaling/conversion
09:53:50speachyI'd make it so that #indef PCM_NATIVE_BITDEPTH #define PCM_NATIVE_BITDEPTH 16
09:54:27dconradI suppose that makes sense
09:54:30speachyand #if (PCM_NATIVE_BITDEPTH > 16) #define HAVE_SWVOL_32 (ie keeping the define purely within pcm_sw_volume.c)
09:54:53dconradhm, ok yeah let me try that
09:55:06speachysince 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:58:09speachyoh, and L70 in pcm-x1000.c should be keyed off PCM_NATIVE_VITDEPTH intead
09:59:19dconradok, I think I got all that
10:00:20dconradoh, and I've been testing g#3633 all week and it's been a click-free experience
10:00:22rb-bluebotGerrit review #3633 at : ErosQ Native: Add DC Offset to PCM data by Dana Conrad
10:00:38dconradexcepting turning on and off the device, intermittently
10:05:48dconradlooks like it's working, uploading a new patchset...
10:06:55 Join amachronic [0] (~amachroni@user/amachronic)
10:10:15dconradspeachy: newest patchset is uploaded, take a look
10:11:35speachydconrad: hmm. make the change in pcm-x1000.c PCM_NATIVE_BITDEPTH > 16
10:11:59speachyotherwise I tihnk it's sane
10:12:17speachyamachronic: any thoughts from you?
10:12:24dconradmaybe I should do == 24, because 18 is also an option?
10:12:36amachronicgave it a once over, looks sane to me
10:12:52speachyhmm. realistically, I don't think we'll ever do anyting other than 16/24/32
10:13:13speachyor 16/24 in the case of the x1000
10:13:25dconradalright, though this patch should be able to cover anything as long as it's ok in a 32-bit container
10:14:23speachyI 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:40dconradsounds good
10:15:53amachronicspeachy, no problem I'll do it
10:18:20amachronicdconrad, is g#3663 supposed to be a prereq?
10:18:22rb-bluebotGerrit review #3663 at : Fix hosted glibc backtrace by Aidan MacDonald
10:18:37dconradactually I was gonna ask you about that haha
10:18:50amachronicwhoops that's wrong
10:18:56amachronici mean 3633
10:19:06dconradI'm not sure if git would do it correctly if you didn't merge 3633 first
10:19:18dconradbut it does basically overwrite that functionality I suppose
10:19:27dconradpersonally I would do 3633 first
10:19:49dconradwell, it has soft mute stuff in it too so probably should
10:20:04amachronicok then
10:21:05amachronicany more last minute changes needed or should I merge now?
10:21:15dconradI think I'm done
10:21:27dconradgotta call it at some point
10:21:49rb-bluebotBuild Server message: New build round started. Revision 56b0dde545, 303 builds, 10 clients.
10:22:15amachronicthere it goes, that's both of them
10:22:21dconradsweet, thanks
10:22:32dconraddoes that queue them up, so it will build one after the other?
10:23:03amachroniclemme see
10:23:45amachronicapparently not, it's skipping 3633
10:24:04amachronicmust be 'cause I submitted the whole chain
10:24:24dconradmust be smarter than we give it credit for
10:32:04rb-bluebotBuild Server message: Build round completed after 615 seconds.
10:32:07rb-bluebotBuild Server message: Revision 56b0dde545 result: 0 errors 4 warnings
10:33:29dconradoh, that should be easy to fix
10:36:40*braewoods fines dconrad for each warning.
10:37:02dconradI'll give you a nickel, max
10:38:55dconradand I stand by it!
10:41:22***No seen item changed, no save performed.
10:42:50dconradm3k is taking a lot longer to build than I remember
10:43:00dconradthere we go
10:45:08dconradamachronic: could you look at g#3674? it should fix the warnings from 3669
10:45:10rb-bluebotGerrit review #3674 at : Fix warnings from 56b0dde545 by Dana Conrad
10:47:36rb-bluebotBuild Server message: New build round started. Revision a2bbd1a549, 303 builds, 10 clients.
10:47:55amachronicgot it, thanks
10:58:32rb-bluebotBuild Server message: Build round completed after 656 seconds.
10:58:34rb-bluebotBuild Server message: Revision a2bbd1a549 result: All green
11:04:25rb-bluebotBuild Server message: New build round started. Revision eeb0aaf36f, 303 builds, 10 clients.
11:09:12 Quit Moriar (Quit: Leaving.)
11:12:44speachyok, back, breakfast in the oven.
11:13:28rb-bluebotBuild Server message: Build round completed after 543 seconds.
11:13:32rb-bluebotBuild Server message: Revision eeb0aaf36f result: All green
11:14:44speachydconrad: the waning fix should have gone into config.h instead, see g#3677
11:14:46rb-bluebotGerrit review #3677 at : move PCM_NATIVE_BITDEPTH definiton into global config code by Solomon Peachy
11:15:13speachyhmm, or audiohw.h now that I think about it.
11:15:40dconradah, sorry about that
11:16:35speachyno worries
11:17:32amachronicand get rid of the one from pcm_sw_volume.c too
11:18:27speachyroger that, take three uploaded
11:19:04speachydoing quick sanity builds
11:20:31speachyok, seems clean
11:20:47rb-bluebotBuild Server message: New build round started. Revision 39fff5cb53, 303 builds, 10 clients.
11:30:53rb-bluebotBuild Server message: Build round completed after 607 seconds.
11:30:55rb-bluebotBuild Server message: Revision 39fff5cb53 result: All green
11:36:51amachronic g#3678, pretty certain it's an ancient 'typo' from this:
11:36:53rb-bluebotGerrit review #3678 at : tagcache: Don't treat tag_virt_basename as a numeric tag by Aidan MacDonald
11:37:32speachyseems so
11:37:38amachronicI'm not familiar with tagcache so I have no idea if there might be other breakage lurking.
11:38:08speachy... given the persistent reports of seemingly random issues with the tagcache, it's possible this is one of the causes
11:38:27speachy(puttiting aside the iflash-induced corruption anyway..)
11:39:45amachronicthe 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:35speachythere are a lot of places TAGCACHE_IS_NUMERIC is checked
11:43:16amachronicthat comment might be wrong since it looks like strings _are_ handled if I'm not mistaken
11:44:10speachynumeric comparisons don't make sense for strings
11:45:14amachroniccheck_against_clause() in tagcache.c
11:46:32speachystrings are handled, yes −− but clause->numeric is what determines how things are handled
11:46:48speachy->numeric is set based on TAGCACHE_IS_NUMERIC
11:47:21speachyalso check out tagcache.c L1113
11:47:57speachythe comparison to tag_virt_basename is checked only if !IS_NUMERIC
11:48:12amachronici know my concern was somebody added it there thinking 'this is needed to use it in comparisons' based on that comment
11:48:36amachronicbut it looks like everything is already handled properly
11:52:20rb-bluebotBuild Server message: New build round started. Revision cf3fa437fc, 303 builds, 10 clients.
11:54:43speachyok, fixed the front page recent wiki stuff so it ignores internal administrative crap
12:02:01rb-bluebotBuild Server message: Build round completed after 581 seconds.
12:02:04rb-bluebotBuild Server message: Revision cf3fa437fc result: All green
12:03:22rb-bluebotBuild 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] (
12:19:19rb-bluebotBuild Server message: Build round completed after 956 seconds.
12:19:21rb-bluebotBuild Server message: Revision 5311ff0173 result: All green
12:23:04dconradspeachy: could I add some info about the eros Q native to wiki?
12:24:02dconradit's nearly done (for my purposes), and the only big thing missing is dual boot
12:24:55dconradbut it should be genuinely useable for someone who doesn't care about dual boot
12:40:58dconradand 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:21speachydconrad: I think the audio situatiou will be comparable once the alsa driver picks up the improved swvol stuff, but absolutely, document away
12:49:03dconradsweet - could you make an account for me? I believe registrations are disabled
12:49:19speachyunlike 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:31speachyok to use the email address in your commits?
12:49:59speachyok, gimme a little bit, alternating back and forth with meatspace tasks
12:50:06dconradno hurry
12:50:14dconradlol meatspace
12:51:29 Quit yosafbridge (Quit: Leaving)
12:52:33 Join yosafbridge [0] (
12:55:20sporkcould you not borrow dual-boot inspiration from the m3k/q1 ?
12:55:33sporkor are not all x1000's created alike
12:56:03dconradas I understand it, it will follow the same idea, but it needs to be specific to the device
12:56:39dconradI guess the original firmwares in both use different loaders, so it might get weird
12:57:49sporkeros-q is uboot ?
12:58:59dconradhm, I think? can't remember haha
12:59:15dconradI remember it was different from m3k
13:00:07dconradyeah according to the old disassembly thread it was u-boot
13:03:59sporkdual boot is nice as long as there are features in the of that rockbox does bot support like usb-dac functionality
13:04:58dconradI agree - I think the two real killer features are usb-dac and bluetooth. Someday maybe rockbox will support them. Someday...
13:06:01sporkfor regular music playback rockbox is so much nicer on m3k/q1
13:06:05dconradI'm just not super eager to delve back into the linux binary haha
13:06:35sporkone of the biggest differende imo is the playlist handling
13:07:45dconradyou 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:06dconradsomething so simple, yet it makes a huge difference, and no other firmwares seem to care to implement it
13:08:40sporktrue, i used it all the time for audio books
13:10:14sporktoo bad it is not working properly on the q1
13:10:46dconradhow so?
13:11:01dconradI don't think there's much there that's port-specific
13:11:14sporkbookmarking works, the touchscreen 'prompt' does not
13:11:24dconradthe yes/no screen?
13:11:39dconradI think you can turn that off if you wanted
13:11:48sporkthe buttons briefly flash on the screen and then dissapear
13:12:18sporki like the prompt feature
13:12:24dconraddid 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:35dconradnot sure what "ok" is on a touchscreen though
13:12:36sporkpress where ?
13:12:46dconradyeah not sure
13:13:14sporkpressing anywhere on screen is 'yes', luckily pressing the volume wheel button is 'no'
13:13:23sporkso there is a way to manage
13:13:44dconradso it doesn't accept a 'yes'?
13:13:55sporkamachronic has even more problems with that yes/no screen
13:14:14dconradhaha I've had my own problems with it too
13:14:14sporkfor me only in that bookmark prompt
13:14:35sporkeverywhere else, i.e. deleting a file, it renders/works fine
13:16:42sporki have a fistfull of sansa's that have more buttons and where it works fine
13:16:46sporkwhile they last
13:17:19dconradyeah rip good sansas
13:17:37dconradI 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@
13:57:59 Quit dconrad (Ping timeout: 252 seconds)
14:32:05 Join dconrad [0] (~dconrad@
14:41:29***Saving seen data "./dancer.seen"
15:13:50 Join sadjhflj333 [0] (
15:44:49 Quit dconrad (Remote host closed the connection)
16:00:33 Join dconrad [0] (~dconrad@
16:04:55 Quit dconrad (Ping timeout: 258 seconds)
16:15:52 Join dconrad [0] (~dconrad@
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] (
16:37:45 Quit sadjhflj333 (Remote host closed the connection)
16:41:30***Saving seen data "./dancer.seen"
17:08:43rb-bluebotBuild Server message: New build round started. Revision da778a1783, 303 builds, 10 clients.
17:20:09 Join sadjhflj333 [0] (
17:22:47rb-bluebotBuild Server message: Build round completed after 845 seconds.
17:22:50rb-bluebotBuild Server message: Revision da778a1783 result: All green
17:22:55rb-bluebotBuild 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@
17:33:52rb-bluebotBuild Server message: Build round completed after 656 seconds.
17:33:54rb-bluebotBuild Server message: Revision 0a6d7abd13 result: All green
17:37:00anonIs 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@
17:56:43 Quit dconrad (Client Quit)
17:57:29_bilgusit probably is but that is more specialized than i know anon
17:57:48_bilguspersonally 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] (
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] (
20:40:19 Join Moriar [0] (
20:41:34***Saving seen data "./dancer.seen"
21:04:14 Join dconrad [0] (~dconrad@
21:17:13 Quit dconrad (Remote host closed the connection)
21:21:08speachydconrad: wiki account created
21:32:56 Join dconrad [0] (~dconrad@
21:37:06 Quit dconrad (Ping timeout: 240 seconds)
21:49:44 Join massiveH [0] (
22:38:50 Join dconrad [0] (~dconrad@
22:39:22dconradspeachy: thanks
22:41:35***Saving seen data "./dancer.seen"
22:45:44 Quit massiveH (Quit: Leaving)
22:46:04 Join massiveH [0] (
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)

Previous day | Next day