| 00:29:57 | | Quit benjaoming (*.net *.split) |
| 00:30:17 | | Join benjaoming [0] (~benjaomin@37.139.19.237) |
| 00:41:38 | | Quit gevaerts (*.net *.split) |
| 00:41:48 | | Join gevaerts [0] (~fg@user/gevaerts) |
| 01:00 |
| 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:00 |
| 02:14:00 | | Quit _bilgus (Remote host closed the connection) |
| 02:15:50 | | Join _bilgus [0] (~bilgus@162.154.213.134) |
| 02:29:19 | | Quit smithjd (Ping timeout: 268 seconds) |
| 03:00 |
| 03:44:40 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:14:15 | | Quit Piece_Maker (Ping timeout: 265 seconds) |
| 04:21:51 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 04:27:05 | | Quit Piece_Maker (Ping timeout: 264 seconds) |
| 04:34:30 | | Join Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 05:00 |
| 05:44:42 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:24:16 | | Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility) |
| 06:33:52 | rb-bluebot | Build Server message: Build round completed after 862 seconds. |
| 06:33:54 | rb-bluebot | Build Server message: Revision 483563a1b2 result: All green |
| 07:00 |
| 07:44:43 | *** | No seen item changed, no save performed. |
| 08:00 |
| 08:09:17 | speachy | yay, bluebot is back! |
| 08:09:57 | speachy | blbro[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] (~ats@cartman.offog.org) |
| 08:57:36 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 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@136.60.128.68) |
| 10:00 |
| 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:00 |
| 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] (topic@31-151-2-135.dynamic.upc.nl) |
| 12:00 |
| 12:43:00 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 12:58:17 | | Quit ac_laptop (Ping timeout: 264 seconds) |
| 13:00 |
| 13:30:08 | | Join toxx [0] (~cnc-guy@v3-1260.vlinux.de) |
| 13:33:52 | | Part toxx |
| 13:44:48 | *** | Saving seen data "./dancer.seen" |
| 13:47:45 | | Join lebellium [0] (~lebellium@lfbn-idf2-1-1386-25.w92-169.abo.wanadoo.fr) |
| 14:00 |
| 14:01:03 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 14:16:28 | | Join calebccff [0] (~calebconn@connolly.tech) |
| 14:16:28 | calebccff | hey, 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:04 | braewoods | calebccff: it's probably related to our inquiries from last year or so. |
| 14:24:15 | braewoods | if they are actually doing that. |
| 14:25:38 | calebccff | braewoords: that would make sense |
| 14:25:48 | braewoods | where'd you read that anyway |
| 14:26:09 | braewoods | i hadn't heard anything further |
| 14:26:13 | calebccff | theres been some discussions in the pine64 dev room |
| 14:26:23 | braewoods | ah, i see. |
| 14:26:44 | braewoods | last i heard we just received some development units for some platform device of theirs |
| 14:27:17 | calebccff | oh? |
| 14:27:37 | braewoods | speachy is the one who's dealt with it most |
| 14:27:54 | braewoods | i mostly just suggested it since they've been working on custom hardware solutions |
| 14:28:08 | braewoods | they're more experienced with this sort of thing. we mostly just write the code. |
| 14:28:22 | calebccff | hm yeah |
| 14:28:38 | braewoods | if it does arrive the initial code would probably be the rockbox Linux port |
| 14:29:46 | calebccff | ah, the hardware wont support linux from what I've heard |
| 14:30:49 | braewoods | or it could be rockbox directly |
| 14:30:55 | calebccff | the idea waa to use a cortex-m4 based chip, designed for use in players and headphones |
| 14:30:57 | braewoods | it was just an educated guess |
| 14:31:20 | calebccff | cool, uh whats the best way for them to reach out? i can let them know |
| 14:31:50 | calebccff | or you could join the dev channel if interested, whatever is easiest for you |
| 14:32:05 | calebccff | they certainly seem very interested in rockbox support |
| 14:32:05 | braewoods | here probably, at least to setup initial discussions |
| 14:32:23 | braewoods | we could always use more targets that aren't unobtainium |
| 14:32:29 | calebccff | ok sure |
| 14:32:35 | calebccff | haha yeah i get that |
| 14:32:51 | braewoods | this would be better than everything else since rockbox has always had to be grafted onto whatever is floating around |
| 14:33:04 | braewoods | we wouldn't need to reverse engineer as much |
| 14:33:39 | calebccff | yeah exactly |
| 14:33:52 | calebccff | its a really exciting prospect |
| 14:34:23 | calebccff | and it could potentially compete with some higher end products too :p |
| 14:34:28 | braewoods | i'm not getting my hopes up though. |
| 14:35:21 | braewoods | thing is, if they want it to support certain things like bluetooth, we need some help there. |
| 14:35:33 | braewoods | we have no stack for wifi or bluetooth |
| 14:35:53 | braewoods | speachy has tried to find a third party one we could use but no luck to date |
| 14:36:43 | braewoods | what's the channel name |
| 14:38:10 | | Quit SammysHP (Quit: *wuff*) |
| 14:38:15 | | Join tllim [0] (~tllim@98.248.138.192) |
| 14:38:40 | | Join ac_laptop [0] (~ac_laptop@2a01:cb1c:3c8:2700:e29d:31ff:fe2d:a258) |
| 14:38:44 | tllim | Hi, I am TL Lim, PINE64 founder |
| 14:38:44 | | Join SammysHP [0] (~SammysHP@faol.sammyshp.de) |
| 14:39:30 | speachy | they reached back out to me last week but I've been too caught up to properly follow up |
| 14:40:18 | speachy | the SoC they're looking at is not a good match for what we need, at first glance. very RAM limited. |
| 14:41:06 | tllim | if you have any question on the project, I will answer. Please noted that I only login on today only. |
| 14:41:20 | braewoods | speachy: how RAM limited? |
| 14:41:21 | tllim | the RMA space is about 960KB |
| 14:41:36 | braewoods | oh that's tiny... rockbox normally requires at least 2MB. |
| 14:41:40 | speachy | under a megabyte total. |
| 14:41:51 | tllim | https://app.box.com/s/3mtqdeeiko99hjviaw7li70okoz753q1 |
| 14:42:02 | braewoods | it might fit if we strip out a lot of extraneous stuff but... |
| 14:42:05 | speachy | dual cortex-M4Fs, at 300MHz, which is quite nice |
| 14:42:11 | tllim | This is the chip spec. BES2300YP |
| 14:42:16 | braewoods | would that leave enough usable RAM |
| 14:43:10 | tllim | This is a famous TWS ANC earbuds chip but the chip can be used for generic purpose. |
| 14:43:45 | braewoods | tllim: is all decoding done in software? |
| 14:43:49 | braewoods | meaning mp3, etc |
| 14:43:52 | speachy | I think so |
| 14:43:54 | tllim | There will be three devices come out from this project, a dev board, a DAP, and a pair of ANC earbuds |
| 14:44:37 | braewoods | hm. what storage options does it support? sd card? |
| 14:44:41 | tllim | Here is teh SDK: https://app.box.com/s/cxw1pdssycsbg93bcazbvbiz96j28og7 |
| 14:45:16 | tllim | please keep this SDK within Rockbox community for reference. |
| 14:45:31 | tllim | The original OS is RTX and can apply to RTOS. |
| 14:45:55 | speachy | if we can execute from flash with reasonable performance then that'll free up RAM for code |
| 14:46:02 | tllim | Here is teh compiler: https://app.box.com/s/b3s6eyemfatd8c0zhgml7uptd7t40ejh |
| 14:46:04 | speachy | but that's not a lot to play with |
| 14:46:19 | braewoods | indeed but it might work for a basic rockbox port. |
| 14:46:28 | tllim | @solomon, for sure the program runs in flash, not system RAM. |
| 14:46:50 | speachy | "basic port" in this case means "a lot of restructuring to make it fit" |
| 14:47:11 | tllim | This is the dev board spec: https://app.box.com/s/vr5j8qopti2vl7dm5i6mekrpn6sb1duw |
| 14:47:12 | speachy | we can pretty much scrap most plugins |
| 14:47:27 | speachy | and probably quit a few of the codecs too |
| 14:47:48 | braewoods | well there's a few lesser used ones. |
| 14:48:09 | braewoods | ones that require too much RAM would have to go |
| 14:48:20 | speachy | the point being the final feature set will necessarily not match what folks have come to expect from "rockbox" |
| 14:48:21 | braewoods | that probably means... aac or w/e |
| 14:48:21 | tllim | Rockbox community ask for a DAP and here is the offer. |
| 14:48:57 | braewoods | speachy: well we have stripped down ports as it is in the sansa line. this is more stripped down but |
| 14:49:14 | braewoods | not 100% unprecedented to have "gimped" ports |
| 14:49:20 | speachy | tllim: please don't think we don't appreciate this. |
| 14:49:38 | speachy | have to figure out the techncical feasibility |
| 14:49:55 | tllim | this is the "best" chip that I able to locates and also potential on open source. |
| 14:50:09 | braewoods | i think we should try it speachy, there's not many options out there for us to leverage. |
| 14:50:28 | speachy | tllim: does this SoC have any sort of display controller/engine, or would we have to use something attached via i2c/spi? |
| 14:50:38 | braewoods | we just need to disclose that the port is going to be "rockbox lite" |
| 14:50:41 | braewoods | so to speak |
| 14:51:23 | tllim | please explore within Rockbox community, if interest to explore, I can provide dev board on next month. |
| 14:52:01 | tllim | the SoC has SPI interface for LCD panel and i2c for touch screen. |
| 14:52:31 | tllim | The idea is this is a 2.5" LCD panel with full touch screen capability. |
| 14:52:55 | braewoods | what about gpio for regular buttons |
| 14:53:02 | tllim | There is memory buffer on LCD controller STV7789 and not occupied system memory space. |
| 14:53:52 | tllim | depends on the designs, the buttons can use ADC input or normal GPIOs |
| 14:53:54 | braewoods | given how i2c works we could also use it for other stuff as well |
| 14:54:07 | braewoods | some fm radio chips work with i2c |
| 14:54:37 | tllim | This is GPIP mux map: https://app.box.com/s/nxk6r4kdb8ou92h3fiw643w3zlmjqfqp |
| 14:55:03 | tllim | ^^^ still two more pin available than above map chart |
| 14:56:06 | tllim | This chip has very good DAC performance, just check the datasheet :-) |
| 14:56:58 | tllim | the DAP can also has ANC capability :-) |
| 14:57:02 | braewoods | tllim: what did you find regarding FM/DAB radio support? |
| 14:57:14 | tllim | no FM/DAB capability |
| 14:57:27 | braewoods | ok, not essential. |
| 14:57:59 | tllim | due to this SoC use in TWS earbuds, the power saving is very good |
| 14:58:37 | tllim | if you have interest to know this chip performance, just check the Oneplus Earbuds Pro. |
| 14:58:47 | braewoods | that must be why the RAM is so low.. it's probably SRAM. |
| 14:58:48 | _bilgus | sounds a lot like the clip v1 in constraints |
| 14:59:13 | tllim | correct, is SDRAM |
| 14:59:22 | braewoods | DRAM consumes more power |
| 14:59:22 | tllim | sorry, is SRAM |
| 14:59:32 | tllim | typo |
| 15:00 |
| 15:00:08 | tllim | there are 4MB internal flash for program |
| 15:00:14 | | Quit pixelma (Quit: .) |
| 15:00:14 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 15:00:21 | tllim | all music file locates at microSD card |
| 15:01:47 | braewoods | if we embed the rockbox core into ROM, we could probably make this work. |
| 15:02:38 | _bilgus | fits right in with my idea to pull everything non essential out of core |
| 15:02:46 | tllim | ^^^ this should eb possible. |
| 15:02:53 | _bilgus | we can page in menus as plugins |
| 15:03:27 | speachy | actually I was thinking the opposite; if we're going to execute from ROM it would be advantageous to run _everything_ from rom. |
| 15:03:28 | braewoods | we already have a few ports that can run rockbox core from ROM. |
| 15:03:36 | tllim | There 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] (marianne@p200300ea87293400305e95fffec66ff3.dip0.t-ipconnect.de) |
| 15:03:47 | | Join amiconn [0] (jens@p200300ea87293400305e95fffec66ff3.dip0.t-ipconnect.de) |
| 15:04:01 | braewoods | namely the iriver H100 and H300 series |
| 15:04:19 | _bilgus | ah embed everything essential to keep the ram free |
| 15:04:20 | speachy | probably mp3, the new bt audio codec, possibly even aac |
| 15:04:36 | tllim | This SoC also has USB port, this means the DAP can also act as USB DAC adapter |
| 15:04:47 | braewoods | i would leave out some of the extraneous codecs that people rarely use such as the non-digital audio formats |
| 15:04:52 | braewoods | like the trackers and such |
| 15:05:10 | speachy | braewoods: eh, it's not a matter of quantity so much as runtime RAM usage. |
| 15:05:20 | braewoods | oh, i see. |
| 15:05:26 | speachy | AAC is one of the worst, IIRC. |
| 15:05:32 | braewoods | yea, i noticed. |
| 15:06:21 | tllim | AAC seems has hardware codec supported. |
| 15:06:42 | speachy | we'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:44 | tllim | AAC is essential in good TWS earbuds design |
| 15:07:00 | _bilgus | we can also use faster cards I presume |
| 15:07:40 | braewoods | tllim: 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:55 | tllim | I have posted the datasheet link |
| 15:08:07 | braewoods | ok. |
| 15:08:11 | braewoods | wasn't sure if it was in there |
| 15:08:17 | tllim | here again: https://app.box.com/s/3mtqdeeiko99hjviaw7li70okoz753q1 |
| 15:08:46 | braewoods | just aac it appears |
| 15:08:53 | tllim | does IRC allow to post PDF file? |
| 15:08:56 | _bilgus | I'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:10 | braewoods | we can only accept text stuff. |
| 15:09:26 | braewoods | so urls are it |
| 15:09:27 | speachy | well, AAC is all that's explicitly mentioned. remember this is targeting bluetooth earbuds. |
| 15:09:27 | tllim | this is why I send the download link |
| 15:09:47 | tllim | the BES2300 NOT only targets for earbuds |
| 15:10:01 | braewoods | even so the bluetooth support could be useful if we can solve the bluetooth stack issue |
| 15:10:05 | tllim | the chip is a more generic audio chip |
| 15:10:30 | tllim | this si why it has stereo audio DAC output |
| 15:11:01 | tllim | the chip that specific design for TWS earbuds only has mono DAC |
| 15:11:19 | braewoods | hm looks like it supports analog audio output too, not surprising |
| 15:11:29 | _bilgus | Speachy Rom is only 400 ish k I don't think core is getting in there as it is currently |
| 15:11:33 | tllim | also has SDPIF :-) |
| 15:11:39 | tllim | in and out |
| 15:11:55 | braewoods | tllim: optical and electrical? |
| 15:11:57 | speachy | _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 | _bilgus | ah ok |
| 15:12:32 | braewoods | good point, is the ROM field reprogrammable? |
| 15:12:39 | speachy | ROM is ROM. |
| 15:12:46 | braewoods | so it's not EEPROM |
| 15:12:48 | braewoods | ? |
| 15:13:00 | tllim | SRAM is 992KB, please check datasheet page 8. |
| 15:13:08 | speachy | presumably including things like data tables for codecs. |
| 15:13:26 | braewoods | bt shared SRAM? |
| 15:13:37 | braewoods | does that means the system can use it as extra RAM |
| 15:13:39 | _bilgus | ok 4mb of flash so very similar to the clip v1 |
| 15:13:41 | tllim | there is onchip 4MB (bytes) flash |
| 15:13:53 | tllim | 4MB, not 4Mb. |
| 15:14:37 | braewoods | i wonder if that means we could repurpose the shared SRAM if we're not using bluetooth. |
| 15:14:54 | speachy | SDK is "all rights reserved" and the audio codec stuff is a binary blob. Hmm. |
| 15:14:58 | tllim | agreed that due to limited SRAM space, on the fly decoding is important |
| 15:15:52 | tllim | anyway, this is the best that IPINE64 can offer. Please explore and lets me know. |
| 15:16:00 | tllim | I am log off now |
| 15:16:02 | speachy | tllim: we will, thank you. |
| 15:16:05 | tllim | cya |
| 15:16:09 | _bilgus | thanks for taking the time for us :) |
| 15:16:58 | tllim | Happy 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 | _bilgus | I don't know how much of rockbox will remain after but at the very least bad code brings in new devs :P |
| 15:17:52 | braewoods | how much do we compress stuff? |
| 15:18:06 | speachy | we won't, because you can't execute compressed code. :) |
| 15:18:29 | braewoods | lol |
| 15:18:41 | _bilgus | UCL for bootloaders |
| 15:19:09 | speachy | the SDK has usable CMSIS headers, at least. |
| 15:19:10 | braewoods | i wouldn't want to embed our main bootloader in RO storage |
| 15:19:25 | braewoods | ROM* |
| 15:19:31 | braewoods | assuming it can't be rewritten later |
| 15:19:33 | speachy | we can't, because we can't write it. |
| 15:19:45 | speachy | you're think WOM. :D |
| 15:19:48 | braewoods | the ROM is probably mostly useless to it |
| 15:20:00 | braewoods | to us then |
| 15:20:05 | speachy | maybe |
| 15:20:07 | braewoods | i can't think of what we'd put in it |
| 15:20:25 | braewoods | it would have to be something we're not going to change |
| 15:20:33 | braewoods | so not likely to be code |
| 15:21:00 | speachy | you're misunderstanding −− it's mask ROM, ie baked in at the time the chip was manufactured. (well, technically, designed) |
| 15:21:17 | braewoods | yea, i understand that now. |
| 15:21:18 | speachy | think things like CRC data tables, ICDT transforms, |
| 15:21:48 | braewoods | ideally the system would boot from the flash that is writeable |
| 15:22:03 | braewoods | so we can update the firmware that way |
| 15:22:03 | speachy | yes, that would be expected |
| 15:22:33 | braewoods | i suggest our own bootloader since uboot is probably too fat |
| 15:22:42 | braewoods | would eat up precious space |
| 15:22:57 | braewoods | sides this kind can't run Linux :) |
| 15:23:09 | speachy | we're bare metal all the way, no reason to use anything fancy like u-boot. |
| 15:23:17 | speachy | (did u-boot ever get ported to microcontrollers anyway?) |
| 15:23:33 | speachy | actually booting up is easy |
| 15:23:38 | speachy | standard cortex-M stuff |
| 15:23:48 | speachy | where this gets messy is getting rockbox itself to simply _fit_ |
| 15:24:24 | _bilgus | I'm excited at the prospect of having obtainable hardware if nothing else |
| 15:24:35 | speachy | assuming it's a 16bit panel we'll need 150K just for the framebuffer. |
| 15:24:44 | calebccff | glad to see you guys are interested |
| 15:24:57 | calebccff | speachy: the panel will have its own framebuffer iirc |
| 15:25:19 | speachy | calebccff: if it's not memory-mapped into the CPU's address space it doesn't matter. |
| 15:25:29 | calebccff | ah, i see |
| 15:25:42 | _bilgus | we could cheat on that a bit by using monochrome |
| 15:26:05 | _bilgus | you'd still get a choice of colors |
| 15:26:22 | speachy | think about these compromises. |
| 15:26:30 | speachy | and ask if you'd actually want to use it. |
| 15:26:44 | calebccff | the panel driver would still be responsible for pushing the framebuffer to the display, so maybe some lossless compression could be used? |
| 15:27:04 | speachy | calebccff: the CPU still has to have something to compress and send over |
| 15:27:17 | speachy | unless you want to assemble one scanline at a time (ala atari VCS, heh) |
| 15:27:43 | calebccff | aha, hm yeah i see |
| 15:28:24 | _bilgus | The areas I wouldn't be willing to compromise is the audio |
| 15:30:20 | speachy | once you strip away half the codecs, meaningful themes, nearly all games/plugins, compromise the UI (touchscreen?).. |
| 15:30:34 | _bilgus | nope no ts |
| 15:30:57 | _bilgus | we have gpios a plenty I hope this thing gets buttons |
| 15:30:57 | speachy | oh, quite possbily/likely the voiced menus too |
| 15:31:12 | _bilgus | voice would be a difficult prop |
| 15:31:18 | _bilgus | but its been done |
| 15:31:35 | _bilgus | itd turn into an either or kinda ordeal |
| 15:31:50 | _bilgus | with enough processing power might be ok |
| 15:31:53 | speachy | how 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:34 | speachy | competing with $30 rknano shovelware |
| 15:32:51 | _bilgus | It'd have to be onm the audio and playlists |
| 15:33:06 | _bilgus | gapless pb and true random |
| 15:33:47 | _bilgus | I somehow doubt the battery life would be spectacularly greater though |
| 15:33:59 | calebccff | touchscreen cant be that big? |
| 15:34:14 | _bilgus | touchscreens suck |
| 15:34:29 | _bilgus | can't use it eyes free |
| 15:34:40 | calebccff | theyre doing cool stuff with them on the pinetime (and i guess other smart watches) |
| 15:34:43 | calebccff | true enough |
| 15:34:59 | calebccff | unless you do gestures while screen off |
| 15:35:19 | speachy | the clipv1 uses 303K of RAM for the core stuff (add 150K for the bigger framebuffer) |
| 15:35:35 | _bilgus | buttons allow muscle memory and intuitive use |
| 15:35:58 | calebccff | agree |
| 15:36:06 | speachy | ~900K for the audio buffer, 80K for plugins. |
| 15:36:47 | speachy | and about another 64K of in IRAM. |
| 15:36:55 | _bilgus | 992 means 500 for fb |
| 15:37:48 | _bilgus | although there is quite a bit of that dedicated to being static stuff that could go to flash? |
| 15:37:57 | speachy | so we're looking at about.. 400K of space for buffering and codec working space. |
| 15:38:16 | speachy | on the clipv1 there's about 600K of code that I left out. :D |
| 15:38:20 | _bilgus | that is not a lot |
| 15:38:51 | speachy | cortex-m4 is thumbv2, which is probably denser on average than what's in the clip |
| 15:39:18 | speachy | nevermind, we're forcing thumb on that thing too |
| 15:39:23 | _bilgus | yep |
| 15:39:55 | speachy | themes and voice stuff works by stealing from the audiobuffer, correct? |
| 15:40:24 | _bilgus | pb first then audio |
| 15:40:36 | _bilgus | plugin* |
| 15:40:44 | speachy | (I'm just flat-out assuming we will put all code into, and execute from, flash. |
| 15:41:02 | _bilgus | no other choice |
| 15:41:35 | speachy | even achieving that would be a pile of work. adding a flash directory for everything.. |
| 15:41:55 | speachy | building all plugins to be fully relocatable |
| 15:42:35 | _bilgus | thats a tall order |
| 15:42:50 | _bilgus | It would have to be an incremental effort |
| 15:43:17 | speachy | thankfully this thing has a linear SRAM address space. :D |
| 15:44:15 | _bilgus | I 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:15 | speachy | heh, and then there's the core port to a dual-core Cortex-M4. :) |
| 15:44:52 | *** | Saving seen data "./dancer.seen" |
| 15:45:13 | speachy | my 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:58 | braewoods | don't we already have that |
| 15:46:02 | braewoods | PP is dual core LOL |
| 15:46:08 | speachy | this thing definitely has the raw cpu oomph to do what we want, even single-core. |
| 15:46:42 | braewoods | does it also have a fpu |
| 15:46:46 | braewoods | not sure if this arm has that |
| 15:46:47 | speachy | braewoods: 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:09 | speachy | these both have the FPU, and the 1st-gen CM DSP stuff too |
| 15:47:30 | speachy | that DSP (==SIMD) opens up a lot of optimization opportunities |
| 15:48:19 | _bilgus | Its probably the only chance we are going to get to claw back some harware for the future |
| 15:48:21 | speachy | ARM provides some optmized libraries for a lot of common numerical tasks |
| 15:51:13 | speachy | I'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:49 | speachy | which makes no sense from a BOM perspective... |
| 15:52:24 | speachy | the real cost for "our own hardware" is a case. |
| 15:57:14 | speachy | USB code is a binary blob |
| 16:00 |
| 16:00:37 | speachy | anyway. |
| 16:05:20 | braewoods | speachy: how do i know if a build client is recognized |
| 16:05:50 | speachy | does the script error out? :) |
| 16:05:56 | braewoods | no, just perl warnings |
| 16:06:17 | braewoods | i started it via a service file |
| 16:06:23 | braewoods | specified the working directory |
| 16:06:24 | speachy | assuming "big-wiener-megawienie |
| 16:06:27 | braewoods | lol |
| 16:06:28 | speachy | is you |
| 16:06:32 | speachy | then it connected |
| 16:06:39 | braewoods | i was bored |
| 16:06:51 | speachy | but please name it appropriately |
| 16:06:59 | braewoods | no fun lol |
| 16:07:03 | braewoods | ok |
| 16:08:04 | speachy | oh this is confusing |
| 16:08:20 | braewoods | there |
| 16:08:25 | braewoods | ? |
| 16:09:06 | speachy | there'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:24 | speachy | but built on the same sw platform as the original Q |
| 16:09:34 | * | speachy twitches. |
| 16:10:01 | braewoods | https://www.ebay.com/itm/274492513488 |
| 16:11:06 | speachy | 5 available, get 'em while you can! :) |
| 16:11:20 | braewoods | haha |
| 16:11:32 | braewoods | maybe if there's any left next month |
| 16:12:06 | braewoods | speachy: i finished a tedious project today |
| 16:12:46 | braewoods | i 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:16 | braewoods | like a 1/40th of the runtime now |
| 16:13:19 | braewoods | of the original runtime |
| 16:13:50 | braewoods | that's for the decoding, more like 1/90th for the encoding |
| 16:13:58 | braewoods | python sucks so bad |
| 16:14:14 | braewoods | that was how they were compressing their data before |
| 16:14:20 | braewoods | python code... |
| 16:14:31 | braewoods | not to mention the performance hit from a lot of fork+exec |
| 16:14:48 | calebccff | speachy: 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:58 | calebccff | that saves ~150k |
| 16:15:53 | braewoods | speachy: 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:17 | braewoods | having a solution that allows us to run in tighter constraints to a degree would be helpful |
| 16:17:05 | speachy | well, if we treat the fb as write-only then sure |
| 16:17:21 | calebccff | from 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:49 | calebccff | is 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:50 | speachy | but making each individual write go out via SPI would represent serious performance penalty with how we currently put the FB together |
| 16:18:38 | calebccff | hmm i see |
| 16:18:56 | braewoods | which is using our own RAM buffer that we setup a DMA transfer for? |
| 16:19:01 | speachy | yeah |
| 16:19:16 | speachy | the theory being we don't have to send it to the hw until we're done painting the whole thing. |
| 16:19:29 | braewoods | doesn't SPI have DMA too? |
| 16:19:39 | calebccff | pretty sure |
| 16:19:42 | speachy | (when it's truly a framebuffer being continually refreshed by dedicated harware, it doesn't matter) |
| 16:19:54 | braewoods | so why can't be treated an SPI write buffer like this? |
| 16:20:06 | speachy | writes block |
| 16:20:18 | calebccff | how many painting steps are there? It's not like you need to care about opacity |
| 16:20:30 | speachy | at minimum, two |
| 16:20:56 | braewoods | trouble is we need to know something about the screen in order to know what to send it |
| 16:20:56 | speachy | background + foreground, but each display element tends to be painted independently, and they can/do overlap. |
| 16:21:05 | braewoods | so not sure how much you can realistically remove |
| 16:21:53 | speachy | when you're updating a framebuffer, you just write a memory location and maybe trigger an async refresh if necessary. |
| 16:22:24 | braewoods | using SPI is probably like controlling a terminal screen. |
| 16:22:32 | speachy | but 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:59 | braewoods | speachy: can't you just use a queue? |
| 16:23:05 | braewoods | or is that not a thing for SPI |
| 16:23:06 | speachy | sure, that has to be written and maintained |
| 16:23:11 | calebccff | fwiw you might find it helpful to look at the code being used for rendering on the Pinetime |
| 16:23:15 | speachy | and the hardware itself doesn't know/care. |
| 16:23:30 | calebccff | it's a smartwatch running an RTOS with an SPI display and has seen some very impressive performance |
| 16:24:29 | speachy | the most performant SPI display interfacing is to use a local framebuffer and have it continually refreshed (over spi) using DMA. |
| 16:24:30 | calebccff | ah, this is rust but maybe still useful: https://lupyuen.github.io/articles/optimising-pinetimes-display-driver-with-rust-and-mynewt |
| 16:24:42 | calebccff | speachy: that makes sense |
| 16:25:08 | calebccff | this thing only has 64kb of RAM, so no framebuffer |
| 16:25:21 | calebccff | it does have the benefit of running software built for it though |
| 16:25:56 | speachy | classic RAM/CPU tradeoff, yeah |
| 16:26:39 | speachy | and that rust code effectivelt just batches a set of updates. which only helps if you're actively painting a contiguous block |
| 16:27:17 | speachy | then again that controller protocol supports that |
| 16:27:36 | speachy | so we can relatively optimize updates. |
| 16:28:54 | speachy | doing away with a local framebuffer is doable in our display API |
| 16:29:02 | speachy | but some plugins will definitely not work. |
| 16:31:27 | speachy | but 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:14 | speachy | though 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:29 | speachy | calebccff: IIRC the Fuze+ uses a spi-attached display, though we still use a local framebuffer for performance reasons. |
| 16:35:35 | speachy | but still, this is half the RAM of any other target rockbox has ever supported. and all of those used monochrome screens. |
| 16:35:53 | calebccff | huh i see. the ipod ports are spi too i think, but ram isn't such an issue there lol |
| 16:35:55 | speachy | not impossible... just a lot of work, and it's still going to be a "lite" experience. |
| 16:36:00 | calebccff | yeah it's tight |
| 16:36:18 | speachy | and tbh I don't think it's worth the effort. |
| 16:37:25 | speachy | at least not if it's to be called "rockbox" −− it wouldn't match the market expection of the existing brand. |
| 16:37:53 | speachy | (and given entirely volunteer labor) |
| 16:42:20 | calebccff | i know a lot of the pine64 commnunity would be interested, there are a few interested developers there at least |
| 16:43:47 | speachy | they're welcome to join and help out at any time. :) |
| 16:44:21 | calebccff | i 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:13 | calebccff | And I guess a decent chance of having something with better hardware come along if works out well |
| 16:45:14 | speachy | the thing is, if it's not able to substantially re-use the rockbox codebase, the value propsition changes considerably. |
| 16:45:33 | speachy | and using a different base platform perhaps makes more sense |
| 16:46:10 | calebccff | right, yeah i see |
| 16:46:20 | speachy | we ditched tens of thousands of lines of code (and a lot of complexity) by scrapping support for the original Archos hwcodec players |
| 16:46:38 | speachy | in many ways this would require bringing much of that back |
| 16:49:05 | speachy | the way these these hardware devices are set up typically is a purely streaming DMA thing with very little CPU intervention |
| 16:50:19 | speachy | CPU 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:53 | braewoods | speachy: so rockbox would just be a glorified traffic controller |
| 16:51:23 | speachy | and the DSP engine might be a dedicated preconfigured hw block or a SW component but it's basically just a black box |
| 16:51:27 | speachy | braewoods: yeah |
| 16:51:55 | speachy | now we actually have our own "DSP" core of sorts that does multi-channel mixing, sample rate conversion, volume, etc |
| 16:52:42 | speachy | but that also requires CPU + RAM resources which are in short supply. :) |
| 16:52:49 | speachy | (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:04 | speachy | consider 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:51 | braewoods | do these even support sound effects being mixed in with the main audio stream |
| 16:55:33 | speachy | probably 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:04 | braewoods | depends how much audio we buffer i gues |
| 16:56:11 | speachy | (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] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 16:57:36 | speachy | a 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:29 | speachy | ...but that comes back to developer-hours. and relatively skilled ones at that. |
| 16:59:02 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 16:59:37 | | Quit ufdm (Read error: Connection reset by peer) |
| 17:00 |
| 17:01:25 | speachy | "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:41 | speachy | eg 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:37 | speachy | keeping in mind that none of us can tell anyone to work on anything in particular. :) |
| 17:05:42 | speachy | heh, doing a port to common RPi touchscreen enclousures might actually be the best bang-for-the-buck thing we could do. |
| 17:06:42 | speachy | I think the low-end is irrecovably lost. |
| 17:07:19 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 17:07:39 | speachy | we'd be competeing with highly optimized reference designs. |
| 17:08:34 | speachy | without enough resources to offer much more than "open source" which really doens't matter to most of our users. |
| 17:09:56 | speachy | amachronic: if you'd care to look at the day's voliminous history, I'd love to see your opinion on this |
| 17:10:14 | amachronic | yeah, I was looking the logs |
| 17:15:32 | amachronic | my 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:56 | speachy | well, at least some of it. |
| 17:16:26 | amachronic | have you heard of LVGL? I came across it while pondering ideas for the rockbox UI. |
| 17:16:46 | amachronic | it has a way of drawing to the LCD that requires less ram. just one row of pixels, I think. |
| 17:16:50 | speachy | nope, bit I see it.. |
| 17:18:27 | braewoods | sounds like the CRT approach to screen drawing |
| 17:18:48 | speachy | minimal one scanline at a time, yeah |
| 17:18:59 | speachy | c99, MIT licensed |
| 17:19:29 | speachy | not sure how we could incrementally use something like this. :) |
| 17:19:59 | amachronic | yeah, that's the main hurdle. It'd be a _ton_ of work. |
| 17:20:14 | speachy | input too |
| 17:20:22 | amachronic | ...and all themes would break. |
| 17:22:37 | speachy | I 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:35 | speachy | the examples are all much higher-end screens than most of our targets. but appropriate for modern hardware |
| 17:24:51 | amachronic | iirc it's mostly touchscreen focused so it may not do as well with buttons, but there is some minimal button support. |
| 17:26:03 | amachronic | but 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] (~dconrad_w@entr-34279.desm.netins.net) |
| 17:26:40 | speachy | it's essentially a display list processor |
| 17:28:52 | dconrad_web | I've been following the logs all afternoon, it sounds like it might be possible to attach an outboard ram chip to this SoC? |
| 17:28:58 | speachy | nope |
| 17:29:06 | dconrad_web | ah, dang never mind then |
| 17:29:12 | speachy | well, those "SPI SRAM" chips, maybe |
| 17:29:36 | dconrad_web | thought, since the hw dev is accessible, maybe they could be lobbied to get us more ram some way, some how |
| 17:29:56 | dconrad_web | since it sounds like that would make the whole thing leaps and bounds more attainable |
| 17:30:03 | speachy | Pine64 didn't make the SoC; we're stuck with what it was designed with. |
| 17:30:13 | dconrad_web | well, they designed the board, though? |
| 17:30:22 | speachy | it's all on-chip |
| 17:30:48 | dconrad_web | I see |
| 17:37:26 | speachy | quick greps through the SDK seem to indicate this thing is the most RAM-equipped of the family |
| 17:38:39 | speachy | ...and that ~1MB of RAM isn't as free for general use as first suspected |
| 17:38:57 | rb-bluebot | Build Server message: New build round started. Revision 99f333c64f, 303 builds, 12 clients. |
| 17:39:24 | speachy | braewoods: we'll see how your builder fares now! |
| 17:40:37 | | Quit dconrad_web (Quit: Connection closed) |
| 17:43:33 | amachronic | speachy, any opinion on g#3828? |
| 17:43:37 | rb-bluebot | Gerrit review #3828 at https://gerrit.rockbox.org/r/c/rockbox/+/3828 : usb: rename usb_drv_recv() to usb_recv_recv_nonblocking() by Aidan MacDonald |
| 17:44:36 | speachy | amachronic: just a mechanical rename? |
| 17:44:40 | amachronic | yep |
| 17:44:56 | *** | Saving seen data "./dancer.seen" |
| 17:45:32 | speachy | make it so! |
| 17:46:42 | braewoods | speachy: alright, captain picard |
| 17:47:14 | braewoods | :-P |
| 17:49:40 | rb-bluebot | Build Server message: Build round completed after 643 seconds. |
| 17:49:42 | rb-bluebot | Build Server message: Revision 99f333c64f result: All green |
| 17:49:59 | rb-bluebot | Build Server message: New build round started. Revision 672bbe434b, 303 builds, 10 clients. |
| 17:50:20 | braewoods | that helped |
| 17:52:01 | braewoods | this server has a lot of bandwidth which probably helped |
| 17:53:51 | speachy | should probably try and re-weight the build scores |
| 17:55:28 | braewoods | what's the UL speed even mean |
| 17:55:30 | braewoods | there's no given units |
| 17:59:02 | amachronic | speachy: here's a very rough spec of that USB API −− https://github.com/amachronic/rockbox/blob/new-usb-api/docs/usb-api.md |
| 17:59:21 | amachronic | commits here to not clutter gerrit for the time being: https://github.com/amachronic/rockbox/commits/new-usb-api |
| 18:00 |
| 18:00:56 | rb-bluebot | Build Server message: Build round completed after 657 seconds. |
| 18:00:58 | rb-bluebot | Build Server message: Revision 672bbe434b result: All green |
| 18:02:05 | amachronic | there'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] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 18:08:01 | | Join smithjd [0] (~enderw@node-1w7jra28yypte4b1rejm4lqiw.ipv6.telus.net) |
| 18:12:03 | | Quit smithjd (Client Quit) |
| 18:42:42 | | Quit amachronic (Quit: amachronic) |
| 18:48:46 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:00 |
| 19:44:59 | *** | Saving seen data "./dancer.seen" |
| 19:46:09 | | Quit calebccff (Quit: Idle timeout reached: 10800s) |
| 19:50:45 | _bilgus | speachy it sounds like this device is a no go then the 1Mb was already really pushing it |
| 19:51:18 | _bilgus | if its not free to use then its not going to be a very great device feature wise |
| 20:00 |
| 20:15:57 | rb-bluebot | Build Server message: New build round started. Revision 412e76b487, 303 builds, 11 clients. |
| 20:16:51 | speachy | _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:17 | rb-bluebot | Build Server message: Build round completed after 680 seconds. |
| 20:27:19 | rb-bluebot | Build Server message: Revision 412e76b487 result: All green |
| 20:34:50 | speachy | ok, time to see if my new "recompute all scores" script works with sim builds now.. |
| 20:37:30 | speachy | the reference machine I'm using produces scores about 1/10th of the old ones. |
| 20:52:38 | speachy | sims are coming in at about 1/4th the points |
| 20:56:33 | | Quit cockroach (Quit: leaving) |
| 21:00 |
| 21:15:40 | speachy | this rescaling ought to make things a bit fairer & more efficient |
| 21:16:51 | speachy | and 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@136.60.128.68) |
| 22:00 |
| 22:20:41 | | Quit Moriar (Ping timeout: 252 seconds) |
| 23:00 |
| 23:17:08 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 23:17:08 | | Quit ufdm (Read error: Connection reset by peer) |
| 23:45:05 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).