You are not logged in.
I have been trying to get my sound that I hear and my microphone recorded at the same time with ALSA but I hit a problem with recording the ALSA loopback device.
I don't really know how you mix two sources together to a single pcm. I can output to the loopback device (Teamspeak picks it up with one of the plughw loopback devices) at the same time as the normal sound. But it seems i can't get this loopback back as input. Or am I misunderstanding how it works?
As it is now i am basically duplicating the output to two mixers, one loopback and one for my on board card. I have working microphone input if I use the dsnooped pcm but I can't seem to mix it with the loopback. I also can't seem to have the loopback as input if I am outputting to it (even different loopback device).
My attempt at mixing can be seen in the multiroutein pcm.
To test this config i am using ffmpeg:
ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0 -f alsa -ac 2 -i default /run/media/toi/Storage\ E/Recordings/fftest.mkvI am trying to avoid using anything other than alsa and ffmpeg.
So does anyone have an idea how to mix the microphone and the loopback device?
This is the current state of my cluttered ~/.asoundrc:
pcm.on_board {
type hw;
card PCH;
hint {
show on;
description "On board";
}
}
pcm.headset {
type hw;
card Headset;
hint {
show on;
description "Headset";
}
}
pcm.loopback0 {
type hw;
card Loopback;
device 0;
hint {
show on;
description "Loopback 0";
}
}
pcm.loopback1 {
type hw;
card Loopback;
device 1;
hint {
show on;
description "Loopback 1";
}
}
pcm.dmixed {
type dmix;
ipc_key 1024;
#ipc_key_add_uid false # let multiple users share
#ipc_perm 0666 # IPC permissions for multi user sharing (octal, default 0600)
slave {
pcm "on_board";
channels 6;
#pcm "headset"
#channels 2
rate 48000;
period_size 2048;
}
hint {
show on;
description "dmixed";
}
}
pcm.loopmix {
type dmix;
ipc_key 4096;
#ipc_key_add_uid false # let multiple users share
#ipc_perm 0666 # IPC permissions for multi user sharing (octal, default 0600)
slave {
pcm "loopback0";
#pcm "loopback"
channels 6;
#pcm "headset"
#channels 2
rate 48000;
period_size 2048;
}
hint {
show on;
description "loopmix";
}
}
pcm.loopbacksnoop {
type dsnoop;
ipc_key 2049;
slave {
rate 44100;
pcm "loopback0";
buffer_size 8192;
period_size 2048;
#periods 128
period_time 0;
buffer_time 0;
}
hint {
show on;
description "dsnooped";
}
}
pcm.dsnooped {
type dsnoop;
ipc_key 2048;
slave {
#pcm "my_card"
rate 44100;
pcm "headset";
#pcm "loopback"
buffer_size 8192;
period_size 2048;
#periods 128
period_time 0;
buffer_time 0;
}
hint {
show on;
description "dsnooped";
}
}
pcm.multiroutein {
type route
slave {
pcm "indev";
}
ttable {
0 { 0 1.0; 1 1.0 }
}
}
pcm.indev {
type multi
slaves {
a {
pcm "dsnooped"
}
b {
pcm "loopbacksnoop"
}
bindings {
0 { slave a; channel 0 }
1 { slave b; channel 0 }
}
}
}
pcm.multiroute {
type route;
slave {
pcm "mdev";
}
ttable {
0 { 0 1.0; 6 1.0 }
1 { 1 1.0; 7 1.0 }
2 { 2 1.0; 8 1.0 }
3 { 3 1.0; 9 1.0 }
4 { 4 1.0; 10 1.0 }
5 { 5 1.0; 11 1.0 }
}
}
pcm.mdev {
type multi;
slaves {
a {
pcm "loopmix";
channels 6;
}
b {
pcm "dmixed";
channels 6;
}
}
bindings {
0 { slave a; channel 0 }
1 { slave a; channel 1 }
2 { slave a; channel 2 }
3 { slave a; channel 3 }
4 { slave a; channel 4 }
5 { slave a; channel 5 }
6 { slave b; channel 0 }
7 { slave b; channel 1 }
8 { slave b; channel 2 }
9 { slave b; channel 3 }
10 { slave b; channel 4 }
11 { slave b; channel 5 }
}
}
pcm.asymed {
type asym
#playback.pcm "dmixed"
playback.pcm "multiroute";
#capture.pcm "loopback1"
capture.pcm "dsnooped"
#capture.pcm "multiroutein";
#capture.pcm "loopbacksnoop";
hint {
show on;
description "asymed";
}
}
pcm.pasymed {
type plug;
slave.pcm "asymed";
hint {
show on;
description "pasymed";
}
}
pcm.dsp0 {
type plug;
slave.pcm "asymed";
hint {
show on;
description "dsp0";
}
}
pcm.softvol {
type softvol;
slave {
pcm "pasymed";
}
control {
name "Pre-Amp";
type hw;
card PCH;
}
min_dB -5.0;
max_dB 20.0;
resolution 6;
}
pcm.!default {
type plug;
slave.pcm "pasymed";
}
ctl.!default {
type hw;
card PCH;
}The output of arecord -l:
**** List of CAPTURE Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: PCH [HDA Intel PCH], device 2: ALC892 Alt Analog [ALC892 Alt Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Headset [Cyborg F.R.E.Q.7 Gaming Headset], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0Last edited by toi (2014-05-25 00:48:10)
Offline
This thread should interest you (especially the last two posts). Does the loopback have an input volume control in alsamixer? You could also try playing around with pcm.file.
Offline
This thread should interest you (especially the last two posts). Does the loopback have an input volume control in alsamixer? You could also try playing around with pcm.file.
Thanks!
I'd like to avoid using files. But the first one looks like it could work, although seems overly complicated xD. But I shall give it a go and get back with results and hopefully i can describe further how I managed to do it.
But an ALSA only solution would be nice, although possibly impossible.
Offline
file STR # Output filename (or shell command the stream will be piped to if STR starts with the pipe char).
You can pipe it also. So, I ask again, did you check input channels in alsamixer?
Offline
Alsa documentation wrote:file STR # Output filename (or shell command the stream will be piped to if STR starts with the pipe char).
You can pipe it also. So, I ask again, did you check input channels in alsamixer?
Ohh right, sorry. I am not on Arch atm but if i recall correctly i did not see any input channels for the loopback device. However it might just have been that i saw no output channels. I will update this post as soon as I can reboot. I will also try piping it somehow.
EDIT: Yeah i can see no input channels in the loopback device.
I have however started to play with the hda-analyzer and it seems work very well (Just ignoring the active connections list as it doesn't show changes i have made). I have been successful in getting the audio looped back at me and now I will try getting this loopback as input and then mix it with the microphone. If it works it seems a lot more "concrete" (if that is the word i am looking for) and should have good performance (not much software meddling).
Last edited by toi (2014-05-24 15:54:15)
Offline
I now have a semi-working solution. By using the link emeres linked I managed to create a hardware loopback and also managed to get input from it.
I have also managed to mix the two input sources when using the hw pcm directly (as shown in the .asoundrc file). I can't however manage to get input from the dsnoop pcms (loopbacksnoop and dsnooped in .asoundrc) that i have attached to the hw pcm:s. Using the hw pcm directly causes unwanted crackling and different "aliasing" effects. When using the dsnoops as input I only get the input from the first slave. Maybe I am misusing the dsnoop pcm:s?
Partly working ~/.asoundrc after fixing "hardware loopback":
defaults.ctl.!card "PCH";
pcm.!default {
type plug;
slave.pcm "asymed";
}
pcm.asymed {
type asym
playback.pcm "dmixed";
#capture.pcm "dsnooped";
capture.pcm "multiroutein";
#capture.pcm "loopbacksnoop";
}
# {{{ Out
pcm.dmixed {
type dmix;
ipc_key 1024;
slave {
pcm "on_board";
channels 6;
#pcm "headset"
#channels 2
rate 44100;
period_size 2048;
}
}
pcm.on_board {
type hw;
card PCH;
}
# }}}
# {{{ In
pcm.multiroutein {
type route;
slave {
pcm "indev";
}
ttable {
0 { 0 1.0; 2 1.0; }
1 { 1 1.0; 3 1.0; }
}
}
pcm.indev {
type multi;
slaves {
a {
#pcm "dsnooped";
#pcm "loopbacksnoop";
pcm "headset";
channels 2;
}
b {
#pcm "loopbacksnoop";
pcm "on_board_alt";
#pcm "dsnooped";
channels 2;
}
}
bindings {
0 { slave a; channel 0; }
1 { slave a; channel 1; }
2 { slave b; channel 0; }
3 { slave b; channel 1; }
}
}
pcm.loopbacksnoop {
type dsnoop;
ipc_key 512;
slave {
rate 44100;
pcm "on_board_alt";
buffer_size 8192;
period_size 2048;
#periods 128;
period_time 0;
buffer_time 0;
channels 2;
}
}
pcm.dsnooped {
type dsnoop;
ipc_key 2048;
slave {
rate 44100;
pcm "headset";
buffer_size 8192;
period_size 2048;
#periods 128;
period_time 0;
buffer_time 0;
channels 2;
}
}
pcm.on_board_alt {
type hw;
card PCH;
device 2;
}
pcm.headset {
type hw;
card Headset;
}
# }}}Also notice that i did not have to replicate the output through ALSA into loopback as I did in my first post.
Last edited by toi (2014-05-24 21:52:03)
Offline
Drop all the hints and bring some order into this configuration, following the signal path for example, starting from default.
defaults.ctl.!card "PCH";
pcm.!default {
type plug;
slave.pcm "asymed";
}
pcm.asymed {
type asym
playback.pcm "dmixed"
# capture.pcm "dsnooped"
capture.pcm "multiroutein";
# capture.pcm "loopbacksnoop";
}
...Last edited by emeres (2014-05-24 21:36:10)
Offline
I updated my previous post with a better structured config.
I am noticing this output a lot from ffmpeg:
[libvorbis @ 0x22edac0] Queue input is backward in time
Last message repeated 2 timeswith varying number of times repeated.
I am also getting a ticking sound in the background when I am playing the ffmpeg generated file when trying to capture the two dsnoop pcm:s.
Last edited by toi (2014-05-24 21:58:03)
Offline
On a sidenote; I managed to use the two dsnoop pcm:s with ffmpeg directly instead of trying to mix them with alsa.
fmpeg -y \
-f alsa -ac 2 -i dsnooped \
-f alsa -ac 2 -i loopbacksnoop \
-filter_complex amix=inputs=2:duration=first:dropout_transition=3 \
-video_size 1920x1080 -framerate 25 -f x11grab -i :0.0 \
/run/media/toi/Storage\ E/Recordings/fftest.mkvThis seems to be working pretty nicely. Haven't made any lengthy videos though.
Offline
First, some configuration notes. Using compound assignments for one subkey value is really inefficient. Use slave.pcm "VALUE" instead. Further you can use type plug (pcm.multiroutein) instead of simple route, since it also accepts ttable. Either use buffer/period size or time, not both.
It seems software mixing with type multi is problematic for both dmix and dsnoop apparently. You may want to read this thread. I would say that this is either a conversion issue (try "plug:[dnooped|loopbacksnoop]" for pcm.indev.slaves.[a|b].pcm, also try putting plug in between other plugins (pcms)) or alsa itself has a structural code issue here.
As for the artefacts in sound, well LADSPA might help. Look up its plugins, at least a combination of some of them should reduce cracks and similar. But the latency just grows further and further. However trying plughw should not hurt:
pcm.indev.slaves.a.pcm "plughw:Headset"
pcm.indev.slaves.b.pcm "plughw:PCH,2"
#makes pcm.headset and pcm.on_board_alt obsoleteMaybe specific parameters for the sound modules could help. Check dmesg and other log sources for any hints what is going on.
So this would be a case for alsa-user mailing list. If you are going to write them, it would be nice to either know the proper configuration or have the code issue resolved, for both inputs and outputs (dsnoop and dmix).
Another possible option would be using pcm.file, search for "alsa type file virtual mic".
Your ffmpeg warning might be related to the latency this setup is creating.
Edit: Great workaround, might be helpful some day. I leave the rest of my post in place though.
Is your issue solved then?
Last edited by emeres (2014-05-25 00:00:43)
Offline
Well partly solved. I have a solution for it, but it's not really the solution to the formulated problem. I will however mark this thread as solved as the solution is very acceptable with no noticeable drawbacks. Thanks for the help!
I may do further testing with ALSA. I tried the different plughw suggestions but to no avail. I also changed to type plug for pcm.multiroutein and used period_size and period_time which also didn't seem to help.
Last edited by toi (2014-05-25 00:52:08)
Offline
Yes, it would be nice to have things cleared up on this topic.
[...] used period_size and period_time which also didn't seem to help.
Misunderstanding here, I meant using either buffer_size and period_size or buffer_time and period_time. There are also other possibilities here. I already pointed to the documentation on this. The reason is stated here. It does not matter for this issue, although increasing the buffer size to 8x or 16x or even higher times period size, could reduce sound artefacts.
Glad I could help.
Last edited by emeres (2014-05-25 01:02:34)
Offline
Yes, it would be nice to have things cleared up on this topic.
toi wrote:[...] used period_size and period_time which also didn't seem to help.
Misunderstanding here, I meant using either buffer_size and period_size or buffer_time and period_time. There are also other possibilities here. I already pointed to the documentation on this. The reason is stated here. It does not matter for this issue, although increasing the buffer size to 8x or 16x or even higher times period size, could reduce sound artefacts.
Glad I could help.
Ahh yes. I had trouble understanding you so I assumed you meant the same as this mentions.
The artifacts only occurred when using the hw directly and not when using the dsnoops pcms.
When trying to mix the two dsnoops, with ALSA, it occurred a clicking sound in the background, as mentioned before. Now when I changed the buffer and period sizes (temporarily) the clicking in the background became less frequent as the period buffer was large. So the clicking is probably tied to the period buffer size.
Last edited by toi (2014-05-25 01:30:04)
Offline
# Buffering (period time defaults to 125000 usecs).
# Size of period, expressed either in usec or byte units:
# period_time USECS
# period_size BYTES# Size of buffers, expressed either in period, usec, or byte units:
# periods PERIODS
# buffer_time USECS
# buffer_size BYTES# The ALSA docs have examples with 'period_time' set to 0, when
# 'period_size' and 'buffer_size' are used instead, but this can
# cause trouble in later releases of ALSA.# For OSS compatibility, 'period_size' and 'buffer_size' should
# be powers of 2. Also, many cards cannot accept a 'period_size'
# much greater than 4096, so 4096 is mostly safe. Some like the
# nForce 8x0 compatibles require a smaller one still.# On my VIA 8233A, any value for 'period_time' greater than
# 85333 usecs (precisely!) causes hiccups in sound output.
# Why? At 48kHz, 85333 usec are just over 4096 bytes/channel.[...]
ctl.dmixer { type hw; card 0 }
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:0,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
}
bindings { 0 0 1 1 }
}
I do not want to dwell on this, it is just so funny to see this again. Whoever wrote this, says using period_time=0 may cause problems with later ALSA versions, and then uses it.
The example I provided earlier on the dmix plugin is very unfortunate when it comes to style and format. I always have to reread that one segment to make sure I got it right. It also states user should set either size or time for buffer and period (one can use period_time and buffer_size, but that may be a little inaccurate), which apparently leads to people using all four parameters, although only two are necessary. And the worst part is, that this is on so many wikis.
Again, I know you understand this, hopefully this little expose will convince others not to bloat their configuration unnecessary. Sorry for my zsh-like syntax of the language of mixing several possibilities bringing confusion.
You can use speaker-test to determine maximal buffer and period size. To further elaborate: period hold the samples, buffer holds periods, which is the reason another option to set buffer is to use "periods" parameter, setting the number of periods in the buffer.
I have an ALC892 codec also, so you probably can set buffer size to maximum 16384 bytes and period size to 1024 (it may accept more, mine shows 1025 as max. and 1023 as min.). Maybe/hopefully then the clicks/anomalies will disappear completely. Another options could be reducing the sample rate, but you probably do not want that.
Offline
...
To test this config i am using ffmpeg:ffmpeg -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0 -f alsa -ac 2 -i default /run/media/toi/Storage\ E/Recordings/fftest.mkv...
I actually managed to get it working by setting -ac 2 to -ac 4. I get the error message:
[libvorbis @ 0x1147440] 4.0 not supported by Vorbis: output stream will have incorrect channel layout.I can however successfully play the recorded file in smplayer and VLC and I am hearing the mic and the loopback.
Offline