Current Server Time: 18:14 (Central Europe)

#apertus IRC Channel Logs

2020/08/11

Timezone: UTC


01:17
RexOrCine
left the channel
01:17
RexOrCine1
joined the channel
04:57
Bertl_oO
off to bed now ... have a good one everyone!
04:57
Bertl_oO
changed nick to: Bertl_zZ
06:13
BAndiT1983|away
changed nick to: BAndiT1983
07:36
mumptai
joined the channel
10:37
mumptai
left the channel
12:58
illwieckz
left the channel
12:58
illwieckz
joined the channel
13:00
Bertl_zZ
changed nick to: Bertl
13:00
Bertl
morning folks!
13: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!
13:45
kbeckmann
s/on/with/
13:48
vup
kbeckmann: very nice
13:49
kbeckmann
as for throughput, i get just like with the binary drivers, around 180 MB/s in 245 mode.
13: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!
13: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
13:55
vup
they have remove async transfers again in the newer versions tho
13:58
Bertl
kbeckmann: usb performance largely depends on the infrastructure, i.e. controller, hubs, cables
13: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?
14:00
kbeckmann
would be fun to try out 60x mode but i haven't done that yet.
14:00
Bertl
there could be a bunch of hubs in your computer as well
14:00
kbeckmann
sure
14:00
Bertl
and the controller might be badly supported
14:01
Bertl
s/badly/not well/
14: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 :)
14:02
kbeckmann
i'll see if i get around to it. if i do i will of course keep you posted!
14: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?
14:10
Bertl
might not be there at all
14:11
Bertl
in my experience, the best solution is to have a dedicated controller card
14:11
Bertl
(they are available for PCs and Laptops) but of course that complicates things
14:12
Bertl
also, if you have one of those (red?) usb 3.2 ports, those are typically directly connected to a controller
14:14
BAndiT1983
are 3.2 red now? as 3.1 were blue
14:14
Bertl
I think the red is not official, but I've seen a bunch of them
14:14
Bertl
similar to the yellow ones for charging/always on
14:15
BAndiT1983
ah, ok, someone mentioned it also -> https://www.quora.com/What-is-the-red-colored-USB-port-of-a-motherboard
14:16
Bertl
ah, yes, USB 3.1 Gen 2 is what I meant
14:35
illwieckz
left the channel
14:35
illwieckz
joined the channel
15:20
illwieckz
left the channel
15:52
thiblahute__
joined the channel
16: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
16:06
BAndiT1983
failing handshake?
16:06
BAndiT1983
either check dmesg or for more hardcore version try wireshark USB sniffing
16:07
kbeckmann
thanks, will try wireshark
16:07
kbeckmann
[594689.174328] usb 8-1: usbfs: process 610734 (stream_checker) did not claim interface 1 before use
16:07
kbeckmann
not sure what that means.. but it shows up when running.
16:08
BAndiT1983
you can google last part, found several entries which can help
16:08
BAndiT1983
am not that deep in USB yet, still trying to understand the low-level CDC protocol
16:08
kbeckmann
true. i'll see if i can find what it is
16:41
thiblahute__
left the channel
16:42
vup
I think the claim interface message also occurs when it is working
16:42
vup
that assert means the chip didn't send the amount of data requested, interesting
16:47
thiblahute__
joined the channel
16: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)
16:50
Bertl
well, that's something, isn't it?
16:50
kbeckmann
tracking it down now, seems to be the hacky way of waiting for the device to re-enumerate that was broken.
16: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)
17: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 :).
17:32
mumptai
joined the channel
21:10
RexOrCine1
left the channel
21:19
BAndiT1983
changed nick to: BAndiT1983|away
22:03
danieel
left the channel
22:04
danieel
joined the channel
22:08
illwieckz
joined the channel
22:34
aombk3
joined the channel
22:38
aombk2
left the channel
22:41
fjodor[m]
joined the channel
23:49
illwieckz
left the channel
00:26
mumptai
left the channel