Tag Archives: tetra

Modifying microphone directivity.

So, we have some Logitech C920 cameras. They are really good for their price and sport a couple of microphones with echo cancellation and an omnidirectional pattern. Which is quite great for its intended use but a major pain if what you want to perform voice activity detection. Basically, all the cameras trigger when someone speaks. It can be worked around but things are a lot easier when the sound from one camera doesn’t leak that much into the others.

Not wanting to replace or modify the internal microphone array if there was another way I decided to test if with some absorbent foam the response could be shaped to something more useful.

Utilísima un poroto.

I cut a couple of rectangular prisms with cavities that more or less match the shape of the cameras. My supply of plushy fabric was rather limited and so I planned a bit more carefully how to divide it and make the crevices. After that I just cut it in four equal pieces and held everything with hot melt glue and some stitches.

Results.

I don’t have proper facilities like an anechoic chamber. Testing was done using a 1KHz tone and recording the sound from the back, 45 and 90 degrees ccw (shouldn’t matter) and facing the front of the camera. While there’s an improvement over the original pattern, the directivity achieved is not enough so we’ll pursue an alternate way of capturing sound (either a multichannel soundcard or modifying the internal mics).

Debugging USB3.0 issues when dealing with USB2.0 devices

Some time ago we needed to connect as many usb cameras as possible to a single computer and capture full hd video and audio. Most of our systems despite having a lot of connectors on the inside they really have one host controller and a hub.

While the available bandwidth may be more than enough using a compressed format the amount of isochronous transfers is rather limited. Our minimal use case called for three C920 cameras. On a normal system (one host controller behind a hub) the best we could achieve was two at 1280×720@30fps with audio and a third without audio, and only one at 1920×1080@30fps with audio.

So, we need to add more controllers. Usb 2.0 add-on cards are a thing of the past but luckily they were replaced with the faster USB3. Most of the usb 3 controllers also feature an usb 2.0 controller and hub for older devices but some (very rare) have a dedicated usb 2 controller for each port.

Given this I went ahead and bought two cards of different brand and different chipset each.

One of them had a NEC PD720200. It worked like a charm but sadly only has one usb 2 controller.

The other sported a VIA VL800. This one has one usb 2 controller per port (this can be seen with lsub -t). That lovingly discovering didn’t last for too long as the controller crashed all the time, at best it would stop responding but sometimes it locked my system hard. The guys at Via have a very interesting definition of meeting the specs. I’ve spent a whole weekend patching kernels trying to make it behave. Now I have a quite expensive and sophisticated paperweight.

Testing procedures:

I ssh’d to the target machine and ran in several consoles:

– watch -n1 ‘dmesg | tail -n 16’ to have a log should the system crash hard.

– watch -n1 ‘grep Alloc /sys/kernel/debug/usb/devices’ to monitor bus usage.

– 3x gst-launch-1.0 v4l2src device=[camera] ! queue ! ! fakesink sync=true alsasrc device=[camera soundcard] ! queue ! fakesink sync=true to capture from each device. video_caps is something like “image/jpeg,width=1920,height=1080,framerate=30/1” but I tried a couple more.

It is really wonderful how much computing power we have nowadays. The first time I compiled a kernel it took a good four hours. On my current machine (not quite new…) it takes about forty minutes from a clean tree and around ten from an already compiled one.

debugging_usb3-0