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 2020-12-23

00:01:48 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
00:23:37 Quit ac_laptop (Ping timeout: 264 seconds)
01:04:03 Join ac_laptop [0] (~ac_laptop@
01:06:08 Quit foolsh (Ping timeout: 260 seconds)
01:27:09 Quit Dundah (Ping timeout: 245 seconds)
01:30:36 Quit ac_laptop (Ping timeout: 240 seconds)
01:54:56***Saving seen data "./dancer.seen"
02:15:14 Join lebellium [0] (
03:06:36 Join Rower [0] (
03:10:03 Join prof_wolfff [0] (
03:45:30 Quit emacsomancer (Ping timeout: 256 seconds)
03:51:48 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:109f:7d04:6197:1a8b)
03:54:58***Saving seen data "./dancer.seen"
03:55:23 Join emacsomancer [0] (
04:03:14 Quit gevaerts (Remote host closed the connection)
04:03:32 Join gevaerts [0] (~fg@rockbox/developer/gevaerts)
04:07:37 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
04:55:43 Quit prof_wolfff (Ping timeout: 272 seconds)
05:08:28bluebrother_bilgus: not really. You could demote them to unstable or unusable, but that would also apply to release builds. In Rockbox Utiltiy you can make a target disabled, so it doesn't show up anymore, but that requires changing rbutil.ini. That's intended for unfinished implementations (f.e. ipod6g was a disabled target for long, since you could install Rockbox, just the bootloader was missing.) Both not
05:08:34bluebrotherreally what you're looking for afaiu.
05:26:03 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
05:31:53 Join gsora [0] (~gsora@unaffiliated/gsora)
05:34:44gsorathe vintage ipod bug got me, i'm thinking about getting one and rockbox-ing it - not a 5g or 5.5g though, what's the best device? I was thinking 4g bw one, but the wiki page isn't particularly clear about the port status
05:39:20bluebrotheripods generally work pretty well and are considered stable. 1g and 2g aren't too common so might have some issues. Ipod Video doesn't have support for video out.
05:39:48bluebrotherI'm using a mini since years and it's pretty stable for me. Though the mini is slightly smaller :)
05:40:11bluebrotherpeople tend to mod those old Ipods with SD adapters these days, those can be problematic.
05:40:26 Join MrZeus [0] (~MrZeus@
05:42:12gsorai was just looking at minis, the coolness factor is over the top with this ones
05:43:43gsorathe bw screen on these ones is gorgeous, I remember having a rockboxed 160gb 7th gen with bw theme/font :-)
05:43:51gsorabluebrother is yours a 1st or 2nd gen?
05:44:56bluebrotherif you're interested in such a mod make sure to check the forum thread first.
05:45:15bluebrotheralso modded with a CF card. Works without any issues for me.
05:45:47gsorai wonder if it's able to play opus
05:45:58gsoraoh for sure, i'll search for the thread rn
05:46:50bluebrotherbut the CF mod is a lot older and I had never issues with that (or heard about major issues with it, unlike the SD adapter mods)
05:48:03gsorawith "CF mod" you're referring to replacing the microdrive with a standard cf card?
05:53:09gsoraoh, found a 6gb mini in mint conditions for a reasonable price... is this my lucky day? :-)
05:54:21bluebrothermaybe? ;-)
05:54:59***Saving seen data "./dancer.seen"
05:56:02gsorai wonder if someone really buys those boxed ipods for 1k€
05:56:34bluebrotherok, just tried with todays build: opus works fine even up to 256k (with the opus files from
05:56:56bluebrothermy old build did skip on the 256k one every 10ish seconds.
05:59:03gsorathis is great news
05:59:15gsoradon't plan on listening to high-res stuff on mine
05:59:46bluebrotherboost a lot with 256k though, and the ui feels a bit sluggish.
06:00:07bluebrother75MHz CPU for that file.
06:00:17gsoratry with 64k
06:00:38gsorashouldn't be that much difference quality-wise iirc
06:01:09bluebrotherforgot the 64k file. But 128k ends up at 66MHz.
06:05:46bluebrother64k is pretty much the same. UI feels somewhat sluggish.
06:06:03gsorawell i guess it will be good enough for my use
06:06:18gsorawow i just found an ebay seller with many pods, good prices too it seems
06:06:19bluebrotherwell, the CPU goes up to 80 MHz, so doesn't really surprise me if decoding already uses ~70MHz.
06:06:43bluebrotherespecially compared to the typical ogg files I'm using, which seem to end up somewhere at 35MHz CPU :)
06:07:35gsoralooks like i'll stick with theora :D
06:08:00bluebrothernah, too open. Use something more obscure and proprietary!
06:08:41gsoratime for some alac
06:09:44*bluebrother hides
06:11:51gsoraproposal sent
06:12:26gsorai might bring back some c skillz too to fix bugs in the future, who knows
06:14:26bluebrotheroh, you're shopping for c skillz? :P
06:17:44bluebrotherscnr :)
06:20:11gsoraDon’t we all?
06:20:36bluebrothersome people do in one way or another. Some people don't care about computers :)
06:21:30gsoraThey’re missing out!
06:21:47gsoraThanks for your opus bench bluebrother
06:27:25bluebrothersure thing, you're welcome. Though I only looked at the numbers the buffering thread shows :)
07:08:38gsorawon the auction \o/
07:22:02 Quit bluebrother (Disconnected by services)
07:22:07 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
07:22:14 Join fs-bluebot_ [0] (
07:23:24 Join MrZeus_ [0] (~MrZeus@
07:23:37 Quit fs-bluebot (Ping timeout: 264 seconds)
07:25:32 Join MrZeus__ [0] (~MrZeus@
07:25:36 Quit MrZeus (Ping timeout: 240 seconds)
07:27:36 Quit MrZeus_ (Ping timeout: 240 seconds)
07:29:11 Quit Stanley00 ()
07:55:02***Saving seen data "./dancer.seen"
08:32:11 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
08:32:59 Join massiveH [0] (
08:34:36 Join prof_wolfff [0] (
08:40:01 Quit pamaury (Quit: this->disconnect())
08:41:13 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
08:45:42 Join ac_laptop [0] (~ac_laptop@
09:13:13 Quit prof_wolfff (Ping timeout: 260 seconds)
09:34:59 Quit massiveH (Quit: Leaving)
09:55:03***Saving seen data "./dancer.seen"
10:24:38 Join saratoga [0] (
10:25:19saratogathe opus fft needs some work on arm, the non-power-of-2 length means we couldn't use the normal fft which is all assembly
10:29:22speachya while back bilgus did a rebase of our opus code to then-current upstream; is this something that upstream might have improved?
10:30:44speachyIIRC he never merged it because it was a slight overall performance regression (under 1% on the targets/files we were using at the time)
10:31:45speachy(this would have been mid-late 2019, I think)
10:32:15speachymake that Jan 2019
10:33:16 Quit pamaury (Ping timeout: 240 seconds)
10:41:08saratogaspeachy: looks like they added a NEON FFT, but that won't help us on ARMv4/v5
10:41:22saratogai have some profiling data somewhere, the fft was the big hot spot
10:42:40saratogaso i don't think they'll be much difference until that is fixed, and upstream probably isn't going to get optimizations for some 25 year old ARM cores at this point :)
10:44:32 Quit MrZeus__ (Ping timeout: 260 seconds)
10:45:12braewoodssaratoga: is there some way to bring it up to a power of 2?
10:45:24braewoodse.g., pad it with data or something
10:45:33saratogano, the codec does not use power of 2 transforms by design
10:45:48braewoodsi see.
10:46:10braewoodsso what do you need? a FFT that works with arbitrary sizes?
10:47:11saratogafixed point and non-power of 2 sizes
10:47:36saratogai don't think the one they have is bad, but usually these have to be scheduled manually in assembly to get good performance
10:47:50saratogatheres usually also some scope for optimization when you dig into the transform
10:47:59saratogaalgorithmic optimization
10:48:19braewoodsmaybe there's an FFT from some library we could use
10:48:54braewoodsif it matters that much, there may be an implementation that already exists
10:49:15braewoodsit could probably be adapted to rockbox
10:50:07saratogai don't think so
10:50:33saratogafor the other codecs we actually spent a lot of time adapting the ffmpeg one to fixed point and then optimizing it
10:50:52braewoodsso we need a new FFT in asm?
10:51:10saratogafor the more common power of 2 case there was only the libtremor fft (IIRC) and we used that for a long time before coming up with a faster one
10:51:58braewoodsi see
10:52:06saratogathe fft works by factorizing the problem into smaller ffts of shorter length, so depending on the transform size the codec is using some of those factors are called a lot more than others
10:52:12saratogaso ideally you'd want to optimize those
10:52:24braewoodsisn't opus already pretty fast?
10:52:29saratogai should dig up the numbers from back in 2013 when i started digging into this
10:52:55saratogai have a breakdown of how often each factor was used
10:52:55speachy(that gerrit ticket has benchmarks on clip+ and fuze+ (armv4/v5, respectively)
10:53:07speachyno wait, clip+ is v5 nm
10:53:18braewoodsi assume armv4 is the earlier PP?
10:53:43speachyyeah, IIRC our only v4 targets are all PPs
10:53:48speachy(actually v4t)
10:55:21saratogahuh no arm4v benchmarks on the codec performance wiki page
10:55:29speachythe PP500x targets are IMO too pathological performance-wise to really care about, but the 502x should be good.
10:55:35saratogai would just do armv4
10:56:05saratogaarmv5 has some neat stuff added, but its too much work to refactor for such a small gain
10:56:27saratogathe 16 bit multiply instructions in particular
11:02:10speachyhmm. it makes sense to redo that whole page using current builds with the gcc 4.9 toolchain
11:02:53speachyso we have an accurate baseline for further work (eg the optimization flag revisiting that's long overdue..)
11:05:11saratogafor the main codecs the optimization flags shouldn't make too much difference since they spend so much time in the MDCT/FFT code, and that is all one library mostly in assembly (although MIPS is another story...)
11:05:20saratogafor weird codecs who knows
11:05:40braewoodsspeachy: any further talk on the pine stuff?
11:06:15saratogathat reminds me, i really need to find time to get back to
11:06:18speachymy motivation behind the compile flags isn't so much ekeing out more/extra performance but to simpilfy things; get everything using the same global settings except where absolutely necessary.
11:06:32saratogathat was pretty close to working when i got distracted and for mp3 should make a large difference
11:07:13speachybraewoods: no further developments on either side. I've had a PineCube for a month or so now, plus a few more V3s developer boards that are a bit more practical to work with
11:07:30speachystill need to pick up suitable screens and batteries for both
11:07:52braewoodsi saw a usb controlled screen that vocore2 was demoing but i think it's too big
11:08:02speachybut $dayjob qas a lot more demanding of my time and I needed to be away from code tinkering for my what passes for my mental health.
11:08:37speachythe pinecube should be fully mainline supported (by linux) as of 5.10
11:08:53speachyIIRC u-boot has everything needed too in their git master but no release yet
11:08:59braewoodsdidn't you want to make a native RB port for it at some point?
11:09:12braewoodsif nothing else maybe this can turn into a DIY rockbox port for people.
11:10:03braewoodsnot the most space optimal but i guess it's something
11:10:13speachyyes I do, but given that we actualyl have full sources for this thing and the ability to completely define our own rootfs, a hosted port could be pretty darn kick-ass
11:10:27speachy(ie not having to hack around questionable OF decisions)
11:11:03braewoodshow good are 3d printed cases and such?
11:11:11speachyyou get what you pay for. :D
11:11:18braewoodsso they utterly suck
11:11:35speachyyes and no; they only make sense for small-volume (and/or high-margin) stuff
11:11:51 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
11:11:55braewoodswhich this would probably be
11:12:12braewoodseither way, having the software system developed might make this an easier sell to pine
11:12:16speachyIMO the economics don't make sense if we can't reuse an existing case
11:12:29speachy(I think pine shares that opinion)
11:12:53braewoodsfastest way is to do a hosted port for now
11:12:56braewoodsnative would take longer
11:13:28braewoodswhat would be a suitable battery? a rechargeable pouch cell?
11:13:46braewoodsi'd probably want to use 18650 cells during development simply due to better safety
11:13:55braewoodsanother chemistry
11:14:04speachyfor the boards I already have? Sompething that physically plugs into the existing connector.
11:14:06braewoodsnimh or so if you don't need to develop the charging
11:14:16braewoodswhat kind of connector do theyu se
11:14:26speachythey arelady have an AXP192 PMIC that handles all of the charging stuff.
11:14:41braewoodsso probably a pouch cell
11:14:43speachyI don't recall offhand. Pine suggested one
11:15:07braewoodswell from what i've seen of mobile batteries
11:15:11speachythe other board ("V3S Cherry Pi") might be a standard 0.1" pitch header.
11:15:19braewoodswe'd either want one a pouch cell with a JST connector or
11:15:27braewoodsone of those cell phone type batteries
11:15:34braewoodsbetter if we can reuse an existing type
11:16:08speachythe final form factor will determine the battey used. Otherwise one LiPo cell is the same as any other, slight chemistry differences notwithstanding
11:17:07braewoodsi've been learning to build my own battery packs
11:17:45braewoods18650 cells are pretty versatile
11:18:11speachyI have a 18650 cell holder with a .1" header somewhere
11:18:23 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:19:47speachymy time lately has been spent on non-software projects.
11:21:34speachyscreen-wise I intend to pick up a cheapie 4-5" QVGA lcd with a standard 40-pin connector.
11:22:43speachy(ie use the SoC's LCD controller, and QVGA is the most likely target for an actual player screen)
11:23:16braewoodsso TN
11:23:24braewoodsfor final product maybe could use IPS
11:23:32braewoodsbut then
11:23:33speachyactual TN/IPS is an implementation detail that doesn't matter from the SoC's perspective.
11:23:50braewoodspeople don't normally care about the screen on these
11:24:08braewoodsIPS' main benefit is more viewing angle
11:24:18speachyIPS's superior viewing angle is all we'd care about in this context
11:24:31braewoodsfor development kinda irrelevant
11:25:11braewoodsdoes RB support 24-bit screens?
11:25:16braewoodsor just 16-bit color?
11:25:54braewoodsalso occurred to me... this port might have enough resources to do video decoding if one were inclined to write the code for that
11:26:18braewoodsdoes the pinecube has video acceleration?
11:26:19speachyyep, it can handle 24bpp, but that's wasted on our typical screens.
11:26:45speachythere's a full GPU on the V3/V3s SoC, but we'd not use it as anything other than a dumb framebuffer.
11:27:15speachy(unless we want to completely rewrite our UI layer to take advantage of HW compositing)
11:27:35braewoodsprobably not
11:27:38speachy(which admittedly isn't as hard as it first sounds sine that's how it already works internally)
11:29:09braewoodsi'd probably want to use external SD card for pretty much everything
11:29:17braewoodseasily removeable battery
11:29:31braewoodsjust make it easy to repair stuff that is guaranteed to wear out from use
11:29:37speachyanyway. gotta scoot.. groceries to buy and a car part that's holding up reassembly of my main project for the week
11:55:05***Saving seen data "./dancer.seen"
12:15:29 Join alexweissman [0] (
12:30:25 Quit ac_laptop (Ping timeout: 246 seconds)
12:35:43 Quit livvy (Ping timeout: 240 seconds)
12:39:01*_bilgus had to do a 30 mile 4 store round trip just to find a thermostat in stock for my car I was beginning to wonder if anyone even had it
12:53:08 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
12:59:05 Join ac_laptop [0] (~ac_laptop@
13:47:01 Quit pamaury (Ping timeout: 264 seconds)
13:47:15 Join MrZeus__ [0] (~MrZeus@
13:53:04 Quit MrZeus__ (Ping timeout: 240 seconds)
13:53:45 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:794f:ccd9:b4cd:c4b4)
13:55:07***Saving seen data "./dancer.seen"
14:09:24 Quit saratoga (Remote host closed the connection)
14:36:05 Join prof_wolfff [0] (
14:47:27 Quit Galois (Ping timeout: 260 seconds)
15:42:18 Quit Rower (Ping timeout: 260 seconds)
15:55:09***Saving seen data "./dancer.seen"
16:20:45 Join Galois [0] (
16:38:56 Join fs-bluebot [0] (
16:39:05 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
16:40:14 Quit bluebrother^ (Ping timeout: 264 seconds)
16:40:52 Quit fs-bluebot_ (Ping timeout: 256 seconds)
17:35:48 Quit ac_laptop (Ping timeout: 258 seconds)
17:36:36 Join ac_laptop [0] (~ac_laptop@
17:48:13 Quit lebellium (Quit: Leaving)
17:55:10***Saving seen data "./dancer.seen"
18:33:36 Quit prof_wolfff (Ping timeout: 240 seconds)
18:47:58 Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
18:57:37 Join user890104_ [0] (
18:57:44 Quit user890104 (Ping timeout: 268 seconds)
19:19:56 Quit Topy44 (Ping timeout: 240 seconds)
19:48:14 Join Topy44 [0] (
19:53:09 Quit Topy44 (Ping timeout: 272 seconds)
19:55:11***Saving seen data "./dancer.seen"
20:11:33 Quit livvy (Remote host closed the connection)
20:15:13 Join Topy44 [0] (
20:41:53 Quit ZincAlloy (Quit: Leaving.)
21:04:05 Join massiveH [0] (
21:14:58 Quit massiveH (Ping timeout: 272 seconds)
21:41:49 Join massiveH [0] (
21:55:15***Saving seen data "./dancer.seen"
22:30:57 Quit MrZeus (Ping timeout: 260 seconds)
23:32:24 Quit massiveH (Ping timeout: 272 seconds)
23:33:04 Quit ac_laptop (Ping timeout: 260 seconds)
23:35:45 Quit TheSeven (Ping timeout: 258 seconds)
23:36:14 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23:55:19***Saving seen data "./dancer.seen"

Previous day | Next day