Dear Sir,
I am recording on a USB Audio device(microphone) connected to RaspberryPi3 ModelB.
[Setup]
Raspberry Pi3 Model B
Raspbian (Debian) 9.1
Kernel linux rasberry pi 409.59-v7+
vhusbdarm 3.4.8
vh client fow windows(x64) 4.3.5
They are connected to a Windows10 machine using a wired network and are recording
the sound on a Windows10 machine. Of course, it was very easy so far.
However, on the assumption that the network will be delayed,
I intentionally caused delays 50ms-200ms in the network using the "tc" command on RPi.
Then, the recorded sound was clogged or dropped or skipped in a while.
The image of the recorded voice is
No-Delay 1..2..3..4..5.. Delay 1.3.5
At this time, I analyzed USB communication using CATC.
As you know, originally, USB isochronous data transfer is done every one millisecond,
But, thi time, there was no USB IN request, data transfer was not being work.
I do not want real time so much. Is there a way to increase URB on VirtualHere ?
If you know another way to solve something, would you please let me know ?
Please advise.
Regards,
Toshiki
.
With isochronous transfers network latency is an important variable. The way isochronous usually works is that the client driver sends several isochronous URB's simultaneously to the device. The device then fills the packets and returns the URBs, and this process continually repeats.
If there is a large network delay there is no way for these urbs to be returned in time so you get starvation at the send (or receive) ends and hence the audio will either stop working or skip.
These URBs cannot be sent without the client driver initiating the transfer because the state-machine in the client driver must match the state inside the usb device. If the virtualhere server was to generate urb requests manually this may not be possible to match them with a future urb request , furthermore isochronous requests may be multiplexed with control transfers e.g to modify the audio capture, so this is why its not possible to pre-submit URBs at the server end without client participation
Usually if you need good microphone support over a variable latency physical medium, you need to transfer the sound at a higher layer in the stack, e.g stream the sound using some windows api
Dear Michael,
Dear Michael,
Thank you for your quick reply.
I understood that a mechanism for transferring data is necessary besides VirtualHere.
By the way, how long is a network delay that does not cause data to be dropped just by VirtualHere ?
Maximum xxx ms or yyy bytes ?
Regards,
Toshiki
.
Not sure sorry, but if you have a good wifi connection or ethernet it should be fine. If you are running it over the internet you will get dropouts or it may not work at all
Dear Michael,
Dear Michael,
I think that is really unfortunate that ViretualHere server alone can not solve this problem.
Thanks.
Toshiki
.
The problem is you are trying to do something that is physically impossible, move up the stack and it should be ok.
There is a new spec called USB-MA meaning media agnostic. this is quite new and nothing supports it yet (except for windows) but in a few years i suspect this will be widely supported then you can reevaluate virtualhere ! :)
Dear Michael,
Dear Michael,
I see.
Thank you for your advise.
Regards,
Toshiki
.
I wanted to add, if this microphone is your product and you control the driver for it and your client runs on windows 10 build 1709 , then please visit this https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-cl… because that may help you update your driver so it supports Media Agnostic (MA) behaviour. I am happy to help you by adding support inside the virtualhere host controller to support MA for you if you want to do this