Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

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

#rockbox log for 2021-09-20

00:29:57 Quit benjaoming (*.net *.split)
00:30:17 Join benjaoming [0] (~benjaomin@
00:41:38 Quit gevaerts (*.net *.split)
00:41:48 Join gevaerts [0] (~fg@user/gevaerts)
01:44:37***Saving seen data "./dancer.seen"
01:54:29 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:5d33:50f:9f23:d9b8)
01:55:08 Quit ZincAlloy (Client Quit)
02:14:00 Quit _bilgus (Remote host closed the connection)
02:15:50 Join _bilgus [0] (~bilgus@
02:29:19 Quit smithjd (Ping timeout: 268 seconds)
03:44:40***Saving seen data "./dancer.seen"
04:14:15 Quit Piece_Maker (Ping timeout: 265 seconds)
04:21:51 Join Piece_Maker [0] (
04:27:05 Quit Piece_Maker (Ping timeout: 264 seconds)
04:34:30 Join Piece_Maker [0] (
05:44:42***Saving seen data "./dancer.seen"
06:24:16 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
06:33:52rb-bluebotBuild Server message: Build round completed after 862 seconds.
06:33:54rb-bluebotBuild Server message: Revision 483563a1b2 result: All green
07:44:43***No seen item changed, no save performed.
08:09:17speachyyay, bluebot is back!
08:09:57speachyblbro[m]: I don't remember if I'd asked this or not, but did you want to move bluebot to the rockbox server infra?
08:43:34 Join ats [0] (
08:57:36 Join massiveH [0] (
09:04:48 Join ac_laptop [0] (~ac_laptop@2a01:cb1c:3c8:2700:e29d:31ff:fe2d:a258)
09:44:45***No seen item changed, no save performed.
09:57:46 Quit emacsomancer (Quit: WeeChat 3.2.1)
09:58:50 Join emacsomancer [0] (~emacsoman@
10:08:56 Quit ac_laptop (Ping timeout: 246 seconds)
10:19:25 Quit massiveH (Quit: Leaving)
10:24:59 Join cockroach [0] (~blattodea@user/cockroach)
10:53:14 Quit tchan (Quit: all)
10:59:13 Join skipwich [0] (~skipwich@user/skipwich)
11:05:47 Quit skipwich (Read error: Connection reset by peer)
11:07:56 Join skipwich [0] (~skipwich@user/skipwich)
11:16:35 Join ac_laptop [0] (~ac_laptop@2a01:cb1c:3c8:2700:e29d:31ff:fe2d:a258)
11:43:29 Quit spork (Ping timeout: 268 seconds)
11:44:46***Saving seen data "./dancer.seen"
11:55:21 Join spork [0] (
12:43:00 Join ZincAlloy [0] (
12:58:17 Quit ac_laptop (Ping timeout: 264 seconds)
13:30:08 Join toxx [0] (
13:33:52 Part toxx
13:44:48***Saving seen data "./dancer.seen"
13:47:45 Join lebellium [0] (
14:01:03 Join tchan [0] (
14:16:28 Join calebccff [0] (
14:16:28calebccffhey, not sure if anyone here has heard of pine64, it looks like they're working on an open source audio player, it will have balanced outputs and bluetooth support I think. Would there be interest in having rockbox support it?
14:24:04braewoodscalebccff: it's probably related to our inquiries from last year or so.
14:24:15braewoodsif they are actually doing that.
14:25:38calebccffbraewoords: that would make sense
14:25:48braewoodswhere'd you read that anyway
14:26:09braewoodsi hadn't heard anything further
14:26:13calebccfftheres been some discussions in the pine64 dev room
14:26:23braewoodsah, i see.
14:26:44braewoodslast i heard we just received some development units for some platform device of theirs
14:27:37braewoodsspeachy is the one who's dealt with it most
14:27:54braewoodsi mostly just suggested it since they've been working on custom hardware solutions
14:28:08braewoodsthey're more experienced with this sort of thing. we mostly just write the code.
14:28:22calebccffhm yeah
14:28:38braewoodsif it does arrive the initial code would probably be the rockbox Linux port
14:29:46calebccffah, the hardware wont support linux from what I've heard
14:30:49braewoodsor it could be rockbox directly
14:30:55calebccffthe idea waa to use a cortex-m4 based chip, designed for use in players and headphones
14:30:57braewoodsit was just an educated guess
14:31:20calebccffcool, uh whats the best way for them to reach out? i can let them know
14:31:50calebccffor you could join the dev channel if interested, whatever is easiest for you
14:32:05calebccffthey certainly seem very interested in rockbox support
14:32:05braewoodshere probably, at least to setup initial discussions
14:32:23braewoodswe could always use more targets that aren't unobtainium
14:32:29calebccffok sure
14:32:35calebccffhaha yeah i get that
14:32:51braewoodsthis would be better than everything else since rockbox has always had to be grafted onto whatever is floating around
14:33:04braewoodswe wouldn't need to reverse engineer as much
14:33:39calebccffyeah exactly
14:33:52calebccffits a really exciting prospect
14:34:23calebccffand it could potentially compete with some higher end products too :p
14:34:28braewoodsi'm not getting my hopes up though.
14:35:21braewoodsthing is, if they want it to support certain things like bluetooth, we need some help there.
14:35:33braewoodswe have no stack for wifi or bluetooth
14:35:53braewoodsspeachy has tried to find a third party one we could use but no luck to date
14:36:43braewoodswhat's the channel name
14:38:10 Quit SammysHP (Quit: *wuff*)
14:38:15 Join tllim [0] (~tllim@
14:38:40 Join ac_laptop [0] (~ac_laptop@2a01:cb1c:3c8:2700:e29d:31ff:fe2d:a258)
14:38:44tllimHi, I am TL Lim, PINE64 founder
14:38:44 Join SammysHP [0] (
14:39:30speachythey reached back out to me last week but I've been too caught up to properly follow up
14:40:18speachythe SoC they're looking at is not a good match for what we need, at first glance. very RAM limited.
14:41:06tllimif you have any question on the project, I will answer. Please noted that I only login on today only.
14:41:20braewoodsspeachy: how RAM limited?
14:41:21tllimthe RMA space is about 960KB
14:41:36braewoodsoh that's tiny... rockbox normally requires at least 2MB.
14:41:40speachyunder a megabyte total.
14:42:02braewoodsit might fit if we strip out a lot of extraneous stuff but...
14:42:05speachydual cortex-M4Fs, at 300MHz, which is quite nice
14:42:11tllimThis is the chip spec. BES2300YP
14:42:16braewoodswould that leave enough usable RAM
14:43:10tllimThis is a famous TWS ANC earbuds chip but the chip can be used for generic purpose.
14:43:45braewoodstllim: is all decoding done in software?
14:43:49braewoodsmeaning mp3, etc
14:43:52speachyI think so
14:43:54tllimThere will be three devices come out from this project, a dev board, a DAP, and a pair of ANC earbuds
14:44:37braewoodshm. what storage options does it support? sd card?
14:44:41tllimHere is teh SDK:
14:45:16tllimplease keep this SDK within Rockbox community for reference.
14:45:31tllimThe original OS is RTX and can apply to RTOS.
14:45:55speachyif we can execute from flash with reasonable performance then that'll free up RAM for code
14:46:02tllimHere is teh compiler:
14:46:04speachybut that's not a lot to play with
14:46:19braewoodsindeed but it might work for a basic rockbox port.
14:46:28tllim@solomon, for sure the program runs in flash, not system RAM.
14:46:50speachy"basic port" in this case means "a lot of restructuring to make it fit"
14:47:11tllimThis is the dev board spec:
14:47:12speachywe can pretty much scrap most plugins
14:47:27speachyand probably quit a few of the codecs too
14:47:48braewoodswell there's a few lesser used ones.
14:48:09braewoodsones that require too much RAM would have to go
14:48:20speachythe point being the final feature set will necessarily not match what folks have come to expect from "rockbox"
14:48:21braewoodsthat probably means... aac or w/e
14:48:21tllimRockbox community ask for a DAP and here is the offer.
14:48:57braewoodsspeachy: well we have stripped down ports as it is in the sansa line. this is more stripped down but
14:49:14braewoodsnot 100% unprecedented to have "gimped" ports
14:49:20speachytllim: please don't think we don't appreciate this.
14:49:38speachyhave to figure out the techncical feasibility
14:49:55tllimthis is the "best" chip that I able to locates and also potential on open source.
14:50:09braewoodsi think we should try it speachy, there's not many options out there for us to leverage.
14:50:28speachytllim: does this SoC have any sort of display controller/engine, or would we have to use something attached via i2c/spi?
14:50:38braewoodswe just need to disclose that the port is going to be "rockbox lite"
14:50:41braewoodsso to speak
14:51:23tllimplease explore within Rockbox community, if interest to explore, I can provide dev board on next month.
14:52:01tllimthe SoC has SPI interface for LCD panel and i2c for touch screen.
14:52:31tllimThe idea is this is a 2.5" LCD panel with full touch screen capability.
14:52:55braewoodswhat about gpio for regular buttons
14:53:02tllimThere is memory buffer on LCD controller STV7789 and not occupied system memory space.
14:53:52tllimdepends on the designs, the buttons can use ADC input or normal GPIOs
14:53:54braewoodsgiven how i2c works we could also use it for other stuff as well
14:54:07braewoodssome fm radio chips work with i2c
14:54:37tllimThis is GPIP mux map:
14:55:03tllim^^^ still two more pin available than above map chart
14:56:06tllimThis chip has very good DAC performance, just check the datasheet :-)
14:56:58tllimthe DAP can also has ANC capability :-)
14:57:02braewoodstllim: what did you find regarding FM/DAB radio support?
14:57:14tllimno FM/DAB capability
14:57:27braewoodsok, not essential.
14:57:59tllimdue to this SoC use in TWS earbuds, the power saving is very good
14:58:37tllimif you have interest to know this chip performance, just check the Oneplus Earbuds Pro.
14:58:47braewoodsthat must be why the RAM is so low.. it's probably SRAM.
14:58:48_bilgussounds a lot like the clip v1 in constraints
14:59:13tllimcorrect, is SDRAM
14:59:22braewoodsDRAM consumes more power
14:59:22tllimsorry, is SRAM
15:00:08tllimthere are 4MB internal flash for program
15:00:14 Quit pixelma (Quit: .)
15:00:14 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
15:00:21tllimall music file locates at microSD card
15:01:47braewoodsif we embed the rockbox core into ROM, we could probably make this work.
15:02:38_bilgusfits right in with my idea to pull everything non essential out of core
15:02:46tllim^^^ this should eb possible.
15:02:53_bilguswe can page in menus as plugins
15:03:27speachyactually I was thinking the opposite; if we're going to execute from ROM it would be advantageous to run _everything_ from rom.
15:03:28braewoodswe already have a few ports that can run rockbox core from ROM.
15:03:36tllimThere is hardware codec block in this chip. However, i don't know what type of codec that supported. SDK may provides this answer
15:03:46 Join pixelma [0] (
15:03:47 Join amiconn [0] (
15:04:01braewoodsnamely the iriver H100 and H300 series
15:04:19_bilgusah embed everything essential to keep the ram free
15:04:20speachyprobably mp3, the new bt audio codec, possibly even aac
15:04:36tllimThis SoC also has USB port, this means the DAP can also act as USB DAC adapter
15:04:47braewoodsi would leave out some of the extraneous codecs that people rarely use such as the non-digital audio formats
15:04:52braewoodslike the trackers and such
15:05:10speachybraewoods: eh, it's not a matter of quantity so much as runtime RAM usage.
15:05:20braewoodsoh, i see.
15:05:26speachyAAC is one of the worst, IIRC.
15:05:32braewoodsyea, i noticed.
15:06:21tllimAAC seems has hardware codec supported.
15:06:42speachywe're going to have a pretty tiny buffer, but with solid-state storage we don't need to have to buffer enough to cover the latency of spinning up some rust.
15:06:44tllimAAC is essential in good TWS earbuds design
15:07:00_bilguswe can also use faster cards I presume
15:07:40braewoodstllim: is there a datasheet for that? we've had ports where we coudn't use the hardware codecs because of lack of datasheets.
15:07:55tllimI have posted the datasheet link
15:08:11braewoodswasn't sure if it was in there
15:08:17tllimhere again:
15:08:46braewoodsjust aac it appears
15:08:53tllimdoes IRC allow to post PDF file?
15:08:56_bilgusI'd commit for some time with a dev board how hard would it be to get a few to send around the active devs
15:09:10braewoodswe can only accept text stuff.
15:09:26braewoodsso urls are it
15:09:27speachywell, AAC is all that's explicitly mentioned. remember this is targeting bluetooth earbuds.
15:09:27tllimthis is why I send the download link
15:09:47tllimthe BES2300 NOT only targets for earbuds
15:10:01braewoodseven so the bluetooth support could be useful if we can solve the bluetooth stack issue
15:10:05tllimthe chip is a more generic audio chip
15:10:30tllimthis si why it has stereo audio DAC output
15:11:01tllimthe chip that specific design for TWS earbuds only has mono DAC
15:11:19braewoodshm looks like it supports analog audio output too, not surprising
15:11:29_bilgusSpeachy Rom is only 400 ish k I don't think core is getting in there as it is currently
15:11:33tllimalso has SDPIF :-)
15:11:39tllimin and out
15:11:55braewoodstllim: optical and electrical?
15:11:57speachy_bilgus: that's 400k of _ROM_, presumably not actually writable. another 4/8MB of on-chip flash.
15:12:05 Quit ac_laptop (Ping timeout: 264 seconds)
15:12:16_bilgusah ok
15:12:32braewoodsgood point, is the ROM field reprogrammable?
15:12:39speachyROM is ROM.
15:12:46braewoodsso it's not EEPROM
15:13:00tllimSRAM is 992KB, please check datasheet page 8.
15:13:08speachypresumably including things like data tables for codecs.
15:13:26braewoodsbt shared SRAM?
15:13:37braewoodsdoes that means the system can use it as extra RAM
15:13:39_bilgusok 4mb of flash so very similar to the clip v1
15:13:41tllimthere is onchip 4MB (bytes) flash
15:13:53tllim4MB, not 4Mb.
15:14:37braewoodsi wonder if that means we could repurpose the shared SRAM if we're not using bluetooth.
15:14:54speachySDK is "all rights reserved" and the audio codec stuff is a binary blob. Hmm.
15:14:58tllimagreed that due to limited SRAM space, on the fly decoding is important
15:15:52tllimanyway, this is the best that IPINE64 can offer. Please explore and lets me know.
15:16:00tllimI am log off now
15:16:02speachytllim: we will, thank you.
15:16:09_bilgusthanks for taking the time for us :)
15:16:58tllimHappy to collaborate with Rockchip if there is a chance. I am a haevy Rockbox user and still using Sansa clip.
15:17:19 Quit tllim (Quit: Connection closed)
15:17:31_bilgusI don't know how much of rockbox will remain after but at the very least bad code brings in new devs :P
15:17:52braewoodshow much do we compress stuff?
15:18:06speachywe won't, because you can't execute compressed code. :)
15:18:41_bilgusUCL for bootloaders
15:19:09speachythe SDK has usable CMSIS headers, at least.
15:19:10braewoodsi wouldn't want to embed our main bootloader in RO storage
15:19:31braewoodsassuming it can't be rewritten later
15:19:33speachywe can't, because we can't write it.
15:19:45speachyyou're think WOM. :D
15:19:48braewoodsthe ROM is probably mostly useless to it
15:20:00braewoodsto us then
15:20:07braewoodsi can't think of what we'd put in it
15:20:25braewoodsit would have to be something we're not going to change
15:20:33braewoodsso not likely to be code
15:21:00speachyyou're misunderstanding −− it's mask ROM, ie baked in at the time the chip was manufactured. (well, technically, designed)
15:21:17braewoodsyea, i understand that now.
15:21:18speachythink things like CRC data tables, ICDT transforms,
15:21:48braewoodsideally the system would boot from the flash that is writeable
15:22:03braewoodsso we can update the firmware that way
15:22:03speachyyes, that would be expected
15:22:33braewoodsi suggest our own bootloader since uboot is probably too fat
15:22:42braewoodswould eat up precious space
15:22:57braewoodssides this kind can't run Linux :)
15:23:09speachywe're bare metal all the way, no reason to use anything fancy like u-boot.
15:23:17speachy(did u-boot ever get ported to microcontrollers anyway?)
15:23:33speachyactually booting up is easy
15:23:38speachystandard cortex-M stuff
15:23:48speachywhere this gets messy is getting rockbox itself to simply _fit_
15:24:24_bilgusI'm excited at the prospect of having obtainable hardware if nothing else
15:24:35speachyassuming it's a 16bit panel we'll need 150K just for the framebuffer.
15:24:44calebccffglad to see you guys are interested
15:24:57calebccffspeachy: the panel will have its own framebuffer iirc
15:25:19speachycalebccff: if it's not memory-mapped into the CPU's address space it doesn't matter.
15:25:29calebccffah, i see
15:25:42_bilguswe could cheat on that a bit by using monochrome
15:26:05_bilgusyou'd still get a choice of colors
15:26:22speachythink about these compromises.
15:26:30speachyand ask if you'd actually want to use it.
15:26:44calebccffthe panel driver would still be responsible for pushing the framebuffer to the display, so maybe some lossless compression could be used?
15:27:04speachycalebccff: the CPU still has to have something to compress and send over
15:27:17speachyunless you want to assemble one scanline at a time (ala atari VCS, heh)
15:27:43calebccffaha, hm yeah i see
15:28:24_bilgusThe areas I wouldn't be willing to compromise is the audio
15:30:20speachyonce you strip away half the codecs, meaningful themes, nearly all games/plugins, compromise the UI (touchscreen?)..
15:30:34_bilgusnope no ts
15:30:57_bilguswe have gpios a plenty I hope this thing gets buttons
15:30:57speachyoh, quite possbily/likely the voiced menus too
15:31:12_bilgusvoice would be a difficult prop
15:31:18_bilgusbut its been done
15:31:35_bilgusitd turn into an either or kinda ordeal
15:31:50_bilguswith enough processing power might be ok
15:31:53speachyhow would you convinve someone to buy/use one of these players? (assuming a $50 price point, which I'm pulling out of my posterior)
15:32:34speachycompeting with $30 rknano shovelware
15:32:51_bilgusIt'd have to be onm the audio and playlists
15:33:06_bilgusgapless pb and true random
15:33:47_bilgusI somehow doubt the battery life would be spectacularly greater though
15:33:59calebccfftouchscreen cant be that big?
15:34:14_bilgustouchscreens suck
15:34:29_bilguscan't use it eyes free
15:34:40calebccfftheyre doing cool stuff with them on the pinetime (and i guess other smart watches)
15:34:43calebccfftrue enough
15:34:59calebccffunless you do gestures while screen off
15:35:19speachythe clipv1 uses 303K of RAM for the core stuff (add 150K for the bigger framebuffer)
15:35:35_bilgusbuttons allow muscle memory and intuitive use
15:36:06speachy~900K for the audio buffer, 80K for plugins.
15:36:47speachyand about another 64K of in IRAM.
15:36:55_bilgus992 means 500 for fb
15:37:48_bilgusalthough there is quite a bit of that dedicated to being static stuff that could go to flash?
15:37:57speachyso we're looking at about.. 400K of space for buffering and codec working space.
15:38:16speachyon the clipv1 there's about 600K of code that I left out. :D
15:38:20_bilgusthat is not a lot
15:38:51speachycortex-m4 is thumbv2, which is probably denser on average than what's in the clip
15:39:18speachynevermind, we're forcing thumb on that thing too
15:39:55speachythemes and voice stuff works by stealing from the audiobuffer, correct?
15:40:24_bilguspb first then audio
15:40:44speachy(I'm just flat-out assuming we will put all code into, and execute from, flash.
15:41:02_bilgusno other choice
15:41:35speachyeven achieving that would be a pile of work. adding a flash directory for everything..
15:41:55speachybuilding all plugins to be fully relocatable
15:42:35_bilgusthats a tall order
15:42:50_bilgusIt would have to be an incremental effort
15:43:17speachythankfully this thing has a linear SRAM address space. :D
15:44:15_bilgusI up for spending some time with a dev board I will defer to your expertise you are clearly more versed in the embedded sphere than any of us
15:44:15speachyheh, and then there's the core port to a dual-core Cortex-M4. :)
15:44:52***Saving seen data "./dancer.seen"
15:45:13speachymy last gig had me working with 12K of SRAM in three 4K blocks that would be powered off if not needed. because nanowatts when sleeping mattered. :)
15:45:58braewoodsdon't we already have that
15:46:02braewoodsPP is dual core LOL
15:46:08speachythis thing definitely has the raw cpu oomph to do what we want, even single-core.
15:46:42braewoodsdoes it also have a fpu
15:46:46braewoodsnot sure if this arm has that
15:46:47speachybraewoods: that's probably not a lot of work, but the CPU startup is different, plus how the two cores interact is anyone's guess at this point
15:47:09speachythese both have the FPU, and the 1st-gen CM DSP stuff too
15:47:30speachythat DSP (==SIMD) opens up a lot of optimization opportunities
15:48:19_bilgusIts probably the only chance we are going to get to claw back some harware for the future
15:48:21speachyARM provides some optmized libraries for a lot of common numerical tasks
15:51:13speachyI've been wanting to do a port to a high-end cortex-M dev board for a while, but one with external DRAM.
15:51:49speachywhich makes no sense from a BOM perspective...
15:52:24speachythe real cost for "our own hardware" is a case.
15:57:14speachyUSB code is a binary blob
16:05:20braewoodsspeachy: how do i know if a build client is recognized
16:05:50speachydoes the script error out? :)
16:05:56braewoodsno, just perl warnings
16:06:17braewoodsi started it via a service file
16:06:23braewoodsspecified the working directory
16:06:24speachyassuming "big-wiener-megawienie
16:06:28speachyis you
16:06:32speachythen it connected
16:06:39braewoodsi was bored
16:06:51speachybut please name it appropriately
16:06:59braewoodsno fun lol
16:08:04speachyoh this is confusing
16:09:06speachythere's the Eros Q II (improved Eros Q on a different sw platform and maybe hw too) but there's also a QII, which is the Q1 with a touchscreen and a different case.
16:09:24speachybut built on the same sw platform as the original Q
16:09:34*speachy twitches.
16:11:06speachy5 available, get 'em while you can! :)
16:11:32braewoodsmaybe if there's any left next month
16:12:06braewoodsspeachy: i finished a tedious project today
16:12:46braewoodsi did someone a favor, optimizing part of their build system by replacing an expensive part with a C version that drastically cut their runtime down
16:13:16braewoodslike a 1/40th of the runtime now
16:13:19braewoodsof the original runtime
16:13:50braewoodsthat's for the decoding, more like 1/90th for the encoding
16:13:58braewoodspython sucks so bad
16:14:14braewoodsthat was how they were compressing their data before
16:14:20braewoodspython code...
16:14:31braewoodsnot to mention the performance hit from a lot of fork+exec
16:14:48calebccffspeachy: I'm pretty sure with the SPI display you don't need a framebuffer in RAM, it has two internally so you write the next frame and then swap buffers
16:14:58calebccffthat saves ~150k
16:15:53braewoodsspeachy: it probably wouldn't hurt to investigate the dev board that tllim picked out. this is a problem we face regularly, not being able to port to something due to low RAM.
16:16:17braewoodshaving a solution that allows us to run in tighter constraints to a degree would be helpful
16:17:05speachywell, if we treat the fb as write-only then sure
16:17:21calebccfffrom what I've heard a lot of the hardware is designed to avoid requiring big RAM buffers, e.g. dedicated audio decoding hw, displays with built in buffers etc
16:17:49calebccffis there any reason why you couldn't also read from the fb over spi? it would be slower than RAM but you can optimise for that i guess
16:17:50speachybut making each individual write go out via SPI would represent serious performance penalty with how we currently put the FB together
16:18:38calebccffhmm i see
16:18:56braewoodswhich is using our own RAM buffer that we setup a DMA transfer for?
16:19:16speachythe theory being we don't have to send it to the hw until we're done painting the whole thing.
16:19:29braewoodsdoesn't SPI have DMA too?
16:19:39calebccffpretty sure
16:19:42speachy(when it's truly a framebuffer being continually refreshed by dedicated harware, it doesn't matter)
16:19:54braewoodsso why can't be treated an SPI write buffer like this?
16:20:06speachywrites block
16:20:18calebccffhow many painting steps are there? It's not like you need to care about opacity
16:20:30speachyat minimum, two
16:20:56braewoodstrouble is we need to know something about the screen in order to know what to send it
16:20:56speachybackground + foreground, but each display element tends to be painted independently, and they can/do overlap.
16:21:05braewoodsso not sure how much you can realistically remove
16:21:53speachywhen you're updating a framebuffer, you just write a memory location and maybe trigger an async refresh if necessary.
16:22:24braewoodsusing SPI is probably like controlling a terminal screen.
16:22:32speachybut when the fb is external, you have to explicitly issue a sync to hardware after each update, or somehow batch updates up for efficiency... which is ... more complexity.
16:22:59braewoodsspeachy: can't you just use a queue?
16:23:05braewoodsor is that not a thing for SPI
16:23:06speachysure, that has to be written and maintained
16:23:11calebccfffwiw you might find it helpful to look at the code being used for rendering on the Pinetime
16:23:15speachyand the hardware itself doesn't know/care.
16:23:30calebccffit's a smartwatch running an RTOS with an SPI display and has seen some very impressive performance
16:24:29speachythe most performant SPI display interfacing is to use a local framebuffer and have it continually refreshed (over spi) using DMA.
16:24:30calebccffah, this is rust but maybe still useful:
16:24:42calebccffspeachy: that makes sense
16:25:08calebccffthis thing only has 64kb of RAM, so no framebuffer
16:25:21calebccffit does have the benefit of running software built for it though
16:25:56speachyclassic RAM/CPU tradeoff, yeah
16:26:39speachyand that rust code effectivelt just batches a set of updates. which only helps if you're actively painting a contiguous block
16:27:17speachythen again that controller protocol supports that
16:27:36speachyso we can relatively optimize updates.
16:28:54speachydoing away with a local framebuffer is doable in our display API
16:29:02speachybut some plugins will definitely not work.
16:31:27speachybut instead of blocking display updates we could queue them up, but that requires more RAM as the buffers we're handed might go away on us
16:33:14speachythough now that I think about it, every viewport expects to have a sufficiently-sized framebuffer behind it, for painting purposes. so I don't know if we'd really be able to save all that much RAM in the end vs just having a local, full-sized framebuffer.
16:34:29speachycalebccff: IIRC the Fuze+ uses a spi-attached display, though we still use a local framebuffer for performance reasons.
16:35:35speachybut still, this is half the RAM of any other target rockbox has ever supported. and all of those used monochrome screens.
16:35:53calebccffhuh i see. the ipod ports are spi too i think, but ram isn't such an issue there lol
16:35:55speachynot impossible... just a lot of work, and it's still going to be a "lite" experience.
16:36:00calebccffyeah it's tight
16:36:18speachyand tbh I don't think it's worth the effort.
16:37:25speachyat least not if it's to be called "rockbox" −− it wouldn't match the market expection of the existing brand.
16:37:53speachy(and given entirely volunteer labor)
16:42:20calebccffi know a lot of the pine64 commnunity would be interested, there are a few interested developers there at least
16:43:47speachythey're welcome to join and help out at any time. :)
16:44:21calebccffi suppose it doesn't have to be "rockbox"? If it's at the point where there would be so little of rockbox core left then it could make sense to build something else i guess. but at the same time i reckon it could work, you already did the maths, trading off CPU for RAM is totally doable on this platform
16:45:13calebccffAnd I guess a decent chance of having something with better hardware come along if works out well
16:45:14speachythe thing is, if it's not able to substantially re-use the rockbox codebase, the value propsition changes considerably.
16:45:33speachyand using a different base platform perhaps makes more sense
16:46:10calebccffright, yeah i see
16:46:20speachywe ditched tens of thousands of lines of code (and a lot of complexity) by scrapping support for the original Archos hwcodec players
16:46:38speachyin many ways this would require bringing much of that back
16:49:05speachythe way these these hardware devices are set up typically is a purely streaming DMA thing with very little CPU intervention
16:50:19speachyCPU tells the SD controller which blocks to read, DMAs to codec, DMAs to DSP engine, which then DMAs to DAC (or BT transport)
16:50:53braewoodsspeachy: so rockbox would just be a glorified traffic controller
16:51:23speachyand the DSP engine might be a dedicated preconfigured hw block or a SW component but it's basically just a black box
16:51:27speachybraewoods: yeah
16:51:55speachynow we actually have our own "DSP" core of sorts that does multi-channel mixing, sample rate conversion, volume, etc
16:52:42speachybut that also requires CPU + RAM resources which are in short supply. :)
16:52:49speachy(not so much CPU on this thing, but still)
16:52:52 Join ac_laptop [0] (~ac_laptop@2a01:cb1c:3c8:2700:e29d:31ff:fe2d:a258)
16:54:04speachyconsider the implications of what would happen if we wanted to handle a voiced menu prompt or even a keyclick while playing back stuff via a hwcodec.
16:54:51braewoodsdo these even support sound effects being mixed in with the main audio stream
16:55:33speachyprobably not. but if the decoder goes to a RAM buffer instead of DMAing directly to the DAC then we can intecept it and mix in whatever we want
16:56:04braewoodsdepends how much audio we buffer i gues
16:56:11speachy(those cheapo rknano/atj2157 shovelware players can't, or at least don't have the RAM to be able to do anyhting meaningful)
16:56:34 Join ufdm_ [0] (
16:57:36speachya decent case can be made (I think) for reworking our audio path to be more flow-oriented. perhaps reworking our codec API a little too so we can hide a hwcodec engine behind it, as long as we can get raw PCM back out again
16:58:29speachy...but that comes back to developer-hours. and relatively skilled ones at that.
16:59:02 Join Moriar [0] (
16:59:37 Quit ufdm (Read error: Connection reset by peer)
17:01:25speachy"does this substantial effort bring more to rockbox than, say, using that same level of effort to port to other DAPs on the market"
17:03:41speachyeg getting erosq/k dualboot going, doing native ports to other x1000 targets (eg xDuoo x3ii/x20), making the touchscreen UI better (which opens up a _lot_ of other targets), improvements to the hosted port (eg better threading), HD audio and/or DSD support,
17:04:37speachykeeping in mind that none of us can tell anyone to work on anything in particular. :)
17:05:42speachyheh, doing a port to common RPi touchscreen enclousures might actually be the best bang-for-the-buck thing we could do.
17:06:42speachyI think the low-end is irrecovably lost.
17:07:19 Join amachronic [0] (~amachroni@user/amachronic)
17:07:39speachywe'd be competeing with highly optimized reference designs.
17:08:34speachywithout enough resources to offer much more than "open source" which really doens't matter to most of our users.
17:09:56speachyamachronic: if you'd care to look at the day's voliminous history, I'd love to see your opinion on this
17:10:14amachronicyeah, I was looking the logs
17:15:32amachronicmy gut feeling is "a lot of work for little gain" but much of that work would be more broadly useful.
17:15:44*speachy nods.
17:15:56speachywell, at least some of it.
17:16:26amachronichave you heard of LVGL? I came across it while pondering ideas for the rockbox UI.
17:16:46amachronicit has a way of drawing to the LCD that requires less ram. just one row of pixels, I think.
17:16:50speachynope, bit I see it..
17:18:27braewoodssounds like the CRT approach to screen drawing
17:18:48speachyminimal one scanline at a time, yeah
17:18:59speachyc99, MIT licensed
17:19:29speachynot sure how we could incrementally use something like this. :)
17:19:59amachronicyeah, that's the main hurdle. It'd be a _ton_ of work.
17:20:14speachyinput too
17:20:22amachronic...and all themes would break.
17:22:37speachyI also wonder how low-end this thing can realistically go. eg earlier-gen ipods which are more CPU limited than anything esle, and the crappy clip/x3 128x64 screens
17:23:35speachythe examples are all much higher-end screens than most of our targets. but appropriate for modern hardware
17:24:51amachroniciirc it's mostly touchscreen focused so it may not do as well with buttons, but there is some minimal button support.
17:26:03amachronicbut we wouldn't need to use lvgl to use the same drawing approach.
17:26:05 Quit lebellium (Quit: Leaving)
17:26:19 Join dconrad_web [0] (
17:26:40speachyit's essentially a display list processor
17:28:52dconrad_webI've been following the logs all afternoon, it sounds like it might be possible to attach an outboard ram chip to this SoC?
17:29:06dconrad_webah, dang never mind then
17:29:12speachywell, those "SPI SRAM" chips, maybe
17:29:36dconrad_webthought, since the hw dev is accessible, maybe they could be lobbied to get us more ram some way, some how
17:29:56dconrad_websince it sounds like that would make the whole thing leaps and bounds more attainable
17:30:03speachyPine64 didn't make the SoC; we're stuck with what it was designed with.
17:30:13dconrad_webwell, they designed the board, though?
17:30:22speachyit's all on-chip
17:30:48dconrad_webI see
17:37:26speachyquick greps through the SDK seem to indicate this thing is the most RAM-equipped of the family
17:38:39speachy...and that ~1MB of RAM isn't as free for general use as first suspected
17:38:57rb-bluebotBuild Server message: New build round started. Revision 99f333c64f, 303 builds, 12 clients.
17:39:24speachybraewoods: we'll see how your builder fares now!
17:40:37 Quit dconrad_web (Quit: Connection closed)
17:43:33amachronicspeachy, any opinion on g#3828?
17:43:37rb-bluebotGerrit review #3828 at : usb: rename usb_drv_recv() to usb_recv_recv_nonblocking() by Aidan MacDonald
17:44:36speachyamachronic: just a mechanical rename?
17:44:56***Saving seen data "./dancer.seen"
17:45:32speachymake it so!
17:46:42braewoodsspeachy: alright, captain picard
17:49:40rb-bluebotBuild Server message: Build round completed after 643 seconds.
17:49:42rb-bluebotBuild Server message: Revision 99f333c64f result: All green
17:49:59rb-bluebotBuild Server message: New build round started. Revision 672bbe434b, 303 builds, 10 clients.
17:50:20braewoodsthat helped
17:52:01braewoodsthis server has a lot of bandwidth which probably helped
17:53:51speachyshould probably try and re-weight the build scores
17:55:28braewoodswhat's the UL speed even mean
17:55:30braewoodsthere's no given units
17:59:02amachronicspeachy: here's a very rough spec of that USB API −− amachronic/rockbox/blob/new-usb-api/docs/">
17:59:21amachroniccommits here to not clutter gerrit for the time being: amachronic/rockbox/commits/new-usb-api">
18:00:56rb-bluebotBuild Server message: Build round completed after 657 seconds.
18:00:58rb-bluebotBuild Server message: Revision 672bbe434b result: All green
18:02:05amachronicthere's no driver support yet, but I came up with a way to keep the existing drivers running until we can port them.
18:05:54 Quit ufdm_ (Quit: Leaving)
18:06:06 Join ufdm [0] (
18:08:01 Join smithjd [0] (
18:12:03 Quit smithjd (Client Quit)
18:42:42 Quit amachronic (Quit: amachronic)
18:48:46 Quit ZincAlloy (Quit: Leaving.)
19:44:59***Saving seen data "./dancer.seen"
19:46:09 Quit calebccff (Quit: Idle timeout reached: 10800s)
19:50:45_bilgusspeachy it sounds like this device is a no go then the 1Mb was already really pushing it
19:51:18_bilgusif its not free to use then its not going to be a very great device feature wise
20:15:57rb-bluebotBuild Server message: New build round started. Revision 412e76b487, 303 builds, 11 clients.
20:16:51speachy_bilgus: I can't say that for sure, the linker script + headers don't seem to jive with the datasheet with respect to available memory. but I might be mis-reading it.
20:23:56 Quit ac_laptop (Quit: WeeChat 3.2.1)
20:27:17rb-bluebotBuild Server message: Build round completed after 680 seconds.
20:27:19rb-bluebotBuild Server message: Revision 412e76b487 result: All green
20:34:50speachyok, time to see if my new "recompute all scores" script works with sim builds now..
20:37:30speachythe reference machine I'm using produces scores about 1/10th of the old ones.
20:52:38speachysims are coming in at about 1/4th the points
20:56:33 Quit cockroach (Quit: leaving)
21:15:40speachythis rescaling ought to make things a bit fairer & more efficient
21:16:51speachyand ccache makes a _big_ difference.
21:45:02***Saving seen data "./dancer.seen"
21:49:14 Quit emacsomancer (Read error: Connection reset by peer)
21:55:09 Join emacsomancer [0] (~emacsoman@
22:20:41 Quit Moriar (Ping timeout: 252 seconds)
23:17:08 Join ufdm_ [0] (
23:17:08 Quit ufdm (Read error: Connection reset by peer)
23:45:05***Saving seen data "./dancer.seen"

Previous day | Next day