Realtime response

Submitted by Marius on #1

Hello all,

we have purchased a virtualhere licence and is in the process of testing the feasibility of the product in our product solution.
Currently, we have our own in-house developed audiometer that connects via usb to client software on a laptop.

Obviously, the client software connects correctly when there exists a direct connection between audiometer and laptop/dektop.
However, when I remotely connect to the device, using a raspberry-pi as an intermediary, I get time-outs on the responses issued by the client software.

I have checked both the cpu utilization of both laptop and Rpi. The bottleneck seems to be on the tcp/ip link which is a direct ethernet link between laptop and Rpi.
I have a theory that the ethernet link becomes temporarily congested when the virtualHere client scans the ip-network for potential servers, which occurs on a frequency of possible every minute. As I said, this is just a theory, as a possible cause for contention on the link, causing time-critical delays within our client software.

Has anyone else experienced similar issues, and how are near-real-time issues dealt with in the virtualHere architecture?
Is it, for instance, possible to insert a streaming protocol on the tcp/ip stack that ensures priority in a contentious environment for virtualHere traffic? However, if my theory is correct, then the contention is caused by different virtualHere processes, and therefore a streaming-protocol solution might be ineffective.
Is it possible to perhaps pause the virtualHere client from performing regular network scanning for later resumption, once user data has been sent and received?

I am awaiting your urgent response.

PS. In the event that this product meets our requirements, we will be purchasing a licence for every one of our remote devices.

Regards
Marius

Submitted by Michael on Tue, 2016/03/01 - 17:11

#2

I assume an "audiometer" is essentially a fancy microphone? Is the audiometer a "full" speed (12MBps) or "high" speed usb device?

Does any sound get recorded at all?

There is a bug in the raspbian kernel that seems to block "full speed" microphone devices from working correctly. I usually recommend OEM's get a beaglebone black instead and use TI kernel as that works with microphones and virtualhere.

Submitted by Marius on Wed, 2016/03/02 - 17:55

#3

Michael,

//I assume an "audiometer" is essentially a fancy microphone?
From a medical standpoint, the device tests auditory capacity over a wide frequency and amplitude sound ranges. It requires no soundbooth.
Our product sports both microphone and speaker combinations, calibrated over the wide-band frequency range.
//Is the audiometer a "full" speed (12MBps) or "high" speed usb device?
we have a fullspeed usb device, driven by esoteric sound-card driver software (in and of itself problematic, kernel bugs aside)
//Does any sound get recorded at all?
Not in the tests I am conducting.
//There is a bug in the raspbian kernel that seems to block "full speed" microphone devices from working correctly.
I have tested with wheezy. I will research and possibly test jessie (time-permitting).
//I usually recommend OEM's get a beaglebone black instead and use TI kernel as that works with microphones and virtualhere.
I will definitely put the beagle on my "must-have" shopping list.
Would you be able to put me in touch with other OEM's that work with the VH/Beagle combo?

Thankyou for your prompt response and assistance.

Submitted by waverunner on Fri, 2016/10/21 - 00:46

#5

Hi Marius -

Were you able to get this working? Were you able to do Pure Tone and Speech Testing? If so, what USB audiometer did you use?

Thanks in advance,
Kyle