| 00:17:08 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 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:00 |
| 02:17:09 | *** | Saving seen data "./dancer.seen" |
| 02:39:30 | spork | the '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:07 | spork | on the linked 'older builds' page, they are all listed though |
| 04:00 |
| 04:17:12 | *** | No seen item changed, no save performed. |
| 04:45:33 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 05:00 |
| 05:57:10 | MarcAndersen | spork, Right now I can see all the voices |
| 06:00 |
| 06:00:02 | | Join asaba [0] (~asabas@103.113.159.250) |
| 06:01:04 | | Quit asabas (Ping timeout: 252 seconds) |
| 06:07:03 | | Quit MarcAndersen (Remote host closed the connection) |
| 06:15:28 | speachy | spork: "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:30 | speachy | Please 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" |
| 06:23:12 | speachy | ...so sayeth the daily build page |
| 07:00 |
| 07:07:37 | spork | ok then |
| 08:00 |
| 08:17:16 | *** | No seen item changed, no save performed. |
| 08:51:49 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:00:35 | | Join greengameplayer [0] (~james@proxy18.d94.org) |
| 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 | _bilgus | speachy 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 | _bilgus | Or maybe thats more hassle if you already got ideas up to you.. |
| 09:50:06 | | Quit greengameplayer (Ping timeout: 245 seconds) |
| 09:53:42 | speachy | I'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:00 |
| 10:17:18 | *** | Saving seen data "./dancer.seen" |
| 10:17:45 | speachy | bbiab |
| 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 | _bilgus | browser crashed I'll try again tonight I'm trying to get it working in the sandbox first |
| 12:00 |
| 12:06:47 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 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:00 |
| 13:09:50 | | Quit kirvesAxe (Ping timeout: 260 seconds) |
| 13:09:59 | | Join kirvesAxe [0] (kirvesaxe@user/kirvesaxe) |
| 13:11:39 | | Join lebellium [0] (~lebellium@2a01cb04012c09000d0085ffcb0230e5.ipv6.abo.wanadoo.fr) |
| 13:35:40 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 13:35:40 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 14:00 |
| 14:17:23 | *** | Saving seen data "./dancer.seen" |
| 14:45:37 | | Quit speachy (Quit: Connection closed) |
| 14:46:34 | _bilgus | that x1000 prescaler amachronic nice catch |
| 15:00 |
| 15:13:39 | | Quit unmanbearpig (Ping timeout: 245 seconds) |
| 15:32:43 | _bilgus | I 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 | _bilgus | instead I think I will start hashing on everything after /.rockbox/ |
| 15:36:36 | _bilgus | Cureently 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 | _bilgus | with relative path.. |
| 15:38:09 | _bilgus | '/rocks/apps/pitch_plugin.rock' |
| 15:47:25 | | Join unmanbearpig [0] (~unmanbear@user/unmanbearpig) |
| 16:00 |
| 16:17:25 | *** | Saving seen data "./dancer.seen" |
| 16:29:04 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 16:35:30 | amachronic | i've written a UASP mass storage driver, it's up on gerrit now if anyone wants to take a look. |
| 16:38:09 | rb-bluebot | Build Server message: New build round started. Revision 465c216636, 303 builds, 12 clients. |
| 16:46:49 | rb-bluebot | Build Server message: Build round completed after 520 seconds. |
| 16:46:50 | rb-bluebot | Build Server message: Revision 465c216636 result: All green |
| 16:49:53 | braewoods | amachronic: is that the newer usb driver? |
| 16:50:04 | braewoods | vs BOT |
| 16:50:07 | amachronic | yeah |
| 16:50:26 | amachronic | it's improved read perf quite significantly on the m3k / q1. not so much for writes. |
| 16:50:27 | braewoods | how'd you make that work? last i checked it requires more endpoints on USB 2.0 |
| 16:50:45 | amachronic | well, the x1000 SOC has 9 endpoints or something. |
| 16:50:56 | braewoods | i see. |
| 16:51:00 | amachronic | UAS only requires one extra in/out endpoint pair vs BOT though. |
| 16:51:14 | braewoods | but a lot of our older targets can't use UAS |
| 16:51:22 | braewoods | so we'll have to keep the BOT driver |
| 16:51:41 | braewoods | mostly due to their endpoints being limited to 3 |
| 16:51:49 | amachronic | yep, I don't intend to replace it |
| 16:52:13 | braewoods | if this works out though it should probably replace the old driver for supported targets |
| 16:52:50 | braewoods | i'd suggest just making it a compile time decision myself |
| 16:53:01 | braewoods | based on whether the target can even support it |
| 16:53:19 | braewoods | and treat mass storage everywhere else the same |
| 16:53:39 | amachronic | of course, I have a define to enable it |
| 16:53:43 | braewoods | it behaves more or less the same as far as the host is concerned |
| 16:53:56 | braewoods | and UAS is old enough that it's supported pretty much everywhere now |
| 16:54:32 | amachronic | probably, but eventually I would like to set it up in the backward compatible mode with UAS on an alternate interface. |
| 16:54:57 | braewoods | fallback to BOT if you can't allocate the extra endpoints needed for UAS? |
| 16:55:26 | braewoods | that would probably work even better. |
| 16:55:27 | amachronic | that, and support non-UAS hosts |
| 16:55:47 | amachronic | it's a standard backwards compatibility thing in the spec but it's just not easy to do with RB's driver model. |
| 16:55:56 | amachronic | it lets non-UASP hosts just use the BOT interface |
| 16:56:10 | braewoods | i don't consider that essential myself |
| 16:56:10 | amachronic | UASP hosts will see the alternate setting and switch |
| 16:56:37 | braewoods | non-UASP hosts in the context of rockbox isn't likely |
| 16:56:53 | braewoods | most people are connecting to a PC or similar that should already support UAS |
| 16:57:08 | amachronic | yep. just me being paranoid :) |
| 16:57:36 | amachronic | "i updated rockbox now it doesn't connect to computer" |
| 16:57:37 | braewoods | the bigger question is whether the hardware supports it |
| 16:58:24 | amachronic | USB-wise, you just need one extra IN and one extra OUT endpoint. |
| 16:58:34 | amachronic | I figure most targets which can do USB HID will be able to use it |
| 16:58:56 | amachronic | although those which are low on EPs might not be able to do HID+UAS at the same time |
| 16:59:18 | braewoods | many targets would struggle to do MTP |
| 16:59:45 | braewoods | i'm considering adding MTP at some point but it's going to require some more work... |
| 16:59:52 | braewoods | are those usb driver API changes in yet? |
| 17:00 |
| 17:00:23 | amachronic | no, speachy was going to review but i don't think he's gotten to it yet |
| 17:00:44 | amachronic | bilgus tested it on a couple of sansas |
| 17:01:12 | amachronic | so what does MTP need that the USB stack is lacking? |
| 17:01:27 | braewoods | MTP requires 3 endpoints. no real issue there. |
| 17:01:40 | braewoods | even our weakest targets can handle that. |
| 17:01:58 | braewoods | the main issue i saw is MTP detection depends on something our drivers cannot interface with |
| 17:02:15 | braewoods | the usb driver decides all the strings and such sent to the host |
| 17:02:32 | braewoods | libmtp assumes "MTP" will be in one of these and they're hard-coded in rockbox. |
| 17:02:44 | braewoods | ideally we'd only export this string if MTP is actually active |
| 17:02:47 | braewoods | to avoid confusing the host |
| 17:03:13 | amachronic | that shouldn't be too hard to add. |
| 17:03:29 | braewoods | basically, the ability for active drivers to add their own strings to what the core sends to the host |
| 17:04:02 | braewoods | most don't need this but some future drivers may |
| 17:04:04 | amachronic | basically just adding new string descriptors |
| 17:04:26 | braewoods | yea, let me dig and see where it currently resides |
| 17:05:32 | braewoods | https://github.com/Rockbox/rockbox/blob/master/firmware/usbstack/usb_core.c#L144 |
| 17:05:42 | braewoods | MTP detectiong requires an extra string in this list, iirc. |
| 17:06:32 | braewoods | heh. speachy loved the change i made to the code to handle the usb string literals differently |
| 17:07:07 | braewoods | the new toolchain supported unicode string literals so we use those now. easier to read and edit. |
| 17:08:21 | braewoods | amachronic: maybe we could add a few extra slots to the static array that drivers could append their own descriptors to |
| 17:08:32 | braewoods | we just need a new way to mark the end |
| 17:08:51 | braewoods | don't need to make this incredibly advanced |
| 17:09:53 | amachronic | that'd work |
| 17:10:42 | amachronic | although I think a callback would also work |
| 17:11:14 | amachronic | just reserving slots in the array is probably far simpler. considering only MTP will need it, at first. |
| 17:14:31 | braewoods | the code would need adjusting |
| 17:14:52 | braewoods | my original solution was just to add it to the existing table but that has one flaw |
| 17:15:08 | braewoods | it causes host issues if the MTP driver isn't actually active |
| 17:15:39 | braewoods | ideally it won't be sent unless MTP is actually enabled |
| 17:16:11 | amachronic | yeah so we'd need an enable/disable hook which is getting messy. |
| 17:16:56 | braewoods | it 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:12 | braewoods | and add a function to handle insertion of new string descriptors |
| 17:17:30 | braewoods | it just needs to be reset when the drivers are unloaded |
| 17:17:37 | braewoods | or something |
| 17:18:08 | braewoods | ideally the driver would deallocate its string descriptor and the core will shift the remaining pointers down to fill the empty space |
| 17:18:13 | amachronic | I 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:53 | braewoods | maybe a hack will suffice for now. |
| 17:19:19 | braewoods | just add an extra one for MTP that's only exposed if MTP is active |
| 17:19:26 | amachronic | something similar to set_first_interface() may work |
| 17:19:43 | braewoods | to date only MTP has proven to need this |
| 17:19:51 | braewoods | so a hack for just MTP would suffice |
| 17:20:07 | braewoods | still |
| 17:20:27 | braewoods | though now that i think about it |
| 17:20:43 | braewoods | do hosts check usb strings that aren't referenced? |
| 17:21:02 | braewoods | if not we can just leave the extras as dormant or so. |
| 17:21:27 | amachronic | i can't see _why_ they would look at them, unless there is a way to get the total number of string descriptors. |
| 17:21:38 | amachronic | do they have to be contiguous? |
| 17:22:08 | braewoods | probably not. from the response code it doesn't send them all at once. |
| 17:22:21 | braewoods | it sends one descriptor at a time in response to an index value. |
| 17:22:36 | braewoods | it's only used in one place |
| 17:22:49 | amachronic | and the magic 0xee index for windows' benefit |
| 17:22:51 | braewoods | once, to determine the # of entries for determing if the requested index is valid |
| 17:23:05 | braewoods | and the rest to load data for sending over usb |
| 17:23:12 | braewoods | it only sends one at a time |
| 17:23:21 | braewoods | there's no way to request the actual index range |
| 17:23:34 | braewoods | so maybe this isn't actually an issue |
| 17:23:58 | braewoods | we can hard-code the extra strings and if they're only used when MTP is activ |
| 17:24:02 | braewoods | there's no problem to solve |
| 17:24:17 | amachronic | seems right to me |
| 17:24:46 | braewoods | but for consistency MTP string would have to be present even if not used |
| 17:25:01 | braewoods | so its index is the same |
| 17:25:37 | amachronic | i know that's no problem |
| 17:26:30 | amachronic | you just need to pass the index to the MTP driver |
| 17:26:57 | braewoods | or just hard-code so it's always at the same position |
| 17:27:28 | amachronic | an enum of all the strings would be ok |
| 17:28:00 | amachronic | enum usb_string_index { MANUFACTURER, PRODUCT, MTP_MAGIC, ... } |
| 17:28:17 | amachronic | keeps it nicely organized |
| 17:28:46 | braewoods | wait that solves my problem |
| 17:28:49 | braewoods | LOL |
| 17:28:58 | braewoods | let me submit this to gerrit |
| 17:31:31 | rb-bluebot | Build Server message: New build round started. Revision 67d4da5342, 303 builds, 12 clients. |
| 17:34:05 | | Join Syco54645_ [0] (~frank@76.125.141.118) |
| 17:36:11 | | Join speachy [0] (~speachy@taster.shaftnet.org) |
| 17:36:11 | | Quit speachy (Changing host) |
| 17:36:11 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 17:36:11 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 17:36:53 | speachy | amachronic: 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:31 | Syco54645_ | 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:09 | amachronic | speachy: thanks, take your time. i'm in no rush. |
| 17:39:31 | rb-bluebot | Build Server message: Build round completed after 480 seconds. |
| 17:39:32 | rb-bluebot | Build Server message: Revision 67d4da5342 result: All green |
| 17:41:58 | rb-bluebot | Build Server message: New build round started. Revision 4be81c2385, 303 builds, 12 clients. |
| 17:44:27 | braewoods | g#3892 |
| 17:44:30 | rb-bluebot | Gerrit review #3892 at https://gerrit.rockbox.org/r/c/rockbox/+/3892 : usbstack: Revise usb string descriptor table to use enum values for indices by James Buren |
| 17:44:57 | braewoods | anyone care to review it? it should be simple to review. |
| 17:45:58 | amachronic | will 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:48 | amachronic | braewoods: just one thing missing, update the hardcoded numbers in the descriptor to use the enum values. |
| 17:49:24 | amachronic | and I'll merge it after this build round is done |
| 17:49:50 | rb-bluebot | Build Server message: Build round completed after 473 seconds. |
| 17:49:51 | rb-bluebot | Build Server message: Revision 4be81c2385 result: All green |
| 17:51:37 | braewoods | amachronic: you do realize that's completely superfluous? |
| 17:51:45 | braewoods | enums start at 0 and count up |
| 17:52:24 | amachronic | haha yes, but I'll do it anyway if you won't :P |
| 17:52:38 | braewoods | i was trying for the same approach the usb driver setup does |
| 17:53:10 | amachronic | just for consistency, as we're using enums to avoid hardcoded numbers... |
| 17:53:54 | braewoods | https://github.com/Rockbox/rockbox/blob/master/firmware/export/usb.h |
| 17:54:16 | braewoods | speaking of which i see a refinement |
| 17:54:18 | braewoods | sec |
| 17:54:46 | | Quit lebellium (Quit: Leaving) |
| 17:55:17 | amachronic | sorry braewoods I just realized, I don't mean using explicit = 1, = 2, = 3. |
| 17:55:30 | amachronic | I mean changing those hardcoded numbers in the descriptor to use the enum names. |
| 17:56:11 | braewoods | amachronic: what do you mean? |
| 17:56:28 | braewoods | oh |
| 17:57:29 | amachronic | see the comment i added on the patch |
| 17:58:00 | amachronic | https://github.com/Rockbox/rockbox/blob/master/firmware/usbstack/usb_core.c#L93 |
| 17:58:20 | braewoods | pushed |
| 17:59:01 | amachronic | ok good, thanks. merging now... |
| 17:59:18 | rb-bluebot | Build Server message: New build round started. Revision c0a59b9a6a, 303 builds, 12 clients. |
| 18:00 |
| 18:00:45 | braewoods | i also got the idea to use the last entry as the length |
| 18:00:55 | braewoods | that was one last minute thing i added |
| 18:01:07 | braewoods | it replaced those annoying sizeof hacks |
| 18:01:19 | braewoods | they work but less elegant than this |
| 18:02:31 | braewoods | now it is more amenable to MTP |
| 18:08:10 | rb-bluebot | Build Server message: Build round completed after 533 seconds. |
| 18:08:11 | rb-bluebot | Build Server message: Revision c0a59b9a6a result: All green |
| 18:17:22 | speachy | woo, board's finally green again. |
| 18:17:29 | *** | Saving seen data "./dancer.seen" |
| 18:28:56 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 18:30:12 | dconrad | amachronic: I figured out why git kept marking that line as changed in the AIC FIFO patch... |
| 18:30:28 | dconrad | my brain just short circuited and assumed both were in the same place, lol |
| 18:30:35 | dconrad | oops |
| 18:31:11 | amachronic | lol it's at least harmless & can be fixed later |
| 18:31:45 | dconrad | yeah, I'll just put up a quick patch to fix it |
| 18:34:51 | dconrad | btw, impressive work on the USB driver, I saw the patchsets, I'll try it out sometime soon |
| 18:36:22 | amachronic | cool. although write speeds are still lacking, which is probably the main pain point for anybody using usb. |
| 18:37:26 | amachronic | so i will still probably need to implement some kind of write caching layer, which i was hoping not to do |
| 18:37:39 | dconrad | could it be an sd card driver limitation? |
| 18:38:02 | amachronic | the big problem turned out to be the SD cards themselves need huge write sizes to perform very well. |
| 18:38:31 | amachronic | the driver is able to write at 20 MB/sec if you write 512-1024k at a time. |
| 18:38:53 | dconrad | that sounds familiar, something about needing to write an entire block at a time? |
| 18:41:23 | dconrad | g#3893 if you want to make sure it's sane |
| 18:41:25 | rb-bluebot | Gerrit review #3893 at https://gerrit.rockbox.org/r/c/rockbox/+/3893 : ErosQNative: Remove duplicate play_last_sample() call by Dana Conrad |
| 18:41:30 | dconrad | not exactly much to it |
| 18:41:31 | rb-bluebot | Build Server message: New build round started. Revision e0468074fe, 303 builds, 12 clients. |
| 18:41:43 | amachronic | there ya go. |
| 18:41:50 | dconrad | that was fast haha |
| 18:41:58 | dconrad | thanks |
| 18:41:59 | amachronic | was already looking at it :) |
| 18:44:50 | amachronic | it's getting late here so... bye bye. |
| 18:45:00 | dconrad | good night! |
| 18:45:04 | | Quit amachronic (Quit: amachronic) |
| 18:49:10 | rb-bluebot | Build Server message: Build round completed after 458 seconds. |
| 18:49:11 | rb-bluebot | Build Server message: Revision e0468074fe result: All green |
| 18:58:14 | Syco54645_ | _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:00 |
| 19:01:08 | | Quit dconrad (Remote host closed the connection) |
| 19:23:39 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 19:24:07 | _bilgus | Syco54645_, 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 | _bilgus | We 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:00 |
| 20:17:30 | *** | Saving seen data "./dancer.seen" |
| 20:33:02 | braewoods | speachy: i have an unmodified xduoo x3 if you want to release a new bootloader payload to test. |
| 20:33:33 | speachy | right now I'm waiting on test results from the one person who reported a problem with the original bootloader. |
| 20:33:43 | speachy | otherwise the new one seems to WorkFineForMe(tm) |
| 20:33:54 | speachy | (and a couple others too, but none of them had issues before, so...) |
| 20:45:31 | | Quit dconrad (Remote host closed the connection) |
| 21:00 |
| 21:13:13 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:14:01 | | Join Kemper [0] (~Kemper@097-106-127-245.res.spectrum.com) |
| 21:16:36 | Kemper | I'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:42 | braewoods | Kemper: are you soliciting advice? |
| 21:19:43 | Kemper | Yes. I was going to elaborate but my text just disappeared. |
| 21:20:47 | braewoods | what are you looking for specifically |
| 21:20:49 | Kemper | I 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:52 | braewoods | it's been updated, at least the main one |
| 21:22:51 | braewoods | xduoo x3 is probably the most recent stable one added |
| 21:23:29 | braewoods | it's basically a more modern version of the basic features the sansas provided. |
| 21:23:46 | braewoods | only problem is it is fairly hard to find on ebay |
| 21:24:05 | Kemper | I 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:38 | braewoods | it' |
| 21:24:55 | braewoods | it's also a function of how much patience you have and how much you're willing to spend |
| 21:25:58 | Kemper | I 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:22 | braewoods | Kemper: to be frank the list of rockbox stuff still in production is a very short list. |
| 21:26:36 | braewoods | it's mostly just the fiio m3k and maybe some other ones speachy would know. |
| 21:27:08 | speachy | if 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:49 | speachy | the m3k is a ~$60-70 player, the x20 is ~$200, the rest are ~$120. |
| 21:28:47 | speachy | the 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:11 | speachy | those can be found occasionally on ebay etc still for varying prices. |
| 21:29:45 | speachy | beyond that, your best bet is probably an older "classic" ipod as they can be modded with flash storage and parts are plentiful. |
| 21:30:38 | braewoods | i bought an xduoo x3 just this month |
| 21:30:48 | braewoods | they show up at least once a month that i've seen |
| 21:30:49 | speachy | anything with non-replacable internal flash is aging out. |
| 21:31:04 | Kemper | Ok. 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:05 | speachy | (that killed my last two sansas) |
| 21:31:54 | speachy | so 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:57 | braewoods | Kemper: 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:10 | speachy | I think that's it for stuff that's still readily available new. |
| 21:32:50 | braewoods | sansa ones usually have sd cards and can last indefinitely if you find some with minimal wear. |
| 21:33:07 | braewoods | thanks to multiboot |
| 21:33:21 | braewoods | which puts all the stress on the sd card |
| 21:33:38 | Kemper | I have a bag full of dead Sansas of varying age. I'll check into the other models you guys mentioned. |
| 21:33:54 | braewoods | Kemper: if it must be new, the other option is new old stock. those are rare but show up sometimes. |
| 21:34:51 | speachy | heh, yeah, I have half a dozen busted fuze/fuzev2s too. great devices, but physically... not so much. |
| 21:35:11 | braewoods | i have several gigabeat S units that i repaired. |
| 21:35:17 | braewoods | good condition for their age. |
| 21:35:35 | speachy | a 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:46 | braewoods | speachy: you want my fuze+? |
| 21:36:00 | braewoods | it's a red 4GB model. |
| 21:36:02 | speachy | I'd just add it to the rockbox box o' rockbox |
| 21:36:07 | Kemper | I 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:34 | braewoods | i 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:57 | Kemper | I'm unfamiliar with the Fuze+ but I've heard of it. I assume it's fully supported by Rockbox? |
| 21:39:09 | braewoods | afaik. it's touch based. |
| 21:39:48 | speachy | it 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:14 | speachy | even the OF was only borderline usable. |
| 21:40:48 | speachy | it also didn't have a proper line out, unlike the older fuzes |
| 21:40:48 | braewoods | most of the iriver ports are ok but coldfire is so slow |
| 21:41:10 | Kemper | My 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:24 | speachy | Kemper: you can buy pre-modded ipods that have varying sizes of SD card storage in 'em. |
| 21:41:33 | speachy | Kemper: IIRC if it has the sd card, it's the clip+ |
| 21:42:20 | braewoods | speachy: i'm tempted to say we might have to shed some ports that have become totally unavailable |
| 21:42:37 | speachy | if the maintaience cost becomes a problem, then sure |
| 21:42:52 | braewoods | the packard bell vibe... i've *never* seen it available |
| 21:42:58 | speachy | right now though.. it's mostly just the overhead of generating the extra builds. |
| 21:43:20 | Kemper | Mine must be the clip+ then. It has the sd card. So are most of my dead ones |
| 21:44:31 | speachy | the next most likely to be dropped will be the 2MB RAM targets (IIRC just a handful of _really_ old sansa models) |
| 21:44:58 | speachy | (which IIRC also lack external storage so it's doubtful there are many that still work...) |
| 21:45:33 | Kemper | By the way here's the webpage I was referring to with the "currently available" models: https://www.rockbox.org/wiki/BuyersGuide |
| 21:46:21 | braewoods | outdated |
| 21:46:37 | Kemper | Looks dated to me. No mention of the xduoo, etc. |
| 21:47:16 | braewoods | i would suggest the xduoo x3 myself. watch ebay or so. |
| 21:50:01 | Kemper | Ok. 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:40 | braewoods | most xduoo x3s run the 50-100 USD gauntlet |
| 21:50:44 | braewoods | when they do show up |
| 21:52:13 | | Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility) |
| 21:52:21 | Kemper | That's about what I saw Sansas going for at one point. Not a bad price I guess. Haven't checked lately. |
| 21:52:55 | braewoods | the xduoo has 2 sd cards, internal storage is just used to boot. |
| 21:54:15 | Kemper | It 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:52 | speachy | I don't think they've come up before but I suspect they're _far_ too RAM constrained to be viable. |
| 21:55:41 | speachy | best options are the S2 with the 8MB of external spi-connected PSRAM |
| 21:55:59 | speachy | but the performance of that will be atrocious. |
| 21:56:37 | Kemper | I 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:11 | speachy | some are quite underpowered but some should have more than enough raw ooomph for Rockbox |
| 21:58:09 | speachy | microcontrollers with enough RAM to be viable are going to cost more than a higher-end SoC with far more resources+ram |
| 21:58:20 | braewoods | it almost feels like we'd be better off writing a port to the pinephone and calling it a day. |
| 21:58:34 | speachy | there already is one, effectively −− the basic SDL port. |
| 21:59:03 | speachy | there's no advantage to doing a native port on that hardware, given its complexity. |
| 22:00 |
| 22:00:07 | speachy | the pine64 folks have proposed an SoC to be the basis for a rockbox player but it still only has 1MB RAM. |
| 22:00:15 | braewoods | would be funny if there was some esoteric tiny x86 system we could launch RB as the single application in X or so |
| 22:02:00 | speachy | best 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:06 | speachy | and a 3d printed case |
| 22:03:08 | Kemper | Man. that would be great. |
| 22:03:20 | speachy | the RPi Zero can run circles around everything we have (except the x1000, maybe) and has what, 4-8x the RAM to boot. |
| 22:03:21 | braewoods | probably bulky though |
| 22:03:24 | speachy | yep. |
| 22:03:43 | speachy | custom case tooling is the real cost for producing a player. |
| 22:04:09 | Kemper | I'd be able to live with bulky for a while |
| 22:04:24 | braewoods | it would be perfect for a stationary boombox or something lol |
| 22:05:02 | speachy | it could easily be done in somehing that's roughtly the size of the original ipods. |
| 22:05:29 | speachy | (I mean the based-on-rpi thing) |
| 22:05:41 | braewoods | we might have to use a touchscreen |
| 22:05:51 | speachy | but it would still probably end up costing more than just picking up a pre-modded ipod6g. :) |
| 22:05:54 | braewoods | just because of how common they've become and for cost reasons |
| 22:06:09 | speachy | the thing is, if we have to use a touch screen, we might as well not bother. |
| 22:06:25 | speachy | there are plenty of touchscreen-only players out there. |
| 22:07:31 | speachy | what makes rockbox truly unique is its accessibility. |
| 22:07:43 | Kemper | I prefer tactile switches and voice prompts to touch screens for eyes-off operation. |
| 22:07:56 | speachy | (in practical terms: usable without looking at what you're doing) |
| 22:08:16 | Kemper | Exactly |
| 22:10:11 | speachy | if we're going to build our own device, what we need to aim at are audiobook readers for visually impaired users. |
| 22:11:12 | speachy | (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:53 | speachy | (And I'm personally all about completely undermining highly proprietary markets) |
| 22:13:22 | Kemper | Amen |
| 22:15:40 | speachy | and it so happens that what makes rockbox great for visually impaired folks also greatly benefits those of us that can see. |
| 22:16:12 | speachy | Being 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:38 | Kemper | That'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:39 | Kemper | Another 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:21 | Kemper | Once 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:00 |
| 23:01:29 | | Quit dconrad () |
| 23:44:32 | Syco54645_ | _bilgus: fine by me. so long as i can update rockbox manually i dont mind. thanks again for fixing that |
icon identifies that the person is a core developer (has commit access).