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
}
Related
During the installation, we are supposed to check the sound card by pressing ‘arecord -L’ to obtain a certain output like shown below,
pi#raspberrypi:~ $ arecord -L
null
Discard all samples (playback) or generate zero samples (capture)
jack
JACK Audio Connection Kit
pulse
PulseAudio Sound Server
default
playback
ac108
sysdefault:CARD=seeed4micvoicec
seeed-4mic-voicecard,
Default Audio Device
dmix:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Direct sample mixing device
dsnoop:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Direct sample snooping device
hw:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Direct hardware device without any conversions
plughw:CARD=seeed4micvoicec,DEV=0
seeed-4mic-voicecard,
Hardware device with all software conversions
usbstream:CARD=seeed4micvoicec
seeed-4mic-voicecard
USB Stream Output
usbstream:CARD=ALSA
bcm2835 ALSA
USB Stream Output
However, the output that I have received is as shown below,
Screenshot of Output
It basically shows that I don’t have the ALSA soundcard, and I cant move on to the sound localization process. Please show how can I move forward, thanks!
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?
The primary video card usually can be set in the BIOS (option Primary VGA card), and it will be the first card used by the system.
My question is how can I programmatically identify (using a shell script and utilities is preferable) which of my two video cards is the primary card?
Edit: I was hoping that I wouldn't have to elaborate why I need this, because it is a bit complex, but I will explain the problem below.
I have a configuration wizard which allows the dynamic configuration of a multiseat system in a LiveCD, with two independent displays, keyboards and mice, my wizard works in this way:
Start one Xorg server per video card (after generating xorg.conf with the correct PCI bus ID).
Start a ui in each of Xorgs with messages for configuration (press key and press mouse). One seat can be configured each time.
After the first seat is configured, the wizard closes the first Xorg and start the definitive Xorg in this seat with the desktop environment (already with the correct keyboard and mouse set).
The second seat now is able to be configured (press key and mouse), after this pass 3 is repeated for seat two.
The problem is: If I start the first Xorg in the primary video card, everything works, but if I start the first Xorg in the secondary card this is what happens:
The passes 1, 2, and 3 works, but at the end of pass 3, when the Xorg of the first seat is closed, the Xorg of the second seat blinks and doesn't come back, just show a blank screen with a _ cursor at top, the desktop of the first seat loads, but I don't see the wizard screen in the second seat, the first Xorg just comes back if I execute a kill -HUP , and I need to start the ui from it again.
So, it is why I need to identify the primary video card before I can start Xorg (sorry I didn't mention this before). I tested this system in different computers, with different video cards and the behavior is the same. I also tested with the lasted packages of the kernel and Xorg in Ubuntu 12.04 (packages of the raring release).
Assuming X11 is running, you could suppose that primary card is the one used by Xorg... then you might try
ls -l /proc/$(pidof X)/fd |grep /dev/dri
on my system Debian/Sid/x86-64 with Linux 3.12 kernel (which has an Nvidia card on a Intel3770K which also has its VGA) I'm getting /dev/dri/card0 etc...
But you should explain really why you are asking and what problem do you want to solve.... Why does that matter to you?
I am not at all sure that Linux has a notion of primary graphic card like the BIOS knows it.
And probably hwinfo is telling you everything about your graphical cards.
There are several command line tools in Linux that give you human readable information from the BIOS. Maybe you can find your Video boards in there and see which one is made primary. From what I see in my output, it does not look like something says "this is the primary video", but I do see quite a lot of information. You could output that information to a file when video card A is primary, again when B is primary, then compare those two files and see whether there is a difference.
The command I used, which gives me a lot of information, is dmidecode:
sudo dmidecode | less
If you look at the manual page:
man dmidecode
You will notice that the programmers offer a few other similar tools such as biosdecode and vpddecode.
From those you learn that the BIOS information is available from the /dev/mem device. Although you need to be root to read it, if you know the address (I don't) then you could go in there and peek and poke as required to find out where that one information of which video card is defined as the primary video card.
Running dmidecode, there are some details about my motherboard:
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Supermicro
Product Name: X9SCI/X9SCA
Version: 1.01
Serial Number: ZM25U44192
Asset Tag: To be filled by O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Here I have one video entry:
Handle 0x000E, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: To Be Filled By O.E.M.
Then the other entry looks like this:
Handle 0x0036, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard IGD
Type: Video
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:02.0
It could also be something you need to read from the Flash memory your BIOS uses. This is done with flashrom (that you may need to install):
sudo flashrom --programmer internal --read my-flash.bin
In my case the ROM on my computer is 2Gb of data. So quite large. However, you can be sure that the information you are looking for exists within that data block since that is the only mean for the BIOS to save data that will stay around when the computer gets turned off.
I have found a way how to check the primary GPU when they are from different vendors or at least have different names.
In KDE go to Info Center, then open Graphics -> OpenGL. In Direct Rendering (GLX) and Direct Rendering (EGL) you can see a Driver block. You can see the Vendor and Device there. It will name the GPU which is primary.
At this screenshot you can see that AMD gpu is primary:
Also, you can get that Vendor value programmatically by running
glxinfo | grep "OpenGL vendor string" | cut -f2 -d":" | xargs.
I guess this method will stop working when kde will switch to vulkan for rendering (in kde 6). But for now I do not know another method of determining primary gpu.
I am trying to O/P audio to a USB soundcard (Lindy PnP SoundCard device) via Python/PySide/PyQT by the use of Phonon and/or QTMultimedia.
I can O/P the aduio (mp3/wav) which is no problem - the issue is that I want to control the USB's output sample clock rate, I need to be able to change this from 44.1 to 48 kHz. The soundcard comes with its own s/w that allows this so it is possible.
I can play Audio through Phonon like so..
self.mediaObj=phonon.Phonon.MediaObject(self)
self.audioSink=Phonon.AudioOutput(Phonon.MusicCategory, self)
self.audioPath=Phonon.createPath(self.mediaObj, self.audioSink)
self.audioSink.setVolume(0.3)
However I do not see any way to change the sample clock rate of the USB device from looking at the Class Reference doc's it seems its not possible.
http://www.pyside.org/docs/pyside/PySide/phonon/index.html
So then I have tried to use Qt Multimedia to change the USB soundcards O/P clock rate..
format = QtMultimedia.QAudioFormat()
format.setChannels(2)
format.setFrequency(44100)
format.setSampleSize(16)
format.setByteOrder(QtMultimedia.QAudioFormat.LittleEndian)
format.setSampleType(QtMultimedia.QAudioFormat.SignedInt)
This has no effect. Does anyone know how I would do this and if it is even possible with Phonon/PyQT? I am guessing I need to go lower and try find the USB Soundcard directly which will be messy..
Much appeciate any help!!
Alan
i'm building a linux based firmare for an alix 2d13 using crosstools-ng, for the toolchain, buildroot, for the root filesystem, and vanilla kernel ... for the kernel.
I need to use compact flash and harddisk but, when i connect them to the alix, i get a really weird error:
[ 1.072380] ata1.00: CFA: CF Card, Ver2.34, max UDMA/100
[ 1.077738] ata1.00: 7880544 sectors, multi 0: LBA
[ 1.082670] ata1.00: limited to UDMA/33 due to 40-wire cable
[ 1.096260] ata1.00: serial number mismatch '6EB10703040700582043' != '6EB1p703040700582043'
[ 1.104738] ata1.00: revalidation failed (errno=-19)
[ 1.109740] ata1.00: limiting speed to UDMA/33:PIO3
.
.
.
[ 6.209775] ata1.00: serial number mismatch '6EB10703040700582043' != '6EB1p703040700582043'
[ 6.218324] ata1.00: revalidation failed (errno=-19)
[ 6.222235] ata1.00: disabled
All works fine if i detach the harddisk from alix. hdparm output is:
Model=CF Card , FwRev=Ver2.34 , SerialNo=6EB10703040700582043
Config={ HardSect NotMFM Fixed DTR>10Mbs }
RawCHS=7818/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
BuffType=(2) DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=?1?
CurCHS=7818/16/63, CurSects=7880544, LBA=yes, LBAsects=7880544
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=no
And alix configuration is
(C) CHS mode L LBA mode W HDD wait V HDD slave U UDMA enable
I tried using pata_amd and pata_cs5536 but the result is the same.
Full kernel output is here
http://pastebin.com/7wcvEdRG
You have a hardware problem or serious misconfiguration, where bits are getting scrambled between the device and host.
When the kernel tries to read the serial number from the drive (using an ATA identify device command), one of the bytes gets a bit flipped. Note that the bad character 'p' (0x70) is only one bit different from '0' (0x30).
It's likely that scrambling identify data is the least of your problems-- read/write data is probably unreliable as well.
If this only happens when you have two devices attached to the same ribbon cable, either one of two things is true:
The two devices are causing signal integrity problems when sharing the bus. Check all of your jumper settings. If everything else is correct, either find another device, a better cable, or give up and don't put them on the same cable.
Your kernel is misconfiguring the ATA controller when both devices are present.