Re: [ros-dev] Open Sound System porting

4Front.

Apparently it's "better".

Original Message:
-----------------
From: King InuYasha [e-mail]
Date: Sat, 22 Sep 2007 16:32:11 -0500
To: [e-mail], [e-mail]
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, [e-mail] <
[e-mail]> 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 [e-mail]
> Date: Sat, 22 Sep 2007 10:28:50 -0500
> To: [e-mail]
> 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 [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
>
> mail2web.com – What can On Demand Business Solutions do for you?
> http://link.mail2web.com/Business/SharePoint
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web

[King InuYasha]

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

On 9/22/07, [e-mail] <
[e-mail]> wrote:
> 4Front.
>
> Apparently it's "better".
> Original Message:
>
> From: King InuYasha [e-mail]
> Date: Sat, 22 Sep 2007 16:32:11 -0500
> To: [e-mail], [e-mail]
> 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, [e-mail] <
> [e-mail]> 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 [e-mail]
> > Date: Sat, 22 Sep 2007 10:28:50 -0500
> > To: [e-mail]
> > 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 [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
> >
> > mail2web.com – What can On Demand Business Solutions do for you?
> > http://link.mail2web.com/Business/SharePoint
> >
> > Ros-dev mailing list
> > [e-mail]
> > 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
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev