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 ...
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 ...
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 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 &&...
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
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.
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]
Use arecord -Dhw:cardID:deviceID test.wav
You can find the card ID and device ID of kinobo USB from arecord -l
The aplay -l ---> will display Card Id and Device ID
$ aplay -Dhw:CardID:DeviceID test.wav
If everything is working ok, I don't think this is anything other than informative. Why do you think it indicates an error?
Not every message spit to console at boot indicates a problem -- in fact, most of them don't. Different software may use different priorities with the system logger in order to force stuff to the screen but that does not mean it is ...
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 ...