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 &&...
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:
Here is a solution you might find helpful:
arecord -D hw:2,0 -d 5 -f cd test.wav -c 1
D option specifies recording device. Since this specific test mic is on “card 2”, “device 0”, the value is “hw:2,0” here. This command creates “test.wav” as a 5-second, CD-quality wave file. Since it’s a mono mic, specify “1” as the number of channels with “-c” option.
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.
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 ...
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
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 ...
Sadly, I don't think this is going to work the way you think it's going to work.
Balanced cabling is effective at minimising noise induced along the length of the cable. If there's an almighty tsunami of white noise produced by the source (here, a Pi's 3.5mm audio output), a balanced cable will endeavour to transmit that noise faithfully from source to ...
Exactly the same device definition works for playback:
slave.pcm "hw:0" # or whatever
ttable [ [ 1 -1 ] ]
Put it into your ~/.asoundrc or into the global /etc/asound.conf, and use the device name fake_balanced to play mono sounds:
aplay -D fake_balanced some_mono_file.wav
(Use plug:fake_balanced to ...
The MAX98357 does not handle the RPi's I2S output well which causes pops/cracks
root cause is a short high-level interruption of BCLK before LRCLK starts (oscillograms: actual, generated)
unclear if cause is I2S driver or SoC peripheral
unclear if other SoCs than BCM2835 (Raspberry Pi 1 A, B, B+, Compute Module, Zero) are affected (...
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 ...