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-10-06

00:17:08***Saving seen data "./dancer.seen"
01:40:32 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c9cc:e847:1c24:93c2)
01:44:01 Quit advcomp2019 (Read error: Connection reset by peer)
01:44:41 Quit ZincAlloy (Ping timeout: 245 seconds)
01:58:35 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
02:17:09***Saving seen data "./dancer.seen"
02:39:30sporkthe 'daily development builds' page lists all voice files for the agptek rocker, most for the aigo eros q/k but none for any of the other devices
02:41:07sporkon the linked 'older builds' page, they are all listed though
04:17:12***No seen item changed, no save performed.
04:45:33 Quit johnb2 (Quit: Nettalk6 -
05:57:10MarcAndersenspork, Right now I can see all the voices
06:00:02 Join asaba [0] (~asabas@
06:01:04 Quit asabas (Ping timeout: 252 seconds)
06:07:03 Quit MarcAndersen (Remote host closed the connection)
06:15:28speachyspork: "Please note that generating these new builds takes upwards of a couple of hours, and if you visit this page while builds are in progress you may see it only partially updated.
06:15:30speachyPlease check back later if what you want is missing, or use the 'older builds' links to grab something from a previous daily build.
06:17:14***Saving seen data "./dancer.seen" sayeth the daily build page
07:07:37sporkok then
08:17:16***No seen item changed, no save performed.
08:51:49 Join massiveH [0] (
09:00:35 Join greengameplayer [0] (
09:40:06 Quit greengameplayer (Ping timeout: 245 seconds)
09:40:52 Join greengameplayer [0] (~james@2607:fb90:17ce:dc98:18d3:136:473e:f35c)
09:48:11_bilgusspeachy do we have the admin login on the wiki or could you admin me, I don't know that I have it fully grasped but it doesn't appear to be rocket surgery
09:48:53_bilgusOr maybe thats more hassle if you already got ideas up to you..
09:50:06 Quit greengameplayer (Ping timeout: 245 seconds)
09:53:42speachyI'm not likely to get anything further done until next week. tomorrow I'm off for a long weekend in the woods.
09:59:45 Join greengameplayer [0] (~james@2607:fb90:17ce:dc98:18d3:136:473e:f35c)
10:17:18***Saving seen data "./dancer.seen"
10:17:47 Quit speachy (Quit: WeeChat 3.2)
10:21:33 Quit greengameplayer (Quit: Konversation terminated!)
10:28:33 Quit massiveH (Quit: Leaving)
10:40:42_bilgusbrowser crashed I'll try again tonight I'm trying to get it working in the sandbox first
12:06:47 Join ZincAlloy [0] (
12:11:20 Quit ZincAlloy (Ping timeout: 265 seconds)
12:17:20***Saving seen data "./dancer.seen"
12:38:50 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:74b2:23df:945c:7532)
13:09:50 Quit kirvesAxe (Ping timeout: 260 seconds)
13:09:59 Join kirvesAxe [0] (kirvesaxe@user/kirvesaxe)
13:11:39 Join lebellium [0] (
13:35:40 Join speachy [0] (~speachy@rockbox/developer/speachy)
13:35:40Mode"#rockbox +v speachy" by ChanServ (
14:17:23***Saving seen data "./dancer.seen"
14:45:37 Quit speachy (Quit: Connection closed)
14:46:34_bilgusthat x1000 prescaler amachronic nice catch
15:13:39 Quit unmanbearpig (Ping timeout: 245 seconds)
15:32:43_bilgusI realized with the way that I hash paths to open plugins will cause issues when later we let the .rockbox directory move around
15:34:09_bilgusinstead I think I will start hashing on everything after /.rockbox/
15:36:36_bilgusCureently I'm working on a perl script to generate the hashes at compile time that way I can use that at compile time to run things like the pitch plugin
15:37:32_bilguswith relative path..
15:47:25 Join unmanbearpig [0] (~unmanbear@user/unmanbearpig)
16:17:25***Saving seen data "./dancer.seen"
16:29:04 Join amachronic [0] (~amachroni@user/amachronic)
16:35:30amachronici've written a UASP mass storage driver, it's up on gerrit now if anyone wants to take a look.
16:38:09rb-bluebotBuild Server message: New build round started. Revision 465c216636, 303 builds, 12 clients.
16:46:49rb-bluebotBuild Server message: Build round completed after 520 seconds.
16:46:50rb-bluebotBuild Server message: Revision 465c216636 result: All green
16:49:53braewoodsamachronic: is that the newer usb driver?
16:50:04braewoodsvs BOT
16:50:26amachronicit's improved read perf quite significantly on the m3k / q1. not so much for writes.
16:50:27braewoodshow'd you make that work? last i checked it requires more endpoints on USB 2.0
16:50:45amachronicwell, the x1000 SOC has 9 endpoints or something.
16:50:56braewoodsi see.
16:51:00amachronicUAS only requires one extra in/out endpoint pair vs BOT though.
16:51:14braewoodsbut a lot of our older targets can't use UAS
16:51:22braewoodsso we'll have to keep the BOT driver
16:51:41braewoodsmostly due to their endpoints being limited to 3
16:51:49amachronicyep, I don't intend to replace it
16:52:13braewoodsif this works out though it should probably replace the old driver for supported targets
16:52:50braewoodsi'd suggest just making it a compile time decision myself
16:53:01braewoodsbased on whether the target can even support it
16:53:19braewoodsand treat mass storage everywhere else the same
16:53:39amachronicof course, I have a define to enable it
16:53:43braewoodsit behaves more or less the same as far as the host is concerned
16:53:56braewoodsand UAS is old enough that it's supported pretty much everywhere now
16:54:32amachronicprobably, but eventually I would like to set it up in the backward compatible mode with UAS on an alternate interface.
16:54:57braewoodsfallback to BOT if you can't allocate the extra endpoints needed for UAS?
16:55:26braewoodsthat would probably work even better.
16:55:27amachronicthat, and support non-UAS hosts
16:55:47amachronicit's a standard backwards compatibility thing in the spec but it's just not easy to do with RB's driver model.
16:55:56amachronicit lets non-UASP hosts just use the BOT interface
16:56:10braewoodsi don't consider that essential myself
16:56:10amachronicUASP hosts will see the alternate setting and switch
16:56:37braewoodsnon-UASP hosts in the context of rockbox isn't likely
16:56:53braewoodsmost people are connecting to a PC or similar that should already support UAS
16:57:08amachronicyep. just me being paranoid :)
16:57:36amachronic"i updated rockbox now it doesn't connect to computer"
16:57:37braewoodsthe bigger question is whether the hardware supports it
16:58:24amachronicUSB-wise, you just need one extra IN and one extra OUT endpoint.
16:58:34amachronicI figure most targets which can do USB HID will be able to use it
16:58:56amachronicalthough those which are low on EPs might not be able to do HID+UAS at the same time
16:59:18braewoodsmany targets would struggle to do MTP
16:59:45braewoodsi'm considering adding MTP at some point but it's going to require some more work...
16:59:52braewoodsare those usb driver API changes in yet?
17:00:23amachronicno, speachy was going to review but i don't think he's gotten to it yet
17:00:44amachronicbilgus tested it on a couple of sansas
17:01:12amachronicso what does MTP need that the USB stack is lacking?
17:01:27braewoodsMTP requires 3 endpoints. no real issue there.
17:01:40braewoodseven our weakest targets can handle that.
17:01:58braewoodsthe main issue i saw is MTP detection depends on something our drivers cannot interface with
17:02:15braewoodsthe usb driver decides all the strings and such sent to the host
17:02:32braewoodslibmtp assumes "MTP" will be in one of these and they're hard-coded in rockbox.
17:02:44braewoodsideally we'd only export this string if MTP is actually active
17:02:47braewoodsto avoid confusing the host
17:03:13amachronicthat shouldn't be too hard to add.
17:03:29braewoodsbasically, the ability for active drivers to add their own strings to what the core sends to the host
17:04:02braewoodsmost don't need this but some future drivers may
17:04:04amachronicbasically just adding new string descriptors
17:04:26braewoodsyea, let me dig and see where it currently resides
17:05:42braewoodsMTP detectiong requires an extra string in this list, iirc.
17:06:32braewoodsheh. speachy loved the change i made to the code to handle the usb string literals differently
17:07:07braewoodsthe new toolchain supported unicode string literals so we use those now. easier to read and edit.
17:08:21braewoodsamachronic: maybe we could add a few extra slots to the static array that drivers could append their own descriptors to
17:08:32braewoodswe just need a new way to mark the end
17:08:51braewoodsdon't need to make this incredibly advanced
17:09:53amachronicthat'd work
17:10:42amachronicalthough I think a callback would also work
17:11:14amachronicjust reserving slots in the array is probably far simpler. considering only MTP will need it, at first.
17:14:31braewoodsthe code would need adjusting
17:14:52braewoodsmy original solution was just to add it to the existing table but that has one flaw
17:15:08braewoodsit causes host issues if the MTP driver isn't actually active
17:15:39braewoodsideally it won't be sent unless MTP is actually enabled
17:16:11amachronicyeah so we'd need an enable/disable hook which is getting messy.
17:16:56braewoodsit may be simpler to just reserve a few slots and track the number in use instead of using a hard-coded length check
17:17:12braewoodsand add a function to handle insertion of new string descriptors
17:17:30braewoodsit just needs to be reset when the drivers are unloaded
17:17:37braewoodsor something
17:18:08braewoodsideally the driver would deallocate its string descriptor and the core will shift the remaining pointers down to fill the empty space
17:18:13amachronicI think the main difficulty is the need to know what string gets what index in order to refer to it from other descriptors.
17:18:53braewoodsmaybe a hack will suffice for now.
17:19:19braewoodsjust add an extra one for MTP that's only exposed if MTP is active
17:19:26amachronicsomething similar to set_first_interface() may work
17:19:43braewoodsto date only MTP has proven to need this
17:19:51braewoodsso a hack for just MTP would suffice
17:20:27braewoodsthough now that i think about it
17:20:43braewoodsdo hosts check usb strings that aren't referenced?
17:21:02braewoodsif not we can just leave the extras as dormant or so.
17:21:27amachronici can't see _why_ they would look at them, unless there is a way to get the total number of string descriptors.
17:21:38amachronicdo they have to be contiguous?
17:22:08braewoodsprobably not. from the response code it doesn't send them all at once.
17:22:21braewoodsit sends one descriptor at a time in response to an index value.
17:22:36braewoodsit's only used in one place
17:22:49amachronicand the magic 0xee index for windows' benefit
17:22:51braewoodsonce, to determine the # of entries for determing if the requested index is valid
17:23:05braewoodsand the rest to load data for sending over usb
17:23:12braewoodsit only sends one at a time
17:23:21braewoodsthere's no way to request the actual index range
17:23:34braewoodsso maybe this isn't actually an issue
17:23:58braewoodswe can hard-code the extra strings and if they're only used when MTP is activ
17:24:02braewoodsthere's no problem to solve
17:24:17amachronicseems right to me
17:24:46braewoodsbut for consistency MTP string would have to be present even if not used
17:25:01braewoodsso its index is the same
17:25:37amachronici know that's no problem
17:26:30amachronicyou just need to pass the index to the MTP driver
17:26:57braewoodsor just hard-code so it's always at the same position
17:27:28amachronican enum of all the strings would be ok
17:28:00amachronicenum usb_string_index { MANUFACTURER, PRODUCT, MTP_MAGIC, ... }
17:28:17amachronickeeps it nicely organized
17:28:46braewoodswait that solves my problem
17:28:58braewoodslet me submit this to gerrit
17:31:31rb-bluebotBuild Server message: New build round started. Revision 67d4da5342, 303 builds, 12 clients.
17:34:05 Join Syco54645_ [0] (~frank@
17:36:11 Join speachy [0] (
17:36:11 Quit speachy (Changing host)
17:36:11 Join speachy [0] (~speachy@rockbox/developer/speachy)
17:36:11Mode"#rockbox +v speachy" by ChanServ (
17:36:53speachyamachronic: fwiw I think the USB control patches are good. I've gone through the first 2/3rds but won't be able to look at anythung else until next week (gonna be out in the woods for a few days)
17:38:31Syco54645_way off topic but twitch was breached. probably a good idea to change twitch and amazon passwords as well as enable 2fa for them both. sorry for offtopic just want to keep people safe
17:39:09amachronicspeachy: thanks, take your time. i'm in no rush.
17:39:31rb-bluebotBuild Server message: Build round completed after 480 seconds.
17:39:32rb-bluebotBuild Server message: Revision 67d4da5342 result: All green
17:41:58rb-bluebotBuild Server message: New build round started. Revision 4be81c2385, 303 builds, 12 clients.
17:44:27braewoods g#3892
17:44:30rb-bluebotGerrit review #3892 at : usbstack: Revise usb string descriptor table to use enum values for indices by James Buren
17:44:57braewoodsanyone care to review it? it should be simple to review.
17:45:58amachronicwill do.
17:46:38 Quit ZincAlloy (Quit: Leaving.)
17:47:18 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:74b2:23df:945c:7532)
17:47:18 Quit ZincAlloy (Client Quit)
17:48:48amachronicbraewoods: just one thing missing, update the hardcoded numbers in the descriptor to use the enum values.
17:49:24amachronicand I'll merge it after this build round is done
17:49:50rb-bluebotBuild Server message: Build round completed after 473 seconds.
17:49:51rb-bluebotBuild Server message: Revision 4be81c2385 result: All green
17:51:37braewoodsamachronic: you do realize that's completely superfluous?
17:51:45braewoodsenums start at 0 and count up
17:52:24amachronichaha yes, but I'll do it anyway if you won't :P
17:52:38braewoodsi was trying for the same approach the usb driver setup does
17:53:10amachronicjust for consistency, as we're using enums to avoid hardcoded numbers...
17:54:16braewoodsspeaking of which i see a refinement
17:54:46 Quit lebellium (Quit: Leaving)
17:55:17amachronicsorry braewoods I just realized, I don't mean using explicit = 1, = 2, = 3.
17:55:30amachronicI mean changing those hardcoded numbers in the descriptor to use the enum names.
17:56:11braewoodsamachronic: what do you mean?
17:57:29amachronicsee the comment i added on the patch
17:59:01amachronicok good, thanks. merging now...
17:59:18rb-bluebotBuild Server message: New build round started. Revision c0a59b9a6a, 303 builds, 12 clients.
18:00:45braewoodsi also got the idea to use the last entry as the length
18:00:55braewoodsthat was one last minute thing i added
18:01:07braewoodsit replaced those annoying sizeof hacks
18:01:19braewoodsthey work but less elegant than this
18:02:31braewoodsnow it is more amenable to MTP
18:08:10rb-bluebotBuild Server message: Build round completed after 533 seconds.
18:08:11rb-bluebotBuild Server message: Revision c0a59b9a6a result: All green
18:17:22speachywoo, board's finally green again.
18:17:29***Saving seen data "./dancer.seen"
18:28:56 Join dconrad [0] (~dconrad@
18:30:12dconradamachronic: I figured out why git kept marking that line as changed in the AIC FIFO patch...
18:30:28dconradmy brain just short circuited and assumed both were in the same place, lol
18:31:11amachroniclol it's at least harmless & can be fixed later
18:31:45dconradyeah, I'll just put up a quick patch to fix it
18:34:51dconradbtw, impressive work on the USB driver, I saw the patchsets, I'll try it out sometime soon
18:36:22amachroniccool. although write speeds are still lacking, which is probably the main pain point for anybody using usb.
18:37:26amachronicso i will still probably need to implement some kind of write caching layer, which i was hoping not to do
18:37:39dconradcould it be an sd card driver limitation?
18:38:02amachronicthe big problem turned out to be the SD cards themselves need huge write sizes to perform very well.
18:38:31amachronicthe driver is able to write at 20 MB/sec if you write 512-1024k at a time.
18:38:53dconradthat sounds familiar, something about needing to write an entire block at a time?
18:41:23dconrad g#3893 if you want to make sure it's sane
18:41:25rb-bluebotGerrit review #3893 at : ErosQNative: Remove duplicate play_last_sample() call by Dana Conrad
18:41:30dconradnot exactly much to it
18:41:31rb-bluebotBuild Server message: New build round started. Revision e0468074fe, 303 builds, 12 clients.
18:41:43amachronicthere ya go.
18:41:50dconradthat was fast haha
18:41:59amachronicwas already looking at it :)
18:44:50amachronicit's getting late here so... bye bye.
18:45:00dconradgood night!
18:45:04 Quit amachronic (Quit: amachronic)
18:49:10rb-bluebotBuild Server message: Build round completed after 458 seconds.
18:49:11rb-bluebotBuild Server message: Revision e0468074fe result: All green
18:58:14Syco54645__bilgus: i will have a new e200 soon that i can try flashing with rbutil if we still need to test that route. scared to do something and mess up the one i have currently. i am exhausted from the project at work moving to QA and when I am tired i make pretty bad mistakes. in theory i can grab the BL from the download on the daily page and just flash it on to the one i have in recovery mode. at least i think that would work.
19:01:08 Quit dconrad (Remote host closed the connection)
19:23:39 Join dconrad [0] (~dconrad@
19:24:07_bilgusSyco54645_, No worries Johnb was able to verify it worked in rbutil but he says that you don't need the OF to put the bootloader on
19:24:57_bilgusWe are not sure whats up with yours but I figure you have recovery mode and USB so probably best to leave well enough alone
20:17:30***Saving seen data "./dancer.seen"
20:33:02braewoodsspeachy: i have an unmodified xduoo x3 if you want to release a new bootloader payload to test.
20:33:33speachyright now I'm waiting on test results from the one person who reported a problem with the original bootloader.
20:33:43speachyotherwise the new one seems to WorkFineForMe(tm)
20:33:54speachy(and a couple others too, but none of them had issues before, so...)
20:45:31 Quit dconrad (Remote host closed the connection)
21:13:13 Join dconrad [0] (~dconrad@
21:14:01 Join Kemper [0] (
21:16:36KemperI've been repairing my Sansa(s) for years waiting to get a new MP3 player to use with Rockbox. I see that there's lots of work being done to get more platforms. Thanks to all the devs.
21:18:42braewoodsKemper: are you soliciting advice?
21:19:43KemperYes. I was going to elaborate but my text just disappeared.
21:20:47braewoodswhat are you looking for specifically
21:20:49KemperI looked at the FAQ and the list of latest devices but the list is pretty dated (2008?). The timestamp at the bottom of the page is recent though.
21:21:52braewoodsit's been updated, at least the main one
21:22:51braewoodsxduoo x3 is probably the most recent stable one added
21:23:29braewoodsit's basically a more modern version of the basic features the sansas provided.
21:23:46braewoodsonly problem is it is fairly hard to find on ebay
21:24:05KemperI would like suggestions on a currently available device that I can run Rockbox on. I'll go back to the website and see if I can find the latest list. The list I saw didn't include the recent xduoo x3.
21:24:55braewoodsit's also a function of how much patience you have and how much you're willing to spend
21:25:58KemperI saw that the xduoo x3 is on the list of supported devices but not on the list of currently available devices. Is the xduoo the most recent device and there aren't any others currently available in production?
21:26:22braewoodsKemper: to be frank the list of rockbox stuff still in production is a very short list.
21:26:36braewoodsit's mostly just the fiio m3k and maybe some other ones speachy would know.
21:27:08speachyif you want something that's still in production the list is pretty much limited to the fiio m3k, xduoo x3ii & x20, and the eros q / k (& their clones)
21:27:49speachythe m3k is a ~$60-70 player, the x20 is ~$200, the rest are ~$120.
21:28:47speachythe original x3 is the next most recent; very solid device except for their choice of screen (functionally equivalent to a faster, more capable sansa clip+ in a far, far more robust case)
21:29:11speachythose can be found occasionally on ebay etc still for varying prices.
21:29:45speachybeyond that, your best bet is probably an older "classic" ipod as they can be modded with flash storage and parts are plentiful.
21:30:38braewoodsi bought an xduoo x3 just this month
21:30:48braewoodsthey show up at least once a month that i've seen
21:30:49speachyanything with non-replacable internal flash is aging out.
21:31:04KemperOk. That's good information. It wasn't clear on the page I saw which units were obsolete and which were still current. I'd prefer not to have to resort to ebay. I'd like to buy something new for a change if that's an option.
21:31:05speachy(that killed my last two sansas)
21:31:54speachyso yeah, m3k (not the m3k pro!), shanling q1, xduoo x3ii & x20, eros q, eros k, agptek h3, hifiwalker h2, surfans f20 (also sold as irulu f20)
21:31:57braewoodsKemper: i repair ebay units from time to time. i have a pretty good grasp of the used market. avoid the flash based units, at least the ones that lack external storage.
21:32:10speachyI think that's it for stuff that's still readily available new.
21:32:50braewoodssansa ones usually have sd cards and can last indefinitely if you find some with minimal wear.
21:33:07braewoodsthanks to multiboot
21:33:21braewoodswhich puts all the stress on the sd card
21:33:38KemperI have a bag full of dead Sansas of varying age. I'll check into the other models you guys mentioned.
21:33:54braewoodsKemper: if it must be new, the other option is new old stock. those are rare but show up sometimes.
21:34:51speachyheh, yeah, I have half a dozen busted fuze/fuzev2s too. great devices, but physically... not so much.
21:35:11braewoodsi have several gigabeat S units that i repaired.
21:35:17braewoodsgood condition for their age.
21:35:35speachya shame I didn't keep my fuze+, should have tried to replace the busted screen but the controls were so awful that I was just DONE with it.
21:35:46braewoodsspeachy: you want my fuze+?
21:36:00braewoodsit's a red 4GB model.
21:36:02speachyI'd just add it to the rockbox box o' rockbox
21:36:07KemperI got lucky a couple of times and found a couple of Sansa Clips in unopened packages but I don't think I'll ever get that lucky again.
21:36:34braewoodsi have some clip+ still. barely used 'em.
21:37:51 Quit rb-bluebot (Ping timeout: 268 seconds)
21:38:06 Quit bluebrother (Ping timeout: 250 seconds)
21:38:57KemperI'm unfamiliar with the Fuze+ but I've heard of it. I assume it's fully supported by Rockbox?
21:39:09braewoodsafaik. it's touch based.
21:39:48speachyit is, but other than power +volume the rest of the controls are using a (quite crappy) touchpad
21:39:52 Join bluebrother [0] (~dom@user/bluebrother)
21:40:14speachyeven the OF was only borderline usable.
21:40:48speachyit also didn't have a proper line out, unlike the older fuzes
21:40:48braewoodsmost of the iriver ports are ok but coldfire is so slow
21:41:10KemperMy daily driver for the last few years has been a Sansa Clip (maybe a plus?). I've recently busted some switches off of it and fell back to an older Sansa. I forget the model number at the moment.
21:41:24speachyKemper: you can buy pre-modded ipods that have varying sizes of SD card storage in 'em.
21:41:33speachyKemper: IIRC if it has the sd card, it's the clip+
21:42:20braewoodsspeachy: i'm tempted to say we might have to shed some ports that have become totally unavailable
21:42:37speachyif the maintaience cost becomes a problem, then sure
21:42:52braewoodsthe packard bell vibe... i've *never* seen it available
21:42:58speachyright now though.. it's mostly just the overhead of generating the extra builds.
21:43:20KemperMine must be the clip+ then. It has the sd card. So are most of my dead ones
21:44:31speachythe next most likely to be dropped will be the 2MB RAM targets (IIRC just a handful of _really_ old sansa models)
21:44:58speachy(which IIRC also lack external storage so it's doubtful there are many that still work...)
21:45:33KemperBy the way here's the webpage I was referring to with the "currently available" models:
21:46:37KemperLooks dated to me. No mention of the xduoo, etc.
21:47:16braewoodsi would suggest the xduoo x3 myself. watch ebay or so.
21:50:01KemperOk. Thanks for the help. Will check out these other models and see if I can find any. In the meantime I'll have to bust out the soldering iron and reflow some cracked solder joints. Again, many thanks for everyone who's kept Rockbox going over the years.
21:50:40braewoodsmost xduoo x3s run the 50-100 USD gauntlet
21:50:44braewoodswhen they do show up
21:52:13 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
21:52:21KemperThat's about what I saw Sansas going for at one point. Not a bad price I guess. Haven't checked lately.
21:52:55braewoodsthe xduoo has 2 sd cards, internal storage is just used to boot.
21:54:15KemperIt may be a FAQ but has anyone looked at the Adafruit Feather series of boards (or similar offerings from Sparkfun, etc.) as possible platforms?
21:54:52speachyI don't think they've come up before but I suspect they're _far_ too RAM constrained to be viable.
21:55:41speachybest options are the S2 with the 8MB of external spi-connected PSRAM
21:55:59speachybut the performance of that will be atrocious.
21:56:37KemperI suspected that they might not be powerful enough. It sure would be good to have some open hardware designs available as options for running Rockbox.
21:57:11speachysome are quite underpowered but some should have more than enough raw ooomph for Rockbox
21:58:09speachymicrocontrollers with enough RAM to be viable are going to cost more than a higher-end SoC with far more resources+ram
21:58:20braewoodsit almost feels like we'd be better off writing a port to the pinephone and calling it a day.
21:58:34speachythere already is one, effectively −− the basic SDL port.
21:59:03speachythere's no advantage to doing a native port on that hardware, given its complexity.
22:00:07speachythe pine64 folks have proposed an SoC to be the basis for a rockbox player but it still only has 1MB RAM.
22:00:15braewoodswould be funny if there was some esoteric tiny x86 system we could launch RB as the single application in X or so
22:02:00speachybest bang-for-the-buck would be a custom hat for a RPi Zero, combining good audio, an appropraite display & button matrix, and a battery/charging controller.
22:02:06speachyand a 3d printed case
22:03:08KemperMan. that would be great.
22:03:20speachythe RPi Zero can run circles around everything we have (except the x1000, maybe) and has what, 4-8x the RAM to boot.
22:03:21braewoodsprobably bulky though
22:03:43speachycustom case tooling is the real cost for producing a player.
22:04:09KemperI'd be able to live with bulky for a while
22:04:24braewoodsit would be perfect for a stationary boombox or something lol
22:05:02speachyit could easily be done in somehing that's roughtly the size of the original ipods.
22:05:29speachy(I mean the based-on-rpi thing)
22:05:41braewoodswe might have to use a touchscreen
22:05:51speachybut it would still probably end up costing more than just picking up a pre-modded ipod6g. :)
22:05:54braewoodsjust because of how common they've become and for cost reasons
22:06:09speachythe thing is, if we have to use a touch screen, we might as well not bother.
22:06:25speachythere are plenty of touchscreen-only players out there.
22:07:31speachywhat makes rockbox truly unique is its accessibility.
22:07:43KemperI prefer tactile switches and voice prompts to touch screens for eyes-off operation.
22:07:56speachy(in practical terms: usable without looking at what you're doing)
22:10:11speachyif we're going to build our own device, what we need to aim at are audiobook readers for visually impaired users.
22:11:12speachy(we're 95% of the way there already; the main thing we lack are support for the rich metadata for that market. think stuff like voiced chapter lists, integrated navigation, etc)
22:12:53speachy(And I'm personally all about completely undermining highly proprietary markets)
22:15:40speachyand it so happens that what makes rockbox great for visually impaired folks also greatly benefits those of us that can see.
22:16:12speachyBeing able to control my player without taking my eyes off the road is a win for everyone.
22:17:31***Saving seen data "./dancer.seen"
22:18:38KemperThat's one of my favorite things about Rockbox. I always load the talk files every time a put a new batch of podcasts or music on my device.
22:23:39KemperAnother feature I really like is the scrobbler function. I basically use it for my personal information rather than for upload to one of the music services. I'm probably the only user who's using it that way though.
22:24:21KemperOnce again, thanks for all you folks are doing and I'm looking forward to using Rockbox well into the future despite my current hardware situation. Thanks also for the leads on possible alternate hardware too. Will check in from time to time and see what's happening.
22:53:49 Quit Kemper (Ping timeout: 265 seconds)
23:01:29 Quit dconrad ()
23:44:32Syco54645__bilgus: fine by me. so long as i can update rockbox manually i dont mind. thanks again for fixing that

Previous day | Next day