Re: Re: sound through enbd

> > enbd would have some problems in a thin-client environment because you
> > would need to allocate a new sound device per thin-client,
> 
> Oh, I see, this is exclusive-open. I disregarded this problem - I
> supposed I could always speak to one of those mixer daemons like esd
> somewhere along the way or solve it somehow.  But yes, I noticed that
> r/w to several devices was held off while I had enbd running, serving
> from /dev/dsp.

For your purposes (and enbds) you should disregard it. I was merely
trying to fit it into my thin-client mindset, and found that it would
have problems with that.

It is exclusive-open, however for servers serving multiple users one
would like each user to be able to open it exclusively, and have the
results routed differently (it is a hack really, to overcome the fact
that applications write directly to soundcard...they never should have
in the first place, they should have played sound through an X extension
or something). Forwarding it to esd wouldn't be necesarry, what would be
necesarry is to give each user a new enbd-client (preferably owned by
that user), and have the device forward the commands to the enbd-client
associated with the user opening it.

Such a thing would be a generic solution for routing the enbd more
dynamically, and would contribute in solve other problems as well (my
removable media project etc.). It is probably not within enbd's goals,
I'm just speculating.

// Dag Sverre