| 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:44 | speachy | _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:33 | fs-bluebot | Build 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:42 | fs-bluebot | Build Server message: Build round completed after 909 seconds. |
| 09:09:50 | fs-bluebot | Build Server message: Revision 640b14c08c result: All green |
| 09:39:40 | _bilgus | g#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:44 | fs-bluebot | Gerrit review #3044 at https://gerrit.rockbox.org/r/c/rockbox/+/3044 : Bluetooth Menu WIP by William Wilgus |
| 09:40:56 | speachy | the 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:40 | speachy | still need to write the actual backend code though. |
| 09:44:23 | _bilgus | yeah I'm totally clueless on the interface |
| 09:44:28 | _bilgus | backend. |
| 09:53:58 | speachy | I'm much more excited about hte native x1000 port. :) |
| 09:59:04 | _bilgus | oh? does that work on that whole segment of players? |
| 10:00 |
| 10:00:04 | speachy | m3k 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:25 | speachy | well, and ifguring out how to patch the OF images appropriately... |
| 10:02:42 | *** | No seen item changed, no save performed. |
| 10:07:50 | _bilgus | oh I bet that is so much nicer and FASTER |
| 10:08:54 | | Quit massiveH (Quit: Leaving) |
| 10:09:38 | _bilgus | I 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 | _bilgus | thats 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 | _bilgus | oh 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:03 | speachy | _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:58 | amachronic | hi all |
| 11:32:10 | amachronic | I've made some progress getting the audio to work on the FiiO M3K |
| 11:32:22 | amachronic | but i'm a little stuck on pcm_play_lock |
| 11:32:46 | amachronic | speachy: could you tell me what this is supposed to guard |
| 11:34:18 | speachy | amachronic: it's to serialize hardware access. |
| 11:34:56 | amachronic | from looking at the other ports, they just seem to disable their DMA interrupt |
| 11:35:01 | speachy | yeah |
| 11:35:07 | amachronic | unfortunately I don't have an easy way to do this on the X1000 |
| 11:35:14 | amachronic | there's only one DMA interrupt in the HW |
| 11:35:38 | speachy | you don't want the hardware to trigger a buffer refill when you're trying to actively trying to change its settings... |
| 11:35:55 | amachronic | so, I should try to defer the pcm_play_dma_complete callback? |
| 11:36:06 | speachy | amachronic: 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:35 | speachy | (that's what the jz4760 implemenation does) |
| 11:36:46 | amachronic | the jz4760 doesn't use descriptors |
| 11:37:08 | amachronic | if you use a descriptor, you have to choose whether you want an interrupt ahead of time |
| 11:37:25 | amachronic | Unless you can just change the descriptor in memory or rewrite the register |
| 11:37:34 | amachronic | Haven't tried, but that doesn't seem right |
| 11:37:46 | speachy | you can rewrite it on the fly actually, but that is inherently racy. |
| 11:38:09 | speachy | gimme a sec, gotta dig up the X1000 PM |
| 11:38:40 | amachronic | Well, 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:00 | amachronic | So then I would call pcm_play_dma_complete in pcm_play_unlock to mimic that behavior. |
| 11:39:19 | amachronic | Any reason that would cause an issue? |
| 11:39:57 | | Quit St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 11:41:19 | speachy | the 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:50 | amachronic | by DSIRQM you mean "DMA soft IRQ mask?" |
| 11:42:32 | speachy | make that DCIRQM ("Dma CHannel IRQ to MCU Mask") |
| 11:42:55 | amachronic | I think that register applies only if you use the programmable software DMA |
| 11:43:12 | amachronic | there's a CPU in the DMA engine which you can load firmware to and I think it uses those registers. |
| 11:43:27 | amachronic | When 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:03 | speachy | it applies for simple descriptor interrupts. |
| 11:45:39 | amachronic | "the register is read only for other masters but entirely controlled (R/W) by the MCU of PDMA" |
| 11:45:55 | amachronic | the MCU that Ingenic is referring to is what I'm talking about |
| 11:46:03 | speachy | mhmm |
| 11:46:09 | amachronic | I'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:37 | speachy | the thing is, without that how are you to tell what dma channel tripped the interrupt? walking every single descriptor chain is ... insane. |
| 11:48:08 | amachronic | look at DIRQP |
| 11:48:35 | amachronic | and I just noticed DCIRQM bits are supposed to be 1 at reset |
| 11:49:25 | amachronic | OK, just tested and writing DCIRQM with 0xff does not mask the interrupts |
| 11:49:38 | speachy | in 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:11 | amachronic | Yeah, I'm not using programmable DMA, because that requires writing a separate firmware binary |
| 11:50:34 | amachronic | (Which I would have to compile and load) |
| 11:50:54 | amachronic | When they refer to MCU, it does not mean the main X1000 CPU |
| 11:51:05 | speachy | this is .. nuts. |
| 11:51:10 | amachronic | Look at the block diagram at the beginning of the PDMA controller |
| 11:51:23 | amachronic | That makes it a little clearer I hope |
| 11:51:55 | speachy | it defies belief that they'd effectively require use of the programmable controller to figure out which DMA channel tripped the interrupt. |
| 11:52:04 | amachronic | You don't need to |
| 11:52:08 | speachy | (without having to poll each channel's registers in turn) |
| 11:52:13 | amachronic | you use DIRQP |
| 11:52:24 | amachronic | that just tells you the IRQs pending. |
| 11:52:33 | amachronic | But there's no corresponding mask register. |
| 11:53:47 | speachy | ah, okay. that makes sense, if .. misguided. |
| 11:53:54 | amachronic | before 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:04 | amachronic | If I go to one of the debug screens, the crackling goes away |
| 11:54:23 | amachronic | So it must be caused by something running from the main thread, I think. |
| 11:54:59 | amachronic | that's why I am asking about pcm_play_lock. |
| 11:57:22 | speachy | masking off the whole interrupt is probably the least awful option right now |
| 11:57:31 | speachy | since you're not using DMA anywhere else yet? |
| 11:57:40 | amachronic | It might not be so bad anyway |
| 11:57:57 | amachronic | The SD controller (called MSC by ingenic) and the LCD have their own internal DMA controllers |
| 11:58:11 | amachronic | And they're definitely not part of the "PDMA controller" |
| 11:58:23 | amachronic | Is there anything else which might need DMA in rockbox? |
| 12:00 |
| 12:02:44 | *** | Saving seen data "./dancer.seen" |
| 12:05:23 | speachy | USB |
| 12:09:55 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 12:10:09 | | Quit J_Darnley (Ping timeout: 264 seconds) |
| 12:11:07 | speachy | looks like the USB controller has an internal DMA feature too. not clear it |
| 12:11:28 | speachy | it's not clear if it's able to do everything but I'm only skimming this |
| 12:12:29 | amachronic | I 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:54 | amachronic | don't know if it's the same kind though. |
| 12:14:01 | speachy | amachronic: yep, it's a DWC2 controller |
| 12:15:49 | speachy | so it looks like the only thing on the general DMA engine is audio. |
| 12:17:18 | amachronic | So 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:02 | speachy | just using simple oneshot DMA for audio? |
| 12:18:15 | amachronic | yes |
| 12:18:32 | amachronic | so 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:45 | speachy | yeah, only much worse seemingly. perhaps due to the LCD update overhead? |
| 12:19:07 | amachronic | I thought so myself, but the debug screen updates the LCD quite frequently too. |
| 12:19:29 | amachronic | It's only the "View HW info" screen where the crackle disappears; other screens seem to have it |
| 12:19:40 | speachy | I'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:45 | speachy | barring that, try porting the changes in g#2751 |
| 12:20:48 | fs-bluebot | Gerrit 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:18 | speachy | hang on, met me rebase it first. |
| 12:29:57 | speachy | done |
| 12:35:12 | amachronic | speachy: Thanks, I'll try getting it up and running and see if it improves things |
| 12:36:14 | amachronic | Although 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:19 | speachy | yeah, rockbox double-buffers things but we need two buffers from the HW perspective, which means we need 3. |
| 12:38:25 | speachy | (because the hw descript needs to point at the next buffer) |
| 12:44:27 | speachy | (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:23 | fs-bluebot | Build Server message: New build round started. Revision 7418ec5009, 293 builds, 9 clients. |
| 14:02:45 | *** | Saving seen data "./dancer.seen" |
| 14:17:27 | fs-bluebot | Build Server message: Build round completed after 903 seconds. |
| 14:17:29 | fs-bluebot | Build 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 | _bilgus | g#3144 |
| 15:11:22 | fs-bluebot | Gerrit 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 | _bilgus | any thoughts? I figure harddrive players should be opted out but do we have a way currently to determine iflash devices? |
| 15:15:26 | braewoods | _bilgus: well, if you can't detect a CF card vs HDD... |
| 15:15:32 | braewoods | what hope is there for iflash? |
| 15:17:27 | _bilgus | I 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 | _bilgus | I could see the issue of fragmentation coming into play on the disk side as well |
| 15:20:02 | _bilgus | I'd be happy to restrict it to strictly flash storage devices as these are my main concern |
| 15:31:38 | speachy | well, the storage_* API is intended to hide all of that stuff from the rest of the code |
| 15:32:23 | speachy | but even when you have ATA-based storage, there's no foolproof way to tell if it's solid-state. |
| 15:32:55 | speachy | the iflash adapters are easy to flag though −− they advertise that they don't support the mandatory power saving command set |
| 15:33:54 | speachy | there are some standard identity fields that report solid state vs spinning rust but only newer CF cards ever implemented it |
| 15:34:21 | speachy | (I suppose PATA->SATA adatpters would probably do the right thing here too) |
| 15:34:47 | _bilgus | so we could flag the iflash at runtime I suppose but that leaves CF cars on the table |
| 15:35:34 | _bilgus | I guess the question is if itd affect harddrives in any meaningful way but its safer on power loss as well |
| 15:36:09 | _bilgus | or I guess I should say potentially |
| 15:36:13 | speachy | it 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 | _bilgus | rather than overwriting it does a new file then remove / rename |
| 15:36:57 | speachy | I guess that depends on how good the FTL is |
| 15:38:26 | speachy | as 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:25 | speachy | does our filesystem layer allow atomic "rename over" operations? |
| 15:40:51 | speachy | because that rename needs to be atomic for this to matter |
| 15:43:10 | _bilgus | appears to https://github.com/Rockbox/rockbox/blob/ca4d63d4d903e3de356afb8d129ae61c660ff9b4/firmware/common/file.c#L1079 |
| 15:54:34 | _bilgus | I 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 | _bilgus | but its always been recoverable so far |
| 15:56:11 | _bilgus | I 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 | _bilgus | or is it an all or nothing I'd suspect not |
| 15:57:53 | _bilgus | probably more than likely its a crash on settings save (looking at you NVRAM emulation) |
| 15:59:39 | _bilgus | so 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 | _bilgus | ie next boot |
| 16:00 |
| 16:02:48 | *** | Saving seen data "./dancer.seen" |
| 16:03:07 | _bilgus | that could also be pushed into service to fallback on bad settings |
| 16:03:43 | speachy | keep multiple historical files and go with the one that has the newest timestamp? |
| 16:04:03 | _bilgus | exactly journaling basically |
| 16:05:18 | _bilgus | for that matter we already have create numbered filename so just have it use the latest |
| 16:05:36 | _bilgus | highest number |
| 16:06:40 | _bilgus | yeah 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 | _bilgus | I 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 | _bilgus | and on emulated nvram it saves the rtc on shutdown |
| 16:09:47 | _bilgus | so say 10 a day potentially 100 |
| 16:10:15 | _bilgus | so long it is |
| 16:10:28 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 16:11:06 | speachy | the 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 | _bilgus | of course they planned on the warranty period lol |
| 16:12:48 | _bilgus | but I like the idea of keeping stuff out of the landfill |
| 16:13:26 | speachy | (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 | _bilgus | buy another! |
| 16:16:15 | _bilgus | I don't care so much wearing out sd cards at least they are replaceable |
| 16:16:34 | _bilgus | and get cheaper |
| 16:16:37 | speachy | rockbox doens't write anything under normal "going through a playlist" operation, correct? only when stopping/shutting down? |
| 16:17:08 | _bilgus | well thats the whole thing with how the dynamic playlist works |
| 16:17:27 | _bilgus | it actually stores only changes from a base playlist |
| 16:17:53 | _bilgus | they could be written potentially several times |
| 16:18:09 | _bilgus | but in normal operation I don't believe so |
| 16:19:15 | _bilgus | so 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 | _bilgus | hmm I'd need to check just how often the playlist control file is synced to say for sure |
| 16:20:46 | _bilgus | thats the one that sometime can't be read after usb unplug |
| 16:21:22 | _bilgus | so 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 | _bilgus | hmm |
| 16:24:12 | speachy | any DAP is going to have to save state on shutdown/etc, or in response to user manipulation. |
| 16:24:56 | speachy | I 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 | _bilgus | https://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 | _bilgus | I don't think so it only applies if you do something to the playlist |
| 16:27:47 | _bilgus | otherwise it loads that control file and stores the difference in ram |
| 16:28:58 | speachy | ok. so.. in other words, we don't really have any opportunities to reduce the number of logical write operations |
| 16:29:27 | speachy | we 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:15 | speachy | but 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 | _bilgus | that 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 | _bilgus | they are discarded on the flash devices though |
| 16:31:50 | speachy | I 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:36 | speachy | (ie three different erase blocks) |
| 16:33:02 | speachy | unless there's some really fancy FTL going on in the background |
| 16:33:23 | _bilgus | that is a good point I somehow doubt it |
| 16:34:42 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 16:35:02 | speachy | granted these things probably have much higher write endurance than a modern flash would. :) |
| 16:35:11 | _bilgus | I 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 | _bilgus | I guess I could hook the truncate file flag and make it happen lower |
| 16:36:47 | speachy | very few targets have true nvram, correct? |
| 16:37:25 | _bilgus | yeah 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:42 | speachy | that doesn't include anything archos? :D |
| 16:37:51 | _bilgus | 2 |
| 16:38:37 | _bilgus | idk thats why I asked for thoughts on the patch of course its a rabbit hole |
| 16:40:14 | _bilgus | I 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 | _bilgus | there 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:27 | speachy | I'm thinking of trying to tackle fs#13266 |
| 16:44:29 | fs-bluebot | https://www.rockbox.org/tracker/task/13266 Some FLAC Files Have Glitched Playback (bugs, unconfirmed) |
| 16:44:43 | speachy | reproducable in the simulator so it's not target-dependent |
| 16:44:53 | _bilgus | nice |
| 16:45:31 | speachy | but like everything else it's time, time time.. |
| 16:46:33 | speachy | the notion about dealing with a ~15-year delta in the codec vs upstream is a bit daunting |
| 16:48:49 | _bilgus | lol is it 15 after I updated it last time? |
| 16:49:17 | _bilgus | I look at it this evening to see whats up with the decoder |
| 16:51:19 | _bilgus | oh that was opus lol |
| 16:51:51 | speachy | yeah, that was opus, which never did get merged −− IIRC it was a ~1% performance impact. |
| 16:52:28 | speachy | the ticket has a file that exhibits teh glitch. |
| 16:53:14 | _bilgus | yeah I grabbed it |
| 16:53:37 | _bilgus | it has album art but I need to look at it closer |
| 16:56:51 | mendel_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:23 | some0nee | Ello everyone. Is there documentation for porting to a new device around? |
| 18:27:28 | speachy | https://www.rockbox.org/wiki/bin/view/Main/NewPort |
| 18:27:45 | some0nee | Thank you |
| 18:27:46 | speachy | more 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:56 | amachronic | speachy: 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:06 | amachronic | whichever is easier for you. |
| 19:54:43 | _bilgus | amachronic, being that there really isn't a before 3137 I doubt it makes too much difference |
| 19:55:03 | speachy | amachronic: merge it into 3137 |
| 19:55:27 | amachronic | OK, thanks |
| 19:58:31 | speachy | oh, 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:44 | speachy | helps make review a little easier for those large changesets |
| 19:59:26 | amachronic | Done |
| 20:00 |
| 20:00:03 | amachronic | btw, I did manage to get that PCM double buffering working, but it actually made the crackle/pop WORSE. |
| 20:00:16 | speachy | heh, okay. |
| 20:00:26 | amachronic | ironically driving the AIC FIFO using the CPU directly is giving me no underflows. |
| 20:00:49 | speachy | the underlying problem probably lies elsewhere. (most likely blocked irq handling) |
| 20:01:00 | amachronic | I was wondering if it might be a caching issue |
| 20:01:49 | amachronic | that bit me before with the storage code, some cache lines on the start/end of the buffer would get corrupted. |
| 20:02:34 | speachy | if you properly use the constructs for invalidating the cache, it should be okay. |
| 20:02:53 | *** | Saving seen data "./dancer.seen" |
| 20:02:59 | speachy | (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:18 | amachronic | I 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:52 | amachronic | (namely the AIC FIFO) |
| 20:04:53 | speachy | also need to invalidate the cache before reading the descriptors back |
| 20:05:24 | speachy | (general rule; I havne't checked your code to see if you're already doing that) |
| 20:05:57 | speachy | what do you see as your next steps with this? |
| 20:06:50 | amachronic | given 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:17 | speachy | I'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:57 | amachronic | do you know anything about flash memory write? I'm under the impression I need to do some kind of ECC in software |
| 20:09:05 | amachronic | or does it depend on the flash chip? |
| 20:09:14 | speachy | it's not something I'm personally familiar with |
| 20:09:28 | speachy | but yeah, we have to implement all of that in software |
| 20:10:23 | amachronic | ok, so I'd have to do some research there... probably going to take a while. |
| 20:10:30 | speachy | I'd start by looking at what u-boot does for these things |
| 20:11:44 | speachy | (or I think fiio used redboot instead? but it shoudl all be the same algorithms) |
| 20:12:19 | speachy | I don't recall if we've implemented the ECC stuff already for other native-flash targets. |
| 20:12:24 | amachronic | from my disassembling of the fiio's SPL, we don't need to do ECC on read |
| 20:12:48 | amachronic | And for rockbox I think only some of the ipods have flash write support, but it looks complicated |
| 20:13:11 | speachy | the ipod nano series, all of the sansa targets, and I'm sure many more. |
| 20:13:59 | speachy | for writing we can use the ingenic tools until we get reliable reading |
| 20:14:19 | speachy | I don't personally think it's worth exposing the onboard flash for general use |
| 20:14:52 | speachy | so other than perhaps an in-system "flash a new bootloader image" plugin, there's no need to write to the flash. |
| 20:15:00 | speachy | (it's only 1Gbit anyway, IIRC) |
| 20:15:45 | amachronic | I 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:06 | amachronic | the only way I have access to the Linux is via that xvortex build. |
| 20:16:26 | amachronic | I'd prefer not to rely on it if at all possible |
| 20:16:28 | speachy | we do theoretically have the ability to construct a custom swupdate image. |
| 20:16:55 | amachronic | ah really, I thought it was signed or something? |
| 20:16:56 | speachy | (fiio supposedly used the "default" ingenic signing keys) |
| 20:17:08 | amachronic | oh |
| 20:17:12 | speachy | nobody's done the legwork to confirm that and generate a new one yet |
| 20:25:48 | speachy | btw, you've done a _really_ good job on this thing. How long were you working on it? |
| 20:30:14 | amachronic | I started back in June 2020, but I could never get the LCD working so it made debugging a huge chore |
| 20:31:01 | amachronic | so I abandoned it for many months and I decided to try getting it running last month. |
| 20:31:31 | amachronic | I had to port all my register defs to reggen and rewrite/review all existing code |
| 20:31:35 | fs-bluebot | Build Server message: New build round started. Revision 73cee8f177, 293 builds, 9 clients. |
| 20:32:12 | amachronic | once I got the LCD working it was a piece of cake (relatively speaking) |
| 20:33:54 | amachronic | this is actually my first serious project with kernel/hardware code so I'm glad to hear somebody thinks it's good ;) |
| 20:47:43 | fs-bluebot | Build Server message: Build round completed after 967 seconds. |
| 20:47:46 | fs-bluebot | Build 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 | _bilgus | speachy you said you could reproduce the error in the sim was it a glitch about 10 seconds in? |
| 21:05:08 | _bilgus | re FLAC |
| 21:07:21 | _bilgus | nm I see the OPs info |
| 21:07:36 | _bilgus | and can reproduce |
| 21:10:55 | fs-bluebot | Build Server message: New build round started. Revision a6eafc86f8, 293 builds, 9 clients. |
| 21:25:27 | fs-bluebot | Build Server message: Build round completed after 872 seconds. |
| 21:25:30 | fs-bluebot | Build 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:28 | speachy | ah, 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:29 | speachy | amachronic: 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:17 | speachy | hmm, nevermind. still wrapping my head around this. |
| 22:22:04 | speachy | only about 1/3 through. next up is the clock tree, and that will hve to wait for another day. |
| 22:30:44 | speachy | it'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 | _bilgus | speachy RE flac |
| 22:45:17 | _bilgus | our implementation is of different provenance than the xiph one |
| 22:45:49 | _bilgus | I 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 | _bilgus | Im 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:01 | saratoga | libffmpegFLAC is indeed not from Xiph :) |
| 23:09:21 | saratoga | we switched from the Xiph decoder back in 2005 |
| 23:09:36 | saratoga | the ffmpeg decoders are almost always much faster |
| 23:10:11 | saratoga | we 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:46 | saratoga | usually 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:33 | saratoga | the ability to compile the codeclib separately from rockbox makes this so much easier than it used to be |
| 23:19:06 | _bilgus | I saw a note of testing and checking the crc between implementations |
| 23:20:23 | saratoga | you mean to find the bad frame? |
| 23:20:31 | saratoga | i usually just subtracted the PCM values |
| 23:22:33 | saratoga | huh the codeclib isn't building for me |
| 23:23:13 | _bilgus | problem 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:00 | saratoga | i used to keep a copy of ffmpeg built from source somewhere for this reason |
| 23:32:56 | saratoga | wow 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 | _bilgus | I see our endian is reversed from the source |
| 23:51:06 | saratoga | huh whole mess of api incompatibilities with warble since i used it last |
| 23:51:16 | _bilgus | at 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 | _bilgus | saratoga you said broken since 2013 I'm sure there are a lot |
| 23:52:39 | _bilgus | well glitches are still there after bringing it up to circa 2015 |
| 23:52:42 | saratoga | i think i used it since then, but definitely encoders were broken (never use those) |
| 23:54:13 | _bilgus | I found 1 potential signed overflow that appears to be fixed in the updated source although they use a macro |
| 23:54:42 | _bilgus | but it wasn't eben in the lpc decode so maybe good for something |
icon identifies that the person is a core developer (has commit access).