589 lines
24 KiB
Markdown
589 lines
24 KiB
Markdown
# Native Capture Cadence
|
|
|
|
This file records measured driver-path camera cadence. It is evidence, not a
|
|
promise.
|
|
|
|
## 2026-05-21: PS3 Eye Raw USB Probe
|
|
|
|
Original probe location: temp workspace only, outside this repo. The dual-camera
|
|
probe now has a repo-owned copy at `native/probes/ps3eye_cadence` and can emit
|
|
JSON frame events for Mimir's diagnostic rolling-buffer adapter.
|
|
|
|
Probe path:
|
|
|
|
- raw PS3 Eye userspace driver reference;
|
|
- libusb/WinUSB interface 0;
|
|
- Bayer frame output;
|
|
- no DirectShow;
|
|
- no Media Foundation;
|
|
- no frame processing;
|
|
- five-second measurement window.
|
|
|
|
Installed device state:
|
|
|
|
- two PS3 Eyes present as `VID_1415&PID_2000`;
|
|
- interface 0 is available through the WinUSB/libusb-style path;
|
|
- interface 1 remains the media/audio side and is not the capture path measured
|
|
here.
|
|
|
|
Sequential results:
|
|
|
|
| Camera | Requested Mode | Frames | Elapsed | Delivered FPS | Avg Delta |
|
|
| --- | ---: | ---: | ---: | ---: | ---: |
|
|
| 0 | 320x240 @ 187 | 934 | 5.002s | 186.72 | 5.355 ms |
|
|
| 1 | 320x240 @ 187 | 917 | 5.001s | 183.35 | 5.454 ms |
|
|
| 0 | 640x480 @ 60 | 292 | 5.006s | 58.33 | 17.118 ms |
|
|
| 1 | 640x480 @ 60 | 290 | 5.010s | 57.89 | 17.237 ms |
|
|
|
|
Dual-camera results in one process:
|
|
|
|
| Camera | Requested Mode | Frames | Elapsed | Delivered FPS | Avg Delta |
|
|
| --- | ---: | ---: | ---: | ---: | ---: |
|
|
| 0 | 320x240 @ 187 | 915 | 5.005s | 182.81 | 5.476 ms |
|
|
| 1 | 320x240 @ 187 | 916 | 5.005s | 183.01 | 5.460 ms |
|
|
| 0 | 640x480 @ 60 | 294 | 5.009s | 58.69 | 17.068 ms |
|
|
| 1 | 640x480 @ 60 | 286 | 5.009s | 57.09 | 17.478 ms |
|
|
|
|
Conclusion: the two PS3 Eyes can be treated as roughly 183 fps timing/marker
|
|
witnesses at 320x240 on the current USB topology when using the raw USB path.
|
|
At 640x480 they are roughly 57-59 fps.
|
|
|
|
Runtime note: `ps3eye_dual_cadence --emit-json-frames` emits one JSON line per
|
|
captured frame with `sourceId` values `ps3-eye-0` and `ps3-eye-1`; Mimir.Runtime
|
|
uses this only as a diagnostic witness until the native capture driver owns the
|
|
buffer handles directly.
|
|
|
|
The probe reported one unrelated invalid USB descriptor from
|
|
`USB\VID_0000&PID_0002`; it did not prevent PS3 Eye capture.
|
|
|
|
## 2026-05-21: LeapUVC Kernel Streaming Probe
|
|
|
|
The Leap Motion Controller is currently present as `VID_F182&PID_0003` and bound
|
|
to `usbvideo.sys`, which means the active mode is LeapUVC/UVC. That mode is
|
|
mutually exclusive with the Ultraleap SDK path for this device.
|
|
|
|
Probe path:
|
|
|
|
- Windows Kernel Streaming capture interface for `KSCATEGORY_CAPTURE`;
|
|
- LeapUVC through `usbvideo.sys`;
|
|
- no Media Foundation;
|
|
- no DirectShow graph;
|
|
- no OpenCV;
|
|
- no frame processing;
|
|
- five-second measurement window per advertised mode.
|
|
|
|
Probe source:
|
|
|
|
- `native/probes/ks_camera_cadence`
|
|
- `--multi-ks-baseline --emit-json-frames` emits JSON frame metadata for
|
|
`leap-stereo-ir`, `kiyo-pro-rgb`, and `kiyo-rgb`.
|
|
|
|
Advertised modes and measured queued KS pull rates:
|
|
|
|
| Mode | Advertised FPS | Frames | Elapsed | Delivered FPS | Bytes / Frame |
|
|
| --- | ---: | ---: | ---: | ---: | ---: |
|
|
| 752x480 YUY2 | 50.00 | 173 | 5.008s | 34.55 | 721,920 |
|
|
| 640x480 YUY2 | 57.50 | 204 | 5.017s | 40.66 | 614,400 |
|
|
| 640x240 YUY2 | 115.00 | 415 | 5.004s | 82.93 | 307,200 |
|
|
| 640x120 YUY2 | 214.00 | 777 | 5.000s | 155.39 | 153,600 |
|
|
| 752x240 YUY2 | 100.00 | 308 | 5.013s | 61.44 | 360,960 |
|
|
| 752x120 YUY2 | 190.00 | 589 | 5.008s | 117.62 | 180,480 |
|
|
|
|
Conclusion: the current direct KS probe can pull real frames from LeapUVC, but
|
|
even eight queued asynchronous reads do not reach the device's advertised
|
|
cadence. The useful stereo IR mode is `640x240 YUY2`, advertised at 115 fps and
|
|
currently measured at about 83 fps. The next cut should either tune LeapUVC
|
|
controls that affect exposure/frame interval or deliberately rebind to a
|
|
WinUSB/libusb UVC path if we decide the Windows UVC stack is the bottleneck.
|
|
|
|
Follow-up control sweep:
|
|
|
|
- the probe now reports known LeapUVC-ish controls directly through KS;
|
|
- it discards a two-second warm-up before the five-second measurement window;
|
|
- `640x240 YUY2` steady-state cadence lands at about 110.7 fps;
|
|
- `640x120 YUY2` steady-state cadence lands at about 205.9 fps.
|
|
|
|
Steady-state `640x240 YUY2` control sweep:
|
|
|
|
| Scenario | Result |
|
|
| --- | ---: |
|
|
| baseline | 554 frames / 5.007s = 110.65 fps |
|
|
| exposure 10us | 554 frames / 5.006s = 110.68 fps |
|
|
| gamma off | 554 frames / 5.002s = 110.76 fps |
|
|
| HDR off | 554 frames / 5.003s = 110.73 fps |
|
|
| LEDs on | 554 frames / 5.003s = 110.72 fps |
|
|
| LEDs off | 554 frames / 5.006s = 110.68 fps |
|
|
| gain minimum | 554 frames / 5.007s = 110.64 fps |
|
|
| dark-frame interval 0 | 555 frames / 5.009s = 110.80 fps |
|
|
| fast combined | 554 frames / 5.001s = 110.77 fps |
|
|
|
|
Rejected controls:
|
|
|
|
- digital gain via `KSPROPERTY_VIDEOPROCAMP_BRIGHTNESS = 0` returned
|
|
`ERROR_INVALID_PARAMETER`;
|
|
- the old LeapUVC FPS-ratio selector through `KSPROPERTY_VIDEOPROCAMP_GAIN`
|
|
returned `ERROR_INVALID_PARAMETER`.
|
|
|
|
Conclusion: the earlier 83 fps number was mostly startup drag inside the short
|
|
measurement window. Once the Leap is hot, the useful stereo mode is close to its
|
|
advertised cadence through the current KS path. The half-height mode can beat
|
|
the PS3 Eyes on raw frame rate, but the PS3 Eyes still win when comparing their
|
|
full 320x240 frames against Leap's useful 640x240 stereo stream.
|
|
|
|
## 2026-05-21: Razer Kiyo Kernel Streaming Probe
|
|
|
|
Installed device state:
|
|
|
|
- `Razer Kiyo` camera: `VID_1532&PID_0E03&MI_00`;
|
|
- `Razer Kiyo Pro` camera: `VID_1532&PID_0E05&MI_00`;
|
|
- both expose UVC camera interfaces through the Windows Kernel Streaming
|
|
capture category.
|
|
|
|
Probe path:
|
|
|
|
- Windows Kernel Streaming capture interface for `KSCATEGORY_CAPTURE`;
|
|
- no Media Foundation;
|
|
- no DirectShow graph;
|
|
- no OpenCV;
|
|
- eight queued asynchronous reads;
|
|
- two-second warm-up discarded before each five-second measurement.
|
|
|
|
Kiyo Pro advertised `MJPG` modes and measured cadence:
|
|
|
|
| Device | Mode | Advertised FPS | Best Measured FPS | Note |
|
|
| --- | --- | ---: | ---: | --- |
|
|
| Kiyo Pro | 1280x720 MJPG | 60.00 | 25.20 | manual exposure did not improve cadence |
|
|
| Kiyo Pro | 1920x1080 MJPG | 60.00 | 25.18 | manual exposure did not improve cadence |
|
|
|
|
Plain Kiyo advertised `MJPG` modes and measured cadence:
|
|
|
|
| Device | Mode | Advertised FPS | Best Measured FPS | Best Setting |
|
|
| --- | --- | ---: | ---: | --- |
|
|
| Kiyo | 1920x1080 MJPG | 30.00 | 30.27 | manual exposure `-9` or `-10` |
|
|
| Kiyo | 1280x720 MJPG | 60.00 | 51.51 | gain minimum after manual exposure sweep |
|
|
|
|
Conclusion: plain Kiyo is exposure-limited by default and becomes usable once
|
|
manual exposure is forced shorter. Kiyo Pro advertises 60 fps modes but the
|
|
current KS path delivers about 25 fps regardless of manual exposure, so it needs
|
|
a separate driver/control investigation before it should be trusted for high
|
|
cadence capture.
|
|
|
|
Online follow-up:
|
|
|
|
- Razer's support page for the Kiyo Pro confirms `1080p @ 60/30/24FPS`,
|
|
`720p @ 60FPS`, USB 3.0 connectivity, and HDR support, but also says HDR must
|
|
be toggled off to keep output aligned with the selected frame rate.
|
|
- Razer's firmware updater page lists `v1.5.0.1_r1` as the current RZ19-0364
|
|
updater lineage and includes a factory-default reset command in that firmware.
|
|
- Razer's flicker/banding guidance says capture frame rate and powerline
|
|
frequency can interact, and points users to the anti-flicker/powerline
|
|
setting.
|
|
- Microsoft documents `KSPROPERTY_CAMERACONTROL_AUTO_EXPOSURE_PRIORITY` as the
|
|
UVC low-light compensation control, and says it allows the device to vary
|
|
frame rate under lighting conditions.
|
|
- Razer community reports show other users seeing Kiyo Pro firmware or control
|
|
states stuck below 60 fps, including one report that Linux and Windows both
|
|
failed to reach 60 fps after a firmware update.
|
|
|
|
Local follow-up after that research:
|
|
|
|
| Device | Mode | Scenario | Result |
|
|
| --- | --- | --- | ---: |
|
|
| Kiyo Pro | 1280x720 MJPG | baseline, low-light priority value `1`, powerline `50Hz` | 127 frames / 5.009s = 25.35 fps |
|
|
| Kiyo Pro | 1280x720 MJPG | low-light compensation off | 125 frames / 5.039s = 24.81 fps |
|
|
| Kiyo Pro | 1280x720 MJPG | powerline `60Hz` | 145 frames / 5.008s = 28.95 fps |
|
|
| Kiyo Pro | 1920x1080 MJPG | baseline, low-light priority value `1`, powerline `50Hz` | 126 frames / 5.006s = 25.17 fps |
|
|
| Kiyo Pro | 1920x1080 MJPG | low-light compensation off | 126 frames / 5.006s = 25.17 fps |
|
|
| Kiyo Pro | 1920x1080 MJPG | powerline `60Hz` | 145 frames / 5.020s = 28.88 fps |
|
|
|
|
Conclusion: the Kiyo Pro's 25 fps result matches the kind of low-light /
|
|
anti-flicker / firmware trouble reported elsewhere, but the standard KS
|
|
properties are not enough to recover 60 fps locally. Powerline `60Hz` moves the
|
|
needle only to about 29 fps. The next investigation should compare this direct
|
|
KS path with Synapse/OBS and inspect whether the firmware exposes a vendor or
|
|
extension control that selects the real 60 fps profile.
|
|
|
|
HDR follow-up:
|
|
|
|
- the probe now tries `KSPROPERTY_CAMERACONTROL_EXTENDED_VIDEOHDR` with both
|
|
filter-scope and pin-0 extended-property headers;
|
|
- the Kiyo Pro reports `ERROR_FILE_NOT_FOUND` / `Element not found`;
|
|
- setting extended Video HDR off also reports `Element not found`;
|
|
- measured cadence is unchanged at about 25 fps for both `720p MJPG` and
|
|
`1080p MJPG`.
|
|
|
|
Conclusion: HDR may still be part of the Razer/Synapse control story, but it is
|
|
not exposed through the standard Windows extended Video HDR KS property on this
|
|
device path. The next useful cut is vendor-extension enumeration or an
|
|
OBS/Synapse comparison to see whether Razer flips a private UVC extension before
|
|
opening the real 60 fps stream.
|
|
|
|
Vendor/USB descriptor follow-up:
|
|
|
|
- Synapse is not installed and was not used.
|
|
- The probe now has a controls-only mode:
|
|
`ks_camera_cadence.exe vid_1532&pid_0e05&mi_00 --controls-only`.
|
|
- The Kiyo Pro exposes two `KSNODETYPE_DEV_SPECIFIC` topology nodes.
|
|
- USB VideoControl descriptor parsing found two UVC extension units:
|
|
`{2c49d16a-32b8-4485-3ea8-643a152362f2}` with unit id `2`, six controls,
|
|
and `bmControls=3f00`; `{23e49ed0-1178-4f31-ae52-d2fb8a8d3b48}` with unit id
|
|
`6`, five declared controls, and `bmControls=ff6f`.
|
|
- The second extension GUID answers KS selector probes on node `2`. Selectors
|
|
`1`, `3`, `4`, `6`, `11`, `12`, `14`, and `15` report writable support;
|
|
selectors `2`, `5`, `7`, `8`, `9`, `10`, and `15` return current payloads.
|
|
Selector `10` returns ASCII `PYTHON_V2B`, which looks like camera/firmware
|
|
identity rather than an FPS switch.
|
|
- The first extension GUID is present in the descriptor but did not answer the
|
|
current KS selector sweep.
|
|
- The local Kiyo Pro is currently behind a Genesys Logic `VID_05E3&PID_0610`
|
|
hub and reports USB speed `2` with `bcdUSB=0x0210`, i.e. high-speed USB 2.x,
|
|
not SuperSpeed USB 3.x.
|
|
|
|
Conclusion: the strongest current explanation for the Pro's 25-29 fps ceiling
|
|
is bus topology, not HDR or low-light mode. Razer documents the Kiyo Pro's
|
|
60 fps modes as USB 3.0 operation; locally the device is sitting on a USB 2.x
|
|
hub path. Move it to a verified SuperSpeed root/hub path before spending more
|
|
time mutating unknown vendor selectors.
|
|
|
|
Motherboard USB3 port follow-up:
|
|
|
|
- After moving the Kiyo Pro off the external hub and directly onto the
|
|
motherboard USB3 port, the device moved to
|
|
`\\?\usb#root_hub30#...` port `7` and reports `bcdUSB=0x0320`.
|
|
- Windows still reports the negotiated connection speed enum as `2`
|
|
(`UsbHighSpeed`, not `UsbSuperSpeed`). The probe now prints the enum name so
|
|
this is harder to misread.
|
|
- The advertised mode surface improved: `1280x720` and `1920x1080` now expose
|
|
`YUY2`, `MJPG`, `H264`, and `NV12` at 60 fps.
|
|
- Baseline measured cadence stayed around 25 fps for every 720p/1080p format:
|
|
|
|
| Mode | Advertised FPS | Delivered FPS |
|
|
| --- | ---: | ---: |
|
|
| 1280x720 YUY2 | 60.00 | 24.96 |
|
|
| 1920x1080 YUY2 | 60.00 | 24.98 |
|
|
| 1280x720 MJPG | 60.00 | 25.20 |
|
|
| 1920x1080 MJPG | 60.00 | 25.03 |
|
|
| 1280x720 H264 | 60.00 | 25.19 |
|
|
| 1920x1080 H264 | 60.00 | 25.01 |
|
|
| 1280x720 NV12 | 60.00 | 25.07 |
|
|
| 1920x1080 NV12 | 60.00 | 25.16 |
|
|
|
|
Conclusion: the direct motherboard port improved enumeration but did not fix
|
|
cadence. Because Windows still reports `UsbHighSpeed`, verify the cable and
|
|
port path before assuming the private firmware selectors are guilty. If the
|
|
same 25 fps lock remains after `UsbSuperSpeed` is confirmed, the next cut is
|
|
explicit frame-interval negotiation or cautious vendor-selector tracing.
|
|
|
|
Second motherboard USB3 port check:
|
|
|
|
- Moving the Kiyo Pro to another motherboard USB3 port changed the composite
|
|
device to `Port_#0008.Hub_#0003` on the same AMD `ROOT_HUB30`.
|
|
- The descriptor path remains `bcdUSB=0x0320`, but the negotiated connection
|
|
speed is still `UsbHighSpeed(2)`, not `UsbSuperSpeed(3)`.
|
|
- The full cadence run was not repeated because the link state is still the
|
|
same high-speed fallback state that measured about 25 fps across formats.
|
|
|
|
Conclusion: two motherboard USB3 ports have now failed to negotiate SuperSpeed
|
|
with the Kiyo Pro's stock cable. The next useful physical test is a known-good
|
|
USB3 data cable or a known-good SuperSpeed device on the same ports.
|
|
|
|
Raven host check:
|
|
|
|
- The neighbor sender machine is now codenamed Raven.
|
|
- With the Kiyo Pro plugged into Raven, Windows reports the camera, media, USB
|
|
composite, and microphone interfaces as present.
|
|
- The descriptor-only probe reports the Kiyo Pro on a USB3 root hub at port `6`
|
|
with `bcdUSB=0x0320`, but negotiated speed is still `UsbHighSpeed(2)`, not
|
|
`UsbSuperSpeed(3)`.
|
|
- Raven's hub inventory reports zero currently connected SuperSpeed devices.
|
|
|
|
Conclusion: the same Kiyo Pro/cable also falls back to high-speed on Raven.
|
|
That makes the stock cable or the Kiyo Pro's own SuperSpeed lane the stronger
|
|
suspect than the receiver workstation's rear ports.
|
|
|
|
## 2026-05-21: Simultaneous Local Camera Pull
|
|
|
|
The first simultaneous pull used one process for KS/UVC cameras and the raw
|
|
PS3 Eye probe beside it. Current local visibility is only three camera devices:
|
|
|
|
- Leap Motion Controller / LeapUVC camera interface;
|
|
- Razer Kiyo Pro camera interface;
|
|
- one PS3 Eye raw libusbk camera interface.
|
|
|
|
The regular Kiyo and second PS3 Eye were not present on this rig during this
|
|
run.
|
|
|
|
Probe changes:
|
|
|
|
- `ks_camera_cadence.exe --multi-ks-baseline` starts all matched KS camera
|
|
streams from one process with one start gate.
|
|
- The raw PS3 Eye probe was launched at the same time as the KS multi-stream
|
|
harness.
|
|
- KS matching now limits Kiyo/Leap profiles to `MI_00` so media/audio
|
|
interfaces do not masquerade as cameras.
|
|
|
|
Simultaneous results with PS3 Eye at `640x480@60`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 40.12 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 24.99 |
|
|
| PS3 Eye | 640x480 Bayer | 56.06 |
|
|
|
|
Simultaneous results with PS3 Eye at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 81.10 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 25.33 |
|
|
| PS3 Eye | 320x240 Bayer | 185.74 |
|
|
|
|
Conclusion: the current local topology can pull the three visible cameras
|
|
concurrently, but Leap cadence collapses under shared load compared with its
|
|
solo/KS-only result. The PS3 Eye's 320x240 mode is much less damaging than its
|
|
640x480 mode, but still drags Leap below its ~110 fps warm steady-state. Before
|
|
claiming six-camera viability, plug in the missing regular Kiyo and second PS3
|
|
Eye and split high-rate cameras across controllers/hubs deliberately.
|
|
|
|
After port swapping, the regular Kiyo and second PS3 Eye appeared, making five
|
|
camera devices visible and six optical sensors present: LeapUVC's packed
|
|
left/right stereo IR pair, Kiyo Pro, Kiyo, and two PS3 Eyes. The Kiyo Pro still
|
|
reports `UsbHighSpeed(2)` on `root_hub30` with `bcdUSB=0x0320`; no hub reported
|
|
a SuperSpeed device.
|
|
|
|
Five-camera simultaneous results with both PS3 Eyes at `640x480@60`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 57.33 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 24.97 |
|
|
| Kiyo | 1920x1080 MJPG | 30.30 |
|
|
| PS3 Eye 0 | 640x480 Bayer | 59.59 |
|
|
| PS3 Eye 1 | 640x480 Bayer | 57.60 |
|
|
|
|
Five-camera simultaneous results with both PS3 Eyes at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 81.05 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 24.97 |
|
|
| Kiyo | 1920x1080 MJPG | 30.28 |
|
|
| PS3 Eye 0 | 320x240 Bayer | 187.60 |
|
|
| PS3 Eye 1 | 320x240 Bayer | 187.03 |
|
|
|
|
Conclusion: all six currently intended optical sensors can be pulled at once
|
|
through the current direct-driver probes, with the Leap stereo pair delivered
|
|
as one packed UVC frame. The PS3 Eyes are healthiest at `320x240@187`; at
|
|
`640x480@60` they stay near target, but Leap drops farther. Leap is not yet a
|
|
stable ground-truth timing camera under this shared USB topology.
|
|
|
|
Follow-up port isolation test:
|
|
|
|
- Leap was moved to be the only camera on the blue rear USB3 group.
|
|
- Both Kiyos were moved to the red rear USB3 group.
|
|
- The PS3 Eyes were moved to remaining front/back USB-A ports.
|
|
- Windows then showed only one PS3 Eye enumerated.
|
|
- Leap was on `root_hub30#5` port 3.
|
|
- Kiyo Pro and regular Kiyo were both on `root_hub30#7&18eea21b`.
|
|
- The visible PS3 Eye was on `root_hub30#7&124f193f` port 4.
|
|
|
|
Visible-sensor simultaneous result with the isolated Leap topology and one PS3
|
|
Eye at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 80.99 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 24.93 |
|
|
| Kiyo | 1920x1080 MJPG | 30.37 |
|
|
| PS3 Eye 0 | 320x240 Bayer | 185.85 |
|
|
|
|
Conclusion: isolating Leap at the root-hub level did not restore its solo
|
|
~110 fps cadence while the other visible cameras were active. The remaining
|
|
loss is likely broader xHCI/controller scheduling, interrupt/CPU pressure, or
|
|
the KS/usbvideo path under multi-device load rather than only a same-row port
|
|
collision.
|
|
|
|
After splitting cameras across Mimir and Raven, the local Mimir host had only
|
|
LeapUVC, regular Kiyo, and one PS3 Eye enumerated. The local split did not
|
|
restore Leap cadence:
|
|
|
|
| Local active set | Leap FPS | Other delivered FPS |
|
|
| --- | ---: | --- |
|
|
| Leap + Kiyo + one PS3 Eye at 320x240@187 | 81.34 | Kiyo 30.27, PS3 Eye 185.56 |
|
|
| Leap + Kiyo only | 82.77 | Kiyo 16.83 |
|
|
| Leap only, baseline control scenario | 84.18 | n/a |
|
|
| Leap only, best fast-combined scenario in that pass | 92.87 | n/a |
|
|
|
|
Conclusion: offloading the Kiyo Pro and one PS3 Eye to Raven did not by itself
|
|
cure the local Leap cadence loss. In this port/controller state, Leap is below
|
|
its previous ~110.8 fps result even when measured alone, so the next check is
|
|
Leap physical/controller state rather than assuming total local camera bandwidth
|
|
was the only problem.
|
|
|
|
Follow-up: the Focusrite Scarlett Solo had been sharing the Leap's USB row.
|
|
After moving it away, Leap cadence recovered substantially:
|
|
|
|
| Local active set after moving Focusrite | Leap FPS | Other delivered FPS |
|
|
| --- | ---: | --- |
|
|
| Leap only, baseline control scenario | 95.48 | n/a |
|
|
| Leap only, best fast-combined scenario in that pass | 101.67 | n/a |
|
|
| Leap only, 640x120 baseline | 192.83 | n/a |
|
|
| Leap + Kiyo + one PS3 Eye at 320x240@187 | 105.10 | Kiyo 30.17, PS3 Eye 185.81 |
|
|
|
|
Conclusion: the split-host local set is viable when the Focusrite is not on the
|
|
Leap's USB neighborhood. Full-height Leap stereo is still a little below the
|
|
old ~110.8 fps best result, but the catastrophic ~81 fps band was caused by the
|
|
local USB layout, not by needing every camera off the machine.
|
|
|
|
## 2026-05-21: Raven PS3 Eye Driver Bring-Up
|
|
|
|
Raven initially enumerated the PS3 Eye composite and media interfaces, but the
|
|
raw `VID_1415&PID_2000&MI_00` camera interface had no driver binding and showed
|
|
`Error`.
|
|
|
|
The working Mimir host binding was exported and installed on Raven:
|
|
|
|
- provider: `libwdi`;
|
|
- service: `WinUSB`;
|
|
- local source INF: `oem26.inf`;
|
|
- Raven published INF: `oem34.inf`;
|
|
- device interface GUID from the INF: `{6ACBF2FC-1246-418C-A63D-0FE38B45129B}`.
|
|
|
|
The libwdi self-signed catalog certificate had to be copied to Raven and added
|
|
to both `Root` and `TrustedPublisher` before `pnputil /add-driver ... /install`
|
|
would accept the package.
|
|
|
|
After binding, Raven's raw Eye interface reported `OK` and the copied
|
|
`ps3eye_dual_cadence.exe` could open the camera. Cadence is not yet viable:
|
|
|
|
| Raven PS3 Eye Mode | Delivered FPS | Notes |
|
|
| --- | ---: | --- |
|
|
| 320x240@187 | 132.24 | first run, max gap 202.841 ms |
|
|
| 320x240@187 | 78.93 | second run, max gap 283.247 ms |
|
|
| 640x480@60 | 6.32 | max gap 2998.965 ms |
|
|
|
|
Conclusion: Raven's PS3 Eye driver binding is fixed enough to open the device,
|
|
but the current Raven USB path/device state is not delivering usable cadence.
|
|
Next Raven work is port/controller isolation and a clean single-process cadence
|
|
run before treating the Eye as a usable remote timing witness.
|
|
|
|
## 2026-05-22: Restored Local Five-Device Pull
|
|
|
|
After moving the Raven PS3 Eye back to the Mimir host, local enumeration showed:
|
|
|
|
- LeapUVC stereo IR pair;
|
|
- regular Razer Kiyo;
|
|
- two PS3 Eyes;
|
|
- Focusrite Scarlett Solo moved away from the Leap USB neighborhood.
|
|
|
|
The Kiyo Pro was not local for this run.
|
|
|
|
Simultaneous local results with both PS3 Eyes at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 106.07 |
|
|
| Kiyo | 1920x1080 MJPG | 30.33 |
|
|
| PS3 Eye 0 | 320x240 Bayer | 186.57 |
|
|
| PS3 Eye 1 | 320x240 Bayer | 186.14 |
|
|
|
|
Simultaneous local results with both PS3 Eyes at `640x480@60`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 108.07 |
|
|
| Kiyo | 1920x1080 MJPG | 30.34 |
|
|
| PS3 Eye 0 | 640x480 Bayer | 57.79 |
|
|
| PS3 Eye 1 | 640x480 Bayer | 58.08 |
|
|
|
|
Conclusion: the current local topology can run all local sensors in parallel:
|
|
Leap stereo plus regular Kiyo plus both PS3 Eyes. With the Focusrite out of the
|
|
Leap neighborhood and the Kiyo Pro absent, Leap stays close to its previous
|
|
best cadence instead of falling into the old ~81 fps band.
|
|
|
|
After moving the Kiyo Pro back to the Mimir host, local enumeration showed
|
|
LeapUVC, Kiyo Pro, and both PS3 Eyes. The regular Kiyo was not local for this
|
|
run. Kiyo Pro remained on high-speed USB:
|
|
|
|
- hub: `root_hub30#7&18eea21b`;
|
|
- port: 8;
|
|
- speed: `UsbHighSpeed(2)`;
|
|
- descriptor: `bcdUSB=0x0320`.
|
|
|
|
Simultaneous local results with Kiyo Pro and both PS3 Eyes at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 110.80 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 24.97 |
|
|
| PS3 Eye 0 | 320x240 Bayer | 187.46 |
|
|
| PS3 Eye 1 | 320x240 Bayer | 186.89 |
|
|
|
|
Simultaneous local results with Kiyo Pro and both PS3 Eyes at `640x480@60`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 110.72 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 24.87 |
|
|
| PS3 Eye 0 | 640x480 Bayer | 59.91 |
|
|
| PS3 Eye 1 | 640x480 Bayer | 59.19 |
|
|
|
|
Conclusion: in the current USB layout, Kiyo Pro does not poison Leap cadence.
|
|
It remains a ~25 fps RGB source because it still negotiates high-speed USB, but
|
|
the restored local sensor set is stable with Leap stereo, Kiyo Pro, and both
|
|
PS3 Eyes active.
|
|
|
|
After moving the regular Kiyo from the front panel to a rear port, all five
|
|
camera devices / six optical sensors were visible locally. The mouse moved into
|
|
the Leap's USB neighborhood and did not disturb cadence. The regular Kiyo was
|
|
behind a Genesys hub at high-speed USB, and the Kiyo Pro remained high-speed
|
|
USB on `root_hub30#7&18eea21b` port 8.
|
|
|
|
Full local result with both PS3 Eyes at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 110.84 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 25.08 |
|
|
| Kiyo | 1920x1080 MJPG | 30.18 |
|
|
| PS3 Eye 0 | 320x240 Bayer | 187.59 |
|
|
| PS3 Eye 1 | 320x240 Bayer | 187.02 |
|
|
|
|
Full local result with both PS3 Eyes at `640x480@60`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 110.76 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 25.14 |
|
|
| Kiyo | 1920x1080 MJPG | 30.18 |
|
|
| PS3 Eye 0 | 640x480 Bayer | 59.66 |
|
|
| PS3 Eye 1 | 640x480 Bayer | 59.95 |
|
|
|
|
Conclusion: the current USB topology can run the full intended local optical
|
|
set: Leap stereo, Kiyo Pro, regular Kiyo, and both PS3 Eyes. The remaining
|
|
limitation is Kiyo Pro cadence from high-speed USB negotiation, not whole-rig
|
|
USB collapse.
|
|
|
|
Follow-up with the regular Kiyo moved from the front panel to a rear port and a
|
|
mouse moved into the Leap's USB neighborhood produced the same healthy full-set
|
|
shape. The mouse did not disturb Leap cadence.
|
|
|
|
Full local result with both PS3 Eyes at `320x240@187`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 110.84 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 25.08 |
|
|
| Kiyo | 1920x1080 MJPG | 30.18 |
|
|
| PS3 Eye 0 | 320x240 Bayer | 187.59 |
|
|
| PS3 Eye 1 | 320x240 Bayer | 187.02 |
|
|
|
|
Full local result with both PS3 Eyes at `640x480@60`:
|
|
|
|
| Device | Mode | Delivered FPS |
|
|
| --- | --- | ---: |
|
|
| LeapUVC | 640x240 YUY2 | 110.76 |
|
|
| Kiyo Pro | 1920x1080 MJPG | 25.14 |
|
|
| Kiyo | 1920x1080 MJPG | 30.18 |
|
|
| PS3 Eye 0 | 640x480 Bayer | 59.66 |
|
|
| PS3 Eye 1 | 640x480 Bayer | 59.95 |
|