[linux-audio-user] Assistance with splitting up stereo channels in ALSA is appreciated.

[Malcolm Baldridge]

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.