Open Sound System porting

Hi guys,

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?

--------------------------------------------------------------------
mail2web.com - Microsoft® Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange

[David Johnson]

Do it! =) You have two weeks to have a functional alpha release.
On Sep 21, 2007, at 7:27 PM, reactos-development(a)silverblade.co.uk  
wrote:

>   Hi guys,
>
>  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?
>
>  --------------------------------------------------------------------
>  mail2web.com - Microsoft® Exchange solutions from a leading provider -
>  http://link.mail2web.com/Business/Exchange
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
_________________________________
Dave Johnson
http://www.davefilms.us DaveFILMS®
San Diego, CA & Nashville, TN
http://perditioncity.us/
Voice Talent
Writer, Producer, Director
Independent Audio Theater Producer
Voice mail and Fax#:[phone]
Voice [phone]
Skype & Msn Live messanger "DaveFilms"
AIM / iChat AV "DaveFilms2007"

[Steven Edwards]

On 9/21/07, reactos-development(a)silverblade.co.uk
<reactos-development(a)silverblade.co.uk> wrote:
>   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? 
You could write a wrapper for ioctl. I had a few ideas on this but you
might not even need to do that. Would ws2_32 ioctlsocket and WSAioctl
maybe work? You might have to add a static lib that does a WSAstartup
to each sound driver.

You might find something of use there. Also check out how Wine uses
ioctl to enumerate the devices in wine/dlls/iphlpapi verses

http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_…

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[King InuYasha]

Maybe it could be diverted through PulseAudio or ESD, since there does exist
an ESD server driver that pipes all of it to an ESOUND daemon. So if you
don't have an official Win32 driver, you could pipe it into PulseAudio and
PulseAudio could connect to OSS.

On 9/21/07, Steven Edwards <winehacker(a)gmail.com> wrote:
>  
>  On 9/21/07, reactos-development(a)silverblade.co.uk
>  <reactos-development(a)silverblade.co.uk> wrote:
> >   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? 
>  You could write a wrapper for ioctl. I had a few ideas on this but you
>  might not even need to do that. Would ws2_32 ioctlsocket and WSAioctl
>  maybe work? You might have to add a static lib that does a WSAstartup
>  to each sound driver.
>
>  You might find something of use there. Also check out how Wine uses
>  ioctl to enumerate the devices in wine/dlls/iphlpapi verses
>
>
>
> http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_…
>
>  --
>  Steven Edwards
>
>  "There is one thing stronger than all the armies in the world, and
>  that is an idea whose time has come." - Victor Hugo
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[King InuYasha]

I forgot to mention this means that sound mixing is then possible and it
would be possible to send sound over a remote connection using VNC and
ESD... It also permits a level of audio device abstraction...

On 9/21/07, King InuYasha <ngompa13(a)gmail.com> wrote:
>  
>  Maybe it could be diverted through PulseAudio or ESD, since there does
>  exist an ESD server driver that pipes all of it to an ESOUND daemon. So if
>  you don't have an official Win32 driver, you could pipe it into PulseAudio
>  and PulseAudio could connect to OSS.
>
>  On 9/21/07, Steven Edwards <winehacker(a)gmail.com> wrote:
> >  
> >  On 9/21/07, reactos-development(a)silverblade.co.uk
> >  <reactos-development(a)silverblade.co.uk> wrote:
> > >   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? 
> >  You could write a wrapper for ioctl. I had a few ideas on this but you
> >  might not even need to do that. Would ws2_32 ioctlsocket and WSAioctl
> >  maybe work? You might have to add a static lib that does a WSAstartup
> >  to each sound driver.
> >
> >  You might find something of use there. Also check out how Wine uses
> >  ioctl to enumerate the devices in wine/dlls/iphlpapi verses
> >
> >
> >
> > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/iphlpapi/ifenum_…
> >
> >  --
> >  Steven Edwards
> >
> >  "There is one thing stronger than all the armies in the world, and
> >  that is an idea whose time has come." - Victor Hugo
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>

[Magnus Olsen]

Hi
I been looking if it was posible todo, but it is not
it is allot lowlevel stuff u need emulated, Linux kernel handling DMA, IRQ,
IO complete diffent
and it is not posible port OSS driver to windows arch or ros, it will be
involed around 2 year coding
todo so, see the USB stack that is from linux crow stack, and the network
stack from freebsd
both took two year getting alive in reactos. and it is really bad idea
trying proting OSS
it will invold another 2 year works only getting it alive, then u need
getting bugs out.
sorry to say that. it is almost same time frame getting OSS and orginal WDM
audio
driver working. in devloping time. and it is bad decistions using OSS




----- Original Message ----- 
From: <reactos-development(a)silverblade.co.uk>
To: <ros-dev(a)reactos.org>
Sent: Saturday, September 22, 2007 2:27 AM
Subject: [ros-dev] Open Sound System porting


Hi guys,

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?

--------------------------------------------------------------------
mail2web.com - Microsoft® Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange



_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev