On 9/22/07, Aleksey Bragin <aleksey@reactos.org> 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
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev