[Solved] System audio and microphone input, as one mixed stream?

Question

I'm using ffmpeg to record screencasts with this command:
ffmpeg -f alsa -ac 2 -i default -f x11grab -r 15 -s 1280x720 -i :0.0+0,17 -acodec pcm_s16le -vcodec libx264 -preset ultrafast -threads 0 -y video.mkv
It works really well for cases where I only need to record my voice ("Mic" capture works). However, there are situations where I would like to record both what I am saying, and what I am hearing. So, my question:
Is there a way to create a virtual ALSA capture device, which will provide the desired "mic + output" stream?
Last edited by Goran (2012-09-17 02:33:32)

Answer 1

Since I don't have a Realtek ALC663 codec chip, the best I can do is provide guidance.
While all the info you need is provided by the hda-analyzer program, it is confusing. What helped me (a bunch) to better visualize the "virtual wires" of my codec was to download it's datasheet.
I found one for the Realtek ALC663 here:
http://www.datasheetarchive.com/
Just search on "alc663" in the search bar at the upper right, then I had to click on the PDF symbol in the search results, which then displayed just the first page of the datasheet. But by clicking on that first page, the whole document could be downloaded... at least that's how it worked for me. Otherwise, try something like using the "Advanced Search" function of Google to search for PDF files with some relevant search words.
Then go to the Block Diagram page of that document. This is what really helped me understand/visualize the wiring. But to be redundant, this diagram should match the wiring shown in hda-analyzer... it's just more "human friendly".
Notice the hexadecimal numbers that are inside the ovals (0Dh, 1Bh, etc). For all my different codec chips, these numbers have matched the Node IDs shown in hda-analyzer (and all other ALSA data on my systems), but that might not be true for all codecs, so be careful.
Also notice that not all the "virtual wires" are shown. Just like in some electronic schematics, the document writers "cheated" by labeling a "virtual wire" and then using that label elsewhere in the document. For example, the "virtual wire" coming from Node 0Fh is labeled "Mono DAC". That "virtual wire" connects to the input of Node 17h on the wire labeled "MONO".
So let's follow some signals... like the "front" two stereo channels...
(1) The PCM digital audio signal will come in at Node 02h. This node seems to allow selection ("SRC"), convert from digital to analog ("DAC"), and volume control ("VOL") from -64 dB to 0 dB in 1 dB steps. This codec chip seems to support 44.1k, 48k, 96k, and 192k samples per second.
(2) It then heads to Nodes 0Fh and 0Ch, but let's just follow the 0Ch mixer node. Where it then leaves with a label called "Front DAC" and connects to many other nodes (14h, 15h, 19h, and more).
(3) But let's just look at Node 14h. The output (called "FRONT(Port-D)") would probably be connected to speakers if this was a laptop, or to jack(s) if this was a desktop. The input to this node has a mixer that mixes the "Front" and "Surr" channels, then it goes into an Input/Output amplifier ("I/Oa") before leaving the chip.
Hmmmm... think about that for a minute. An external connection that is obviously an output (speakers) has an input??? The answer is "yes" for this codec chip. I quote from the datasheet:
"Multiple analog IO (except MONO, PCBEEP, and HP-OUT) are input and output capable, and provide headphone amplifiers."
That was the feature that I used to create a hardware loopback in my ALC662 chip... and it appears that you can too on your ALC663. You probably need to just connect and/or unmute some nodes to do so using hda-analyzer. I've found that other codec chips from other manufacturers also have this ability.
So... assuming that you wanted to loop the "front" signal path that we just followed back as input (capture)... let's follow that path...
ALSA play to hw:?,? -> 02h -> 0Ch -> 14h -> ((22h -> 09h) or (23h -> 08h)) -> ALSA capture from hw:?,?
So fire up hda-analyzer and verify that the path that you want is connected and unmuted and make the required changes if they aren't. Simple, right?... chuckle.
In my case I used hda-analyzer to connect the front two stereo channels going to my "Line Out" into the capture input and found that I also needed to unmute some of the mixers/switches in that new path that were not available in alsamixer. Then I fired up alsamixer and played with it's controls until I got a good bouncy audio signal using:
arecord -vv -f cd -V stereo -D plughw:0,0 /dev/null
while simultaneously playing some tunes, to verify that it was working. Then told hda-analyzer to create a Python script of the changes. Then I used hda-analyzer to put the codec back to it's original condition and created another Python script.
Now I had scripts to turn on the hardware loopback and to turn it back off again. Like I said in that previous thread, the changes will disappear on a reboot unless you jump through even more hoops.
Obviously, you need to use the correct "plughw:X,Y" for your system (i.e. The correct sound card,device)... Hint: look at the output from "arecord -l". Like your codec, mine also had two capture devices to complicate matters, so I had to keep trying different alsamixer settings and/or "plughw:X,Y" parameters until things smoothed out.
Now just fire up projectM-libvisual-alsa and enjoy the trip... or try your screencast quest.
This is, by far, one of the hardest methods for loopback... but perhaps the most personally satisfying/frustrating, and with the fewest problems once it's working.
Good luck.
Last edited by pigiron (2012-09-17 00:05:18)