I found myself some free time between research and other work stuff. I played with JACK audio on my AMD64 system (http://www.jackaudio.org). In my opinion there are 3 things that GNU/Linux sux0rs at.. Audio, Printing, and Installing. Each one is a black art. JACK audio is yet another audio server, but it has a twist, it was designed and written to have zero-to-low latency. The server eats up 0.25% of my processor when it's running and I can't detect any latency (unlike some other sound daemons with several K buffers).
Jack shows some promise, it's installing it on an AMD64 system is probably my first mistake, since nothing works on AMD64 right away.. My second mistake is that I have 2 soundcards, and I'd like to use both of them. Problem, the JACK daemon supports one soundcard.. you have to run one daemon for each soundcard. Problem, JACK daemons don't talk to each other.
One of the reasons I took a liking to JACK was what it lets you do with connections. A GUI app like qjackctl (http://qjackctl.sourceforge.net/) can connect and disconnect apps to various sound interfaces while running. I can start playing an MP3, then disconnect the left, right, or both channels from my "sound card". My sound card is just an object that accepts a sound stream. Other objects that accept sound streams are, for example, Audacity (http://audacity.sourceforge.net/) so I can redirect the MP3 into Audacity. The music player is just a sound source, so is the MIC input.. you get the idea. Using this sort of system you can chain applications together, duplicate input or output, and generally be in total control of your sound. /me likes.
But I'm a special user, I have 2 sound cards (a 5.1 dolby system connected to an SB Audigy, and an el-cheapo AC'97 onboard jobbie connected to my headset earphone and mic). It would sure be nice to be able to redirect the output of any app to _either_ sound card, from a single interfece.. or redirect my headset MIC input to my 5.1 speakers (well, that's not very common, but I succeeded!, read on.)
I run Gentoo, JACK installed out of the box (emerge jack-audio-connection-kit). qjackctl also installed out of the box (emerge qjackctl). Fire up the GUI, set the driver to ALSA (JACK uses ALSA to actually talk to the sound hardware, it doesn't re-implement all the individual sound card drivers, that would be silly). Set my device to hw:1,0 (second sound card, the 5.1 system). And start the daemon. Recompile the various apps to use JACK.. and presto, sound works. Now, I actually followed the realtime guide too, so I could have the server running in realtime mode. I like my sound to be skip free, even when under load.
So what, when does the fun start? Well, I have spent many hours searching for a solution to use multiple sound cards. Everything I have read says the "best" solution is to combine multiple sound cards into one virtual card with 4 channels, instead of 2, and just use one JACK daemon. That's great, except first of all I couldn't get it to work, second, I don't want one big virtual sound cards, I have a 5.1 system and a headset, I want 2 separate cards.
I know I can run 2 JACK daemons, one for each card.. so, all I really need is a bridge. Something that registers itself as a client in both daemons, and just shunts sound back and forth. So I can do all the sound redirection in a single qjackctl window... and so I don't have to tell individual apps which JACK daemon to connect to, they all connect to the same one.
And here is my first crack at it: jack_bridge.c
There is a "master" daemon, and the "slave" daemon. The bridge connects to the slave JACK daemon, and just steals all MIC input, and forwards anything it gets to the speaker output. The bridge also connects to the master daemon, but doesn't do any stealing of signals, it just gives itself a name (I use "Headset" as the client name). In the qjackctl that is talking to the "master" daemon, I can create a connection between any app and "Headset", and the bridge accepts data from the master JACK daemon, and writes it to the slave JACK daemon.. which forwards it to the speakers which is actually the headset. Same for the MIC, only backwards.
It's not perfect, there is an audible ticking sound.. I don't think i'm transporting the data "real-time" enough.. sounds like it's playing just slightly too fast, creating a momentary break in the audio where there is no data.. no idea how to fix that yet :( .. but it works. :)
