It's amazing to see how much effort has been put in to trying to resolve
various sound related problems for the Raspberry Pi. Apparently it must be
the weakest spot for new users to successfully develop with and use ALSA
under Raspbian. Having spent considerable time and effort trying to get my
own RPi3 sound working in different OS versions ...
According to the ALSA Wiki, under the title that reads "How to choose a particular order for multiple installed cards", it states the following:
Which card is card number 0, 1 and so is by default determined by module load order. This is particularly useful to choose which card becomes the default one.
In theory therefore it is possible to choose ...
Turns out the file is now called alsa.conf and is found in /usr/share/alsa.
Changed the lines
to card 1 and that's me up and running. Looks like others have different problems with other sound cards so worth looking at other solutions too. Found some good suggestions (including my solution) here:
To get different definitions for playback and capture, use the asym device:
(Something like this is not possible for control devices.)
If you want to compile something from source that links to a specific library, you also need the appropriate header files (#include ...). These are not included when the library is installed since they're only needed when compiling; instead, they come in small associated "development" packages.
On Raspbian these have a -dev suffix:
> apt-cache search ...
Ok, first delete the file /etc/modprobe.d/alsa-base.conf Raspbian Jessie does not use this config file like Wheezy did.
Now, to set the USB sound card to your default card you will need to edit the file /usr/share/alsa/alsa.conf with the command sudo nano /usr/share/alsa/alsa.conf scroll down until you find the lines
I'd guess that you're gaining the delay due to some sort of buffering taking place or due to high CPU load. The later you can check by running the top command.
The FluidSynth Wiki suggests three command line options you can use to reduce latency.
-r=RATE (sample rate, default 44100)
-c=NUM (number of audio buffers, default 16)
-z=SIZE (buffer size, default ...
I found a simple solution using just ALSA and uses little CPU - around 3-5% on RPi 3 using latest Jessie build and a USB Audio Device
It appears that recent builds all come with ALSA's dmix plugin built-in. This allows you to share and output audio output stream
Create New .asoundrc
pi@raspberrypi:~ $ sudo nano .asoundrc
Copy/Paste this based on USB ...
sudo apt-get install libasound2-dev
before attempting to configure and compile ffmpeg or anything where you need alsa support.
Process for resolving similar build dependencies:
Returning to this build/install method:
$ cd /usr/src
$ sudo git clone git://source.ffmpeg.org/ffmpeg.git
$ cd ffmpeg/
$ sudo ./configure && sudo make &&...
By default pigpio uses the PCM peripheral to time the DMA leaving the PWM peripheral free for standard audio.
Perhaps your ALSA device is using high quality audio. If that's the case you need to use the PWM peripheral to time the DMA leaving the PCM peripheral free for high quality audio.
To do that from C use gpioCfgClock.
adding an 'asymmetrical' ALSA device worked:
change the contents of /etc/asound.conf and ~/.asoundrc to the following:
and sudo alsa force-reload for good measure
Create a Bash file with the following code:
amixer sset 'Master' 50%
Make the Bash file executable using chmod +x filename
In Python, use the following:
You can use module-loopback functionality of PulseAudio. First identify the names for your sound card's line in and speakers using pactl list sources and pactl list sinks respectively. Then create the loopback:
pactl load-module module-loopback source=src_name sink=sink_name
If your soundcard is detected with correct default source and sink, simply running ...
I did manage to play sound and record using my Marshall MID headphones using a Raspberry Pi Zero W, which has a builtin WiFi + Bluetooth adapter, but no audio jack.
Please note that there are different approaches using different tools such as bluez alsa and pulseaudio, hcitool, bluetoothctl.
Bluez Alsa let's you play sound on a ...
I found a workaround. Instead of re-ordering the index for the mic card, I can change the default mic card with this:
$sudo vi ~/.asoundrc
I got this working by running the following command to configure which audio output to use:
amixer cset numid=3 1
The last number is the audio output with 1 being the 3.5 jack, 2 being HDMI and 0 being auto.
Configure looks for the presence of the development libraries of PulseAudio, Jack and ALSA, in that order.
That is why in answers like this it is mentioned that "...It also appears that ALSA will not be used if PulseAudio is installed...".
In my particular case, I didn't have anything else installed besides ALSA. But then I remembered that I did some tests ...
RPIO, like pigpio, servoblaster, piblaster, and possibly others, use DMA to time the servo pulses. In effect the pulses are hardware timed. In contrast to software PWM they suffer little if any jitter.
The DMA timing is achieved by pacing transfers from a Broadcom SOC peripheral. There are only two which may be used, PWM and PCM. Initialising the ...
You can make these various settings in your asoundrc, discussed here. You need to set the default input and output in your asoundrc file. Note that when the input and output devices are different, there can be problems with playback and recording at the same time (full duplex). This is because the two sound cards don't share a common clock. It seems that it ...
Here's a writeup for the hack we came up with in the comment stream:
Most fortunately, we're able to take advantage of the limited scope of this request:
I don't care that sound doesn't work on pygame. The application works perfectly just this annoying 6 line error message shows. I just want to get rid of the messages
We don't know why exactly ALSA is ...
The subdevices are for multiple audio services usage that would be mixed to input/output.
There are also subdevices that are a part of an input or output
device. There must be at least 1 subdevice. In the context of output
devices, a device having multiple subdevices means the hardware can do
mixing, i.e. it can take multiple streams of PCM and mix ...
Section 3 at the bottom of the installation guide Troubleshooting part:
Couldn't acquire D-Bus name: org.bluealsa
It is not possible to run more than one instance of the BlueALSA
server per D-Bus interface. If one tries to run second instance, it
will fail with the "Couldn't acquire D-Bus name: org.bluealsa" error
message. This message ...
You are supposed to mention your sound card number to store the settings using sudo alsactl store,
You could see the card number of your device using the command,
The output would be apparaently in this form,
List of CAPTURE Hardware Devices
card 1: U0x41e0x30d3 [USB Device 0x41e:0x30d3], device 0: USB Audio [USB Audio]
aplay -l lists all hardware devices, i.e., devices handled by an ALSA kernel driver.
These devices, identified by card number x and device number y, can be accessed directly with a device name hw:x,y. Software plugins that are layered on top of hardware device also accept these numbers, e.g., plughw:x,y or dmix:x.
aplay -L lists the ALSA device names of all ...
As per the manual page (which should be installed, read man aplay):
List all soundcards and digital audio devices
List all PCMs defined
PCM is the standard way that uncompressed digital audio is encoded for playback. It may colloquially refer to a source/sink of such a signal ("PCM interface" might be clearer), ...
2 Bytes = 16 Bits
Adding a bit of code so that I can understand how the wave module works:
waveFile = wave.open("/home/pi/Music/second_stupidest_birthday_ever.wav", "rb")
frames = waveFile.getnframes() # total number of frames / samples
rate = waveFile.getframerate() # number of frames / samples per ...