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?