Talk:PulseAudio

Listen to microphone over the speakers using pulseaudio

By default, We cannot hear any sound of microphone over speaker on Debian or Ubuntu OS. So, we cannot sing karaoke. After “google” its, I’ve found a solution at “http://ubuntuforums.org/showthread.php?p=8672035”.

Using this command to route the mic input through output:

pactl load-module module-loopback latency_msec=1

To turn it off:

first find the module number

it gives it to you when you run the first command, or use this to find it:

pacmd list-modules

then to unload it use this with your module number:

pactl unload-module 27

Additional:

To fix the problem permanently, you need to load the modules when Pulseaudio starts. To do this, you need to add a line to the /etc/pulse/default.pa file with the following commands:

sudo gedit /etc/pulse/default.pa

Scroll down to the bottom of the file and add this line:

load-module module-loopback

Now the modules will load automatically and your line-in audio will always be available.

jackd and qjackctl

The program jackd is an audio sound server daemon for Linux, and its counterpart qjackctl is a simple user interface that let you handle JACK audio server. From this you can virtually connect the output of your mic to your speakers.

You can install them from you terminal with:

sudo apt-get install jackd qjackctl

errors : snd_pcm_open: Device or resource busy

snd_pcm_open: Device or resource busy -

~/.local/share/Steam/steamapps/common/PULSARLostColony/PULSAR_LostColony_Data/soundbackends/libalsa_linux_amd64.so error: ALSA

dooku:~$ lsof /dev/snd/pcm*
COMMAND    PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 3553 xxxxx  mem    CHR  116,9           631 /dev/snd/pcmC0D0p
pulseaudi 3553 xxxxx   52u   CHR  116,9      0t0  631 /dev/snd/pcmC0D0p
PULSAR_Lo 4854 xxxxx  mem    CHR 116,10           632 /dev/snd/pcmC0D0c
PULSAR_Lo 4854 xxxxx   68u   CHR 116,10      0t0  632 /dev/snd/pcmC0D0c

dooku:~$ lsof /dev/snd/pcm*
COMMAND    PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 3553 xxxxx  mem    CHR  116,9           631 /dev/snd/pcmC0D0p
pulseaudi 3553 xxxxx   52u   CHR  116,9      0t0  631 /dev/snd/pcmC0D0p
PULSAR_Lo 4854 xxxxx  mem    CHR 116,10           632 /dev/snd/pcmC0D0c
PULSAR_Lo 4854 xxxxx   68u   CHR 116,10      0t0  632 /dev/snd/pcmC0D0c

dooku:~$ lsof /dev/snd/pcm*

libalsa_linux_amd64.so

linux dmix

dmix

dooku:~$ aplay -L|grep dmix
dmix:CARD=PCH,DEV=0
dmix:CARD=PCH,DEV=3
dmix:CARD=PCH,DEV=7
dmix:CARD=PCH,DEV=8
dmix:CARD=PCH,DEV=9
dmix:CARD=PCH,DEV=10
dmix:CARD=HDMI,DEV=3
dmix:CARD=HDMI,DEV=7
dmix:CARD=HDMI,DEV=8
dmix:CARD=HDMI,DEV=9
dmix:CARD=HDMI,DEV=10

alsa testing

The simplest way to find out something about your sound card(s) and how ALSA sees them is calling aplay -l for playback and arecord -l for recording. These commands list the cards, hardware devices and subdevices available for playback and recording, respectively. It also lists the card ID, which can be used instead of its index to specify the card.

ALSA directly accesses sound hardware and blocks access to it for other clients. But it is possible to set up ALSA to serve multiple clients.

~$HOME/.asoundrc

~$HOME/.asoundrc :

pcm_slave.slavej {
  pcm "hw:0"
  channels 2
  rate 44100
}
pcm.plugj {
  type plug
  slave slavej
}

blacklist snd_hda_intel

lsmod command lists all currently loaded kernel modules.

lsmod

Before you unload or blacklist any module it is good to see what other modules depend on it:

modinfo -F depends snd_hda_intel

returns:

snd-hda-core,snd-hda-codec,snd-pcm,snd,snd-intel-dspcfg

ok, sure thats a lot of sound stuff

sudo vi /etc/modprobe.d/blacklist.conf

sudo update-initramfs -u

blacklist snd_hda_codec_hdmi

Try to blacklist both:

blacklist snd_hda_intel
blacklist snd_hda_codec_hdmi

or just

blacklist snd_hda_codec_hdmi

to get rid of hdmi audio devices.

If you have another soundboard or usb soundboard this could work.

ATI Audio / AMD audio radeon.audio=0

Disable support for audio over HDMI disable the audio support in video driver

for example for AMD Radeon you should add in the kernel command line:

radeon.audio=0

add the following to /etc/default/grub file:

GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.audio=0"
GRUB_DISABLE_RECOVERY=false

then refresh

sudo grub-mkconfig -o /boot/grub/grub.cfg

for short term test try (instead)

/boot/vmlinuz-5.4.0-58-generic root=UUID=214e903a-3995-4c07-a18e-6b13b83d813c ro  quiet splash radeon.audio=0

starting and stopping pulseaudio

xxxxx@host:~/test$ systemctl --user stop pulseaudio.socket
xxxxx@host:~/test$ systemctl --user stop pulseaudio.service
xxxxx@host:~/test$ pulseaudio --check
xxxxx@host:~/test$ ps ax|grep -i pulse
  24166 pts/1    S+     0:00 grep --color=auto -i pulse
xxxxx@host:~/test$ systemctl --user start pulseaudio.socket
xxxxx@host:~/test$ systemctl --user start pulseaudio.service
xxxxx@host:~/test$ ps ax|grep -i pulse
  25146 ?        S<sl   0:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal
  25182 ?        Sl     0:00 /usr/libexec/pulse/gsettings-helper
  25328 pts/1    S+     0:00 grep --color=auto -i pulse
xxxxx@host:~/test$ pulseaudio --check
xxxxx@host:~/test$ systemctl --user stop pulseaudio.socket
xxxxx@host:~/test$ systemctl --user stop pulseaudio.service
xxxxx@host:~/test$ ps ax|grep -i pulse
  27114 pts/1    S+     0:00 grep --color=auto -i pulse

PulseAudio fighting with Alsa

When the PulseAudio audio daemon starts, it by default loads module-udev-detect, which detects and opens all sound cards. PulseAudio uses ALSA to interface to the hardware; ALSA is a combination of kernel moadules and userspace libraries.

As a result of PulseAudio opening all the sound cards, and as a result of the fact that ALSA cards can only be opened once, the user sees "Device or resource busy" error when trying to open an ALSA card after PulseAudio has started:

$ arecord -D hw:2 -f S16_LE -c 1 -r 48000 -d 3 t.wav
arecord: main:830: audio open error: Device or resource busy

The general design of a sound server is to accept data from a wide variety of software and route it to a useful audio device, and vice versa (for input).

Since that's the goal, PulseAudio needs to know about the capabilities of each device it wants to use. It must therefore open them to query capabilities about things like supported sample sizes and expected latency, as well as device names (because the user will want to know that to select the device). Once it's done that, it can present those options to the user.

If the user wants to play something to a device, PulseAudio can just play to that card if the card is already open. If the card is not open, then PulseAudio must first acquire it, which may not work if another device is using it. In that case, the user will perceive their sound to be broken without a justified reason. Similarly, the user may question why their microphone doesn't seem to be producing sound.

Because the average user does not know about or want to look at logs, having suddenly broken sound which required inspecting logs, especially if trying to start something like a video meeting, would be at best irritating and at worst an insurmountable problem. I'm a highly technical user with decades of experience on Linux and I don't want to troubleshoot sound problems (or any problems, for that matter).

Acquiring all the sound cards and then having ALSA use PulseAudio as the default ALSA device means that programs which know how to use ALSA but not PulseAudio will just work without contending with other programs. Otherwise, for example, your audio player could hold onto the card while preventing sound effects like your terminal bell from working. This is not an uncommon problem, in fact; it's why PulseAudio is supported as an ALSA output device.

Of course, this design doesn't meet everyone's needs, but it does produce the simplest, most robust behavior, since cards which are displayed to the user are generally usable, and those which are not are not. It may be possible to produce the behavior you desire with some configuration, or you may prefer to use a different solution, such as JACK or ALSA with dmix.