I am trying to set a multi camera in my computer on Linux 14.04.
In fact, the name of the camera is LadyBug5.
https://www.ptgrey.com/ladybug5-360-degree-usb3-spherical-camera-systems
after the different configuration of drivers, I got this message in terminal, saying that I cannot detect the camera as desired :
zac#zac:~/catkin_ws/src/ladybugcapture$ LadybugRecorderConsole
Loading configuration from /etc/ladybug/LadybugRecorderConsole.xml
*** Configuration ***
Camera Configuration
Data format: JPEG (8-bit)
Frame rate: 10
Use auto frame rate: Yes
JPEG quality: 80%
GPS Configuration
Use GPS: No
Port: 4
Device name: dev/ttyACM0
Baud rate: 115200
Refresh interval (ms): 1000
Stream Configuration
Destination directory: .
Cameras detected: 0
Insufficient number of cameras detected.
Error: Failed to initialize camera (Operation failed)
Do you have any tips to resolve this problem?
thanking you in advance
My first question is: is the camera recognized by the linux kernel? Detach the camera from the computer, run dmesg command, then atach the camera to your computer and run dmesg agin. The new lines at the end of the output should give a first hint if the camera is recognized at all.
After this try the lsusb command to see if the USB subsystem has access to the camera.
If it looks fine, then you could have a problem with the access rights to the camera's USB system. Can you try to run the LadybugRecorderConsole command with root privileges, e.g. sudo LadybugRecorderConsole?
Related
I am trying, and failing, to connect an I2S microphone (Invensense ICS43432) to my Raspberry Pi (B+) running Arch Linux. I have asked for specific advice in the relevant Arch Linux ARM forum but my question is really more general than that: how does one go about debugging Linux audio input issues?
I have verified with a logic analyser that the I2S microphone is sending sensible data in the correct channel (left) and the correct pin of the Raspberry Pi. The I2S microphone appears under ALSA as a "sound card". arecord is perfectly happy to record from that device and I have boosted the gain of that device using alsamixer by 30 dB. Yet all the data bytes of the recorded file are zero.
How does one go about checking the flow of audio data, the operation of DMA, under Linux?
I had the same problem trying to record in stereo, using 2 Adafruit I2S MEMS breakout mics: arecord worked fine, but zeros when using ALSA to write to a bin file. Choosing a 32 bit word format (Little Endian 32 bits, Signed) made it work. Only I end up with 64 bit stereo Frames.
We have a setup with a Windows 7 machine where we installed Dante Virtual Soundcard and start that soundcard with ASIO capabilities. The soundcard will receive audio over the network from a Tesira server. We want to capture the audio to files (highly preferring each channel to a separate file). The files will be played back on a later moment. There will likely be 6 channels or more.
In the same setup we use ffmpeg to capture some video which is working fine, with Direct Show. So for audio we wanted to use the same setup, since ffmpeg is able to record audio as well. However, there seems to be no option to select the ASIO devices which the virtual soundcard probably creates. So the question is what command line to use for ffmpeg, or what to install? Or which other program can record ASIO from command line?
I already tried installing:
Asio4all (actually wrong way around)
sox (don't know why actually)
HiFi Cable Asio Bridge (from VB-audio, not enough channels even with donate version)
Voicemeeter (from VB-Audio, not enough channels and actually mixes down)
O Deus Asio link, this might be an interesting option but it did not let me configure any route, any suggestions?
One thing I noticed is that the virtual soundcard can also be set to use WDM. Then I can see the devices with ffmpeg -list_devices true -f dshow -i duymmy, but recording does not yield any result, I have to ctrl-c to make it stop instead of q, and the file is zero bytes. Supposedly this is because the data over the network is all ASIO formatted and the Tesira Server cannot send "WDM data". FFmpeg stops at selecting the capture pin for audio only
EDIT:
I ran ffmpeg with high verbosity and when selecting the WDM soundcard it stops at Selecting pin Capture on audio only. Also when requesting the options it gives the same line for 22 times: min ch=1 bits=8 rate= 11025 max ch=2 bits=16 rate= 44100
You might use Voicemeeter instead of HIFI-Cable / ASIO-Bridge. Voicemeeter is a virtual audio device mixer able to connect everything together, any audio point, in any interface and any app together (including ASIO DAW)... Download & User Manual on www.voicemeeter.com
To answer my own question: it is not possible to capture sound from an ASIO device with ffmpeg. Maybe I will write the code for it if I need it...
I could however solve my issues by separating the two streams of audio data we have (AVB and Dante). These where on the same switch and maybe it is a bug in the firmware, maybe misconfiguration.
Thanks for your help!
How do I get the output from an ASIO device to IceCast2 or FFMpeg?
Duplicate?
And if not, Place the output for ffmpeg -f dshow -i "audio=your_device_name_in_dshow" -list_options
I want to use my BeagleBone Black to setup a Webcam. I installed fswebcam and configured it to take a picture every 10 seconds. However, the BeagleBone produces the following errors in dmesg every few minutes:
dmesg | tail -n 3
-> [ 220.258214] musb_host_rx 1762: Rx interrupt with no errors or packet!
-> [ 490.302277] musb_ep_program 896: broken !rx_reinit, ep13 csr 0003
-> [ 490.308731] musb_host_rx 1762: Rx interrupt with no errors or packet!
After a few hours (at most!) it freezes up completely and I have to power-cycle it. (The power-button doesn't shut it down anymore.)
This error has been bugging me for weeks. I tried all possible configurations I can think of:
Three different Beaglebones: Two revision A5A and one revision A5C
Five different Power supplies: Three via USB, two via Barrel connector
Three different Webcams: One Logitech C920, one HP 3100, one no-name El-Cheapo
Two different Linux distributions: The current ArmHF Ubuntu 14.04 distribution and the currently linked debian distribution on the official "latest images" page (which is a few months behind!). I updated the Kernel of the latter image using the appropriate script in /opt/scripts - but that did not help either.
I installed fswebcam through package managers and compiled it from source.
For fswebcam I tried various config files (including delays and skipping images). One example config file that I tried:
background
loop 10
resolution 1920x1080
scale 1280x720
title "test-picture"
timestamp "%d.%m.%Y %H:%M:%S (%Z)"
jpeg 70
banner-colour #FF000000
line-colour #FF000000
no-shadow
save ~/test-picture.jpg
How can I keep my BeagleBone Black from crashing?
Update: I finally got it to work using a (borrowed) Rev A5C BeagleBone. I still get the dmesg errors, but at least the BeagleBone does not crash. I currently suspect a hardware issue on the RevA5B BeagleBone.
How will you detect the camera signal disconnection (not the module disconnection or hardware disconnection) without the support of V4l2-ctl command? Because my Camera Driver is not supporting v4l2-ctl command.
Found the temporary solution for camera disconnection in linux.First let me explain how to find the camera disconnection(signal disconnection) from your linux with the support of v4l2-ctl command
Command is :-
$v4l2-ctl -d <device name>(for ex-/dev/video0) --all
will list all the parameters of the camera where in the video input you can find the camera signal value changes when you disconnect the camera signal.
For without the support of v4l2 it takes 2 seconds with the help of ffmpeg command to find out.
With ffmpeg command we can take pictures of the camera devices every second and through shell script we can find out the space of the image taken for the latest file.If the image is less than 1KB then we can say that the camera signal is disconnected
I am building a music player system using a Raspberry Pi with Raspbian and a NuForce uDAC-3 USB-DAC.
I got mpd use the DAC instead of Pi's sound system using these lines in /etc/mpd.conf. As far as I know, the essential thing here is selecting hw device 1 instead of default 0.
audio_output {
type "alsa"
name "My ALSA Device"
device "hw:1,0" # optional
format "44100:16:2" # optional
mixer_device "default" # optional
mixer_control "PCM" # optional
mixer_index "0" # optional
}
The driver used for my DAC (snd_usb_audio) doesn't, however, support hardware volume control. There is no volume control available for it in alsamixer, for example. As far as I know, that's a known "feature" for that driver or it's support for that DAC. I got mpd control the volume by uncommenting this in /etc/mpd.conf:
mixer_type "software"
The primary problem now is that there is some lag in volume control that wasn't there with the integrated sound system. I mean, when I slide the volume control in my client program (QMPDClient), there is a short but notable delay before the change in volume can be heard. It's bearable but makes me wonder if everything really works as it should.
The second problem, somewhat related to the first one, is that I am wondering if there is a way to make the sound more perfect as far as any configuration files are concerned.
I have tried various examples of /etc/asound.conf I have found on the internet but either I don't understand what they are supposed to do or they simply are not working. What I thought I would get is either a Master volume control for the DAC recognized by mpd or a virtual sound card that would have a Master volume control and that would feed the sound to the DAC. Initially, /etc/asound.conf was empty, and it still is, now that nothing there seems to affect anything.
Just for the case it has any relevance, the music is in .flac files ripped from CDs.
The snd-usb-audio driver does support hardware volume control in the external dac.
The question is whether your dac supports it.
I'm using the Micromega MYDAC set to USB 2.0 with the little switch on the back.
After plugging it in, dmesg gives:
$ dmesg
[ 489.232193] usb 2-2: new high-speed USB device number 4 using ehci-pci
[ 489.365330] usb 2-2: New USB device found, idVendor=26f2, idProduct=0200
[ 489.365340] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 489.365348] usb 2-2: Product: MICROMEGA MYDAC
[ 489.365355] usb 2-2: Manufacturer: MICROMEGA
[ 489.365361] usb 2-2: SerialNumber: 0000
[ 489.855449] usbcore: registered new interface driver snd-usb-audio
Using amixer I can see the volume control interface:
$ amixer -c MYDAC scontents
Simple mixer control 'MICROMEGA Clock Selector',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 127 [100%] [0.00dB] [off]
Front Right: Playback 127 [100%] [0.00dB] [off]
Simple mixer control 'MICROMEGA Clock Selector',1
Capabilities: pvolume pvolume-joined pswitch pswitch-joined
Playback channels: Mono
Limits: Playback 0 - 127
Mono: Playback 121 [95%] [-6.00dB] [off]
The audio_output section of my mpd.conf contains:
audio_output {
type "alsa"
name "MICROMEGA MYDAC"
device "hw:MYDAC"
mixer_type "hardware"
mixer_device "hw:MYDAC"
mixer_control "MICROMEGA Clock Selector"
replay_gain_handler "mixer"
auto_resample "no"
auto_channels "no"
auto_format "no"
}
With mpc commands or any other mpd client the volume can now be set to any percentage:
$ mpc volume 100
Oscar Peterson - On A Clear Day You Can See Forever
[playing] #169/213 0:30/4:25 (11%)
volume:100% repeat: on random: on single: off consume: off
$ mpc volume 90
Oscar Peterson - On A Clear Day You Can See Forever
[playing] #169/213 0:33/4:25 (12%)
volume: 90% repeat: on random: on single: off consume: off
However this is where the bad news starts.
Looking at the interface with amixer we see what the external DAC actually did when we set its volume to 90%.
Since its limits for volume are 0..127, it set the volume to 90% of 127 which is 114.
Now 114 is 127-13 so it simply reduced the volume by 13 dB!
$ amixer -c MYDAC scontents
Simple mixer control 'MICROMEGA Clock Selector',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 114 [90%] [-13.00dB] [on]
Front Right: Playback 114 [90%] [-13.00dB] [on]
So every step down from 127 reduces the volume by 1 dB.
This is not at all what 90% of the volume should be.
The dB scale should work as follows:
0 dB = 100%
-0.9 dB = 90%
-1.9 dB = 80%
-6 dB = 50%
-20 dB = 10%
So the DAC should have reduced the volume by 0.9 dB, not by 13 dB.
This becomes even more disastrous when you want to use replaygain to automatically control the volume.
mpd uses the dB scale as I gave above.
I ripped all my CDs to flac and added replaygain tags.
These work fine on two other systems not using an external DAC (Poweramp on Android on a Samsung tablet and Deadbeaf on the openPandora device). All volumes come out nicely even.
When I use mpd with the MYDAC the following happens, for example.
mpd plays a song with track replaygain of -4.3 dB.
So mpd instructs the interface to go to 60% since 20log 0.60 = -4.3 dB.
However, the interface doesn't go to 60% of the volume.
Instead it sets its parameter 0..127 to its 60% value, which is 0.60 x 127=76.
Since the max parameter value 127 corresponds to 0 dB and 76 is 127-51,
the DAC simply reduces to -51 dB instead of the intended -4.3 dB.
The result is that the music can't be heard at all anymore!
$ metaflac --list 01.Dancers_in_Love.flac
....
METADATA block #2
type: 4 (VORBIS_COMMENT)
comments: 11
comment[0]: ARTIST=Duke Ellington
comment[1]: ALBUM=The Small Groups
comment[2]: TITLE=Dancers in Love
comment[3]: GENRE=Big Band
comment[4]: TRACKNUMBER=01
comment[5]: CDDB=7d10d619
comment[6]: REPLAYGAIN_REFERENCE_LOUDNESS=89.0 dB
comment[7]: REPLAYGAIN_TRACK_GAIN=-4.34 dB
comment[8]: REPLAYGAIN_TRACK_PEAK=0.81216431
comment[9]: REPLAYGAIN_ALBUM_GAIN=-3.61 dB
comment[10]: REPLAYGAIN_ALBUM_PEAK=0.81216431
$ mpc
Duke Ellington - Dancers in Love
[playing] #90/213 0:04/1:55 (3%)
volume: 60% repeat: on random: on single: off consume: off
$ amixer -c MYDAC scontents
Simple mixer control 'MICROMEGA Clock Selector',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 76 [60%] [-51.00dB] [on]
Front Right: Playback 76 [60%] [-51.00dB] [on]
It seems that the interpretation of volume in percentage and volume in dB by this external DAC is totally useless. Unfortunately I have a further external DAC that gives similar outputs of the "amixer scontents" command, i.e., it reduces by whole 1dB steps and it maps percentage volume control commands simply to a percentage of the volume parameter of the DAC. I can't say who is at fault here. I would argue the DAC manufacturers. The net result is that volume control in an external DAC is effectively not possible.
I have not found any report of an external DAC that would do hardware volume control correctly according to the dB scale. So I guess software mixer volume control is the only option, even though you loose quality that way. I would love to stand corrected though.
To get lower latency, reduce the buffer_time setting:
audio_output {
...
buffer_time 100000
}