[ros-dev] Open Sound System porting

King InuYasha ngompa13 at gmail.com
Sun Sep 23 00:48:48 CEST 2007


the 4Front licensing FAQ about the GPLd version seems questionable...

On 9/22/07, reactos-development at silverblade.co.uk <
reactos-development at silverblade.co.uk> wrote:
>
> 4Front.
>
> Apparently it's "better".
>
>
> Original Message:
> -----------------
> From: King InuYasha ngompa13 at gmail.com
> Date: Sat, 22 Sep 2007 16:32:11 -0500
> To: reactos-development at silverblade.co.uk, ros-dev at reactos.org
> Subject: Re: [ros-dev] Open Sound System porting
>
>
> Which OSS implementation are you looking at? The OSS/Free one, or the OSS
> one from 4Front?
>
> On 9/22/07, reactos-development at silverblade.co.uk <
> reactos-development at silverblade.co.uk> wrote:
> >
> > Thanks for all the replies so far.
> >
> > I find it quite insane that MSDN compares ioctl to DeviceIoControl.
> Whilst
> > they achieve
> > the same results, the actual parameters used etc. are entirely
> different.
> >
> > I'm not sure if Steven's suggestion would work (ie, use ws2_32) since,
> to
> > my knowledge,
> > that particular implementation is specific to sockets.
> >
> > Probably the best way around this then, would be to make an ioctl
> wrapper
> > that takes the
> > OSS-specific IOCTL codes, and translates them into custom NT IOCTL
> codes.
> > The wrapper
> > would take things like structures being passed via the ioctl and send
> them
> > via
> > DeviceIoControl instead.
> >
> > It does seem like a fair amount of work but if an appropriate "wrapper"
> is
> > created, it
> > could work...
> >
> >
> > Original Message:
> > -----------------
> > From: King InuYasha ngompa13 at gmail.com
> > Date: Sat, 22 Sep 2007 10:28:50 -0500
> > To: ros-dev at reactos.org
> > Subject: Re: [ros-dev] Open Sound System porting
> >
> >
> > 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 <aleksey at 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 at reactos.org
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> >
> >
> > --------------------------------------------------------------------
> > mail2web.com – What can On Demand Business Solutions do for you?
> > http://link.mail2web.com/Business/SharePoint
> >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev at reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://link.mail2web.com/mail2web
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20070922/f368ae02/attachment.html 


More information about the Ros-dev mailing list