Greetings Esteemed Gentlemen: I've been hacking around with ALSA (1.0.3b), Jack [CVS as of two weeks ago], and other audio miscellanea and have found it all to work wonderfully. I've managed to add more tasks to my already overworked home server (which runs my entire networking/firewalling/routing and service operations). A summary of just the audio tasks of possible interest and background: I have a 1.6Ghz Pentium 4 (pre-Northwood) with the PC133 chipset (i840), which has 82801BA-ICH2 audio hardware with the usual AC97 codec. Kernel is 2.4.25-lck1 [Con's low-latency patches, as well as HZ=1000 timebase changes.] The audio output jack is connected to my MERLIN phone system's music-on-hold port, which is fed mono/downmixed output via "mpg123 -z -q -2 -m". I have each (L + R) channels of my LINE-IN jack connected to two Phone Patch boxes to monitor phonecalls "for Quality purposes" automatically. I had to write that recording software, which does configurable SQUELCH noise gating, and the like. The phone patch compensates for the differential levels of the send/receive sides of phone conversations, so the resulting mix has each side of the phonecall sounding about the same amplitude. It's the only way to do this. I found the Jack audio interface to be interesting and friendly, so I wrote the software to the Jack API, starting with one of the example client applications included with Jack. It's multi-threaded and event-driven, with callbacks from Jack when audio arrives. It works well. I then spawn off a child process to "lame -S --silent --nohist -q 2 -h -v -b 8 -B 32" with some ID3 tags representing the call's origin time, and any decoded DTMF tones, etc. This too works better than I imagined. Since it's spawned from the main process of my monitoring program, I don't tie up the audio monitoring/capturing threads during the encoding/processing operation. The jack and audio capturing threads run at RT priority, the rest run at normal priority. I run the encode jobs at nice +18. None of this skips ever, even during large file uploads/downloads from my 100BaseT connected SAMBA users, or during updatedb. This brings me to my question. It turns out that I should be sending a "beep" down the lines I am monitoring to notify the parties that they are being recorded. I have a spare output channel [the R channel of the main PCM device]. The L channel is providing music-on-hold, remember, via mpg123 which is using the ALSA driver. How can I configure ALSA (via asoundrc?) to split the PCM device into two independently accessible components for the L and R channels? I'm very pleased with mpg123 and do not feel I need to reinvent any wheels on that side. I don't feel it necessary to give Jack more to do, so I'd like to stay out of Jack if possible. (I run jackd with "jackd -R -d alsa -S -C -p 4096 -M -n 2 -r 11025"). The documentation for ALSA's asoundrc aspires for more than it can attain, alas. I suspect I need to configure some bindings, but it's not at all clear how I specify which channel in the device specification syntax. hw:0,0 refers the first device of the first soundcard, for example. But how do I specify the first (L) channel of the first device of the first soundcard? Ultimately, all that matters is Quality, =MB= -- A focus on Quality.