[ros-dev] Open Sound System porting
ngompa13 at gmail.com
Sat Sep 22 04:02:52 CEST 2007
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 at gmail.com> wrote:
> On 9/21/07, reactos-development at silverblade.co.uk
> <reactos-development at 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
> > this just
> > seems to be definitions for the ioctl codes. So I suspect a majority of
> > drivers are
> > calling ioctl.
> > Therefore, I figure the best way around this is probably to provide a
> > 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,
> > 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
> 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 at reactos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ros-dev