I want to operate PulseAudio using DBus. In several instructions I read about using the module 'module-dbus-protocol'. But it does not exist.
$ pacmd load-module module-dbus-protocol
Module load failed.
I looked for it with autocomplete, 'pacmd list-modules', and even in the built git sources.
Is my PulseAudio properly configured? Or do I have a version problem?
Currently I use pulseaudio 5.0
EDIT:
Found, is in my /usr/lib/pulse/ folder.
was my mistake. I had the modules of two different pulsaudio versions in
- /usr/lib
-/usr/local/lib
and my running PA was linking to to the older one.
I just simply deleted all of the pulseaudio files from the /usr* repo by hand and reinstalled pulseaudio
Related
I have a laptop and a computer and I want to test the Media Player example of Qt.
On my laptop, everything is working, but on my computer I have this message:
no service found for - "org.qt-project.qt.mediaplayer"
I have installed the Multimedia Dependencies but it's change nothing.
So I have try to find the missing packet by using synaptic and on the both computer, I have the same result by searching Gstreamer:
I have also create two file to compare with this command:
apt list | grep inst > apt_list.txt
# and
apt list | grep inst > apt_list_laptop.txt
tkdiff apt_list.txt apt_list_laptop.txt
I can't find what's missing, I ask your help to find it.
Edit:
I run the program with QT_DEBUG_PLUGINS=1 and on the computer I have: "QLibraryPrivate::loadPlugin failed on "/home/.../libgstmediaplayer.so"
It's also said that it can't open libgstaudio-0.10.so.0 but on the laptop it use the 1.0 version.
And effectively, when I write:
ldd libgstmediaplayer.so
It's linked with gstreamer0.10 on my computer, and with 1.0 on my laptop
I found the reason, it's because QtCreator use the library located in /home/user/Qt/5.5/gcc_64/plugins/mediaservice/ but these libraries use the 0.10 version of gstreamer:
Qt Multimedia Module:
Added GStreamer 1.0 support. Note that the default is still 0.10.
The library in the libqt5multimedia5-plugins package use the 1.0 version. So, to launch the media player without "no service" message, I have compile by using command line:
qmake player.pro && make
By this way, qmake use the system library and not the libraries locate in the Qt folder.
I'm setting up the BlueZ protocol stack on a custom system using linux 3.3. I'm using buildroot to setup the filesystem, and specifically am using BlueZ-4.101.
I'm attempting to use the hcidump utility to get some logs, but the binary has not been installed.
I've checked that:
Device driver is installed in kernel
BlueZ Utils is enabled in buildroot .config file
Other utilities work, such as hcitool or hciconfig
Going into the Makefile in output/build/bluez_utils-4.101 it would appear that the object file hcidump.o is being compiled into a binary called btmon.
Further investigation would reveal that in Makefile, btmonis assigned to am__EXEEXT_10, and that is then assigned to the variable noinst_PROGRAMS.
So this is where I'm at. I'm pretty sure that this is an automatically generated Makefile by buildroot. I'm not sure how these files are generated, thus I'm unsure as to why btmon is being assigned to the noinst_PROGRAMS variable.
In summary, I believe that my version of BlueZ uses a binary btmon instead of hcidump. btmon is compiled (binary seen at output/build/bluez_utils-4.101/monitor/btmon), but not being installed onto my target system because of instructions in Makefile.
My best guess would something weird about compatibility between my kernel version and bluez. Any suggestions would be greatly appreciated!
In BlueZ 4, hcidump was distributed as a separate package, bluez-hcidump. This has never been packaged in buildroot, however. So either create your own package for bluez-hcidump, or switch to BlueZ 5. BleuZ 5 is provided by buildroot starting from 2014.08.
I need to add new functionality to a chinese Linux-based time attendance clock. More specifically I need to make It SNMP capable, which is not available by factory default.
After some research I found a login:password which worked for the TelNet login and managed to get inside the system with root privileges.
The first thing I did was to figure out which Linux distro was It running:
cat /etc/issue throws this:
"PXA Linux Preview Kit
Kernel 2.6.29 on armv5tejl"
I did a quick google search and found that
"PXA Linux is a port of the Linux kernel for PXA based processor based devices and machines."
I dont understand why It's running a PXA Linux Preview Kit on an armv5tejl.
I gave no importance to this fact, and got to the next step: finding which package manager has this system:
I tried several commands:
apt-get, aptitude, rpm, dpkg, yum, slapt-get, ipkg, and several others. None of them worked.
I found that the system had Busybox installed. More specifically BusyBox 1.15.3. In this BusyBox I couldnt find any of those commands. I found that BusyBox does implement rpm and dpkg but this version doesnt have them.
The only command which seems to be "software installation related" I found was the command "install". From BusyBox docs:
"install [-cdDsp] [-o USER] [-g GRP] [-m MODE] [source] dest|directory
Copy files and set attributes"
But probably it doesnt replace the package manager tool. I think that I need to get a way to install dpkg or rpm, and then use them to install the SNMP packages I want. As I read, the lowest level package installation tool is dpkg so I don't have a clue on where to begin.
Can someone give me some advice on how to approach this issue? How can I install a package with no package manager possiblities at all?
You won't be able to install additional software to that system via a package manager. Such devices aren't designed like that. The firmware that was shipped with the device is all there is. What would be the incentive of the device manufacturer to maintain a package repository with general purpose linux software?
But not all hope is lost. You can of course try to compile the needed software yourself (and by that extend the firmware). For that to work you will need a suitable ARM cross compiler (GCC). Via static linking your SNMP package won't have any dependencies to the library versions already on the device (so you don't need a sysroot matching the libraries on the device).
The release notes for RedHawk 2.0 say that the GPP device previously written in Python has been replaced with one written in "Written in C++, so it is more responsive". But I find it still running in Python (according to ps command python is running GPP.py, and the $SDRROOT/dev/devices/GPP/GPP.spd.xml which also has softpkg version="1.10.0". Was my installation defective and I still have parts of the 1.10 runtime system? My IDE says 2.0.
It sounds like REDHAWK 2.0 was not properly installed on your system, the IDE and the framework/assets are separate and it is possible to get into a situation with conflicting versions depending on the installation steps taken.
Determining what version of REDHAWK you have installed can be determined in a handful of ways. If you installed via yum or rpm you can check the versions of the rpms installed with:
rpm -qa | grep -i redhawk
The redhawk package, and redhawk-ide package should both be at 2.0. Note that the REDHAWK assets are versioned independently.
If you installed via source, you can use the package config files to obtain version information. The framework keeps it's pc files in $OSSIEHOME/lib64/pkgconfig:
cat $OSSIEHOME/lib64/pkgconfig/ossie.pc
Will print out version information for the core framework installed. Depending on what is installed, there are pc files for the framework, bulkio, frontend, and burstio.
I am sorry. The GPP-2.0.0-3.el6.x86_64 DOES contain an ELF executable for GPP device. But the rpm does not install unless I manually erase the GPP-1.10 pkg. Until erased yum says "nothing to do" for some reason. I saw the source code in GPP-debuginfo but did not notice the executable in GPP-2.0.0 since it was all caps and looked like the directory.
I recently installed redhawk on RHEL 5.8 using the instructions found here http://redhawksdr.github.io/Documentation/mainch2.html#x4-60002
I was installing from the redhawk-yum-1.10.0-10-el5-x86_64.tar.gz file.
After the installation and a reboot I found that all the files in /dev/ on the system had been changed to be owned by usrp:usrp and permissions were changed so that other users could not write to those files.
This created a lot of problems as many user scripts on the system write things to /dev/null which became unavailable.
Has anyone seen this before?
I also noticed that all the directories like /usr/local/redhawk were owned by root:root instead of redhawk:redhawk.
UPDATE:
I found that even after restoring the correct ownership and permissions to /dev/* files a reboot reverted those changes. Then I removed the file /etc/udev/rules.d/10-usrp-udh.rules and restored the correct permissions once more. After a reboot this time, the correct permissions persisted and the problem ended. Something must be up with the USRP-UDH rules installed by the UDH RPM with redhawk in EL5 series installer.
You're correct that the problem is being caused by the udev rules file installed by the UHD RPM. Specifically, The udev system within CentOS5 (14.32.el5) does not support the SUBSYSTEMS and ATTRS tags, which are included in the udev rules file created using the official UHD driver and fedora spec file. Since the current version of REDHAWK (1.10.1) does not support CentOS5, the recommended solution is to upgrade to CentOS6. If this is not a viable option for you, you'll need to obtain a CentOS5-compatible build of the UHD drivers.