guenter.geiger at psp-vie.be.philips.com
Fri Dec 4 23:06:17 CET 1998
> -----Original Message-----
>>>>>>>>>>>>>> From: opt at wrzk.farmersmanual.co.at
> - maybe there is already a solution for this, but whats shit on linux
> (besides the full-duplex mess) is that if one app has open dev/dsp you
> cant access it from another applicatiion.
I started a sounddriver for Linux who could do that (and still does on my
It´s working for SB16 cards, Terra Tech Base1, and ..uhm ..Turtle Beach
Ah, yes the es1668 chip based cards. Otherwise it supports the OSS API, so all
standard Apps work.
I think I am the only user of this driver ... it wasn´t really a great success.
> so you would need something like soundmanager on the mac,
> which "serves"
> virtual audio-devices but mixes them internally, so no app beside
> soundmngr really accesses dev/dsp. would this work with NAS
> for example?
> or what else?
Yes, and there´s another sound server (can´t remember it´s name).
I have written a sound server which mimics the SGI audio library, it was called
(Actually a shame that I didn´t make that public).
All this server based solutions will introduce an additional delay and .... will
your /dev/dsp too. ....
> on the other hand, i thought, maybe its possible to have pd to do this
> so an editor or a file player can connect to a internal-signal-inlet
> which you can then just mix or send it through processing
> chain ... but,
> in fact there's probably no way around recompiling each app you would
> want to use in this manner ... though .. i would go for it ...
That would be really cool. We could implement an ALSA API that just connects to
of the sound devices. We then would only have to recompile ALSA aware
(e.g CSound ..)
> - ... aeh, yeah, when will we do a workshop in "programming of
> pd-externals for the layman"?? (maybe somewhere in austria in earlier
Why not, if there´s enough interest .... (and Beer :R )
More information about the Pd-list