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?

[King InuYasha]

Couldn't the source be patched to use DeviceIOControl instead of ioctl?
According to MSDN about porting from UNIX to Win32, ioctl maps directly to
DeviceIOControl, so it could be possible to simply change all the instances
of ioctl to DeviceIOControl...

On 9/22/07, Aleksey Bragin [e-mail] wrote:
> 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?
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev