Re: [Liboss-devel] osscat

[Dave V. <va...@so...>]

Justin Hallett wrote:
> yes i meant kext, though I didn't want to go that route.  I'd rather 
> just
> a lib but a daemon migh tbe needed, though I guess to stay in the OSX
> spirit a kext would be that choice, just trying to get an offical feel 
> for
> the direction here i guess.
>
> Immediate would be good, an esd wrapper for a 0.1 release i think 
> would be
> good.  Then we can port it to core audio for a v1 release.

Making a real /dev/dsp would be an interesting project, but it's not 
really necessary. I was thinking about it mostly because it's not 
always a great idea to #define common words like "open". For example, 
the aRTs oss code uses open() to open /dev/dsp, but also has a C++ 
method someClass::open(). Liboss currently would not work there, since 
it would turn someClass::open() into someClass::oss_open()--but the 
best workaround is probably just to hack on aRTs's oss module. Just 
make an #ifdef in soundcard.h so that aRTs can #include it without 
#defining open(), and then make aRTs explicitly use oss_*() when 
necessary. I guess the folks upstream might not like that hack, so we 
could just make it into a whole new file "audioliboss.cc" or something.

I'm not sure that I agree that liboss should be moved from esound to 
CoreAudio. To make liboss based on CoreAudio, we would need to spawn a 
daemon, do a lot of IPC, do some conversion between types of sound, 
etc--esd already does most of this, is it worth rewriting all that? The 
things that esound doesn't do perfectly are:

1) The way it buffers audio now is reasonably prone to skipping (the 
threads stumble over each other a lot).
2) It doesn't do a great job of dealing with different audio devices. 
(It can't open for just for playing or just for recording; and it can't 
deal with non-default devices--so I can't play audio with esound while 
I have my USB mic attached. Weird, eh?)
3) It uses esound's standard methods for converting between, say, 16- 
and 32-bit audio. CoreAudio's methods are likely to be optimized.
4) The /dev/dsp "implementation" in esddsp.c isn't complete.

All of these need to be fixed in esound, even if we weren't making 
liboss. So it would be more efficient to have just one place to worry 
about these issues (esd), and fix them all there. The only concern I 
have with staying with esound is that it may not be quite as efficient 
(we have to profile that!). If the esd performance is not good enough, 
we could take the intermediate route of stealing some of the esd code 
for the daemon and dsp emulation, and dumping the stuff for mixing and 
all, replacing it with CoreAudio code.

Dave