--- Log for 18.09.120 Server: card.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 20 days and 9 hours ago 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.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.10.33 # 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 # 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 # 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 # so it should be possible 02.18.58 # <_bilgus_> oh sure but it just needs someone who *WANTS* to 02.19.52 # 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 # 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 # Oh. 02.21.10 # I see. 02.21.19 # 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 # 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 # i wasn't even thinking of modifying the bootloaders 02.22.41 # <_bilgus_> you just have to ndef BOOTLOADER 02.22.45 # just trying to make it possible to switch what transfer mode rockbox uses when connected to PC. 02.23.19 # 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 # afaik 02.23.39 # 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 # also because UMS may be necessary to perform upgrades to rockbox and such 02.24.49 # but I would probably want to make MTP filter out system files if at all possible. 02.25.04 # Or just trust people aren't dumb enough to delete their vital files. lol 02.25.08 # <_bilgus_> .rockbox 02.26.08 # _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 # this one expected the whole device to be formated fat32 which i don't know to be possible under windows 02.26.29 # so i used linux to set it up 02.27.08 # 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 # i'll finish rebuilding this mp3 player before I try building rockbox and such. 02.29.21 # i need a development device anyway 02.29.44 # <_bilgus_> in windows you need a 3rd party formatter 02.29.50 # ah. i figured. 02.29.57 # 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 # it was a philips gogear hdd1630 02.30.24 # 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 # i know. most of the devices won't take exfat anyway. 02.31.07 # it may be easier to just use a combination of windows and linux 02.31.10 # to get setup 02.31.26 # <_bilgus_> Ditch windows its all easier in linux 02.31.37 # there's one thing i can't do under linux though 02.31.44 # 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 # no problem. i just use an old PC. 02.32.15 # <_bilgus_> gonna have to go to xp too? 02.32.28 # yea. i reinstalled windows xp on an ancient thing from 2010. 02.32.30 # <_bilgus_> heh yeah been there 02.32.44 # at least the firmware is still available 02.32.48 # 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 # i had to resort to finding WP 10 from winetricks since microsfot doesn't provide it anymore 02.33.13 # WMP* 02.33.20 # the upgrade stuff was tied to WMP 10 02.33.24 # it wouldn't work without it 02.33.28 # main reason i had to use windows xp 02.33.52 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 02.33.57 # interesting the iriver firmware updaters work with modern windows despite their age 02.34.03 # they don't depend on any ancient windows stuff 02.34.06 # evidently 02.34.23 # i was able to do it from windows 7 02.34.32 # someone else did with 8 02.34.51 # _bilgus_: but yea... firmware is about the only reason i still have windows installations. 02.35.06 # i use it do the upgrade and then it goes back into storage. 02.39.33 # _bilgus_: fyi, i also found a source for third party chargers for these older mp3 players that use proprietary connectors. 02.39.52 # e.g., https://www.gomadic.com/iriver-h10-5gb-straight-power-hot-sync-charge-charger-usb-cable.html 02.40.15 # or more accurately 02.40.21 # cables 02.40.45 # that was good find since a lot of the ebay listings don't have the cables anymore 02.41.20 # 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.03.05 # _bilgus_: no idea. 03.03.14 # but i bought some recently. they're still selling. 03.03.39 # they're a modular design. the cable and adapter tip are separate. 03.03.53 # <_bilgus_> ah makes sense 03.04.34 # 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 # so it's actually an upgrade. 03.05.22 # two cables in one so to speak 03.05.34 # it was an odd time 03.05.44 # proprietary connectors on a lot of things before they went fully usb 03.06.32 # 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 # but these are still the older style of 2 ring for stereo audio. 03.40.43 # serious question. 03.40.53 # what is the f-flex connector type mentioned here? 03.40.54 # https://www.rockbox.org/wiki/HardDriveReplacement 03.41.13 # 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 # oh. fun. 03.44.55 # so avoid those mp3 players like the plague. 03.45.09 # 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 # but you'd need an adapter. 03.47.07 # i can't see myself building one. 03.47.54 # <_bilgus_> I bet someone in shenzen has one 03.49.07 # i wonder... 03.49.25 # some of the ones using microdrives include their own adapter ribbon cable 03.49.30 # 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 # Is this a joke? 03.53.29 # https://www.ebay.com/itm/A-RELIC-OF-TECH-The-Apple-iPod-Classic-20GB-Apples-First-iPod/182909336044 03.54.08 # 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 # ok. 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.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.27.32 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:e824:a488:e6b9:98c8) 06.48.08 *** Saving seen data "./dancer.seen" 07.06.09 # _bilgus_: I think I have it working. sysbench churning on it now 07.11.43 # aaand no good. 07.24.47 # okay, maybe. 07.25.05 # g#2750. beware it might eat your cat. 07.50.38 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 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.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.26.14 # 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 # 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.53.49 # <_bilgus_> I feel like unless you really feel like messing with it that those are some pretty damn big gains 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.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.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.01.52 # _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 # but that's probably true about most of the other USB drivers 15.03.46 # 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 # "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 # yeah 15.36.58 # Until we have a non-mass-storage user of the bulk endpoints there's probably nothing further to do. 15.44.05 # 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.01.58 # <_bilgus_> braewood ^ up above might be an mtp endpoint for instance 16.10.10 # aye 16.10.16 # back 16.10.18 # ? 16.10.25 # though you failed to highlight me lol 16.10.27 # and perhaps one day isoc transfers for audio 16.10.47 # that's going to be a pretty hairy bit of usb driver hackery 16.11.20 # ah. 16.11.46 # right. i would like to see if i could optimize MTP for file transfer speeds. 16.12.00 # maybe possible if we have larger buffers 16.12.19 # 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 # 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 # no idea. 16.13.41 # 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 # 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 # 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 # at least when i was doing dd with usb flash drives 16.15.31 # was surprising how much the block size could impact performance 16.15.45 # anywho 16.18.35 # I wouldn't expect mtp to be terribly fast. 16.18.44 # vs mass storage 16.19.03 # I see... i've gotten decent speeds with my smartphone 16.19.10 # so i thought it at least had potential 16.19.46 # anyway i won't know until i try 16.19.56 # my first priority is just getting it to work 16.20.05 # your smartphone probably has a couple times more buffers for mtp usage than any single rockbox target. :) 16.20.13 # lol 16.20.17 # 2G of RAM 16.20.45 # mtp's advantage is non-exclusive access to storage rather than performance. 16.20.51 # 32MB is a fair bit and rockbox has no network stack really so 16.21.06 # i'll see what i can do. 16.21.37 # in userspace i mostly had to care about having buffers large enough for aligned writes 16.21.46 # since it seems to matter somewhat 16.22.04 # i don't know much about the IO Buffers in the kernel 16.22.07 # to be honest 16.22.18 # 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.35.45 Quit Rower (Ping timeout: 258 seconds) 17.47.04 Quit pablocastellanos (Ping timeout: 256 seconds) 17.50.44 # 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.11.30 # Build Server message: Build round completed after 1247 seconds. 18.11.32 # 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.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.48.23 *** Saving seen data "./dancer.seen" 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.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 # until there's no more data to be had. 22.26.09 # <_bilgus_> like every 32 bytes every 1k? 22.26.13 # with DMA, it shouldn't fire more than once. 22.26.24 # per transfer I mean 22.26.44 # <_bilgus_> ah ok 22.27.08 # for large transfers, even in the worst case it would be once per 512 bytes 22.27.43 # 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 # 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 # (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 # there's definitely still room for improvement in that code 22.32.31 # <_bilgus_> ie the talk splash on invalid voice 22.32.33 # yeah, I thought it might be a good idea to voice it. 22.33.16 # 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 # 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 # 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 # I'll probably just attach that patch to the old bug ticket as a better starting point. 22.42.15 # 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 # nope; the USB block has its own DMA engine, courtesy of Mentor 22.43.47 # (for which I am grateful..) 22.43.49 # <_bilgus_> ah just some weird a s 22.44.01 # <_bilgus_> crazy 22.45.04 # 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 # the voice failsafe is fs#13216 btw 22.49.13 # http://www.rockbox.org/tracker/task/13216 Add a failsafe voice prompt for "voice file failed to load" (feature requests, new) 22.50.08 # actually the USB DMA engine is refreshingly simple and bug-free. The USB controller itself is where the headaches come from. 22.53.08 # 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.01.10 # 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 # the detection heuristics are simpler for exfat than fat12/16/32 23.02.53 # (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)