From: Aaron McDaid (hoss at domain technologist.com)
Date: Sun 22 Apr 2001 - 23:43:42 IST
On Sun, Apr 22, 2001 at 09:41:45PM +0100, kevin lyda wrote:
> actually mpg123 on my system defaults to esd. redhat 6.2 box,
> mpg123-0.59r-4 is what an rpm -q returns.
Not on my system. Debian 2.2. mpg123 0.59q. Compatibility is important
to me and while I accept mixing is non-trivial I don't think it's
impossible to keep my version of mpg123 working.
OK. I should have first said I'm not an expert on sockets. I didn't
really mean network sockets. The likes of /dev/printer and a file
create by everybuddy are sockets apparently.
hoss at domain cookin:~ file /dev/printer
/dev/printer: socket
I don't really now why I brought them up! Aren't they kind of like fifos?
> and all the apps that create graphics on my box use libX11 and friends...
Graphics is very complex but I have my own theories on that;)
Sound is essentially a one way stream of data.
> esd does open sockets, but for its protocol. look into esddsp. as far
> as "just writing to a file," there's more to controlling an audio card then
> just spewing audio streams at it. volume, balance, etc.
Isn't that what /dev/mixer is for ;) I can see how controlling volume
etc. over a network could be a problem for my scheme. However the
solution is the same as that for /dev/dsp
Local access to /dev/dsp isn't a problem
> > Isn't one of the UNIX philosophies: Everything should be a file?
>
> then i assume you're against the socket call and just stick to opening in
> the tree where your portal fs is mounted?
Eh? I'm feeling confused and out of my depth here! portal fs?
> > But this hypothetical networking thing I'm talking about would
> > take whats written to /dev/dspX and send it. It would be
> > relatively transparent.
>
> it can't be. every soundcard has different ways of controling it's
> different bits. in addition kernel drivers listening to tcp/ip ports
> etc add way too much complexity. i think the solution for the wide
I never mentioned kernel drivers changing at all. I'm trying to come
up with a way for sound mixing to be done in userland while
maintaining compatibility with apps that want to output to /dev/dsp.
This program could do networking too but that doesn't affect the issue.
What is the problem with making /dev/dsp1,/dev/dsp2,/dev/dsp3 into fifos?
The run some daemon that reads from them, mixes them and puts the output
to /dev/dsp.
Any sound output program I've seen has a command line option to choose
which device to output to.
I only mentioned symlinks as a possible way to automatically choose a
free /dev/dsp[0-9]. Allowing multiples opens would help this also.
>
> kevin
Aaron
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:09:59 GMT