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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-03-01

00:02:30***Saving seen data "./dancer.seen"
01:00
01:05:23 Quit koniu (Ping timeout: 268 seconds)
01:18:22 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
01:32:25 Quit daswf852 (Read error: Connection reset by peer)
01:32:46 Join daswf852 [0] (~daswf852@unaffiliated/dwf)
02:00
02:02:33***Saving seen data "./dancer.seen"
02:15:42 Quit daswf852 (Quit: ZNC 1.8.2 - https://znc.in)
02:17:56 Join daswf852 [0] (~daswf852@unaffiliated/dwf)
03:00
03:21:34 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
03:35:14 Quit koniu (Ping timeout: 268 seconds)
03:36:14 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
04:00
04:02:34***Saving seen data "./dancer.seen"
06:00
06:02:37***No seen item changed, no save performed.
06:55:44speachy_bilgus: I'm hoping I'll get a better reason than "because rockbox has always behaved this way" but it does seem that DJs would be a bit of a stretch (versus just using dynamic playlists..)
08:00
08:02:38***No seen item changed, no save performed.
08:38:35 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc)
08:54:33fs-bluebotBuild Server message: New build round started. Revision 640b14c08c, 293 builds, 9 clients.
09:00
09:03:03 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-9037-5582-fe14-93cc.res6.spectrum.com)
09:09:42fs-bluebotBuild Server message: Build round completed after 909 seconds.
09:09:50fs-bluebotBuild Server message: Revision 640b14c08c result: All green
09:39:40_bilgusg#3044 I'm guessing by the derth of further comments from wodz its either perfect or so terrible lol or maybe he is just busy can't say I'm any different but I'm gonna try and pick this back up a day or two a week
09:39:44fs-bluebotGerrit review #3044 at https://gerrit.rockbox.org/r/c/rockbox/+/3044 : Bluetooth Menu WIP by William Wilgus
09:40:56speachythe toolchain mode that has all the necessary libraries for bluetooth is already in, though my builders are probably the only ones that have been updated.
09:41:40speachystill need to write the actual backend code though.
09:44:23_bilgusyeah I'm totally clueless on the interface
09:44:28_bilgusbackend.
09:53:58speachyI'm much more excited about hte native x1000 port. :)
09:59:04_bilgusoh? does that work on that whole segment of players?
10:00
10:00:04speachym3k is the one in gerrit −− not finished (no audio) but it's _native_. Porting that to the various other players is mostly a matter of writing any needed drivers.
10:00:25speachywell, and ifguring out how to patch the OF images appropriately...
10:02:42***No seen item changed, no save performed.
10:07:50_bilgusoh I bet that is so much nicer and FASTER
10:08:54 Quit massiveH (Quit: Leaving)
10:09:38_bilgusI noticed a few days ago that my battery icon was off it only showed ~75-80% in the icon and that battery was at 100% according to the debug menu
10:10:59_bilgusthats the clipzip although I'm not sure if its been that way a while pretty sure its a clean install but I guess I double check first
10:14:44_bilgus#g3129 nice
10:26:59_bilgusoh I see the Ipod 4G has a fix too
10:39:05 Quit koniu (Remote host closed the connection)
10:39:32 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
10:43:14 Join perpetuality [0] (493e8ed2@73.62.142.210)
10:48:57 Quit perpetuality (Quit: Ping timeout (120 seconds))
11:00
11:24:33 Quit daswf852 (Ping timeout: 264 seconds)
11:26:03speachy_bilgus: faster boot certianly, but at runtime probably won't see mucn of a difference. The real benefit is we'll be able to use the full amount of RAM in the system.
11:26:50 Join daswf852 [0] (~daswf852@unaffiliated/dwf)
11:31:45 Join amachronic [0] (5284bbc9@82.132.187.201)
11:31:58amachronichi all
11:32:10amachronicI've made some progress getting the audio to work on the FiiO M3K
11:32:22amachronicbut i'm a little stuck on pcm_play_lock
11:32:46amachronicspeachy: could you tell me what this is supposed to guard
11:34:18speachyamachronic: it's to serialize hardware access.
11:34:56amachronicfrom looking at the other ports, they just seem to disable their DMA interrupt
11:35:01speachyyeah
11:35:07amachronicunfortunately I don't have an easy way to do this on the X1000
11:35:14amachronicthere's only one DMA interrupt in the HW
11:35:38speachyyou don't want the hardware to trigger a buffer refill when you're trying to actively trying to change its settings...
11:35:55amachronicso, I should try to defer the pcm_play_dma_complete callback?
11:36:06speachyamachronic: oh? that doesn't seem right; sure the DMA engine only has one interrupt but each indivudal channel within that controller is maskable
11:36:35speachy(that's what the jz4760 implemenation does)
11:36:46amachronicthe jz4760 doesn't use descriptors
11:37:08amachronicif you use a descriptor, you have to choose whether you want an interrupt ahead of time
11:37:25amachronicUnless you can just change the descriptor in memory or rewrite the register
11:37:34amachronicHaven't tried, but that doesn't seem right
11:37:46speachyyou can rewrite it on the fly actually, but that is inherently racy.
11:38:09speachygimme a sec, gotta dig up the X1000 PM
11:38:40amachronicWell, the reason I suggest deferring pcm_play_dma_complete is that if other ports are disabling their DMA interrupt, when it is re-enabled, they should get the IRQ immediately correct?
11:39:00amachronicSo then I would call pcm_play_dma_complete in pcm_play_unlock to mimic that behavior.
11:39:19amachronicAny reason that would cause an issue?
11:39:57 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
11:41:19speachythe descriptor should only apply to the channel; so if you mask off the interrupt at the channel level (DSIRQM) the channel's interrupt (triggered by the descriptor) will never fire.
11:41:40 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
11:41:50amachronicby DSIRQM you mean "DMA soft IRQ mask?"
11:42:32speachymake that DCIRQM ("Dma CHannel IRQ to MCU Mask")
11:42:55amachronicI think that register applies only if you use the programmable software DMA
11:43:12amachronicthere's a CPU in the DMA engine which you can load firmware to and I think it uses those registers.
11:43:27amachronicWhen you use DMA from the main CPU, I don't think those regs apply
11:44:57 Quit J_Darnley (Ping timeout: 264 seconds)
11:45:03speachyit applies for simple descriptor interrupts.
11:45:39amachronic"the register is read only for other masters but entirely controlled (R/W) by the MCU of PDMA"
11:45:55amachronicthe MCU that Ingenic is referring to is what I'm talking about
11:46:03speachymhmm
11:46:09amachronicI'll go ahead and try writing the register and see what happens
11:47:17 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
11:47:37speachythe thing is, without that how are you to tell what dma channel tripped the interrupt? walking every single descriptor chain is ... insane.
11:48:08amachroniclook at DIRQP
11:48:35amachronicand I just noticed DCIRQM bits are supposed to be 1 at reset
11:49:25amachronicOK, just tested and writing DCIRQM with 0xff does not mask the interrupts
11:49:38speachyin 16.10 it says to use programmable DMA, you enable the TIE for that channel, enable the programmable flag, and _mask_ the DCIRQM bit.
11:50:11amachronicYeah, I'm not using programmable DMA, because that requires writing a separate firmware binary
11:50:34amachronic(Which I would have to compile and load)
11:50:54amachronicWhen they refer to MCU, it does not mean the main X1000 CPU
11:51:05speachythis is .. nuts.
11:51:10amachronicLook at the block diagram at the beginning of the PDMA controller
11:51:23amachronicThat makes it a little clearer I hope
11:51:55speachyit defies belief that they'd effectively require use of the programmable controller to figure out which DMA channel tripped the interrupt.
11:52:04amachronicYou don't need to
11:52:08speachy(without having to poll each channel's registers in turn)
11:52:13amachronicyou use DIRQP
11:52:24amachronicthat just tells you the IRQs pending.
11:52:33amachronicBut there's no corresponding mask register.
11:53:47speachyah, okay. that makes sense, if .. misguided.
11:53:54amachronicbefore you get too deep into one of these Ingenic rabbit holes, I do have sound working but there is a ton of crackling.
11:54:04amachronicIf I go to one of the debug screens, the crackling goes away
11:54:23amachronicSo it must be caused by something running from the main thread, I think.
11:54:59amachronicthat's why I am asking about pcm_play_lock.
11:57:22speachymasking off the whole interrupt is probably the least awful option right now
11:57:31speachysince you're not using DMA anywhere else yet?
11:57:40amachronicIt might not be so bad anyway
11:57:57amachronicThe SD controller (called MSC by ingenic) and the LCD have their own internal DMA controllers
11:58:11amachronicAnd they're definitely not part of the "PDMA controller"
11:58:23amachronicIs there anything else which might need DMA in rockbox?
12:00
12:02:44***Saving seen data "./dancer.seen"
12:05:23speachyUSB
12:09:55 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
12:10:09 Quit J_Darnley (Ping timeout: 264 seconds)
12:11:07speachylooks like the USB controller has an internal DMA feature too. not clear it
12:11:28speachyit's not clear if it's able to do everything but I'm only skimming this
12:12:29amachronicI haven't checked out the USB too deeply myself, but I think it's a designware controller which might be implemented in Rockbox as part of the ARM ports
12:12:54amachronicdon't know if it's the same kind though.
12:14:01speachyamachronic: yep, it's a DWC2 controller
12:15:49speachyso it looks like the only thing on the general DMA engine is audio.
12:17:18amachronicSo I tried disabling the DMA interrupt entirely in pcm_play_lock, and added a check for FIFO underflow; it looks like the crackling is just FIFO underflow.
12:18:02speachyjust using simple oneshot DMA for audio?
12:18:15amachronicyes
12:18:32amachronicso it's probably the same problem as the you mentioned with the jz4760
12:18:36 Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
12:18:45speachyyeah, only much worse seemingly. perhaps due to the LCD update overhead?
12:19:07amachronicI thought so myself, but the debug screen updates the LCD quite frequently too.
12:19:29amachronicIt's only the "View HW info" screen where the crackle disappears; other screens seem to have it
12:19:40speachyI'd make sure you're not rapidly triggering ay other interrupt activity
12:20:40 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
12:20:45speachybarring that, try porting the changes ing#2751
12:20:48fs-bluebotGerrit review #2751 at https://gerrit.rockbox.org/r/c/rockbox/+/2751 : jz4760: (very) WIP: Use double-buffered DMA for PCM data. by Solomon Peachy
12:26:18speachyhang on, met me rebase it first.
12:29:57speachydone
12:35:12amachronicspeachy: Thanks, I'll try getting it up and running and see if it improves things
12:36:14amachronicAlthough didn't you mention Rockbox already keeps a second buffer around?
12:36:43 Quit amachronic (Quit: Connection closed)
12:37:14 Join amachronic [0] (5284bbc9@82.132.187.201)
12:37:19speachyyeah, rockbox double-buffers things but we need two buffers from the HW perspective, which means we need 3.
12:38:25speachy(because the hw descript needs to point at the next buffer)
12:44:27speachy(which under the rockbox->pcmdriver API, we don't know until the first one is returned as completed)
12:49:25 Join MrZeus [0] (~MrZeus@194.37.96.119)
12:55:10 Quit koniu (Ping timeout: 268 seconds)
12:56:36 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13:00
13:33:13 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
13:33:46 Quit amachronic (Quit: Connection closed)
14:00
14:02:23fs-bluebotBuild Server message: New build round started. Revision 7418ec5009, 293 builds, 9 clients.
14:02:45***Saving seen data "./dancer.seen"
14:17:27fs-bluebotBuild Server message: Build round completed after 903 seconds.
14:17:29fs-bluebotBuild Server message: Revision 7418ec5009 result: All green
14:24:55 Quit koniu (Remote host closed the connection)
14:25:24 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
15:00
15:11:20_bilgusg#3144
15:11:22fs-bluebotGerrit review #3144 at https://gerrit.rockbox.org/r/c/rockbox/+/3144 : Add temp file write to config and disk based nvram WIP by William Wilgus
15:13:04_bilgusany thoughts? I figure harddrive players should be opted out but do we have a way currently to determine iflash devices?
15:15:26braewoods_bilgus: well, if you can't detect a CF card vs HDD...
15:15:32braewoodswhat hope is there for iflash?
15:17:27_bilgusI was hoping for a foolproof define but I don't think it should add too much time as the disk is already spinning up for the file write
15:18:40_bilgusI could see the issue of fragmentation coming into play on the disk side as well
15:20:02_bilgusI'd be happy to restrict it to strictly flash storage devices as these are my main concern
15:31:38speachywell, the storage_* API is intended to hide all of that stuff from the rest of the code
15:32:23speachybut even when you have ATA-based storage, there's no foolproof way to tell if it's solid-state.
15:32:55speachythe iflash adapters are easy to flag though −− they advertise that they don't support the mandatory power saving command set
15:33:54speachythere are some standard identity fields that report solid state vs spinning rust but only newer CF cards ever implemented it
15:34:21speachy(I suppose PATA->SATA adatpters would probably do the right thing here too)
15:34:47_bilgusso we could flag the iflash at runtime I suppose but that leaves CF cars on the table
15:35:34_bilgusI guess the question is if itd affect harddrives in any meaningful way but its safer on power loss as well
15:36:09_bilgusor I guess I should say potentially
15:36:13speachyit makes thing safer on power loss but it's going to increase the absolute number of writes, unless I'm mis-reading what it's doing
15:36:37_bilgusrather than overwriting it does a new file then remove / rename
15:36:57speachyI guess that depends on how good the FTL is
15:38:26speachyas long as we're emulating 512B sectors and using FAT, I don't think there's anything meaningful we can do to minimize flash wear.
15:40:25speachydoes our filesystem layer allow atomic "rename over" operations?
15:40:51speachybecause that rename needs to be atomic for this to matter
15:43:10_bilgusappears to https://github.com/Rockbox/rockbox/blob/ca4d63d4d903e3de356afb8d129ae61c660ff9b4/firmware/common/file.c#L1079
15:54:34_bilgusI wonder what the flash wear out is like leading up to the big event on those clip+ and zips I know I have corrupted the OF area with weird crashes and power glitches
15:54:57_bilgusbut its always been recoverable so far
15:56:11_bilgusI guess leading up it would either be a file copying event or just a setting change depending on whats more likely to kill the flash in the area that the bootloader uses
15:56:33_bilgusor is it an all or nothing I'd suspect not
15:57:53_bilgusprobably more than likely its a crash on settings save (looking at you NVRAM emulation)
15:59:39_bilgusso maybe an even better idea would be to write a new settings file on shutdown and do the load off the tmp file and finally rename the tmp file once in a safer enviroment
15:59:51_bilgusie next boot
16:00
16:02:48***Saving seen data "./dancer.seen"
16:03:07_bilgusthat could also be pushed into service to fallback on bad settings
16:03:43speachykeep multiple historical files and go with the one that has the newest timestamp?
16:04:03_bilgusexactly journaling basically
16:05:18_bilgusfor that matter we already have create numbered filename so just have it use the latest
16:05:36_bilgushighest number
16:06:40_bilgusyeah I like that no rename writes and it really doesn't use terrible amounts of space but i'll still need an upper limit
16:08:24 Quit jdarnley (Ping timeout: 245 seconds)
16:08:56_bilgusI wonder just how many files I could potentially create in a day of normal use I suppose settings only when I chnaged them but every shutdown we have the track index or bookmarks
16:09:21_bilgusand on emulated nvram it saves the rtc on shutdown
16:09:47_bilgusso say 10 a day potentially 100
16:10:15_bilgusso long it is
16:10:28 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
16:11:06speachythe thing is even these sansas dying due to flashw earing out is still well beyond what their maker thought their lifespan would be
16:12:24_bilgusof course they planned on the warranty period lol
16:12:48_bilgusbut I like the idea of keeping stuff out of the landfill
16:13:26speachy(then you have modern DAPs like the fiio m3k that you have a hard time seeing lasting even through the end of the nominal warranry period due to how badly they abuse the flash)
16:14:21 Quit pamaury (Ping timeout: 264 seconds)
16:14:27_bilgusbuy another!
16:16:15_bilgusI don't care so much wearing out sd cards at least they are replaceable
16:16:34_bilgusand get cheaper
16:16:37speachyrockbox doens't write anything under normal "going through a playlist" operation, correct? only when stopping/shutting down?
16:17:08_bilguswell thats the whole thing with how the dynamic playlist works
16:17:27_bilgusit actually stores only changes from a base playlist
16:17:53_bilgusthey could be written potentially several times
16:18:09_bilgusbut in normal operation I don't believe so
16:19:15_bilgusso your shuffle of a playlist is only a bunch of randomized positions written to ram but they are backed my the playlist control file
16:19:54_bilgushmm I'd need to check just how often the playlist control file is synced to say for sure
16:20:46_bilgusthats the one that sometime can't be read after usb unplug
16:21:22_bilgusso it'd have to get written on usb plug when it relinquishes the disk
16:22:08 Quit daswf852 (Ping timeout: 245 seconds)
16:22:58 Join daswf852 [0] (~daswf852@unaffiliated/dwf)
16:23:29_bilgushmm
16:24:12speachyany DAP is going to have to save state on shutdown/etc, or in response to user manipulation.
16:24:56speachyI just wonder if we have a, say, 10 hour playlist, and press play on a fully charged battery, will it write anything until the system auto-shuts down due to the battery level?
16:26:35_bilgushttps://github.com/Rockbox/rockbox/blob/master/apps/playlist.c#L1961
16:26:36 Quit bluebrother (Quit: leaving)
16:26:43 Quit fs-bluebot (Remote host closed the connection)
16:27:17_bilgusI don't think so it only applies if you do something to the playlist
16:27:47_bilgusotherwise it loads that control file and stores the difference in ram
16:28:58speachyok. so.. in other words, we don't really have any opportunities to reduce the number of logical write operations
16:29:27speachywe might be able to reduce the number of low-level writes in response to those logical writes (ie "update playlist control file" or "save configuration")
16:30:15speachybut givne the realities of FAT, any file write is likely to trigger at least 3 low-level writes (update FAT, update directory, update file contents)
16:30:36_bilgusthat mechanism should already happen as a byproduct of the spinning disk callbacks
16:30:45 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
16:31:12_bilgusthey are discarded on the flash devices though
16:31:50speachyI mean the data that's being written is likely in three different places on "disk"
16:31:58 Join fs-bluebot [0] (~fs-bluebo@55d4a316.access.ecotel.net)
16:32:36speachy(ie three different erase blocks)
16:33:02speachyunless there's some really fancy FTL going on in the background
16:33:23_bilgusthat is a good point I somehow doubt it
16:34:42 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
16:35:02speachygranted these things probably have much higher write endurance than a modern flash would. :)
16:35:11_bilgusI figure the nvram disk write to be the most likely culprit but maybe it is pointless unless I move all the writes to the same
16:36:08_bilgusI guess I could hook the truncate file flag and make it happen lower
16:36:47speachyvery few targets have true nvram, correct?
16:37:25_bilgusyeah no exacy counts but i'd estimate 4
16:37:31 Join PimpiN8 [0] (~PimpiN8@2001:1c04:3308:a500:1a9:bc4a:ecc6:49c3)
16:37:42speachythat doesn't include anything archos? :D
16:37:51_bilgus2
16:38:37_bilgusidk thats why I asked for thoughts on the patch of course its a rabbit hole
16:40:14_bilgusI think I should probably pull at that playlist control file I've been meaning to look into it as well
16:40:15 Quit mikroflops (Ping timeout: 246 seconds)
16:41:07_bilgusthere was someone somewhere asking about the rtc clock never saving that got me back on this
16:42:08 Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se)
16:44:27speachyI'm thinking of trying to tackle fs#13266
16:44:29fs-bluebothttps://www.rockbox.org/tracker/task/13266 Some FLAC Files Have Glitched Playback (bugs, unconfirmed)
16:44:43speachyreproducable in the simulator so it's not target-dependent
16:44:53_bilgusnice
16:45:31speachybut like everything else it's time, time time..
16:46:33speachythe notion about dealing with a ~15-year delta in the codec vs upstream is a bit daunting
16:48:49_bilguslol is it 15 after I updated it last time?
16:49:17_bilgusI look at it this evening to see whats up with the decoder
16:51:19_bilgusoh that was opus lol
16:51:51speachyyeah, that was opus, which never did get merged −− IIRC it was a ~1% performance impact.
16:52:28speachythe ticket has a file that exhibits teh glitch.
16:53:14_bilgusyeah I grabbed it
16:53:37_bilgusit has album art but I need to look at it closer
16:56:51mendel_munkis_bilgus:thanks for reminding me, I should get around to finishing my RTC work.
17:00
17:00:36 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
17:21:38 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:22:11 Quit koniu (Ping timeout: 268 seconds)
17:35:59 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
17:36:51 Join PimpiN8 [0] (~PimpiN8@178.239.173.176)
17:48:28 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
17:59:54 Quit lebellium (Quit: Leaving)
18:00
18:02:50***Saving seen data "./dancer.seen"
18:12:41 Quit f1refly (Remote host closed the connection)
18:13:00 Join f1refly [0] (~f1refly@2a01:c23:9031:4100:fcae:babe:a132:2860)
18:25:53 Join some0nee [0] (44c33990@ool-44c33990.dyn.optonline.net)
18:26:23some0neeEllo everyone. Is there documentation for porting to a new device around?
18:27:28speachyhttps://www.rockbox.org/wiki/bin/view/Main/NewPort
18:27:45some0neeThank you
18:27:46speachymore or less
18:37:02 Quit some0nee (Ping timeout: 240 seconds)
18:40:50 Quit PimpiN8 (Quit: Textual IRC Client: www.textualapp.com)
18:50:18 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
19:00
19:40:17 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be)
19:40:55 Quit J_Darnley (Ping timeout: 240 seconds)
19:43:49 Join amachronic [0] (5284ba7c@82.132.186.124)
19:45:56amachronicspeachy: are you still around? I have some audio-related code to push and I wanted to know if I should update https://gerrit.rockbox.org/r/c/rockbox/+/3137 or do it as a separate change on top of that
19:46:06amachronicwhichever is easier for you.
19:54:43_bilgusamachronic, being that there really isn't a before 3137 I doubt it makes too much difference
19:55:03speachyamachronic: merge it into 3137
19:55:27amachronicOK, thanks
19:58:31speachyoh, in the updated commit message, it helps if you could describe (in high-level terms at least) what changed from the previous one.
19:58:44speachyhelps make review a little easier for those large changesets
19:59:26amachronicDone
20:00
20:00:03amachronicbtw, I did manage to get that PCM double buffering working, but it actually made the crackle/pop WORSE.
20:00:16speachyheh, okay.
20:00:26amachronicironically driving the AIC FIFO using the CPU directly is giving me no underflows.
20:00:49speachythe underlying problem probably lies elsewhere. (most likely blocked irq handling)
20:01:00amachronicI was wondering if it might be a caching issue
20:01:49amachronicthat bit me before with the storage code, some cache lines on the start/end of the buffer would get corrupted.
20:02:34speachyif you properly use the constructs for invalidating the cache, it should be okay.
20:02:53***Saving seen data "./dancer.seen"
20:02:59speachy(spent a lot of time getting it right on the 4760. though it's possible the x1000 might need thigns done slightly differently...)
20:04:18amachronicI did commit_dcache_range on the audio buffer and DMA descriptors, so it should've been OK, but it's not easy to check since the DMA is writing to a place we can't see
20:04:52amachronic(namely the AIC FIFO)
20:04:53speachyalso need to invalidate the cache before reading the descriptors back
20:05:24speachy(general rule; I havne't checked your code to see if you're already doing that)
20:05:57speachywhat do you see as your next steps with this?
20:06:50amachronicgiven that the audio's "stable" right now, I was going to try my hand at getting a working bootloader
20:07:09 Quit ac_laptop (Ping timeout: 264 seconds)
20:07:17speachyI'd like to still properly review things before merging it, but functionally it's in better shape than some of the other stuff that's in-tree
20:08:57amachronicdo you know anything about flash memory write? I'm under the impression I need to do some kind of ECC in software
20:09:05amachronicor does it depend on the flash chip?
20:09:14speachyit's not something I'm personally familiar with
20:09:28speachybut yeah, we have to implement all of that in software
20:10:23amachronicok, so I'd have to do some research there... probably going to take a while.
20:10:30speachyI'd start by looking at what u-boot does for these things
20:11:44speachy(or I think fiio used redboot instead? but it shoudl all be the same algorithms)
20:12:19speachyI don't recall if we've implemented the ECC stuff already for other native-flash targets.
20:12:24amachronicfrom my disassembling of the fiio's SPL, we don't need to do ECC on read
20:12:48amachronicAnd for rockbox I think only some of the ipods have flash write support, but it looks complicated
20:13:11speachythe ipod nano series, all of the sansa targets, and I'm sure many more.
20:13:59speachyfor writing we can use the ingenic tools until we get reliable reading
20:14:19speachyI don't personally think it's worth exposing the onboard flash for general use
20:14:52speachyso other than perhaps an in-system "flash a new bootloader image" plugin, there's no need to write to the flash.
20:15:00speachy(it's only 1Gbit anyway, IIRC)
20:15:45amachronicI don't think using it at runtime is worth it either, but AFAIK there is no way we can run code on a stock FiiO M3K except by booting over USB
20:16:06amachronicthe only way I have access to the Linux is via that xvortex build.
20:16:26amachronicI'd prefer not to rely on it if at all possible
20:16:28speachywe do theoretically have the ability to construct a custom swupdate image.
20:16:55amachronicah really, I thought it was signed or something?
20:16:56speachy(fiio supposedly used the "default" ingenic signing keys)
20:17:08amachronicoh
20:17:12speachynobody's done the legwork to confirm that and generate a new one yet
20:25:48speachybtw, you've done a _really_ good job on this thing. How long were you working on it?
20:30:14amachronicI started back in June 2020, but I could never get the LCD working so it made debugging a huge chore
20:31:01amachronicso I abandoned it for many months and I decided to try getting it running last month.
20:31:31amachronicI had to port all my register defs to reggen and rewrite/review all existing code
20:31:35fs-bluebotBuild Server message: New build round started. Revision 73cee8f177, 293 builds, 9 clients.
20:32:12amachroniconce I got the LCD working it was a piece of cake (relatively speaking)
20:33:54amachronicthis is actually my first serious project with kernel/hardware code so I'm glad to hear somebody thinks it's good ;)
20:47:43fs-bluebotBuild Server message: Build round completed after 967 seconds.
20:47:46fs-bluebotBuild Server message: Revision 73cee8f177 result: All green
20:51:10 Quit MrZeus (Ping timeout: 276 seconds)
20:53:49 Quit amachronic (Quit: Connection closed)
21:00
21:04:59_bilgusspeachy you said you could reproduce the error in the sim was it a glitch about 10 seconds in?
21:05:08_bilgusre FLAC
21:07:21_bilgusnm I see the OPs info
21:07:36_bilgusand can reproduce
21:10:55fs-bluebotBuild Server message: New build round started. Revision a6eafc86f8, 293 builds, 9 clients.
21:25:27fs-bluebotBuild Server message: Build round completed after 872 seconds.
21:25:30fs-bluebotBuild Server message: Revision a6eafc86f8 result: All green
21:27:21 Join amiconn_ [0] (jens@rockbox/developer/amiconn)
21:27:21 Nick amiconn is now known as Guest66098 (jens@rockbox/developer/amiconn)
21:27:21 Quit Guest66098 (Killed (moon.freenode.net (Nickname regained by services)))
21:27:21 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn)
21:28:28speachyah, the sweet sound of my builder spooling up its fans..
21:46:17 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
21:58:29speachyamachronic: I think you screwed up the OST clocking (and the udelay that relies on it)
22:00
22:02:57***Saving seen data "./dancer.seen"
22:11:59 Join pixelma_ [0] (marianne@rockbox/staff/pixelma)
22:11:59 Nick pixelma is now known as Guest59053 (marianne@rockbox/staff/pixelma)
22:11:59 Quit Guest59053 (Killed (moon.freenode.net (Nickname regained by services)))
22:11:59 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma)
22:18:17speachyhmm, nevermind. still wrapping my head around this.
22:22:04speachyonly about 1/3 through. next up is the clock tree, and that will hve to wait for another day.
22:30:44speachyit's not building any of the plugins, hmm.
22:34:14 Quit WakiMiko (Ping timeout: 264 seconds)
22:44:46 Quit bonfire (Quit: Leaving)
22:44:54_bilgusspeachy RE flac
22:45:17_bilgusour implementation is of different provenance than the xiph one
22:45:49_bilgusI found a few overflows and have it narrowed down to decode_subframe_lpc
22:45:55 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko)
22:49:09_bilgusIm not seeing a mention of buggy_lpc in our decoder so I'd sav its OLLLLDDDD
22:57:16 Join f1reflyylmao [0] (~f1refly@2a01:c23:8846:c400:3ff3:604a:d9ab:b67e)
22:58:15 Quit f1refly (Ping timeout: 240 seconds)
22:58:15 Nick f1reflyylmao is now known as f1refly (~f1refly@2a01:c23:8846:c400:3ff3:604a:d9ab:b67e)
23:00
23:01:39 Quit cockroach (Quit: leaving)
23:04:26 Quit koniu (Ping timeout: 268 seconds)
23:08:44 Join saratoga [0] (620acd42@cpe-98-10-205-66.rochester.res.rr.com)
23:09:01saratogalibffmpegFLAC is indeed not from Xiph :)
23:09:21saratogawe switched from the Xiph decoder back in 2005
23:09:36saratogathe ffmpeg decoders are almost always much faster
23:10:11saratogawe actually use the ffmpeg MDCT on all pure transform codecs but Opus because it was way faster than the libfaad or Xiph one
23:16:27 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
23:16:46saratogausually for tracking down bugs in our ports of ffmpeg codecs, I end up picking out the frame that doesn't decode right, then run it through both codecs and look to see where the values diverge
23:17:33saratogathe ability to compile the codeclib separately from rockbox makes this so much easier than it used to be
23:19:06_bilgusI saw a note of testing and checking the crc between implementations
23:20:23saratogayou mean to find the bad frame?
23:20:31saratogai usually just subtracted the PCM values
23:22:33saratogahuh the codeclib isn't building for me
23:23:13_bilgusproblem is I havent figured out what to do with it now that I have the bad frame I guess I need to find an upstream of the ffmpeg version
23:24:00saratogai used to keep a copy of ffmpeg built from source somewhere for this reason
23:32:56saratogawow warble (codec debug tool) may have been broken since 2013 if you try to compile it for a target with recording
23:43:58 Join M-iam-some0nee[m [0] (m-iam-some@gateway/shell/matrix.org/x-wppdpteiyxyvykqt)
23:46:48_bilgusI see our endian is reversed from the source
23:51:06saratogahuh whole mess of api incompatibilities with warble since i used it last
23:51:16_bilgusat first I thought it was to use lpc_decode_emac but it appears to have the same offset odd maybe someone found it more performant
23:51:52_bilgussaratoga you said broken since 2013 I'm sure there are a lot
23:52:39_bilguswell glitches are still there after bringing it up to circa 2015
23:52:42saratogai think i used it since then, but definitely encoders were broken (never use those)
23:54:13_bilgusI found 1 potential signed overflow that appears to be fixed in the updated source although they use a macro
23:54:42_bilgusbut it wasn't eben in the lpc decode so maybe good for something

Previous day | Next day