I can run aplay with no problem, and play a wav test file.
In my application, the call to snd_pcm_open gives the following error:
ALSA lib conf.c:3357:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
ALSA lib pcm.c:2266:(snd_pcm_open_noupdate) Unknown PCM default
I checked the code in aplay, and I'm using the same device name ('default'), and same mode. The codes are practically the same, only that aplay is only one file to test ALSA and I'm trying to run ALSA inside a very large application.
It gets even more weird when I realized that by just retrying the call after a brief sleep, it works.
If instead of opening the device I try to snd_ctl_open, I get an error
ALSA lib conf.c:3357:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
ALSA lib control.c:954:(snd_ctl_open_noupdate) Invalid CTL hw:0
control open (0): No such file or directory
after which I can open the device.
As if after one call to snd_pcm_open or snd_ctl_open fixes the issue, so the next call it works.
what can cause this behaviour? I don't want to call snd_pcm_open twice. It's symptomatic that something is wrong.
I'm running ubuntu.
Installing the package libasound2-plugins:i386 solved the issue.
But if anybody knows why making a second call to ALSA worked, I'll mark your answer as the correct answer because right now I have no idea.
Related
I'm having a similar problem to that listed here - SDL2 is not seeing X11/Video Device correctly
I'm trying to follow the Lazy Foo tutorial for SDL and I keep getting the 'no available video device' error. If I update SDL_VIDEODRIVER to x11 I get that x11 is not available. I'm linking against it but it doesn't seem to help.
I'm calling SDL_GetVideoDriver at the beginning of my program and all it's seeing is dummy.
System is Ubuntu 20.04.
If anyone has any tips on how to try and debug this that would be greatly appreciated.
So the problem turned out to be that I had compiled SDL2 myself instead of using a package manager, but I had also then installed it with a package manager. It was using the version from my compilation which didn't include the drivers correctly.
The easiest solution was just to remove the compiled installation and go with the package manager.
I am new to VyOS development. I have written a code, which will fetch info from VyOS kernel module and write it on a netlink socket.But the problem is I am not sure whether
Can I edit the kernel module code directly to call my defined function or I have to write the patch.
If I have to make a patch file for it then where to place it in kernel source code. I have already made a patch file using diff command.
I have searched a lot about this problem but couldn't find the satisfactory solution.
Thanks.
After a long search I solved the problem I was facing. Here is conclusions in case any of you gets stuck in same problem.
Yes, you can edit the kernel module code in VyOS Development. But this method is not much appreciated.
Yes, you can write patch for kernel modules too. and it should be in GIT formate as described in How to write VyOS Patch. Soon I will update, where to place .patch file in VyOS kernel code.
To check the debugging output using dmesg, use KERN_DEBUG option. As I am not sure about others.
printk(KERN_DEBUG "%s: Debuging info \n", __FUNCTION__);
Moreover to check modification in VyOS kernel you don't need to make a complete ISO file all the time. You just need to run following commands.
*Note each path is
described everytime from the main iso building directory to avoid path problems.
cd build-iso/
sudo make clean-linux-image
sudo make linux-image
Then
cd buil-iso/pkgs/
Here you will find these debian packages.
buil-iso/pkgs/linux-image-3.13.11-1-amd64-vyos_999.dev_amd64.deb
buil-iso/pkgs/linux-libc-dev_999.dev_amd64.deb
buil-iso/pkgs/linux-vyatta-kbuild_999.dev_amd64.deb
Copy these files to an already installed VyOS Sytem and install them over there.
dpkg -i linux-image-3.13.11-1-amd64-vyos_999.dev_amd64.deb
dpkg -i linux-libc-dev_999.dev_amd64.deb
dpkg -i linux-vyatta-kbuild_999.dev_amd64.deb
reboot the system and check you modifications using dmesg.
I'm trying to develop a plugin for alsa. I compiled my plugin as a shared library and copies it to
/usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_myplug.so
Then I try to test it using arecord and get the following error
arecord --device=my_plug_test blah.pcm
ALSA lib dlmisc.c:254:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_myplug.so
arecord: main:682: audio open error: No such device or address
But the file does clearly exist. I'm wondering if there is something about using .so files that i'm overlooking. Anyone have any ideas?
Could be some other dependency not found. Try:
ldd /usr/lib/i386-linux-gnu/alsa-lib/libasound_module_pcm_myplug.so
Or, is it possible your system is expecting 32-bit but you compiled 64-bit or vice versa?
Check with:uname -a
My team and I are working on a project with OpenCV (v. 2.4.2) and QT(v. 4.8.4). We are developing in QtCreator. It is a cross-platform project that will be primarily looking for movement in video files.
On the Mac OSX, the video file will open properly using the normal cv::VideoCapture object and interface and we can run our program successfully. However, on Windows, the file would not open, just throwing this error on the QtCreator terminal when the program exits:
warning: Error opening file (../../modules/highgui/src/cap_ffmpeg_impl.hpp:361)
However, when we set QtCreator to 'Release' build mode instead of 'Debug', the program opens the file as it should.
My teammate and I have done extensive research on this error and found no real solutions.
We have tried installing codecs, moving the opencv_ffmpeg.dll file to the working directory of the .exe, and modifying the path with the location of the opencv_ffmpeg.dll (as well as the location of the ffmpeg library.) We have also made sure that our video is valid, as well as the file path (the same video works on a MacOS, and the video file will actually play in Windows through Qt's Phonon module).
Similar questions:
VideoCapture OpenCV 2.4.2 error in windows
Problem with VideoCapture in OpenCV 2.3
Any ideas about what could be causing this issue?
Unfortunately, I can't give the reason but we also often get these problems if we use precompiled OpenCV dll's. The error is caused anywhere by connecting ffmpeg to the videocapture. In our case rebuilding OpenCV on the concerned computer fixed the error.
I migrated my program built with gtk+3.0 from linux to Mac OS X(10.6.8).
And I compiled the program without errors.
However, after I started the program and I chose to open a file, the terminal shows following message.
GLib-GIO-CRITICAL **: Settings schema 'org.gtk.Settings.FileChooser' is not installed
Then, the program ends with Segmentation fault.
How to solve it?
Thanks for any helps.
Seems you're not the one having this problem, and it also happens on Windows on MinGW. Luckily, that person gave a solution:
The thing, as it seems as I was running the test-widget example (that I
built with gtksourceview-3.0.0 using MSVC), was that I need to compile the
org.gtk.Settings.FileChooser.gschema.xml file (from GTK+-3.x, under
$(srcroot)/gtk) with the glib-compile-schemas utility that is from GLib,
which will generate gschemas.compiled in the same folder.
After that, place that gschemas.compiled file in the this folder:
$(parent_folder_of_the_gtk3_dll)\share\glib-2.0\schemas
and one will be set to use the gtkfilechooser without the puzzling
[GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser'
is not installed] error.
I will add to my GLib project files to compile the glib-compile-schemas
utility and add to my GTK+-3.x project files to compile the
the org.gtk.Settings.FileChooser.gschema.xml shortly.
I ran in to this problem with a program that I crosscompiled with mingw for windows, the solutions is to run glib-compile-schemas [path to org.gtk.Settings.FileChooser.gschema] in my case was that file in ./share/glib-2.0/schemas.It will generate gschemas.compiled, that is the file FileChooser is looking for.