-----Original Message-----
>>>>>>>> From: opt@wrzk.farmersmanual.co.at
<snip> > - 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 system). ItŽs working for SB16 cards, Terra Tech Base1, and ..uhm ..Turtle Beach Multisound. 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 "soundshame". (Actually a shame that I didnŽt make that public).
All this server based solutions will introduce an additional delay and .... will block 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 pd instead of the sound devices. We then would only have to recompile ALSA aware applications. (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 1999?)
Why not, if thereŽs enough interest .... (and Beer :R )
Guenter