Device Usbpdo-8

[Demetrius Dade]

DeviceError Code 10. I will try it with older FW. (Device is ok, because it works with my Laptops (Lenovo/Win 10 and Macbook Pro) but not with my studio workstation). It could be also a problem with the USB Hub from the mainboard ASUS P7H55-M and an usb-controller: Intel 5 Series/3400 Series Chipset Family USB Enhanced Host Controller - 3B3C

Anyone else have this problem?

Manuel perhaps it depends on older mainboards with older hubs and drivers under windows 10. FW 2.0 works perfect with my 13 years old macbook pro and a lenovo laptop about 4 years old also windows 10 installed. My studio workstation is about 12 years old and had never usb issues with any audio devices also win 10 installed. I hope we find a solution. if you need more infos, write me. Thanks for your help :-)

USBDeview is a small utility that lists all USB devices thats currently connected to your computer, as well as all USB devices that you previously used.

USBDeview also allows you to uninstall USB devices that you previously used, disconnect USB devices that are currently connected to your computer, as well as to disable and enable USB devices.

when system boots it loads the root bus driver that will create a FDO. Now it will enumerates its child devices and i guess some hot plug method of the bus driver will be called, when a new child will be found and that method will notify the PNP manager. PNP manager will call the AddDevice() routine of the root bus driver and that will intern create PDOs for new buses like one for PCI and etc. Please explain the whole flow in detail, this is just my imagination. And then it is documented that system will load the functional driver for the PCI bus that will create the FDO ?? what is this FDO?? and why would i need that?? According to me PCI bus driver should also follow the same as done by the root bus, enumerate its child and create PDOs for them, or by this FDO they mean PDO only ?? I am so much confused :( !!

A PDO acts as a physical device, but it does not necessarily have to be physical. It is essentially the interface between a device on a bus, and the bus itself. This is pretty well covered on MSDN.

If your point of reference is the PCI bus, then Pci.sys is the function driver. But if your point of reference is the Proseware Gizmo device, then Pci.sys is the bus driver. This dual role is typical in the PnP device tree. A driver that serves as function driver for a bus also serves as bus driver for a child device of the bus.

You also have filter drivers which allow you to sit between PDO's and FDO's and start doing naughty stuff like hiding files, POC rootkits etc. At this stage you can add extra functionality, or completely prevent access to the PDO.

Same issue here with the fingerprint sensor on my HP dv6-6b51ea. Tried installing the Windows 8 x64 driver found on the laptop's support page, however it doesn't work. The installation gets so far and then cuts out. How hard is it for HP to have working models of all their laptops, testing and developing new drivers in anticipation of new Windows OS updates?

It's worth mentioning that if anybody else here has got a similar HP model with 'switchable graphics', Windows 8.1 completely messed it up (like I haven't had enough problems trying to troubleshoot Switchable Graphics in the past), so I had to uninstall all AMD products, restart a few times and install the AMD stuff from the laptop's support page again.

Managed to get it to work! I had everything uninstalled to start with. I forgot to mention previously that in Device Manager, there were no Biometric Devices, however there was one extra USB port with a yellow icon (which I assumed to be the sensor). I disabled and enabled it a few times, but nothing. Then decided to try installing HP Simplepass 2011 which goes by SP61399.exe. That installed fine. I next tried the driver installation which is SP58834.exe. That, as before, cut out half way through. I tried running it under different compatibility settings, namely Windows 7 and 8. Each time it cut out. I decided to restart anyway and alas, it was working! Sorry about waffling on but I'm not entirely sure which of the above worked - all I know is that one of them did!

After upgrading to Windows 8.1 I had to reinstall the Validity Sensor software which was working under Windows 8.1 Preview. Now I am unable to get it working. Here are the details with respect to the Validity Sensor Hardware installed on my HP HDX 16:

There is no software for your particular computer for Windows 8. For the Fingerprint sensor to work it needs the Validity Sensor software and the HP SimplePass. I have included a link to a download for the SimplePass software for Windows 8.

Last week, I updated my PC to windows 8.1 and the fingerprint reader stopped working. The reader does not flash anymore. When I checked the device manager, there is no error displayed. And yet, I did try the steps showed herewithin this solution. But my fingerprint reader is not working.

Hi, does anyone know if there are any known issues sharing USB headsets (headphones and microphone) over VirtualHere on the Android version? I'm specifically using an Nvidia Shield, and a SteelSeries Arctis 9.

When I connect the device, I get an extra Android popup warning me that VirtualHere doesn't have audio recording permissions, but it could record audio if I grant it access. When I allow this, the headset does show up on my Windows client, and I can set it as the default audio output, but it still doesn't seem to work for either output or recording.

I should note that I know using Gamestream/Moonlight interferes with this (since it will constantly try to grab the audio out). That's my second hurdle to solve! But even without that it doesn't seem to work.

Can i confirm you are using the dongle via virtualhere? Usually you use a bluetooth dongle via virtualhere and sync to that and it should work. I think the dongle with that headset is bluetooth but i wasnt entirely sure

OK i think you should try a normal USB bluetooth dongle if you have one, and use that via virtualhere then sync to that instead. That custom dongle might have some special firmware that virtualhere cant support via Android. If you have a pi4 or something like that it might work ok.

Ah okay, interesting. I was hoping to use the higher fidelity wireless for the PC audio rather than bluetooth, but good to know another option like the Pi might work as that was another thought I'd considered. Sad that they are impossible to find right now...! But I'll keep looking. (And in the meantime I might also be able to try a USB bluetooth dongle too)

Okay thanks. I've just tried using CloudHub, but the one headset shows up as two devices in the VirtualHere client (one with a star, and one with a speaker icon). Connecting to either one separately doesn't seem to work, and I don't have a license for the Pi version so can't connect to both. Is there a way to temporarily test this or transfer my Android license? (Also, if I do buy a license for the Pi version, will that be locked to the CloudHub build? Just in case I do ever decide to install something else on the Pi, that might warrant switching over to Raspbian.)

Hold that thought, I just realised I hadn't switched something on the headset (facepalm). If I connect just to the device showing the speaker icon, I do get sound out of the headset. However, it is quite crackly and drops out often, and the mic input back does not record properly, it is jittery. I noticed the crackling was better if the Pi was connected via Ethernet rather than WiFi, is this just a limitation of the setup, or is that second device in VirtualHere important? Thanks again for the help.

The headset is connected to a custom USB 2.4ghz wireless receiver that came with the headset which is connected to the Pi. I have not noticed any issue with latency the way I do when I use a bluetooth headset (i.e. a delay in audio but perfect fidelity), only crackling noise and what seems to be dropped 'frames' of audio from the mic.

Ah OK, that means that the latency is just too high for the audio to work without dropping. Some headsets compress the audio so it gets around this delay but seems like yours sends the raw signal. What does the latency look like in virtualhere. Right click USB Hubs->About->Statistics? Is it generally below 15ms?

I had some trouble getting the headset to connect again, it showed up in Windows but did not send any sound. Eventually after selecting 'use' and 'don't use' a few times it started working. The output was better, but the mic input was still bad. The latency in VirtualHere was consistently under 1ms, here's just a few entries from the log:

Could you plug your headphones directly into your pc and then run this program -sieber.de/usbtreeview_e.html#download . This will show a list of all USB devices. Can you find your headphones on the list on the left, then click on it then paste in here all the text on the right side.

OK thanks, yes it shows the headset has a very high sample rate for the microphone (48khz) and is sending raw data every 1ms . Im pretty sure this is the problem because the slightest jitter in the network will cause it to missample. The USB protocol cannot buffer data to work around this so via virtualhere its not going to be able to be clear for the microphone unfortunately.

I again had a little trouble getting it to connect. Once I did, I'd say the microphone was slightly improved, but still not usable, enough jitter that entire words were dropped when I tried recording.

Also, I did go get a Bluetooth dongle, and that works much more stably, including through my original Android version of VirtualHere on the Shield. I'm not sure how often I'll end up using it that way (as I was hoping to connect the headset to another device with Bluetooth) but glad to know it's there as an option.

Yesterday I was working on my laptop. Suddenly I noticed that the indicator light of the webcam was on, despite the fact that I wasn't making a video call or using the webcam in any other way at the moment.

3a8082e126