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.