On Friday 04 December 2009 3:53:46 pm Stefan Dösinger wrote:
Am 04.12.2009 um 18:51 schrieb Chris Robinson:
Though you'll still need a way to talk to the hardware. Using
ALSA/OSS/etc directly has proven problematic with not only the current
design and upkeep, but properly implementing
Am 05.12.2009 um 10:35 schrieb Chris Robinson:
Except it also has API-provided 3D features that would be a big benefit for
implementing DSound3D,
This is indeed a big plus for OpenAL - if we use our own sound system we'll
have to reimplement DSound3D features. It fits the sit on the shoulders
On Sat, Dec 5, 2009 at 12:50 PM, Stefan Dösinger stefandoesin...@gmx.at wrote:
Am 05.12.2009 um 10:35 schrieb Chris Robinson:
Except it also has API-provided 3D features that would be a big benefit for
implementing DSound3D,
This is indeed a big plus for OpenAL - if we use our own sound
Roderick Colenbrander thunderbir...@gmail.com writes:
Right now we are a couple of months away for a Wine 1.2 freeze. If
dsound-openal works well enough it might be a good short-term
solution but the code should be written in such a way that it would be
easy to move it to a wasapi backend (I
Hi Robert,
Robert Reif schreef:
I believe the approach you are taking moving openal into direct sound
is not a good idea and is going to create a lot of regressions that
can not be fixed with your current approach.
Windows audio programmers know that they can get access to the same
hardware
The current wine direct sound implementation can do multiple opens of
the same device and hardware mixing and hardware 3d acceleration without
any modifications if the low level driver supports it. No wine audio
driver implements all that because the linux audio APIs don't support
it. An
Robert Reif wrote:
The current wine direct sound implementation can do multiple opens of
the same device and hardware mixing and hardware 3d acceleration without
any modifications if the low level driver supports it. No wine audio
driver implements all that because the linux audio APIs don't
2009/12/3 Robert Reif r...@earthlink.net
Maarten Lankhorst wrote:
--
As I said, I'm confident nobody uses it, since wine never implemented it
properly anyway
---
I think you will find that you will have to add it back later because both
interfaces are commonly used.
The private
Hi,
Robert Reif schreef:
The current wine direct sound implementation can do multiple opens of
the same device and hardware mixing and hardware 3d acceleration
without any modifications if the low level driver supports it. No
wine audio driver implements all that because the linux audio APIs
Am 04.12.2009 um 16:00 schrieb Maarten Lankhorst:
I'm NOT going to touch our winmm drivers any more apart from maintanance. I
am willing to make 1 more, 'wine7audio' that forwards to IAudioClient, and
does all bizarre things like looping wave packets, etc there, so our audio
will be
On Friday 04 December 2009 7:50:59 am Stefan Dösinger wrote:
Wrt OpenAL, I am opposed to using it for our sound system. I think its a
good idea for the transition to Win7, as a first driver and probably later
reference driver. But I think we need an exit strategy to get rid of
OpenAL as a
Am 04.12.2009 um 18:51 schrieb Chris Robinson:
Though you'll still need a way to talk to the hardware. Using ALSA/OSS/etc
directly has proven problematic with not only the current design and upkeep,
but properly implementing various features. Not that I'm advocating
PulseAudio
here, but
I don't have issues with what Maarten is trying to accomplish. In fact
I'm happy to see someone making a serious effort to fix wine audio.
What I do have serious issue with is the way he is attacking the problem.
The windows 95 driver model is not a bad model. If you look at the
winmm
Maarten Lankhorst wrote:
--
As I said, I'm confident nobody uses it, since wine never implemented it
properly anyway
---
I think you will find that you will have to add it back later because
both interfaces are commonly used.
The private interface is used for enumerating devices and is
Hi Robert,
Robert Reif schreef:
Maarten Lankhorst wrote:
--
As I said, I'm confident nobody uses it, since wine never implemented
it properly anyway
---
I think you will find that you will have to add it back later because
both interfaces are commonly used.
The private interface is
David Adam schreef:
2009/12/3 Robert Reif r...@earthlink.net mailto:r...@earthlink.net
Maarten Lankhorst wrote:
--
As I said, I'm confident nobody uses it, since wine never
implemented it properly anyway
---
I think you will find that you
I believe the approach you are taking moving openal into direct sound is
not a good idea and is going to create a lot of regressions that can not
be fixed with your current approach.
Windows audio programmers know that they can get access to the same
hardware through multiple APIs at the same
On Thursday 03 December 2009 3:57:49 pm Robert Reif wrote:
I believe the approach you are taking moving openal into direct sound is
not a good idea and is going to create a lot of regressions that can not
be fixed with your current approach.
Windows audio programmers know that they can get
18 matches
Mail list logo
