Subject: [linux-audio-user] Assistance with splitting up stereo channels in ALSA is appreciated.
From: Malcolm Baldridge (linux-audio_AT_paypc.com)
Date: Mon Apr 26 2004 - 07:16:44 EEST
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.
This archive was generated by hypermail 2b28 : Mon Apr 26 2004 - 07:12:56 EEST