alsa: reroute sound output to line in?

ondoho · 2013-11-07 18:10:35

Hello,
i've been on this for a week now, not getting anywhere.
but now i'm determined to crack the nut that is alsa.

a familiar problem: i want to use alsa's sound output - pcm or master - internally.

i have set up a loopback device now; it works with e.g. recordmydesktop, but the application i'm interested in seems to only chose the first capture channel of the default soundcard :-(
(it's sndpeek).

so, is it possible to duplicate & reroute the default card's pcm or master channel back into the default card's Line channel (Line in)?

of course i'm open to other suggestions.

thanks.

current .asoundrc (creates a 2nd sound card that i cannot access with sndpeek, but works otherwise)

pcm.!default {    type asym
                  playback.pcm "LoopAndReal"
                  #capture.pcm "looprec"
                  capture.pcm "hw:0,0"
}
pcm.looprec {       type hw
                    card "Loopback"
                    device 1
                    subdevice 0
}
pcm.LoopAndReal {     type plug
                      slave.pcm mdev
                      route_policy "duplicate"
}
pcm.mdev {            type multi
                      slaves.a.pcm pcm.MixReale
                      slaves.a.channels 2
                      slaves.b.pcm pcm.MixLoopback
                      slaves.b.channels 2
                      bindings.0.slave a
                      bindings.0.channel 0
                      bindings.1.slave a
                      bindings.1.channel 1
                      bindings.2.slave b
                      bindings.2.channel 0
                      bindings.3.slave b
                      bindings.3.channel 1
}
pcm.MixReale {        type dmix
                      ipc_key 1024
                      slave {   pcm "hw:0,0"
                                rate 48000
                                #rate 44100
                                periods 128
                                period_time 0
                                period_size 1024 # must be power of 2
                                buffer_size 8192
                            }
}
pcm.MixLoopback {     type dmix
                      ipc_key 1025
                      slave {   pcm "hw:Loopback,0,0"
                                rate 48000
                                #rate 44100
                                periods 128
                                period_time 0
                                period_size 1024 # must be power of 2
                                buffer_size 8192
                            }
}

- copied over from here.

the soundcard is a basic laptop intel chip.

$ dmesg|grep -i intel
...
[    1.037761] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[   19.315080] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X
[   20.408741] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[   20.408940] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
[   20.409100] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
...

thanks for any advice!

Last edited by ondoho (2013-11-07 19:37:46)

pigiron · 2013-11-10 03:55:23

so, is it possible to duplicate & reroute the default card's pcm or master channel back into the default card's Line channel (Line in)?

If you're talking about the analog audio path the answer is maybe. But fair warning, you'll be spending many more hours (maybe) getting it to work while wallowing real deep in today's integrated audio hardware and ALSA if you want to use this method.

the soundcard is a basic laptop intel chip.

This is the first thing you need to learn. That chip is generic and found on almost all modern x86 motherboards. Where the audio magic actually happens is the "codec" chip and the vendor/model varies. The HDA Intel chip merely "talks" to the codec chip which sits "behind" the HDA Intel chip on the bus.

So the first step is to figure out which codec chip is installed and then determine if you can "manually" connect the "virtual wires" inside the codec to make a connection from the output (play) to the input (capture).

One way that you might find which codec you have is to enter:
less /proc/asound/cardX/codec#Y
where "X" is your card number and "Y" is the codec number
Just look for "Codec:" near the top. Also, there's gobs of other good info in that file that will be used in a moment.

The codec chip contains what I call "virtual wires" that connect it's internal components (amplifiers, mixers, ADCs, DACs, etc). ALSA gathers info from BIOS and determines which connections to enable, but I've found that most codec chips have many connections that are not enabled. More importantly in this case, I've also found that many chips have a connection from the output (play) to the input (capture), it's just not enabled... and that may (or may not) also be the case for your chip. I've been able to enable the internal connections in my chips to create a hardware loopback so that Line Out is connected to Line In... so what you hear in the speakers is also sent to ALSA's capture interface... and the capture level is independently adjustable.

So how would you inspect and change these "virtual wires"? With a program called hda-analyzer. It will use the data in the /proc/asound directory (and more) to show you how your codec is wired in both text and graphics form, along with allowing you to change it. One way to get it is by running this command:

wget -O run.py http://www.alsa-project.org/hda-analyzer.py

I'll leave it to you to figure out which dependency packages need to be installed, but once you install them, run:

python2 run.py

where it will download yet more code (possibly in the /dev/shm directory) and will barf because you either need to install yet more dependency packages to run hda_analyzer.py, or simply because it tried to automatically run it using python3 (because it's also a python2 program, so run it manually like: "python2 hda_analyzer.py").

Once you get it running, the confusion factor will probably kick into high gear. Take your time and poke around. Get your bearings somewhat by clicking on "Graph" to display the wiring layout and hover your mouse over the square blocks and the wires. As I said in a previous post, if you can download the datasheet for your codec chip, it may help if it includes an internal diagram:

https://bbs.archlinux.org/viewtopic.php?id=147208
https://bbs.archlinux.org/viewtopic.php … 3#p1089243

Any changes you make to the "wiring" are instantaneous (so you can try it while making changes) and will go away on a reboot. Clicking "Exp" will create a python script of your changes that you can run later to make those connections again from the command line.

Good luck, and I'll check back to help if I can find the time... that is if you're up for such a major challenge.

Last edited by pigiron (2013-11-10 04:31:25)

ondoho · 2013-11-10 17:59:06

edit: forgot to mention that i undid the loopback mentioned in post #1, before starting to experiment with hda-analyzer.

thanks pigiron!
i was able to get the program started and found a datasheet, too.
as you predicted i've been fiddling for hours and still don't get the desired result...
your description from here is pretty consistent with my situation; but it seems that i can't influence some crucial settings with hda_analyzer - either the sliders jump back to zero, or some radio buttons can't be pressed.
i do get some sound effects, clicking, humming, feedback (there seems to be some safety setting that cuts in after a second of feedback, after that i can't produce feedback with that same channel anymore. but i guess that's a good thing).
here's a scrot of my realtek chip data sheet (its ALC883).

i thought taking the same route as you suggested, that would be:
02h -> 0Ch -> 14h -> ((22h -> 09h) or (23h -> 08h))
but the nodes 22h and 23h don't offer any adjustment in hda_analyzer. they are there, but no buttons or sliders.
there's the "big centerpiece" mixer 0Bh that has lots of sliders and mute buttons though.
hmmm...

Last edited by ondoho (2013-11-11 18:41:48)

pigiron · 2013-11-18 01:20:05

Well that really sucks. But there still might be a glimmer of hope.

Since I'm now running with a new motherboard with a different codec chip, I tried to retrace the steps I took when I wrote those earlier posts... and I had problems also... and things weren't as I remembered them (no surprise there). Bottom line is that I couldn't get it to work no matter what I tried either.

So I grabbed an old version of hda-analyzer that I had tucked away in the corner of my hard drive. When I ran it, it immediately barfed complaining about not being root... light bulb time.

So I jumped back to the fresh version of hda-analyzer I had just downloaded and tried it with root authority... success. So now my new ALC662 codec has hardware loopback working. I'm thinking hda-analyzer pokes files where being in the "audio" group won't help (possibly some files in /sys).

One thing I noticed that may be different than the past was that active connections are now shown in both dark and (very) light blue. I have no idea what the difference is. In my case, when I turned on the "Out" connection on 0x14 (which was labeled "In" in the hda-analyzer text screen... go figure), those connections on the graph now changed from gray to light blue (i.e. They became active). Then it was just a matter of unmuting some other nodes in the path.

Oh, I noticed that the "Active" radio buttons still don't work on most nodes, but I don't think you need those buttons. It seems to simply list the "In" connections for that node (but it won't necessarily tell you which are active).

Anyway, give root a try. It looks like your ALC883 path would be the same as my ALC662 codec (0x14 <-> ((0x23 <-> 0x08) OR (0x22 <-> 0x09)) to loopback the two front channels.

Your 0x22 and 0x23 look similar to mine. While they didn't offer any adjustments, they do have mute/unmute checkboxes, so here's another thing. To check if the connection of interest is muted/unmuted on a node, count down (1,2,3,etc) from the top of the Connection List on the text screen until you hit the connection of interest, then count down the same number of pairs in the list that has the mute/unmute checkbox pairs. In my case I needed to use that "counting" thing to unmute the correct connection pair (i.e. The connection coming from 0x14) on 0x22.

Like I said in that other post, I had one terminal running alsamixer (pointed to the correct card), then another terminal running this (pointed to the correct card and capture device... and you have two capture devices also, so you might try both):

arecord -vv -f cd -V stereo -D plughw:0,0 /dev/null

while playing a really long song... looking for a good bouncy signal in arecord's text VU meter as I tweaked alsamixer and hda-analyzer.

Arch Linux

#1 2013-11-07 18:10:35

alsa: reroute sound output to line in?

#2 2013-11-10 03:55:23

Re: alsa: reroute sound output to line in?

#3 2013-11-10 17:59:06

Re: alsa: reroute sound output to line in?

#4 2013-11-18 01:20:05

Re: alsa: reroute sound output to line in?

Board footer