--- Log for 01.03.121  Server: verne.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 month and 19 days ago

00.02.30 ***     Saving seen data "./dancer.seen"
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.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.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.02.34 ***     Saving seen data "./dancer.seen"
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.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.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.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.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.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.33.13 Join    koniu [0] (~koniu@gateway/tor-sasl/koniu)
13.33.46 Quit    amachronic (Quit: Connection closed)
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.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.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.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.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.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.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.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.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.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