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@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@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_r...
-- 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