Re: [ros-dev] Open Sound System porting

[Aleksey Bragin]

I didn't thoroughly look through the OSS source code, but if it has
some kind of platform-independent design in mind, then I would really
recommend porting, and porting with as minimal changes to the
original source code required (you probably are going to need a
wrapper-library, for ioctls at least, plus NT-specific parts).
I may help too, because of the usb stack wrapping I did a while ago.
WBR,
Aleksey Bragin.
>  I've been in touch with the guy that ported OSS to Haiku (open-
>  source BeOS)
>  after some
>  discussion with the folks over at #winehackers to get some help
>  with audio
>  development.
>  Anyway, basically the idea so far is to use OSS as a "fall-back" audio
>  driver
>  implementation. So unless there is a "better" driver installed (ie an
>  official one for
>  an audio device), ReactOS can use an Open Sound System driver instead.
>  The result? There will at least be sound functionality.
>  OSS is designed to be mostly platform-independent. By rewriting a
>  few of
>  the core
>  modules, the entire set of drivers will be able to work with whatever
>  platform you
>  desire.
>  This can be implemented on top of the existing MME API architecture
>  for the
>  moment, and
>  can later be translated to use the WDM audio framework.
>  Anyway, having stuck the OSS code into my local ReactOS source
>  tree, I'm
>  trying to
>  figure out how to get it to compile using rbuild. The first hurdle
>  I have
>  come across is
>  that there is extensive use of ioctl. Indeed it seems that most
>  ports of
>  OSS work on
>  platforms based on Posix (Unix?)
>  So my main question at this time is how to handle this? The calls in
>  question appear to
>  be documented inside a file called "soundcard.h" in the OSS sources
>  however
>  this just
>  seems to be definitions for the ioctl codes. So I suspect a
>  majority of the
>  drivers are
>  calling ioctl.
>  Therefore, I figure the best way around this is probably to provide
>  a fake
>  ioctl that
>  provides the expected functionality, and make this wrap
>  DeviceIoControl
>  with something
>  that can translate the ioctl parameters into whatever...
>  The only other way I see around this is to rewrite all calls to
>  ioctl, and
>  rewrite the
>  IOCTL codes with NT-style ones.
>  Thoughts/ideas?