--- Log for 10.07.122  Server: sodium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 8 days and 10 hours ago

00.38.47 Quit    munkis (Remote host closed the connection)
00.51.57 Join    munkis [0] (~mendel_mu@ool-ae2cb229.dyn.optonline.net)
01.07.28 Quit    massiveH (Quit: Leaving)
01.59.43 ***     Saving seen data "./dancer.seen"
03.59.47 ***     No seen item changed, no save performed.
05.41.21 Quit    Galois (Ping timeout: 276 seconds)
05.59.52 ***     Saving seen data "./dancer.seen"
07.36.16 Join    Galois [0] (djao@efnet.math.uwaterloo.ca)
07.40.18 Quit    Piece_Maker (Ping timeout: 276 seconds)
07.59.54 ***     Saving seen data "./dancer.seen"
08.23.56 Quit    Guest9490 (Changing host)
08.23.56 Join    Guest9490 [0] (sid23779@fsf/member/yang)
08.24.01 Nick    Guest9490 is now known as yang (sid23779@fsf/member/yang)
08.55.49 Join    finkfox [0] (~finkfox@user/finkfox)
08.55.57 Quit    finkfox (Client Quit)
08.57.27 Join    NoTuff [0] (~NoTuff@dynamic-077-183-148-117.77.183.pool.telefonica.de)
08.58.54 #       <NoTuff> hi there. i'm looking for a device currently on sale that I can put rockbox firmware on. any recommendations?
08.59.29 #       <NoTuff> I found https://www.rockbox.org/wiki/AgptekRocker but that device doesn't seem to be for sale anymore, does it?
09.01.09 #       <NoTuff> there is also agptek rocker v2 with model number MC15B-2nd  ... but also not really for sale
09.03.11 #       <NoTuff> and yes, I could use a "smartphone". unfortunately, google managed to break external sd card support ... https://issuetracker.google.com/issues/147619577
09.03.51 #       <NoTuff> so yes, there is a need for rockbox (I last used with iPod5 decades ago ... )
09.04.56 #       <NoTuff> ps. does rockbox support bluetooth? in the case of agptekrocker? or any other device?
09.06.08 #       <spork> rockbox does not support bluetooth
09.08.38 Join    amachronic [0] (~amachroni@user/amachronic)
09.27.23 Quit    NoTuff (Quit: Ping timeout (120 seconds))
09.32.25 Join    NoTuff [0] (~NoTuff@dynamic-077-183-148-117.77.183.pool.telefonica.de)
09.32.43 #       <NoTuff> is it realistic that one day rockbox may support playback via bluetooth?
09.36.09 #       <amachronic> on a hosted target, yes; on a native target, I'd say no.
09.39.25 #       <NoTuff> amachronic, what do you mean with "hosted target"?
09.40.04 #       <amachronic> sorry, that's the lingo for when rockbox is running on top of a host OS, usually Linux.
09.40.28 #       <amachronic> a "native target" is when rockbox *is* the kernel and OS.
09.42.15 #       <NoTuff> is there already such a "hosted" solution out there?
09.42.43 #       <NoTuff> never heard of this befofre
09.44.33 #       <amachronic> no, there's nothing at all in rockbox to deal with bluetooth yet
09.45.26 #       <amachronic> the reason it's easier on a hosted port is purely because Linux has bluetooth drivers and a bluetooth stack (BlueZ) which we could piggyback off
09.46.14 #       <amachronic> with the native port we'd need to write all bluetooth drivers ourselves and port a bluetooth stack / write one from scratch, which is a lot of work and hence unlikely to ever happen.
09.51.19 #       <NoTuff> ok I understand. so another way would be to attach a "bluetooth adapter" to a rockbox device, right?
09.54.24 #       <amachronic> yeah, if you had something which took a line-in
09.55.59 #       <amachronic> with something like a usb adapter... you're looking at a similar problem as on-board bluetooth.
09.59.57 ***     Saving seen data "./dancer.seen"
10.18.10 Quit    NoTuff (Ping timeout: 252 seconds)
10.20.55 Quit    Natch (Remote host closed the connection)
10.34.13 Join    NoTuff [0] (~NoTuff@dynamic-077-183-148-117.77.183.pool.telefonica.de)
10.56.37 Join    SonoSooS [0] (~SonoSooS@91-82-135-121.pool.digikabel.hu)
10.57.10 #       <SonoSooS> good (UGT) morning!
10.57.40 #       <SonoSooS> hactar|ant: sorry for leaving so fast, I had an audio driver crash, and also fell asleep, lol
10.58.43 #       <SonoSooS> I would give a test .firm, but it's really broken atm... there is an insane amount of lag, scrolling is ultra sluggish, DOOM runs at like... a few frames a second, and audio playback takes like half a minute to start playing one song
10.59.22 #       <SonoSooS> I have a feeling that I made a mistake when setting up the timer driver, and it runs 8x-10x slower than it should, but I still need to investigate
11.00.25 #       <SonoSooS> this has to be an issue on my end, as the 3DS is definitely in the top 5% of supported Rockbox devices in terms of raw power
11.01.13 #       <SonoSooS> oh yeah, and forgot to mention, but I do read back the IRC logs, so not to worry
11.03.12 #       <SonoSooS> I also keep forgetting that most functions in header files actually have vast documentation above them, I blame VSCode for now showing them
11.04.37 #       <SonoSooS> * s/now showing/not showing/
11.06.26 #       <SonoSooS> oh, also thanks gevaert\s for the logs, I did find some things in it which helped to mitigate the issues in the audio driver caused by buffering issues (backslash added to name prevent unnecessary pinging)
11.07.38 #       <amachronic> two random suggestions: check your LCD driver (may explain general lag) and your IO (may explain why starting playback is slow)
11.08.12 #       <SonoSooS> you're very right about the LCD driver, as that's what I have to use for audio sequencing :/
11.08.22 #       <amachronic> lol :)
11.08.44 #       <SonoSooS> the audio device (CSND) has no interrupts, so I have to poll using CPU
11.09.04 #       <amachronic> ouch
11.09.28 #       <SonoSooS> and since I have ran out of timers (all two of them, wow!), I had to resort to HSync interrupt
11.10.25 #       <SonoSooS> as for IO, I am using the MMU to enable caching, as the main RAM (FCRAM) is absolutely damn slow
11.10.57 #       <SonoSooS> I have tried to arrange the memory map in such a way as to avoid RAS/CAS switching as much as possible
11.12.05 #       <amachronic> well, rockbox is generally terrible about how it does LCD updates and I/O
11.12.16 #       <SonoSooS> the only architectural optimizations I have left are enabling IRAM support, and spawning Core1 to make use of the two more timers, and perhaps to enable Rockbox's coprocessor support
11.12.26 #       <SonoSooS> OH, I see what you mean now
11.12.29 #       <amachronic> LCD is optimized very much around simple LCDs where you can transfer bits & pieces of the frame
11.12.36 #       <amachronic> so one frame --> many little partial updates
11.12.56 #       <amachronic> i imagine the 3ds is oriented liek a typical gaming machine where you redraw every frame completely
11.13.05 #       <SonoSooS> yeah uh... Rockbox doesn't support LCD rotating, and the LCD controller (besides on the very original 3DS modell) doesn't support horizontal flipping, so I have to flip the framebuffer on the CPU :D
11.13.43 #       <SonoSooS> (the physical display is actually installed into the case rotated to the left)
11.14.35 #       <SonoSooS> * note: don't know if Rockbox actually doesn't support LCD rotating, but I can't find anything inside of the source code regarding that, besides changing LCD stride from horizontal to vertical
11.15.09 #       <amachronic> yes I was just thinking vertical stride might solve the rotation problem
11.15.28 #       <amachronic> if you are memory bandwidth limited that could help a lot
11.16.10 #       <amachronic> anyhow for I/O, almost all I/O is done one sector at a time
11.16.11 #       <SonoSooS> vertical stride sadly doesn't help, as I still need to horizontally flip the framebuffer
11.16.34 #       <amachronic> the only I/O that is done in big chunks is loading stuff into the audio buffer
11.16.51 #       <SonoSooS> not here :P
11.17.02 #       <SonoSooS> the audio is fed in chunks of ~3-8samples
11.17.17 #       <SonoSooS> otherwise the hardware will race the CPU, and will play garbage
11.17.37 #       <SonoSooS> but can't do greedy buffering either, otherwise Rockbox will enter a kill-restart loop on the PCM playback
11.18.05 #       <SonoSooS> even though I have literally allocated 16Megs of RAM for the audio buffer
11.19.10 #       <amachronic> i think you're confused about the pcm architecture, the PCM buffers you get at the HW level is in smallish chunks (around 4kb IIRC)
11.19.21 #       <amachronic> that's what pcm_play_dma_start() gets
11.19.46 #       <amachronic> the audio buffer stores files for decoding on demand
11.19.47 #       <SonoSooS> you'd be correct about my confusion, as I'm doing Rockbox porting by literally inspecting the already existing drivers, and just bruteforcing things until it works
11.20.01 #       <SonoSooS> I did find that I needed to increase the buffer size in pcm_mixer.h
11.20.03 #       <amachronic> yes same here our docs are crap
11.20.04 #       <SonoSooS> MIX_FRAME_SAMPLES 16384
11.20.17 #       <SonoSooS> the docs aren't crap, they are non-existant on the wiki
11.20.27 #       <SonoSooS> there are docs on most functions inside of the headers
11.20.37 #       <SonoSooS> but VSCode decides that they don't exist
11.20.48 #       <amachronic> except when it's wrong or out of date :)
11.20.49 #       <SonoSooS> so I keep forgetting to inspect the headers for docs
11.21.03 #       <SonoSooS> yeah, I found that out the hard way...
11.21.13 #       <SonoSooS> lol, speaking of out-of-date
11.21.29 #       <SonoSooS> I managed to make Rockbox build on Windows with gcc 5.3.0
11.21.53 #       <SonoSooS> absolutely no issues regarding the setup, everything works fine besides of the bad performance
11.23.06 #       <SonoSooS> I know that the wiki says to use some awfully old version, but I literally had to reverse-engineer the binary so many times, and did not find any anomalies, it compiles just fine
11.23.45 #       <amachronic> yeah the danger is mainly in newer compilers exploiting undefined behavior and breaking things
11.24.16 #       <SonoSooS> OH, you made me rememeber that it is indeed true, when I tried to port a project of mine from gcc 5.3.0 to gcc 8.1.0
11.24.24 #       <SonoSooS> it just, completely died
11.24.32 #       <SonoSooS> and had a bajillion compiler warnings
11.25.25 #       <SonoSooS> my guess is that that wiki page is made for users compiling Rockbox, not developers
11.28.01 #       <amachronic> how much IRAM have you got?
11.28.16 #       <SonoSooS> a bit less than 512k
11.28.32 Quit    NoTuff (Quit: Client closed)
11.28.33 #       <amachronic> sounds like you need to use that then
11.28.50 #       <SonoSooS> well, technically 1Megs, but the lower half is allocated to the DSP (not in use)
11.29.11 #       <amachronic> an audio DSP?
11.29.39 #       <SonoSooS> the reason I'm not using the DSP is because the blob is proprietary copyrighted, and the weird shared memory architecture and the DSP pipe is currently out of my capacity to implement
11.29.46 #       <SonoSooS> yeah, it does have an I2S line
11.29.58 #       <amachronic> oh, I see.
11.30.47 #       <SonoSooS> whereas the simple audio hardware is literally... pointer, length, set it to loop forever, and make a ring buffer driver to feed the memory in front of the FIFO at all times
11.32.18 #       <amachronic> maybe you'll need to add double buffering in the PCM layer
11.32.40 #       <SonoSooS> it is already double-buffered
11.33.16 #       <SonoSooS> just the default buffer size (MIX_FRAME_SAMPLES 256) is way too small
11.33.17 #       <amachronic> IIRC it'll only prepare one mix buffer at a time.
11.33.27 #       <SonoSooS> it actually kickstarts two
11.34.06 #       <amachronic> yes there's two buffers but one is in use by DMA at all times and we ping-pong back and forth
11.34.38 #       <SonoSooS> ah yeah, fair enough
11.34.43 #       <amachronic> if you had three (so two lined up for the HW to consume at any moment) then you'd have greater latency, right?
11.34.54 #       <SonoSooS> it even says so in the comments: "Hosted targets need larger buffers for decent performance due to OS locking/scheduling overhead"
11.35.01 #       <SonoSooS> oops, wrong comment
11.35.13 #       <SonoSooS> "Assume HW DMA engine is available or sufficient latency exists in the PCM pathway"
11.35.29 #       <SonoSooS> yeah, more latency
11.35.35 #       <amachronic> with just two buffers you need to kick off DMA for the next buffer before the audio FIFO finishes playing the previous buffer
11.35.48 #       <amachronic> in your case I'd think you don't have enough time to copy things into the ring buffer
11.36.01 #       <amachronic> unless you had the extra latency
11.36.18 #       <amachronic> using IRAM for PCM mix buffers will also help
11.36.19 #       <SonoSooS> yeah, I'd need to crank up the buffer size significantly to be able to drop the HSync interrupt
11.36.35 #       <SonoSooS> hmm
11.36.48 #       <amachronic> a lot of our older targets use IRAM extensively to get good performance
11.36.54 #       <amachronic> some even have an IRAM framebuffer
11.37.02 #       <SonoSooS> how much IRAM do those targets have?
11.37.12 #       <SonoSooS> I only have a bit less than 512k
11.37.37 #       <amachronic> the as3525 (sansas) has 320k
11.37.53 #       <SonoSooS> geez, I guess I'm really spoiled by the hardware then
11.37.56 #       <amachronic> i.MX targets have 32k, 256k, or 512k depending on the model
11.38.19 #       <SonoSooS> yeah, I have definitely majorly screwed up my driver layer thne
11.38.26 #       <SonoSooS> * s/thne/then/
11.39.09 #       <SonoSooS> I highly doubt Rockbox would run this awfully on an ultra-strong(tm) hardware, while it runs just fine even on the crappiest of hardware
11.39.17 #       <SonoSooS> so it has to be my fault
11.40.02 #       <SonoSooS> I have plotted the timer interrupts on the top display, and I barely count 8-16, which makes me think that I have configured the dividers incorrectly
11.40.19 #       <SonoSooS> I still need to read the docs on the timer and the ticker, but I keep forgetting
11.40.45 #       <amachronic> and double check your macros for typos!
11.40.58 #       <SonoSooS> I don't think I'm using any macros, except for FBPTR
11.41.25 #       <amachronic> i mean whatever you use for register fields etc.
11.41.47 #       <SonoSooS> ohhhhhhhhh, I'm using my drivers I made for my own kernel, and they have been extensively tested, and they work just fine
11.41.53 #       <amachronic> i was one bit off and screwed up one of my own timers on the x1000
11.42.07 #       <amachronic> (in my defense the HW manual displayed the wrong bit field widths...)
11.42.08 #       <SonoSooS> the problem is definitely in the integration layer, where I connect my drivers with Rockbox
11.42.37 #       <SonoSooS> well, except for a compiler error inside of the CODEC init  code
11.43.02 #       <SonoSooS> CODEC init is highly timing-sensitive, so much so, that simply just using a different compiler ruins it
11.43.10 Join    Natch [0] (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se)
11.44.44 #       <SonoSooS> but yeah, I have made tons of typos in my interfacing code due to my reduced capacity
11.44.54 #       <amachronic> well, good luck. I gotta go now. hopefully you'll manage to get rockbox running well on such a weird device!
11.44.54 #       <SonoSooS> especially the MMU
11.45.11 #       <SonoSooS> thank you, good well to you as well!
11.45.27 #       <amachronic> thanks, bye
11.45.29 Quit    amachronic (Quit: amachronic)
11.59.58 ***     Saving seen data "./dancer.seen"
12.43.11 #       <hactar|ant> oh hey SonoSooS 
12.43.53 #       <SonoSooS> hello
12.45.05 #       <SonoSooS> I'll need to investigate why I'm still getting awful performance, but I can upload a test build if you really need it
12.45.55 #       <hactar|ant> sure i'll check it out
12.46.10 #       <SonoSooS> let me make Rockbox + codecs + DOOM
12.46.13 Quit    akaWolf (Ping timeout: 244 seconds)
12.46.30 #       <hactar|ant> lol doom running in rockbox on 3ds 
12.47.17 #       <SonoSooS> it does work, but I can't figure out how to map the keys properly, as the 3DS has way more keys than Rockbox DOOM makes use of
12.48.06 Join    akaWolf [0] (~akaWolf@akawolf.org)
12.52.32 #       <SonoSooS> well then, or it just data aborts
12.55.12 #       <hactar|ant> do you have an n3ds?
12.55.43 #       <SonoSooS> I have old3DS (Zelda), old3DS (black, broken hardware, but still works somewhat), new3DSXL (Zelda), 2DS (white-red)
12.56.03 #       <hactar|ant> oh wow ok lol
12.56.10 #       <hactar|ant> is performance noticeably better on n3ds?
12.56.24 #       <SonoSooS> (I make a lot of homebrew and other things for the 3DS)
12.56.30 #       <SonoSooS> nope
12.56.44 #       <hactar|ant> anything i'd recognise?
12.56.46 #       <SonoSooS> because I don't have any new3DS-specific drivers yet, like CPU frequency adjustment, or L2 cache
12.57.21 #       <hactar|ant> i think luma allows you to force the faster cpu
12.57.24 #       <SonoSooS> HzMod/HorizonM, TWPatch, TerraInvedit(Threedee|Droid), OCDM, idk what else
12.57.27 #       <hactar|ant> but yeah, that obviously shouldn't be needed
12.57.37 #       <SonoSooS> yeah, I'm not runninng Rockbox in hosted mode
12.57.41 #       <SonoSooS> this runs baremetal
12.57.53 #       <SonoSooS> so it's a .firm, not a .cia/.3dsx
12.58.08 #       <hactar|ant> oh wow lol
12.58.09 #       <hactar|ant> ok
12.58.26 #       <SonoSooS> if I had made it hosted, it would run even worse tbh xd
12.58.59 #       <hactar|ant> wait does that mean it requires a 3ds flashcard, cause i don't have one. i just use cfw
12.59.54 #       <SonoSooS> you can use anything which can launch a .firm, you can use Luma's chainloader (hold START during power on until screen turns on), although personally I use fastboot3DS installed to FIRM0
13.01.37 Quit    skipwich (Quit: DISCONNECT)
13.03.18 Join    skipwich [0] (~skipwich@user/skipwich)
13.09.46 Part    Chewi (I'm outta here!)
13.10.54 #       <SonoSooS> hactar|ant: I think I have included everything? https://puu.sh/JaoMV/b901d15588.zip
13.13.03 #       <SonoSooS> well, except the UI theme, I forgot that
13.14.55 #       <SonoSooS> oh yeah, warning: volume adjustment doesn't work due to compiler errors, so you might 1) not have sound at all, 2) have extremely loud sound at max volume, 3) hav extremely quiet sound with no adjustment
13.27.34 #       <hactar|ant> lol ok, i'll check it out
13.28.09 #       <hactar|ant> wait, agb.firm?
13.28.28 #       <SonoSooS> yeah, ignore that filename, it's complicated why my build system outputs that name
13.28.48 #       <SonoSooS> if you look into the .firm, there is a whole .exe file (yes, .exe on 3DS) embedded into it for SDCard support
13.32.05 #       <speachy> c
13.41.31 #       <hactar|ant> what are the controls?
13.42.24 #       <hactar|ant> only button that seems to do anything is A
13.42.47 #       <SonoSooS> for DOOM: good luck. otherwise, it's really jank: LEFT/RIGHT navigate in the menu, A to enter, B to back, X and Y do something, and the rest of the controls are completely missing, as it' low-priority for me currently
13.43.09 #       <SonoSooS> my highest priority atm is trying to figure out why the performace is so abysmal :/
13.43.17 #       <hactar|ant> so no way to scroll?
13.43.23 #       <SonoSooS> LEF/RIGHT to scroll
13.43.33 #       <hactar|ant> oh weird i swear i tried that
13.43.35 #       <SonoSooS> no CPad driver btw, use DPAD
13.43.44 #       <SonoSooS> also hold it, there is a huge amount of lag
13.44.03 #       <hactar|ant> i might have just been tapping 
13.44.11 #       <SonoSooS> yeah, that doesn't work yet
13.44.49 #       <SonoSooS> I could use HID interrupts to latch buttons until they are read out, but I'll do that after fixing the performance issue
13.46.14 #       <hactar|ant> it seems to just give up on flac
13.46.24 #       <hactar|ant> mp3 it took a while to start and was glitchy for 10 seconds but now is playing fine
13.46.58 #       <SonoSooS> yeah, the PCM driver is ultra jank sadly
13.47.21 #       <SonoSooS> due to my lack of capacity, my friend with no 3DS had to write it for me
13.48.16 #       <SonoSooS> sometimes it glitches out because the hardware reads way too much ahead
13.48.19 #       <hactar|ant> lol
13.49.40 #       <hactar|ant> well this is a pretty neat start
13.49.55 #       <SonoSooS> yeah, been working on it since almost a month or so
13.50.17 #       <hactar|ant> unfortunately i can't really provide any technical help but i am happy to play around with builds and try to break them 
13.50.49 #       <hactar|ant> would be very cool to see this as a proper hosted homebrew
13.51.01 #       <SonoSooS> yeah, everything is held together by faith in the compiler, so it's too easy to break
13.51.04 #       <hactar|ant> there are a lot of possibilities with two screens but that's quite a ways down the line
13.51.19 #       <SonoSooS> yeah, there is no way I'll make this hosted
13.51.26 #       <SonoSooS> way too janky
13.52.15 #       <SonoSooS> there is way too much overhead in threading
13.52.31 #       <hactar|ant> someone could, surely
13.52.48 #       <hactar|ant> i occasionally used my ds lite as a music player before i got an ipod
13.52.49 #       <SonoSooS> I mean, to be fair my wording gives it no mercy
13.52.59 #       <hactar|ant> oh man, that thing had a terrible sound chip
13.53.07 #       <SonoSooS> it *is* possible, but for so low reward that I won't do it, I think
13.53.27 #       <SonoSooS> ah, so I bet you used Moonshell
13.53.37 #       <SonoSooS> also you're wrong, it wasn't that terrible
13.53.54 #       <SonoSooS> in fact, I'm using basically the same sound engine as the DS has
13.54.01 #       <hactar|ant> i tried moonshell but i liked dsorganize better
13.54.11 #       <SonoSooS> ah, never used that one
13.54.54 #       <hactar|ant> dso had a music player AND a web browser AND an irc client, what more could one want?
13.55.00 #       <SonoSooS> but yeah, GBA had timer + PCM FIFO DMA, DS had that hardware combined with more channels into "SND", then some minor adjustments were made to the hardware, and embedded into the 3DS ("CSND")
13.55.02 #       <hactar|ant> ereader too
13.55.22 #       <SonoSooS> lol damn, web browser *and* IRC client
14.00.01 ***     Saving seen data "./dancer.seen"
14.00.52 #       <SonoSooS> well okay, to be fair the 3DS indeed has a much better audio system
14.01.18 #       <SonoSooS> the DS still had that awful speaker PWM (afaik) as from the GBA, which needed BIAS voltage, and other awful stuff
14.02.50 #       <SonoSooS> whereas the 3DS uses a proper CODEC chip, and with the CSND hardware, it can do ~47.605kHz sample rate, or ~32.72849kHz if using the DSP (configurable to also run at that ~47kHz, but it breaks some stuff in userland)
14.03.39 #       <SonoSooS> although the CSND hardware itself can sample up to ~1MHz before it hangs, but it's resampled to that ~47kHz before actually being sent to the DAC
14.17.46 #       <hactar|ant> i thought the ds used a low sampling frequency
14.23.45 #       <SonoSooS> it definitely wasn't lower than 32kHz
16.00.03 ***     No seen item changed, no save performed.
16.59.23 #       <SonoSooS> ah, it seems like the enormous file loading time is caused by prebuffering - there is like ten seconds of buffer fill before the audio starts playing
17.55.41 Quit    SonoSooS (Ping timeout: 244 seconds)
18.00.06 ***     Saving seen data "./dancer.seen"
18.27.28 Join    S|h|a|w|n [0] (~shawn156@user/shawn/x-4432647)
20.00.09 ***     No seen item changed, no save performed.
22.00.11 ***     No seen item changed, no save performed.