I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver)
OpenAL seems to have enough functionality to do the job.
Are there any problems with using OpenAL for such a purpose?
- Nick
On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote:
Are there any problems with using OpenAL for such a purpose?
Probably not, it depends on the exact level of abstraction OpenAL gives. But it begs the question - why?
thanks -mike
On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote:
Are there any problems with using OpenAL for such a purpose?
Probably not, it depends on the exact level of abstraction OpenAL gives. But it begs the question - why?
thanks -mike
The reason for using OpenAL is for platforms that dont have alsa/oss/esd/... support For one it gives a chance to test audio on windows for example -- and on mac osx (although the winecoreaudio driver is making great progress).
- Nick
The reason for using OpenAL is for platforms that dont have alsa/oss/esd/... support For one it gives a chance to test audio on windows for example -- and on mac osx (although the winecoreaudio driver is making great progress).
planning to use OpenAL for portability reasons is a bad idea IMO: - it won't support the mapping required by dsound (unless we decide to drop the HW support) - OpenAL is overkill (in terms of API) for portability (PortAudio would be better IMO) - OpenAL doesn't support recording AFAICT
A+
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly
The OpenAL api is rather simple - For playback : you make buffers and queue them then poll them (to find out when they are done) There are some extensions that cut out copies/support eax/... (I have not looked at em yet) (support 2d and 3d audio) - For recording (1.1 only) : start capturing -- poll (get data -- if there) -- stop recording
The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good)
PortAudio looks like a good choice as well -- afaict -- but I dont have any exp with it (not that I had any openal exp when i started that driver hehe)
----- Should I just submit my driver to wine-devel and see what people think? It does work for wavein/waveout (still trying to flesh out a few issues)
- Nick
Nick Burns wrote:
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly
half or full duplex ?
The OpenAL api is rather simple
- For playback : you make buffers and queue them then poll them (to
find out when they are done) There are some extensions that cut out copies/support eax/... (I have not looked at em yet) (support 2d and 3d audio)
hmm that's what we said for Alsa... 3 years later quality is still not there :-/
- For recording (1.1 only) : start capturing -- poll (get data -- if
there) -- stop recording
The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good)
I doubt it for direct HW mapping (HEL should be fine). Unfortunately, no doc.
PortAudio looks like a good choice as well -- afaict -- but I dont have any exp with it (not that I had any openal exp when i started that driver hehe)
The whole point here is that OpenAL doesn't bring much to the picture (apart perhaps from a portability perspective, but it's still overkill). A+
Date: Tue, 06 Jun 2006 22:36:26 +0200
Nick Burns wrote:
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly
half or full duplex ?
Unknown... (sorry not an openal master ...yet...). I can ask the dev working on OpenAL about these types of things.
The OpenAL api is rather simple
- For playback : you make buffers and queue them then poll them (to find
out when they are done) There are some extensions that cut out copies/support eax/... (I have not looked at em yet) (support 2d and 3d audio)
hmm that's what we said for Alsa... 3 years later quality is still not there :-/
Hehe -- I had no knowledge of this (just learned oss, alsa and openal existed like 3 weeks ago)
- For recording (1.1 only) : start capturing -- poll (get data -- if
there) -- stop recording
The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good)
I doubt it for direct HW mapping (HEL should be fine). Unfortunately, no doc.
Hmm... Is there a way I can request some docs (or is the source code + msdn the doc)?
PortAudio looks like a good choice as well -- afaict -- but I dont have any exp with it (not that I had any openal exp when i started that driver hehe)
The whole point here is that OpenAL doesn't bring much to the picture (apart perhaps from a portability perspective, but it's still overkill). A+
I would not say overkill (well maybe for linux its overkill but....)
Mac OSX only has JACK(does not work atm), ESD(...slow), and now CoreAudio(crashs in winecfg -- does play games -- but has ... static) drivers CoreAudio is the only one that can show any decent performance -- and its not really very... Portable
OpenAL can show good performance on Mac OSX and other platforms (so others can test things and stuff -- even under windows)
I am not saying that OpenAL should be the catch-all sound driver -- but its nice to have an alternative (that I can play GTA3 with -- although i suggest not playing with a trackpad)
You can take a look at my driver (posted to this list -- and its in the archive at http://www.winehq.org/pipermail/wine-devel/2006-June/048273.html) It is heavily based on the esd driver (my starting point). Which was heavily based off of arts/alsa...
- Nick
Nick Burns wrote:
Date: Tue, 06 Jun 2006 22:36:26 +0200
Nick Burns wrote:
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes) -- My driver handles this atm -- it checks for recording capabilities and supports accordingly
half or full duplex ?
Unknown... (sorry not an openal master ...yet...). I can ask the dev working on OpenAL about these types of things.
it's not an openal point. it's whether you can open, in two steps (from the windows point of view) the device in playback mode, then in record mode (keeping the playback mode opened)
The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good)
I doubt it for direct HW mapping (HEL should be fine). Unfortunately, no doc.
- For recording (1.1 only) : start capturing -- poll (get data -- if
there) -- stop recording
Hmm... Is there a way I can request some docs (or is the source code + msdn the doc)?
basically, look on MSDN at the dsound interfaces, and the way it's done on OSS
The whole point here is that OpenAL doesn't bring much to the picture (apart perhaps from a portability perspective, but it's still overkill).
I would not say overkill (well maybe for linux its overkill but....)
Mac OSX only has JACK(does not work atm), ESD(...slow), and now CoreAudio(crashs in winecfg -- does play games -- but has ... static) drivers CoreAudio is the only one that can show any decent performance -- and its not really very... Portable
OpenAL can show good performance on Mac OSX and other platforms (so others can test things and stuff -- even under windows)
I am not saying that OpenAL should be the catch-all sound driver -- but its nice to have an alternative (that I can play GTA3 with -- although i suggest not playing with a trackpad)
You can take a look at my driver (posted to this list -- and its in the archive at http://www.winehq.org/pipermail/wine-devel/2006-June/048273.html) It is heavily based on the esd driver (my starting point). Which was heavily based off of arts/alsa...
my point is linking to a 3D effect library for low level audio portability *IS* overkill as if someone suggests that for plotting a dot on a screen (and only that) you'd need opengl A+
-
Eric Pouech -
Mike Hearn -
Nick Burns