It's about time I laid out my theory in full.
/dev/dsp,/dev/midi,/dev/mixer are left alone. One program (hereafter
referred to as the daemon) writes to these.
The daemon listens to multiple fifos all over the place and to certain
TCP ports and mixes all the input together.
There could be a certain program whos job it is to find/create
a free fifo to write to. It could also create a mixer device. eg:
hoss at cookin~$ mksndsocket
hoss at cookin~$ xmms `mksndcocket` &
hoss at cookin~$ mpg123 `mksndsocket` &
mksndcocket could even look at the DISPLAY variable and inform
the local daemon that any write to those fifos are to be send
over the network to a remote daemon.
If a certain application wants it could talk direct to the remote
daemon if it knows the protocol. In fact, if a protocol is standardized
whereby mixing and the raw data are part of one stream then it could
still go through a different kind of fifo.
PS: mpg123 -s outputs to standard out. redirect this to a file and
the output can be cat(1)ed to /dev/dsp at will. This worked ok
with my old soundcard by my new one doesn't like the bit rates. I
have to pass extra parameters to mpg123 to get it going right.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!