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@gmail.com> wrote:
On 9/21/07, reactos-development@silverblade.co.uk
<reactos-development@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_reactos.c?revision=27850&view=markup
--
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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev