Subject: [linux-audio-dev] client/server stuff in MCS
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka 10 1999 - 12:33:13 EDT
[ i broke this out since it seems like a separate aspect of things
altogether
]
this client/server stuff: what is a client ? my best guess so far might be a
standalone program that wants to route its (say) audio through the
MCS. it seems that you propose using the event system for
this.
ignoring my misgivings about this for a moment, this is handled very
simply using a sensor thread plus the kind of shmem setup that Benno
has described. the sensor thread behaves exactly as would a sensor
thread reading from /dev/snd/pcmCnDnn. so thats easy.
but wait a moment: this implies that we have to code other
applications to use this system, and not the one that they would use
if they were writing to /dev/snd/pcmCnDnn. this isn't nice.
i think that its a much better idea to use esd-like
open/close/read/write redirection via LD_PRELOAD. our read/write
wrapper can take care of mapping the system call into a "scribble in a
shared memory buffer". the open/close wrapper converts a device open
to "shmget+shmat/shmdt" operations.
that way, applications can function without alteration with or without
a running MCS system.
% alias use_mcs='env LD_PRELOAD=/lib/mcs_wrapper.o'
% if [ $MOON_PHASE -gt 3 ] ; then
use_mcs oolaboola ...
else
oolaboola ...
fi
%
or (better):
% cat run-audio
#!/bin/sh
if [ -f /var/lock/mcs.pid ] ; then
exec env LD_PRELOAD=/lib/mcs_wrapper.o $*
else
exec $*
fi
% run-audio oolaboola ...
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST