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).

#rockbox log for 2021-07-01

01:03:54***Saving seen data "./dancer.seen"
01:43:35 Quit Piece_Maker (Read error: Connection reset by peer)
01:44:57 Join Piece_Maker [0] (
01:57:08 Nick JanC_ is now known as JanC (~janc@user/janc)
03:03:56***Saving seen data "./dancer.seen"
03:29:38 Quit akaWolf (Ping timeout: 252 seconds)
04:18:25 Join akaWolf [0] (
05:03:58***Saving seen data "./dancer.seen"
07:04:00***No seen item changed, no save performed.
08:23:48 Join massiveH [0] (
09:04:04***No seen item changed, no save performed.
09:27:49braewoodsspeachy, _bilgus: i'm considering how i should size my read buffer. i've usually done powers of 2 to date, but does that matter for rockbox? is there any benefit to it being a power of 2 at the higher level API? if rockbox is doing its own buffering it may not matter all that much...
09:31:39braewoodsi'm basically trying to write my own mini-allocation code for ZIP support to reduce waste of the provided "scratch paper"
09:31:52braewoodsbasically managing my own stack from what would otherwise be a heap allocation
10:12:49 Quit massiveH (Quit: Leaving)
10:13:18 Join massiveH [0] (
10:14:46 Quit massiveH (Client Quit)
10:15:05 Join massiveH [0] (
10:15:38 Quit massiveH (Client Quit)
10:15:57 Join massiveH [0] (
10:16:07 Quit massiveH (Client Quit)
10:17:26speachybraewoods: size/resource use is more important than performance. and rockbox already has its own read buffering going on, so I'd not htink there's much advantage to anythin gover 512 bytes.
11:04:08***Saving seen data "./dancer.seen"
11:27:13braewoodsspeachy: ok. thanks.
11:29:01f1reflybraewoods: the size of allocated buffers should not make any difference on regular hardware. it's nice to go with familiar numbers tho as it helps to think about the problem imo
11:29:08f1reflyso i get where you're coming from
11:29:36braewoodsusually it's more about how much i have to keep in memory at once.
11:29:59braewoodsi've been using larger reads just to avoid having to write more complex parsing code
11:30:07braewoodsthink like 64k or so at a time.
11:30:40braewoodsotherwise i need something more advanced to refill my ram buffer or so and that's kinda involved when the whole data chunk is small enough to fit in RAM.
11:31:04braewoodsthis is all for my ZIP stuff and it's only used temporarily so not a permanent reservation
11:31:16braewoodsi'm also reusing buffers once they're done with their original purpose
11:31:53braewoodsfor my ZIP support i decided to split my code into 3 phases...
11:32:23braewoodsseeks can be expensive when you're jumping all over the file so i decided to cache the data i need from the CD in one read pass so i won't need to seek back to do it while i'm processing the actual file data
11:32:36f1reflyi wrote the logic to reuse a partially read buffers content last week, avoiding it seems like a logical choice to me :)
11:32:55braewoodsah, just a habit i developed from learning about parsers.
11:32:58f1reflythat seems very reasonable
11:33:18braewoodsi'm trying to decide how to utilize the memory best
11:33:28braewoodsand caching small data so i don't need to seek back to it is a good use for it
11:33:42braewoodsthat probably will kill the ZIP performance more than anything
11:33:53f1reflyyes, it is
11:34:29braewoodsi actually deployed a stripped down version of the CD because it has a lot of fields i don't actually need because the LF header has most of it
11:34:31f1reflyhow are you going to manage what you keep at what place?
11:34:33braewoodsit's a duplicate
11:34:41f1reflyare you doing that centrally or where you use it?
11:34:49braewoodswhat do you mean?
11:34:52braewoodsthe memory allocation?
11:35:24braewoodsi'm taking a large memory chunk the the user of the ZIP code provides so i don't need to deal with how it should be allocated
11:35:39braewoodsinstead i just chunk up the memory chunk they give me to allocate memory for my ZIP code
11:35:52braewoodskinda like the function stack
11:36:15braewoodsit also allows me to dynamically use it so smaller entries don't use as much space
11:36:34braewoodsand i don't need to pay the regular price that usually comes with dynamic memory allocations
11:37:25f1reflyso you're putting tiny parts into your big allocated buffer, right?
11:37:35f1reflyor am i just too dumb to get it right now?
11:37:43braewoodswell let me show my code so far
11:38:07braewoodsit's not ready to be staged into rockbox but this is what i have
11:38:41braewoodsi start from the point of when the zip handle is first opened
11:38:44*f1refly is clocking out of work for the day
11:39:19braewoodsi try to get an aligned pointer from the provided buffer
11:39:29braewoodsi assign that for the zip handle's own stuff
11:39:52braewoodsthen i store the pointer to the remainder of the chunk for future allocations in the handle itself
11:40:06braewoodschecking if there's enough space remaining each time i need to use it
11:41:17braewoodsi thought it best to do this so i can minimize the cost and space waste normally associated with dynamic memory management
11:41:30braewoodsit also allows me to work with more kinds of memory buffers
11:41:52braewoodssince i'm planning for this to be usable in bootloaders and rockbox core
11:42:25braewoodsi'm read a lot about memory management techniques but this is honestly my first time actually trying it for myself
11:42:49braewoodsi normally just use malloc and call it a day
11:43:08braewoodsbut the overhead it has makes me want to roll my own in this case
11:43:18braewoodssince rockbox has limited memory and cpu resources
11:43:24f1reflygive me a few minutes more to read into your file
11:45:10braewoodsmost of my use of it doesn't need aligned access but some of it does
11:45:36braewoodsnote it's still under development
11:45:47braewoodsthis is like my third overhaul as i got ideas for how to improve i
11:45:58braewoodsthink this is my last major revision
11:46:16braewoodsi decided i needed to more intelligently use my RAM buffers
11:46:32braewoodsinstead of always using a fixed size like a moron...
11:46:44braewoodsif this was a PC i'd do that just for simplicity but
11:46:59braewoodsi don't have gigabytes of RAM or megabytes of stack space at my disposal
11:47:24braewoodsi wanted to try to make this usable even on our lowest RAM target, around 2MB I believe
11:47:41f1reflyI think i get it now
11:47:44f1reflylooks pretty good
11:48:06braewoodsf1refly: it's based on the same principle as stack allocations
11:48:26f1reflyi only know in theory how that works
11:48:30braewoodswhich is the most efficient way to dynamically manage memory
11:48:33f1reflynever had to implement something like it before
11:48:35braewoodsbut it comes with a cost
11:48:38f1reflybut your implementatino looks good
11:48:50braewoodsthere's an upper limit on how much you can allocate with it
11:49:03braewoodsbut it's excellent way for dynamic allocations of temporary buffers or so
11:49:17braewoodsafter all in my use case all the permanent stuff is going to be handled by the user callback
11:49:29braewoodsi just need to buffer it long enough for them to do their thing
11:51:12f1reflycan you recommend me a book where i can learn more?
11:51:39f1reflyi develop c++ for a living but always wanted to learn more about c best practices
12:18:42braewoodsf1refly: about memory management?
12:25:46speachy"let someone else do it" :D
12:26:30braewoodssometimes i think the most complex part of a libc is all the dynamic memory APIs.
12:26:38braewoodsthey all have to work together
12:27:00braewoodsmalloc, calloc, aligned_alloc
12:27:01speachythat's the real mess.
12:27:13braewoodsyea, and threading also plays a part since these have to be thread safe
12:49:13 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:8d8d:14e6:d447:3796)
13:04:11***No seen item changed, no save performed.
13:54:53 Quit advcomp2019 (Read error: Connection reset by peer)
13:56:44 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
15:04:12***Saving seen data "./dancer.seen"
16:18:07 Quit lebellium (Quit: Leaving)
16:28:42 Quit rb-bluebot (Ping timeout: 268 seconds)
16:29:56 Quit bluebrother (Ping timeout: 268 seconds)
16:31:36 Join bluebrother [0] (
16:42:27 Join rb-bluebot [0] (
16:57:52_bilgusbraewoods, I'm a bit surprised the inbuilt buflib wasnt good enough TLSF
16:59:48_bilguseh Two-Level Segregated Fit before you think its some weird turn of phrase :p
17:00:52speachyThread-Local Storage?
17:04:13***Saving seen data "./dancer.seen"
18:00:50 Quit akaWolf (Ping timeout: 252 seconds)
18:33:39 Join akaWolf [0] (
19:04:15***Saving seen data "./dancer.seen"
19:59:24 Quit MarcAndersen (Read error: Connection reset by peer)
21:04:18***Saving seen data "./dancer.seen"
21:16:53 Join richbridger [0] (
21:18:01 Quit aquijoule_ (Read error: Connection reset by peer)
21:30:12kirvesAxeUhh... any idea what could cause rockbox running on an AGPtek Rocker to refuse playing .ogg files under one directory tree, but playing other file types from there and all types of files from other directories without issues? :)
21:31:57kirvesAxe(this issue appeared after the latest "take the microsd card for a spin on the PC" phase)
22:39:38 Quit amiconn (Quit: No Ping reply in 64 seconds.)
22:40:11 Quit j-r (Ping timeout: 244 seconds)
22:40:34 Join j-r [0] (
22:40:47 Join amiconn [0] (
23:04:21***Saving seen data "./dancer.seen"
23:10:50 Quit blbro[m] (Remote host closed the connection)
23:10:53 Quit kadoban (Read error: Connection reset by peer)
23:11:53 Join kadoban [0] (~kadoban@user/kadoban)
23:18:00 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
23:29:15 Join mendel_munkis [0] (
23:31:10 Quit munkis (Ping timeout: 258 seconds)
23:31:51 Nick mendel_munkis is now known as munkis (
23:33:08 Quit kadoban (Quit: node-irc says goodbye)
23:43:22 Quit blbro[m] (Quit: node-irc says goodbye)

Previous day | Next day