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 2023-03-18

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:00
01:15:11 Quit massiveH (Quit: Leaving)
01:45:47***Saving seen data "./dancer.seen"
03:00
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:00
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:00
05:45:52***Saving seen data "./dancer.seen"
07:00
07:45:56***No seen item changed, no save performed.
09:00
09:46:00***No seen item changed, no save performed.
11:00
11:46:01***No seen item changed, no save performed.
12:00
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:00
13:09:40 Join danwellby [0] (~danwellby@cpc1-cdif16-2-0-cust352.5-1.cable.virginm.net)
13:18:36dconradI'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:20dconradquite bizarre, but reproducible - some buffer isn't being emptied when stopping playback?
13:19:31dconrad(that's my thought at least)
13:24:06dconradI thought we were always guaranteed to get l+r pairs of samples but perhaps not
13:31:37rb-bluebotBuild Server message: New build round started. Revision 0c29d1788e, 303 builds, 9 clients.
13:31:37rb-bluebot[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:01rb-bluebotBuild Server message: Build round completed after 1227 seconds.
13:52:05rb-bluebotBuild Server message: Revision 0c29d1788e result: All green
13:52:35rb-bluebotBuild Server message: New build round started. Revision a0a59ab610, 303 builds, 8 clients.
13:52:35rb-bluebotFix locked context fallthrough by Aidan MacDonald
13:56:00dconradperhaps 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:45dconrador maybe it has to do with stopping/starting the i2s clock
14:00
14:08:10amachronicreading the i2s spec the word select line (aka. frame clock or LR clock) is low for left and high for right.
14:08:32fourHZhow does a wrong DAC sound?
14:08:46rb-bluebotBuild Server message: Build round completed after 976 seconds.
14:08:49rb-bluebotBuild Server message: Revision a0a59ab610 result: All green
14:09:01amachronicon the cpu side it's AIC_I2SCR.RFIRST that defines channel ordering from the FIFO
14:09:04fourHZis it the bass or treble? have you any test media to share?
14:10:27dconradI 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:54dconradwhich might actually make sense, because I think the m3k manages switching frequencies much more closely (or at all?) than the eros
14:35:15dconradfourHZ - the left and right channels actually swap sides sometimes
14:37:43fourHZdconrad that would be nasty. i did not hear something like that before afaik
14:44:24dconradnot nasty, just a bug we can get sorted out
14:45:21dconradthanks amachronic - I believe we shouldn't ever have reason to switch the channel ordering, right?
14:45:28fourHZah just one bug of dac that can happen i get it now.
14:45:59amachronicyep, the ordering is set at boot and shouldn't change.
14:46:54dconradso perhaps when we switch frequencies the word select doesn't necessarily get changed correctly
14:49:05_bilgusor samples are still sized by the old sampling rate and causes it to get out of sync?
14:49:32dconradhmm that certainly seems possible too
14:49:45_bilgusdoes it happen if you jump from something tiny to the largest
14:49:49amachronicunless the DAC has a hardware bug how could it *ever* get confused about left/right?
14:49:53_bilgussampling rate that is
14:50:05amachronicthe i2s bus is *telling it* exactly what channel its sending at all times
14:50:42dconradI 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_bilgusamachronics leaning towards a config bug then
14:51:26dconradit seems to happen just changing the frequency setting between 2 values, like between 44.1khz and 48khz
14:52:09amachronicwell... I'd assume normally the outputs couldn't get out of sync but it depends on the FIFO config.
14:52:23amachronicdoesn't the erosq use 32-bit FIFO entries?
14:52:30amachronicwhereas the M3K used the packed 16-bit format?
14:52:53dconradI thought it was 24 bit IIRC
14:53:12dconradI seem to remember the x1000's aic doesn't support 32 bit samples
14:53:22dconrad(or was it the dac, I don't remember)
14:54:19_bilgusi'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:01amachronicI'm guessing that on the M3K we're always sending the L+R channel together due to the packed format
14:55:19amachronicon the ErosQ there are two FIFO entries (one for each channel)
14:55:38amachronicif you stop the FIFO between the left and right samples then the channels *might* swap
14:56:31_bilgusso 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_bilgussorry
14:59:55amachroniclooking at the X1000 manual, they recommend to wait for the FIFO to drain when stopping playback.
15:00
15:00:04_bilgusinteresting way to find that bug too wonder how many headphones they mislabeled before they discovered it
15:00:57amachronicas long as you always write an even number of samples and let the FIFO drain the parity shouldn't go wrong.
15:03:53dconradthat makes sense... I'm thinking this might be fixable then by doing that before stopping the i2s bit clock to change frequency
15:04:14dconradit 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:00
17:46:10***Saving seen data "./dancer.seen"
18:00
18:43:47dconradwell, 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:15dconradit 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:07dconradin 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:34dconradI think I'm in over my head, but that seems like something that might influence this issue
18:52:14dconradI 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:00
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:00
20:05:01 Join Webchat255_lurki [0] (~Webchat25@2a01:e0a:337:b6b0:3527:34e0:694f:1154)
20:08:12dconradseems 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:47dconradI 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:48dconradnevermind, 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
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:00
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:00
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)

Previous day | Next day