--- Log for 18.03.123 Server: calcium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 2 months and 22 days ago 00.26.13 Quit Ckat (Ping timeout: 256 seconds) 00.26.44 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) 00.37.16 Quit m01 (Quit: Konversation terminated.) 00.39.38 Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) 01.15.11 Quit massiveH (Quit: Leaving) 01.45.47 *** Saving seen data "./dancer.seen" 03.30.53 Join fourHZ [0] (~fourHZ@92-52-40-121.dynamic.orange.sk) 03.45.50 *** No seen item changed, no save performed. 03.55.23 Join lebellium [0] (~lebellium@2a01cb040109a60034e6e0748656b458.ipv6.abo.wanadoo.fr) 04.03.28 Quit Bobathan (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) 04.05.15 Join Bobathan_ [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) 05.45.52 *** Saving seen data "./dancer.seen" 07.45.56 *** No seen item changed, no save performed. 09.46.00 *** No seen item changed, no save performed. 11.46.01 *** No seen item changed, no save performed. 12.41.21 Join dconrad [0] (~dconrad@152.117.104.235) 12.47.26 Quit danwellby (Quit: Watch out For sysops carrying carpet and quicklime) 13.09.40 Join danwellby [0] (~danwellby@cpc1-cdif16-2-0-cust352.5-1.cable.virginm.net) 13.18.36 # I'm looking into this but I also want to ask... anyone have any immediate thoughts on this? https://forums.rockbox.org/index.php/topic,54481.0.html 13.19.20 # quite bizarre, but reproducible - some buffer isn't being emptied when stopping playback? 13.19.31 # (that's my thought at least) 13.24.06 # I thought we were always guaranteed to get l+r pairs of samples but perhaps not 13.31.37 # Build Server message: 3New build round started. Revision 0c29d1788e, 303 builds, 9 clients. 13.31.37 # 3[Bugfix] open_plugin_browse() not showing plugins by William Wilgus 13.43.21 Join amachronic [0] (~amachroni@user/amachronic) 13.46.04 *** Saving seen data "./dancer.seen" 13.52.01 # Build Server message: 3Build round completed after 1227 seconds. 13.52.05 # Build Server message: 3Revision 0c29d1788e result: All green 13.52.35 # Build Server message: 3New build round started. Revision a0a59ab610, 303 builds, 8 clients. 13.52.35 # 3Fix locked context fallthrough by Aidan MacDonald 13.56.00 # perhaps the question I should be asking is "what mechanism on m3k (most similar port?) ensures that we always get a pair of l+r samples into the DAC? And how does the eros q differ?" 13.56.45 # or maybe it has to do with stopping/starting the i2s clock 14.08.10 # reading the i2s spec the word select line (aka. frame clock or LR clock) is low for left and high for right. 14.08.32 # how does a wrong DAC sound? 14.08.46 # Build Server message: 3Build round completed after 976 seconds. 14.08.49 # Build Server message: 3Revision a0a59ab610 result: All green 14.09.01 # on the cpu side it's AIC_I2SCR.RFIRST that defines channel ordering from the FIFO 14.09.04 # is it the bass or treble? have you any test media to share? 14.10.27 # I think I've discovered through testing that it might be related to switching audio frequency - test file is in that thread from Oktan 14.11.54 # which might actually make sense, because I think the m3k manages switching frequencies much more closely (or at all?) than the eros 14.35.15 # fourHZ - the left and right channels actually swap sides sometimes 14.37.43 # dconrad that would be nasty. i did not hear something like that before afaik 14.44.24 # not nasty, just a bug we can get sorted out 14.45.21 # thanks amachronic - I believe we shouldn't ever have reason to switch the channel ordering, right? 14.45.28 # ah just one bug of dac that can happen i get it now. 14.45.59 # yep, the ordering is set at boot and shouldn't change. 14.46.54 # so perhaps when we switch frequencies the word select doesn't necessarily get changed correctly 14.49.05 # <_bilgus> or samples are still sized by the old sampling rate and causes it to get out of sync? 14.49.32 # hmm that certainly seems possible too 14.49.45 # <_bilgus> does it happen if you jump from something tiny to the largest 14.49.49 # unless the DAC has a hardware bug how could it *ever* get confused about left/right? 14.49.53 # <_bilgus> sampling rate that is 14.50.05 # the i2s bus is *telling it* exactly what channel its sending at all times 14.50.42 # I guess I was thinking the x1000 actually gets its outputs out of sync, but I guess that's managed so it couldn't? 14.51.12 # <_bilgus> amachronics leaning towards a config bug then 14.51.26 # it seems to happen just changing the frequency setting between 2 values, like between 44.1khz and 48khz 14.52.09 # well... I'd assume normally the outputs couldn't get out of sync but it depends on the FIFO config. 14.52.23 # doesn't the erosq use 32-bit FIFO entries? 14.52.30 # whereas the M3K used the packed 16-bit format? 14.52.53 # I thought it was 24 bit IIRC 14.53.12 # I seem to remember the x1000's aic doesn't support 32 bit samples 14.53.22 # (or was it the dac, I don't remember) 14.54.19 # <_bilgus> i'm thinking you have a slightly more than random chance of ending up unaligned between pairing like that but less so between 48 an 96khz I'd think 14.55.01 # I'm guessing that on the M3K we're always sending the L+R channel together due to the packed format 14.55.19 # on the ErosQ there are two FIFO entries (one for each channel) 14.55.38 # if you stop the FIFO between the left and right samples then the channels *might* swap 14.56.31 # <_bilgus> so you'd either need a dummy sample or to skip forward half a sample? could you detect thaT LIKE EVEN ODD OR SOMETHING 14.56.40 # <_bilgus> sorry 14.59.55 # looking at the X1000 manual, they recommend to wait for the FIFO to drain when stopping playback. 15.00.04 # <_bilgus> interesting way to find that bug too wonder how many headphones they mislabeled before they discovered it 15.00.57 # as long as you always write an even number of samples and let the FIFO drain the parity shouldn't go wrong. 15.03.53 # that makes sense... I'm thinking this might be fixable then by doing that before stopping the i2s bit clock to change frequency 15.04.14 # it seems to be directly related to changing the sample frequency as far as I can tell 15.25.04 Quit amachronic (Quit: amachronic) 15.46.08 *** Saving seen data "./dancer.seen" 15.48.08 Quit fourHZ (Quit: Client closed) 17.46.10 *** Saving seen data "./dancer.seen" 18.43.47 # well, no matter how thoroughly I try to reset x1000 aic in audiohw_set_frequency(), I can't get it to where the issue doesn't occur at all 18.44.15 # it seems to get better but I'm not sure if I'm just imagining it 18.45.09 Join massiveH [0] (~massiveH@173.54.137.97) 18.46.07 # in trying to trace the function calls upwards I did find that the audio buffer is aligned in pcm_play_data_start_int() (pcm.c) to 16-16 through some magic macro I can't make heads or tails of... would it be possible (and if so, advantageous?) to change this to better suit the larger 32-bit sample sizes? 18.46.34 # I think I'm in over my head, but that seems like something that might influence this issue 18.52.14 # I think it's a situation where we can reset AIC all we want, but there's no guarantee that the next sample in the buffer is a left-channel sample 18.52.40 Quit lebellium (Quit: Leaving) 19.37.08 Quit Webchat255_lurki (Ping timeout: 260 seconds) 19.46.11 *** Saving seen data "./dancer.seen" 19.49.15 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 19.54.03 Quit Webchat255_lurki (Ping timeout: 260 seconds) 20.05.01 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 20.08.12 # seems like maybe there's a fundamental flaw in that trying to use the pcm system with larger-than-16-bit samples means there's no way to ensure they are always treated as pairs? 20.09.48 Quit Webchat255_lurki (Ping timeout: 260 seconds) 20.16.47 # I tried to compile a version which is limited to 44.1k, but wow it screwed up all the strings bad 20.20.44 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 20.25.33 Quit Webchat255_lurki (Ping timeout: 260 seconds) 20.31.48 # nevermind, just needed to clean my build directory 20.38.36 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 20.43.38 Quit Webchat255_lurki (Ping timeout: 260 seconds) 20.50.22 Join jacobk [0] (~quassel@47-186-81-17.dlls.tx.frontiernet.net) 20.55.55 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 21.00.33 Quit Webchat255_lurki (Ping timeout: 260 seconds) 21.12.43 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 21.17.28 Quit Webchat255_lurki (Ping timeout: 260 seconds) 21.31.03 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 21.36.08 Quit Webchat255_lurki (Ping timeout: 260 seconds) 21.46.15 *** Saving seen data "./dancer.seen" 21.46.24 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 21.50.43 Quit Webchat255_lurki (Ping timeout: 260 seconds) 21.57.39 Quit dconrad (Remote host closed the connection) 21.58.44 Join dconrad [0] (~dconrad@152.117.104.235) 22.02.39 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 22.03.11 Quit dconrad (Ping timeout: 250 seconds) 22.07.03 Quit Webchat255_lurki (Ping timeout: 260 seconds) 22.18.48 Quit Romster (Quit: Leaving) 22.19.06 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 22.21.18 Join dconrad [0] (~dconrad@152.117.104.235) 22.23.23 Quit Webchat255_lurki (Ping timeout: 260 seconds) 22.25.59 Quit dconrad (Ping timeout: 264 seconds) 22.36.42 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 22.41.28 Quit Webchat255_lurki (Ping timeout: 260 seconds) 22.42.14 Join Romster [0] (~romster@202.169.118.85) 22.44.28 Join dconrad [0] (~dconrad@152.117.104.235) 22.45.41 Quit dconrad (Client Quit) 22.53.53 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 22.58.23 Quit Webchat255_lurki (Ping timeout: 260 seconds) 23.11.43 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 23.16.28 Quit Webchat255_lurki (Ping timeout: 260 seconds) 23.28.35 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 23.33.23 Quit Webchat255_lurki (Ping timeout: 260 seconds) 23.44.37 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154) 23.46.19 *** Saving seen data "./dancer.seen" 23.49.08 Quit Webchat255_lurki (Ping timeout: 260 seconds) 23.51.51 Quit massiveH (Quit: Leaving) 23.52.13 Join massiveH [0] (~massiveH@2600:4040:a99f:1f00:c446:70de:f28f:da9)