| 00:17 | RexOrCine | left the channel |
| 00:17 | RexOrCine1 | joined the channel |
| 03:57 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 03:57 | Bertl_oO | changed nick to: Bertl_zZ
|
| 05:13 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 06:36 | mumptai | joined the channel |
| 09:37 | mumptai | left the channel |
| 11:58 | illwieckz | left the channel |
| 11:58 | illwieckz | joined the channel |
| 12:00 | Bertl_zZ | changed nick to: Bertl
|
| 12:00 | Bertl | morning folks!
|
| 12:44 | kbeckmann | just wanted to let you know that i was able to run https://github.com/apertus-open-source-cinema/ft60x-rs on my ft600 as well (just had to change the PID), and it does indeed use very little cpu resources. great!
|
| 12:45 | kbeckmann | s/on/with/
|
| 12:48 | vup | kbeckmann: very nice
|
| 12:49 | kbeckmann | as for throughput, i get just like with the binary drivers, around 180 MB/s in 245 mode.
|
| 12:50 | miek | ooh it's in rust, nice. i wrote a viewer for thermal imaging data a while back using libusb-rs, but it wasn't great to work with. i'll have to check out that rusb crate!
|
| 12:54 | vup | miek: rusb is essentially a continuation of libusb-rs and thus very much the same, the only advantage is, that there is a old version that supports async transfers
|
| 12:55 | vup | they have remove async transfers again in the newer versions tho
|
| 12:58 | Bertl | kbeckmann: usb performance largely depends on the infrastructure, i.e. controller, hubs, cables
|
| 12:59 | kbeckmann | well, in this case i don't have much connected and it's connected straight into the computer (no hub in between). and the numbers seem to scale 2x with yours, you got 360 right?
|
| 13:00 | kbeckmann | would be fun to try out 60x mode but i haven't done that yet.
|
| 13:00 | Bertl | there could be a bunch of hubs in your computer as well
|
| 13:00 | kbeckmann | sure
|
| 13:00 | Bertl | and the controller might be badly supported
|
| 13:01 | Bertl | s/badly/not well/
|
| 13:01 | vup | kbeckmann: well if you try out 60x mode and it gets higher throughput we might be motivated to add support for that to the rust driver aswell :)
|
| 13:02 | kbeckmann | i'll see if i get around to it. if i do i will of course keep you posted!
|
| 13:03 | kbeckmann | it would be nice to see a schematic of the mainboard of my computer.. seems there is a hub internally after all. annoying :). guess i have to try all the ports until i find a "pure" one?
|
| 13:10 | Bertl | might not be there at all
|
| 13:11 | Bertl | in my experience, the best solution is to have a dedicated controller card
|
| 13:11 | Bertl | (they are available for PCs and Laptops) but of course that complicates things
|
| 13:12 | Bertl | also, if you have one of those (red?) usb 3.2 ports, those are typically directly connected to a controller
|
| 13:14 | BAndiT1983 | are 3.2 red now? as 3.1 were blue
|
| 13:14 | Bertl | I think the red is not official, but I've seen a bunch of them
|
| 13:14 | Bertl | similar to the yellow ones for charging/always on
|
| 13:15 | BAndiT1983 | ah, ok, someone mentioned it also -> https://www.quora.com/What-is-the-red-colored-USB-port-of-a-motherboard
|
| 13:16 | Bertl | ah, yes, USB 3.1 Gen 2 is what I meant
|
| 13:35 | illwieckz | left the channel |
| 13:35 | illwieckz | joined the channel |
| 14:20 | illwieckz | left the channel |
| 14:52 | thiblahute__ | joined the channel |
| 15:04 | kbeckmann | hum, weird. found a red port and this doesn't seem to work at all. using the official lib stalls, and the rust codes asserts on src/ft60x.rs:103:33
|
| 15:06 | BAndiT1983 | failing handshake?
|
| 15:06 | BAndiT1983 | either check dmesg or for more hardcore version try wireshark USB sniffing
|
| 15:07 | kbeckmann | thanks, will try wireshark
|
| 15:07 | kbeckmann | [594689.174328] usb 8-1: usbfs: process 610734 (stream_checker) did not claim interface 1 before use
|
| 15:07 | kbeckmann | not sure what that means.. but it shows up when running.
|
| 15:08 | BAndiT1983 | you can google last part, found several entries which can help
|
| 15:08 | BAndiT1983 | am not that deep in USB yet, still trying to understand the low-level CDC protocol
|
| 15:08 | kbeckmann | true. i'll see if i can find what it is
|
| 15:41 | thiblahute__ | left the channel |
| 15:42 | vup | I think the claim interface message also occurs when it is working
|
| 15:42 | vup | that assert means the chip didn't send the amount of data requested, interesting
|
| 15:47 | thiblahute__ | joined the channel |
| 15:48 | kbeckmann | oh weird. my code that was using the proprietary lib stalled in the reconfiguration step. if i comment that out and go straight to streaming data it works, and i get 190 MB/s (compared to 180 through a hub)
|
| 15:50 | Bertl | well, that's something, isn't it?
|
| 15:50 | kbeckmann | tracking it down now, seems to be the hacky way of waiting for the device to re-enumerate that was broken.
|
| 15:52 | kbeckmann | but yeah, 190 instead of 180 is nice. this might not scale linearly, but perhaps you may get past 360 if you also skip the hub (unless you already did that)
|
| 16:13 | kbeckmann | urgh, seems that the proprietary lib has some internal state that gets messed up when you re-enumerate even though I close the driver handle. anyway, won't be using that in the future anyway :).
|
| 16:32 | mumptai | joined the channel |
| 20:10 | RexOrCine1 | left the channel |
| 20:19 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 21:03 | danieel | left the channel |
| 21:04 | danieel | joined the channel |
| 21:08 | illwieckz | joined the channel |
| 21:34 | aombk3 | joined the channel |
| 21:38 | aombk2 | left the channel |
| 21:41 | fjodor[m] | joined the channel |
| 22:49 | illwieckz | left the channel |
| 23:26 | mumptai | left the channel |