| 00:05:55 | | Quit ac_laptop (Ping timeout: 272 seconds) |
| 00:44:26 | | Quit Oksana (Ping timeout: 244 seconds) |
| 00:47:58 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:09:52 | | Quit pixelma (Quit: .) |
| 01:09:52 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:09:52 | | Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 01:12:42 | | Join amiconn [0] (jens@rockbox/developer/amiconn) |
| 01:12:43 | | Join pixelma [0] (marianne@rockbox/staff/pixelma) |
| 01:22:52 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 01:24:15 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 01:27:32 | | Quit ZincAlloy (Ping timeout: 260 seconds) |
| 01:38:03 | | Quit livvy (Ping timeout: 240 seconds) |
| 01:44:15 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9c96:65a0:6877:70e0) |
| 01:48:38 | | Quit pamaury (Ping timeout: 272 seconds) |
| 01:49:09 | | Quit ZincAlloy (Ping timeout: 272 seconds) |
| 01:58:44 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 01:59:21 | | Join johnb5 [0] (~johnb2@p5b3afe20.dip0.t-ipconnect.de) |
| 02:00 |
| 02:10:33 | braewoods | speachy: I've spend 10+ years developing experience with C in userspace applications, generally Linux. How useful is that to a project like Rockbox since it's more of a kernel than a regular application? I believe it involves what the C standard calls a freestanding implementation instead of the usual hosted ones I'm used to. |
| 02:14:16 | _bilgus_ | essentially rb is its own OS ^ yes but its not too bad actually quite nice coop multitasking though plugins are slightly limited by the API but its pretty expansive |
| 02:17:41 | braewoods | my main interest is in adding MTP support to some degree. I don't like having to always use UMS for trivial data transfers. |
| 02:18:08 | braewoods | i mean many of these devices originally supported MTP in their OF |
| 02:18:14 | _bilgus_ | IOW I doubt you'd have a terrible time getting into the codebase |
| 02:18:18 | braewoods | so it should be possible |
| 02:18:58 | _bilgus_ | oh sure but it just needs someone who *WANTS* to |
| 02:19:52 | braewoods | MTP support would pretty much mean RB could fully replace most OF functionality on what I use at least. |
| 02:20:11 | _bilgus_ | the only thing to be concerned with would be to make sure you don't add it to the bootloaders |
| 02:20:30 | braewoods | why would I want to? i understand UMS is vital to servicing RB at times. |
| 02:21:00 | _bilgus_ | UM NO too many bootloaders are too close to their max |
| 02:21:08 | braewoods | Oh. |
| 02:21:10 | braewoods | I see. |
| 02:21:19 | braewoods | i just don't see any value in MTP in the bootloaders anyway |
| 02:21:30 | _bilgus_ | you'll be at it for weeks trying to add something big like that or have to be extremely selective |
| 02:21:54 | braewoods | I thought of it as an optional addon for every day usage once fully booted. |
| 02:22:03 | _bilgus_ | not saying all bootloaders are maxed or all have a size limit |
| 02:22:14 | _bilgus_ | but esp the SANSAs |
| 02:22:20 | braewoods | i wasn't even thinking of modifying the bootloaders |
| 02:22:41 | _bilgus_ | you just have to ndef BOOTLOADER |
| 02:22:45 | braewoods | just trying to make it possible to switch what transfer mode rockbox uses when connected to PC. |
| 02:23:19 | braewoods | main advantage is you can disconnect at any time |
| 02:23:21 | _bilgus_ | be pretty easy to pop a menu in like 10 loc so no worries there |
| 02:23:22 | braewoods | afaik |
| 02:23:39 | braewoods | the default would still be UMS to retain backwards compatibility |
| 02:24:11 | _bilgus_ | in that case even easier just need to add a setting in 3 files |
| 02:24:34 | _bilgus_ | settings_list settings.c settings.h |
| 02:24:39 | braewoods | also because UMS may be necessary to perform upgrades to rockbox and such |
| 02:24:49 | braewoods | but I would probably want to make MTP filter out system files if at all possible. |
| 02:25:04 | braewoods | Or just trust people aren't dumb enough to delete their vital files. lol |
| 02:25:08 | _bilgus_ | .rockbox |
| 02:26:08 | braewoods | _bilgus_: i found something interesting when rebuilding the firmware for a CF upgrade.. some devices use a partition table and some don't. |
| 02:26:24 | braewoods | this one expected the whole device to be formated fat32 which i don't know to be possible under windows |
| 02:26:29 | braewoods | so i used linux to set it up |
| 02:27:08 | braewoods | still shows up correctly in windows but i don't know how would i format a volume in windows where there's no partition table allowed. |
| 02:27:16 | | Quit johnb5 (Ping timeout: 272 seconds) |
| 02:29:16 | braewoods | i'll finish rebuilding this mp3 player before I try building rockbox and such. |
| 02:29:21 | braewoods | i need a development device anyway |
| 02:29:44 | _bilgus_ | in windows you need a 3rd party formatter |
| 02:29:50 | braewoods | ah. i figured. |
| 02:29:57 | braewoods | i used Linux since I didn't know of any. |
| 02:30:10 | _bilgus_ | I listed some on the forum but I honestly don't remember which worked |
| 02:30:17 | braewoods | it was a philips gogear hdd1630 |
| 02:30:24 | braewoods | that i upgrade to a better CF card |
| 02:30:41 | _bilgus_ | rb wanst fat32 too we don't have a exfat driver |
| 02:30:50 | _bilgus_ | Wants* |
| 02:30:53 | braewoods | i know. most of the devices won't take exfat anyway. |
| 02:31:07 | braewoods | it may be easier to just use a combination of windows and linux |
| 02:31:10 | braewoods | to get setup |
| 02:31:26 | _bilgus_ | Ditch windows its all easier in linux |
| 02:31:37 | braewoods | there's one thing i can't do under linux though |
| 02:31:44 | braewoods | reinstalling the original firmware so the drive is bootable |
| 02:31:46 | _bilgus_ | run in a vm seethe dev guide |
| 02:32:00 | _bilgus_ | ah uses a windows binary |
| 02:32:12 | braewoods | no problem. i just use an old PC. |
| 02:32:15 | _bilgus_ | gonna have to go to xp too? |
| 02:32:28 | braewoods | yea. i reinstalled windows xp on an ancient thing from 2010. |
| 02:32:30 | _bilgus_ | heh yeah been there |
| 02:32:44 | braewoods | at least the firmware is still available |
| 02:32:48 | braewoods | that's more than most can say |
| 02:33:04 | _bilgus_ | I had something that needed win98 that was a shocking difference from what I remembered |
| 02:33:08 | braewoods | i had to resort to finding WP 10 from winetricks since microsfot doesn't provide it anymore |
| 02:33:13 | braewoods | WMP* |
| 02:33:20 | braewoods | the upgrade stuff was tied to WMP 10 |
| 02:33:24 | braewoods | it wouldn't work without it |
| 02:33:28 | braewoods | main reason i had to use windows xp |
| 02:33:52 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 02:33:57 | braewoods | interesting the iriver firmware updaters work with modern windows despite their age |
| 02:34:03 | braewoods | they don't depend on any ancient windows stuff |
| 02:34:06 | braewoods | evidently |
| 02:34:23 | braewoods | i was able to do it from windows 7 |
| 02:34:32 | braewoods | someone else did with 8 |
| 02:34:51 | braewoods | _bilgus_: but yea... firmware is about the only reason i still have windows installations. |
| 02:35:06 | braewoods | i use it do the upgrade and then it goes back into storage. |
| 02:39:33 | braewoods | _bilgus_: fyi, i also found a source for third party chargers for these older mp3 players that use proprietary connectors. |
| 02:39:52 | braewoods | e.g., https://www.gomadic.com/iriver-h10-5gb-straight-power-hot-sync-charge-charger-usb-cable.html |
| 02:40:15 | braewoods | or more accurately |
| 02:40:21 | braewoods | cables |
| 02:40:45 | braewoods | that was good find since a lot of the ebay listings don't have the cables anymore |
| 02:41:20 | braewoods | they were literally the only source i could find for some of the rockbox targets |
| 02:48:02 | *** | Saving seen data "./dancer.seen" |
| 02:53:18 | | Quit Strife89 (Ping timeout: 260 seconds) |
| 02:56:04 | | Join Strife89 [0] (sid399903@gateway/web/irccloud.com/x-sibmydgvhyiknsor) |
| 02:59:24 | _bilgus_ | makes me wonde if they are still making them or just selling whats left |
| 03:00 |
| 03:03:05 | braewoods | _bilgus_: no idea. |
| 03:03:14 | braewoods | but i bought some recently. they're still selling. |
| 03:03:39 | braewoods | they're a modular design. the cable and adapter tip are separate. |
| 03:03:53 | _bilgus_ | ah makes sense |
| 03:04:34 | braewoods | i suspect the adapter is probably connecting the AC adapter and usb together so it can piggy back off USB even if the original had split power. |
| 03:05:15 | braewoods | so it's actually an upgrade. |
| 03:05:22 | braewoods | two cables in one so to speak |
| 03:05:34 | braewoods | it was an odd time |
| 03:05:44 | braewoods | proprietary connectors on a lot of things before they went fully usb |
| 03:06:32 | braewoods | if i was designing an mp3 player in this age i'd use a 3 ring 3.5mm jack. those ones that combine the microphone and headphone. |
| 03:06:47 | braewoods | but these are still the older style of 2 ring for stereo audio. |
| 03:40:43 | braewoods | serious question. |
| 03:40:53 | braewoods | what is the f-flex connector type mentioned here? |
| 03:40:54 | braewoods | https://www.rockbox.org/wiki/HardDriveReplacement |
| 03:41:13 | braewoods | i can find no reference to what it was or is anywhere. |
| 03:42:35 | _bilgus_ | https://www.ebay.com/p/1701429609?iid=333576813125 |
| 03:43:08 | _bilgus_ | its a segate? assuming proprietary |
| 03:44:05 | braewoods | oh. fun. |
| 03:44:55 | braewoods | so avoid those mp3 players like the plague. |
| 03:45:09 | braewoods | there's no common adapter for making them work with modern CF. |
| 03:46:32 | _bilgus_ | https://en.wikipedia.org/wiki/Seagate_ST1 |
| 03:46:50 | _bilgus_ | its probably pretty straight forward still ata |
| 03:47:01 | braewoods | but you'd need an adapter. |
| 03:47:07 | braewoods | i can't see myself building one. |
| 03:47:54 | _bilgus_ | I bet someone in shenzen has one |
| 03:49:07 | braewoods | i wonder... |
| 03:49:25 | braewoods | some of the ones using microdrives include their own adapter ribbon cable |
| 03:49:30 | braewoods | i wonder if it's the same thing. |
| 03:53:24 | _bilgus_ | https://www.seagate.com/support/disc/manuals/external/photo/100375652a.pdf |
| 03:53:26 | braewoods | Is this a joke? |
| 03:53:29 | braewoods | https://www.ebay.com/itm/A-RELIC-OF-TECH-The-Apple-iPod-Classic-20GB-Apples-First-iPod/182909336044 |
| 03:54:08 | braewoods | ah. flex connector. 45 pins. |
| 03:54:10 | _bilgus_ | sec 2.5 |
| 03:54:41 | _bilgus_ | & sec 4.0 |
| 03:55:26 | _bilgus_ | so totally different but the same lol |
| 03:55:58 | _bilgus_ | enjoy yourself i'm out. |
| 03:56:02 | braewoods | ok. |
| 04:00 |
| 04:48:04 | *** | Saving seen data "./dancer.seen" |
| 04:52:57 | | Quit danielp3344 (Quit: killed) |
| 04:53:06 | | Quit SiliconExarch (Quit: killed) |
| 04:53:07 | | Quit blbro[m] (Quit: killed) |
| 04:53:10 | | Quit kadoban (Quit: killed) |
| 05:00 |
| 05:17:28 | | Join SiliconExarch [0] (sewiredci@gateway/shell/matrix.org/x-ecwpfbhjlsvjsbhx) |
| 05:19:19 | | Quit SiliconExarch (Remote host closed the connection) |
| 05:25:41 | | Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-cujetldydfzpmpsd) |
| 05:35:07 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
| 05:50:23 | | Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-jdkdmdayzlobouuw) |
| 05:50:23 | | Join SiliconExarch [0] (sewiredci@gateway/shell/matrix.org/x-dbuajfyqktxnicdw) |
| 05:50:30 | | Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-wqwulyzuluvxuhlx) |
| 05:56:12 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 05:56:40 | | Quit ufdm (Read error: Connection reset by peer) |
| 06:00 |
| 06:27:32 | | Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:e824:a488:e6b9:98c8) |
| 06:48:08 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:06:09 | speachy | _bilgus_: I think I have it working. sysbench churning on it now |
| 07:11:43 | speachy | aaand no good. |
| 07:24:47 | speachy | okay, maybe. |
| 07:25:05 | speachy | g#2750. beware it might eat your cat. |
| 07:50:38 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 08:00 |
| 08:25:12 | | Quit vup (Ping timeout: 265 seconds) |
| 08:28:42 | | Join vup [0] (~~~~@46.101.193.235) |
| 08:37:42 | | Quit olspookishmagus (Quit: All for nothing) |
| 08:40:17 | | Quit massiveH (Quit: Leaving) |
| 08:45:29 | | Quit pamaury (Quit: Konversation terminated!) |
| 08:48:12 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:23:57 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 09:24:32 | | Quit olspookishmagus (Client Quit) |
| 09:25:50 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 10:00 |
| 10:26:14 | speachy | survived sysbench! With this card, using DMA boosed sequential writes by 34% and reads by 43%. |
| 10:33:55 | | Join LambdaCalculus37 [0] (LambdaCalc@gateway/vpn/privateinternetaccess/lambdacalculus37) |
| 10:34:49 | | Quit LambdaCalculus37 (Client Quit) |
| 10:36:43 | | Quit MrZeus (Ping timeout: 272 seconds) |
| 10:39:36 | speachy | I might be able to eke out a few more % on the write side, but it might require completely splitting dma and non-dma code paths. |
| 10:48:13 | *** | Saving seen data "./dancer.seen" |
| 10:50:11 | | Join johnb5 [0] (~johnb2@p5b3afe20.dip0.t-ipconnect.de) |
| 10:53:05 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:55:12 | | Quit johnb5 (Ping timeout: 272 seconds) |
| 11:00 |
| 11:53:49 | _bilgus_ | I feel like unless you really feel like messing with it that those are some pretty damn big gains |
| 12:00 |
| 12:04:06 | | Quit tchan (Quit: WeeChat 2.8) |
| 12:08:43 | | Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) |
| 12:13:19 | | Quit ZincAlloy (Ping timeout: 260 seconds) |
| 12:15:50 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:884b:a452:17a3:c23b) |
| 12:16:18 | _bilgus_ | Seq Wr ^58% Rnd R/W v14% / v13% Seq Rd ^68% over the baseline, Impressive |
| 12:17:35 | _bilgus_ | SR 7.59 SW 5.46 |
| 12:32:05 | | Quit ufdm_ (Quit: Leaving) |
| 12:34:41 | | Join johnb2 [0] (~johnb2@p5b3afe20.dip0.t-ipconnect.de) |
| 12:48:14 | *** | Saving seen data "./dancer.seen" |
| 12:56:46 | | Quit Acou_Bass (Ping timeout: 256 seconds) |
| 12:59:28 | | Join Acou_Bass [0] (~eddie@cpc97736-bolt17-2-0-cust152.10-3.cable.virginm.net) |
| 13:00 |
| 13:00:34 | | Quit johnb2 (Ping timeout: 260 seconds) |
| 13:01:52 | | Quit pamaury (Ping timeout: 272 seconds) |
| 13:12:57 | | Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:a908:a1a:bfc4:249a) |
| 13:41:40 | | Quit MrZeus (Read error: Connection reset by peer) |
| 13:42:29 | | Join johnb5 [0] (~johnb2@p5b3afe20.dip0.t-ipconnect.de) |
| 13:43:09 | | Join MrZeus [0] (~MrZeus@05467834.skybroadband.com) |
| 13:54:13 | | Quit johnb5 (Ping timeout: 260 seconds) |
| 14:00 |
| 14:48:17 | *** | Saving seen data "./dancer.seen" |
| 14:54:02 | | Quit beencubed (Quit: Leaving) |
| 14:57:02 | | Join beencubed [0] (~beencubed@209.131.238.248) |
| 15:00 |
| 15:01:52 | speachy | _bilgus_: so any reason you can think of for me to not commit it? I know there are some corner cases that will break as soon as we try BULK-anything-other-than-mass-storage |
| 15:02:02 | speachy | but that's probably true about most of the other USB drivers |
| 15:03:46 | speachy | the write optimization would be to stage the DMA op prior to the endpoint being posted. It would save us the interrupt overhead of getting started. won't help much on larger transfers but it will definitely help small ones. |
| 15:27:16 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 15:34:49 | _bilgus_ | personally I'd rather fix this than try to do anything with tthe old code |
| 15:35:50 | speachy | "this" ? |
| 15:35:54 | _bilgus_ | not to mention the hold switch makes it pretty easy to verify if its a dma issue |
| 15:36:05 | _bilgus_ | what you have thus far |
| 15:36:22 | speachy | yeah |
| 15:36:58 | speachy | Until we have a non-mass-storage user of the bulk endpoints there's probably nothing further to do. |
| 15:44:05 | speachy | but fwiw the old code worked fine and was quite reliable; it was just slow. |
| 15:45:45 | | Join johnb5 [0] (~johnb2@p5b3afe20.dip0.t-ipconnect.de) |
| 15:47:14 | | Quit Acou_Bass (Quit: ZNC 1.7.5 - https://znc.in) |
| 15:51:24 | | Join Acou_Bass [0] (~eddie@cpc97736-bolt17-2-0-cust152.10-3.cable.virginm.net) |
| 15:58:14 | | Quit Huntereb (Read error: Connection reset by peer) |
| 16:00 |
| 16:01:58 | _bilgus_ | braewood ^ up above might be an mtp endpoint for instance |
| 16:10:10 | speachy | aye |
| 16:10:16 | braewoods | back |
| 16:10:18 | braewoods | ? |
| 16:10:25 | braewoods | though you failed to highlight me lol |
| 16:10:27 | speachy | and perhaps one day isoc transfers for audio |
| 16:10:47 | speachy | that's going to be a pretty hairy bit of usb driver hackery |
| 16:11:20 | braewoods | ah. |
| 16:11:46 | braewoods | right. i would like to see if i could optimize MTP for file transfer speeds. |
| 16:12:00 | braewoods | maybe possible if we have larger buffers |
| 16:12:19 | braewoods | but initially i would focus on getting it to work |
| 16:12:34 | | Quit Acou_Bass (Quit: ZNC 1.7.5 - https://znc.in) |
| 16:12:42 | braewoods | my idea is that not much else would be happening while MTP is operating so it might be possible to allocate more IO buffers to it |
| 16:13:11 | braewoods | no idea. |
| 16:13:41 | braewoods | i don't usually need to think about my IO buffer sizes due to how much caching the kernel does for me |
| 16:13:59 | braewoods | then again Linux usually has MUCH more ram than rockbox has to work with |
| 16:14:36 | | Join Acou_Bass [0] (~eddie@cpc97736-bolt17-2-0-cust152.10-3.cable.virginm.net) |
| 16:14:43 | braewoods | i would probably want something like 128K or so since flash memory usually writes faster if you align at a larger block size |
| 16:15:19 | braewoods | at least when i was doing dd with usb flash drives |
| 16:15:31 | braewoods | was surprising how much the block size could impact performance |
| 16:15:45 | braewoods | anywho |
| 16:18:35 | speachy | I wouldn't expect mtp to be terribly fast. |
| 16:18:44 | speachy | vs mass storage |
| 16:19:03 | braewoods | I see... i've gotten decent speeds with my smartphone |
| 16:19:10 | braewoods | so i thought it at least had potential |
| 16:19:46 | braewoods | anyway i won't know until i try |
| 16:19:56 | braewoods | my first priority is just getting it to work |
| 16:20:05 | speachy | your smartphone probably has a couple times more buffers for mtp usage than any single rockbox target. :) |
| 16:20:13 | braewoods | lol |
| 16:20:17 | braewoods | 2G of RAM |
| 16:20:45 | speachy | mtp's advantage is non-exclusive access to storage rather than performance. |
| 16:20:51 | braewoods | 32MB is a fair bit and rockbox has no network stack really so |
| 16:21:06 | braewoods | i'll see what i can do. |
| 16:21:37 | braewoods | in userspace i mostly had to care about having buffers large enough for aligned writes |
| 16:21:46 | braewoods | since it seems to matter somewhat |
| 16:22:04 | braewoods | i don't know much about the IO Buffers in the kernel |
| 16:22:07 | braewoods | to be honest |
| 16:22:18 | braewoods | i guess for RB they're basically the same since everything is kernel mode |
| 16:28:45 | | Quit Acou_Bass (Quit: ZNC 1.7.5 - https://znc.in) |
| 16:32:01 | | Join Acou_Bass [0] (~eddie@cpc97736-bolt17-2-0-cust152.10-3.cable.virginm.net) |
| 16:45:49 | | Quit johnb5 (Ping timeout: 264 seconds) |
| 16:46:49 | | Quit ZincAlloy (Quit: Leaving.) |
| 16:48:20 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:35:45 | | Quit Rower (Ping timeout: 258 seconds) |
| 17:47:04 | | Quit pablocastellanos (Ping timeout: 256 seconds) |
| 17:50:44 | fs-bluebot_ | Build Server message: New build round started. Revision e404026, 280 builds, 7 clients. |
| 17:51:17 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 18:00 |
| 18:11:30 | fs-bluebot_ | Build Server message: Build round completed after 1247 seconds. |
| 18:11:32 | fs-bluebot_ | Build Server message: Revision e404026 result: All green |
| 18:12:39 | | Quit pamaury (Ping timeout: 260 seconds) |
| 18:17:31 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
| 18:17:40 | | Quit benedikt93 (Ping timeout: 256 seconds) |
| 18:48:22 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:03:30 | | Quit MrZeus (Ping timeout: 272 seconds) |
| 19:56:06 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 19:57:11 | | Join fs-bluebot [0] (~fs-bluebo@55d46ccd.access.ecotel.net) |
| 19:59:24 | | Quit bluebrother^ (Ping timeout: 260 seconds) |
| 19:59:45 | | Quit fs-bluebot_ (Ping timeout: 272 seconds) |
| 20:00 |
| 20:48:23 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:10:17 | | Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) |
| 21:13:19 | | Join tchan [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) |
| 21:13:19 | | Quit tchan (Changing host) |
| 21:13:19 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 21:31:05 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 22:00 |
| 22:22:12 | | Quit cockroach (Quit: leaving) |
| 22:25:41 | _bilgus_ | speachy how many times does the while loop repeat in EPOUT_handler? |
| 22:25:57 | speachy | until there's no more data to be had. |
| 22:26:09 | _bilgus_ | like every 32 bytes every 1k? |
| 22:26:13 | speachy | with DMA, it shouldn't fire more than once. |
| 22:26:24 | speachy | per transfer I mean |
| 22:26:44 | _bilgus_ | ah ok |
| 22:27:08 | speachy | for large transfers, even in the worst case it would be once per 512 bytes |
| 22:27:43 | speachy | unless the host is deliberately sending over data in tiny chunks.... |
| 22:27:54 | _bilgus_ | eh that might be a bit often then like we should move some of those check out of the hot path |
| 22:29:52 | speachy | with DMA going, we shouldn't go throught that loop more than twice for any given logical transfer. |
| 22:30:04 | _bilgus_ | yeah then nbd |
| 22:30:05 | speachy | (once to start the transfer, once when it's done) |
| 22:32:15 | _bilgus_ | I think it was you that brough up wanting to speak InvalidVoice on FS yes? |
| 22:32:22 | speachy | there's definitely still room for improvement in that code |
| 22:32:31 | _bilgus_ | ie the talk splash on invalid voice |
| 22:32:33 | speachy | yeah, I thought it might be a good idea to voice it. |
| 22:33:16 | speachy | but probably a real PITA to implement given how the voice/lang code is structured |
| 22:33:32 | _bilgus_ | I made a talk file in hopes of tricking the voice engine into playing it but sound isn't initialized yet so I may have to move the 'notice' to a bit later |
| 22:36:23 | _bilgus_ | not to mention I still need to add a kill thread for the voice system so I can shut it down after |
| 22:37:05 | speachy | it mighjt be simpler to just make it beeep SOS or something instead. |
| 22:37:45 | _bilgus_ | I debated that tbh |
| 22:38:37 | _bilgus_ | I guess we could make it one of the 'sys_sounds' |
| 22:40:28 | speachy | I got the abandoned mtp code extracted into a single patch. granted it's against a 9-yr-old tree but I had to start somewhere |
| 22:40:49 | speachy | I'll probably just attach that patch to the old bug ticket as a better starting point. |
| 22:42:15 | speachy | and go back to the double-buffered PCM code. The core changes were actually pretty minor; what I'm procrastinating on is rewriting the audio dma code to use descriptor-based DMA instead of the simple oneshot it's using now. |
| 22:43:02 | _bilgus_ | I was wondering if you learned anything applicable to the other DMAs around the codebase |
| 22:43:29 | speachy | nope; the USB block has its own DMA engine, courtesy of Mentor |
| 22:43:47 | speachy | (for which I am grateful..) |
| 22:43:49 | _bilgus_ | ah just some weird a s |
| 22:44:01 | _bilgus_ | crazy |
| 22:45:04 | speachy | the audio dma engine is the same one used by all of ingenic's homegrown stuff −− eg the mass storage controller. |
| 22:45:49 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 22:48:26 | *** | Saving seen data "./dancer.seen" |
| 22:49:11 | speachy | the voice failsafe is fs#13216 btw |
| 22:49:13 | fs-bluebot | http://www.rockbox.org/tracker/task/13216 Add a failsafe voice prompt for "voice file failed to load" (feature requests, new) |
| 22:50:08 | speachy | actually the USB DMA engine is refreshingly simple and bug-free. The USB controller itself is where the headaches come from. |
| 22:53:08 | speachy | and I also want to add code that detects and complains about exfat partitions. |
| 22:59:59 | _bilgus_ | that one seems simple on the surface |
| 23:00 |
| 23:01:10 | speachy | yeah, I know what to look for but there's no real way to report it out of the filesystem probe/mount code. so we'd have to set a flag and splash it later or something. |
| 23:01:41 | speachy | the detection heuristics are simpler for exfat than fat12/16/32 |
| 23:02:53 | speachy | (what I actually want is native exfat. but that's a much more involved undertaking. |
| 23:54:16 | | Quit TheSeven (Ping timeout: 244 seconds) |
| 23:54:29 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
icon identifies that the person is a core developer (has commit access).