> > > Someone approached me regarding a ReactOS port ... > > Seems like the ReactOS people were planning on using OSS as a fall > back > driver, doing the opposite of what I was suggesting and building a > wrapper interface which maps the MME (Windows legacy audio) or WDM > Audio > API to a kernel side OSS which is in control of the actual hardware. > > What I was suggesting was a userland map of the OSS API to the kernel > side > built-in Window WDM/KS audio interface.
You mean to help porting *nix apps to win ? isn't there already some kind of OSS emulation in cygwin ? It's probably old though. Or maybe it emulates esd or arts... Anyway it's a totally different goal, one is to help porting *nix apps, the other one is to provide more audio support. Of course for win it's not really that useful (wait, actually OSS drivers might actually work better, be way smaller and easier to install than the own vendor's CD full of I-install-myself-everywhere-and-mess-with-the-registry apps you are forced to install :))) > Working with the ReactOS people might be a great idea if you intend > to > actually provide kernel level OSS audio drivers for Windows which > provide > both a OSS API interface and the native windows audio interfaces. But > obviously you would still need a userland wrapper to map the OSS > system > calls (for example the Windows equivalent of ioctl() is > DeviceIoControl()). Yes of course, just as I did for BeOS/Haiku. We don't intend to expose the underlying OSS API because we have our own native one and we want to maintain consistency. So the media_server uses a userland addon that exposes the OSS drivers as native objects. Windows certainly has some kind of user support DLL also... > > I had a quick looked at the OSX audio subsystem but it seems a bit > > more > > complex than a simple kernel mode POSIX file driver... > >From my understanding, the lowest level interface in OSX is the Audio > HAL > (AudioHardware.h) which only accepts floating point input streams and > does > software mixing. This is similar to Vista's audio stack in > functionality. > Haiku does also have a system mixer using floats, then it forwards to the selected sound output node. But that's implemented in userland. cf. http://revolf.free.fr/Alchimie-7/Alchimie7_OSS_Haiku.en.pdf > I've been programming using the HAL simply because there appears to > be no > way to bypass the Audio HALs software mixing and get exclusive access > to > the drivers using the IOKit interface. > > However, from what I have read, some professional audio apps for OSX > require you to press a special key during boot to disable the Audio > HAL > from loading, and instead load their own drivers to get exclusive > access > to the hardware. That sounds hackish. > > So it looks as if you have three options in OSX: > > 1.) A userland API, as I was describing before, to emulate the system > calls. Downside is it requires a renaming to avoid naming > conflicts, > ie oss_ioctl() instead of an actual ioctl(). Not necessarily, if it's done with concern for cygwin and mingw it can actually hook in and have the ioctl() redirected to itself for the devices it publishes. Never really looked much into it though. You definitely want to check if they have already an OSS emulation. > 2.) Actually port real OSS drivers to OSX. Either bypass the HAL on > boot, > or you could also provide the IOAudio* interfaces required for > the HAL > to provide both the OSS interface and the native CoreAudio > interface > from the drivers. The XCode docs on my old PPC mac have a dummy > audio > driver shell showing what is required. I believe the path to it > was, > /Developer/Examples/Kernel/IOKit/Audio/Phantom... or something > like > that. There again, I'd rather have the thing splitted, you might want to use apps using OSS API, and have OSS drivers, but again bypassing the native API may be simpler but forces you to only use OSS drivers with those apps. Having the 2 things separate will allow better integration with native apps (card sharing, using native drivers, using oss drivers from native apps...) The only downside is the OSS emulation won't have all the features of OS itself, but there is really no reason I know to use xmixer on OSX. At least I myself value OS consistency enough not to do it that way. Besides, the Haiku port I did shows it's quite doable to expose if not all most of the features from OSS to the system. > 3.) Might be possible, but I have my doubts: use the IOKit to build a > kernel driver which simply provides the real OSS interface and > ioctls, > but routes the audio through either the HAL or actual OSX device > drivers. That's actually 2 separate projects as I said, and I'd favor that. (do you really need to fake a /dev/oss/ though ? wouldn't liboss emulation be enough for most apps ? also you might colide with the underlying real OSS which might want to publish devices, unless they are exposed differently to the HAL than through /dev). François. _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
