Nabble - OpenAL - Dev

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 isreleased!)

2009-11-10T16:56:21Z

The gstreamer pulseaudio src "plugin" captures audio fine. So there
must be some setup nuance required. I'll have a look at the pulsesrc
gstreamer piece and see how it does it.

Mike

On Tue, 2009-11-10 at 18:16 -0600, Mike Dickson wrote:

> Looking for one. I'll check that next. I think gstreamer has a pulse
> src module.
>
> So taking a seperate tack, is it possible to use the config file to use
> alsa for capture and pulseaudio for playback? How would that be set up?
> The pulseaudio alsa capture module does seem to work...
>
> Mike
>
> On Tue, 2009-11-10 at 16:05 -0800, Chris Robinson wrote:
> > On Tuesday 10 November 2009 12:49:33 pm Mike Dickson wrote:
> > > Using the test capture client source I've tracked this down to a hang in
> > > opening the capture device. The client opens the output device find and
> > > then opens the capture device. It hangs in pulse_open at line 391 at the
> > > call to ppa_threaded_mainloop_wait:
> > >
> > ...
> > >
> > > I'm a little confused by one thing.. Doesn't the call to set the
> > > state_callback need to go before the polling loop? I'm hesitant to
> > > start tinkering in here since this code is shared with the code that
> > > opens the output device and that *is* working fine..
> >
> > There's a call to ppa_context_set_state_callback before it attempts a
> > connection. The one that happens afterward is to set a different callback
> > which watches for context failures (eg. from the server being killed).
> >
> > If it hangs on ppa_threaded_mainloop_wait, that likely means the context isn't
> > fully connecting or failing, for some reason. Does pulseaudio recording work
> > with other apps?
> > _______________________________________________
> > Openal-devel mailing list
> > Openal-devel@...
> > http://opensource.creative.com/mailman/listinfo/openal-devel
>
>
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture

2009-11-10T16:37:21Z

On Tuesday 10 November 2009 4:16:45 pm Mike Dickson wrote:
> Looking for one. I'll check that next. I think gstreamer has a pulse
> src module.
>
> So taking a seperate tack, is it possible to use the config file to use
> alsa for capture and pulseaudio for playback? How would that be set up?
> The pulseaudio alsa capture module does seem to work...

There isn't a way to default to alsa for capture and pulseaudio for playback.
But you can configure alsa to use any capture device you want, by setting:
[alsa]
capture = <devicename>
in ~/.alsoftrc. You can then configure the app to use "ALSA Capture on
default".
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 isreleased!)

2009-11-10T16:16:45Z

Looking for one. I'll check that next. I think gstreamer has a pulse
src module.

So taking a seperate tack, is it possible to use the config file to use
alsa for capture and pulseaudio for playback? How would that be set up?
The pulseaudio alsa capture module does seem to work...

Mike

On Tue, 2009-11-10 at 16:05 -0800, Chris Robinson wrote:

> On Tuesday 10 November 2009 12:49:33 pm Mike Dickson wrote:
> > Using the test capture client source I've tracked this down to a hang in
> > opening the capture device. The client opens the output device find and
> > then opens the capture device. It hangs in pulse_open at line 391 at the
> > call to ppa_threaded_mainloop_wait:
> >
> ...
> >
> > I'm a little confused by one thing.. Doesn't the call to set the
> > state_callback need to go before the polling loop? I'm hesitant to
> > start tinkering in here since this code is shared with the code that
> > opens the output device and that *is* working fine..
>
> There's a call to ppa_context_set_state_callback before it attempts a
> connection. The one that happens afterward is to set a different callback
> which watches for context failures (eg. from the server being killed).
>
> If it hangs on ppa_threaded_mainloop_wait, that likely means the context isn't
> fully connecting or failing, for some reason. Does pulseaudio recording work
> with other apps?
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 isreleased!)

2009-11-10T16:05:51Z

On Tuesday 10 November 2009 12:49:33 pm Mike Dickson wrote:
> Using the test capture client source I've tracked this down to a hang in
> opening the capture device. The client opens the output device find and
> then opens the capture device. It hangs in pulse_open at line 391 at the
> call to ppa_threaded_mainloop_wait:
>
...
>
> I'm a little confused by one thing.. Doesn't the call to set the
> state_callback need to go before the polling loop? I'm hesitant to
> start tinkering in here since this code is shared with the code that
> opens the output device and that *is* working fine..

There's a call to ppa_context_set_state_callback before it attempts a
connection. The one that happens afterward is to set a different callback
which watches for context failures (eg. from the server being killed).

If it hangs on ppa_threaded_mainloop_wait, that likely means the context isn't
fully connecting or failing, for some reason. Does pulseaudio recording work
with other apps?
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: OpenAL SDK header compatibility

2009-11-10T15:54:57Z

On Tuesday 10 November 2009 7:42:41 am Daniel PEACOCK wrote:
> Hi Chris,
>
> I've made a note here. Next time we refresh the SDK we'll roll this
> change in.

Cool, thanks. :)
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 isreleased!)

2009-11-10T12:49:33Z

Using the test capture client source I've tracked this down to a hang in
opening the capture device. The client opens the output device find and
then opens the capture device. It hangs in pulse_open at line 391 at the
call to ppa_threaded_mainloop_wait:

while((state=ppa_context_get_state(data->context)) != PA_CONTEXT_READY)
{
if(!PA_CONTEXT_IS_GOOD(state))
{
AL_PRINT("Context did not get ready: %s\n",
ppa_strerror(ppa_context_errno(data->context)));

ppa_context_unref(data->context);
data->context = NULL;

ppa_threaded_mainloop_unlock(data->loop);
goto out;
}

ppa_threaded_mainloop_wait(data->loop);
ppa_threaded_mainloop_accept(data->loop);
}
ppa_context_set_state_callback(data->context, context_state_callback2, device);

I'm a little confused by one thing.. Doesn't the call to set the
state_callback need to go before the polling loop? I'm hesitant to
start tinkering in here since this code is shared with the code that
opens the output device and that *is* working fine..

Thoughts?

Mike

On Mon, 2009-11-09 at 19:57 -0500, Jason Daly wrote:

> Chris Robinson wrote:
> > On Monday 09 November 2009 5:01:46 am Mike Dickson wrote:
> >
> > > Great release!
> > >
> > > The pulseaudio support for output is working great for the apps I've
> > > tried. Much better performance overall than using the ALSA emulation.
> > > I do still have problems with pulseaudio capture, specifically with
> > > Vivox/secondlife. I'd like to help with that if possible but I'm new to
> > > the OpenAL sources so I hope an occasional question to the list is fine.
> > >
> >
> > There shouldn't be any issue about asking here. Thanks for wanting to look
> > into it. :)
> >
>
> No problem at all. That's one reason why the openal-devel list
> exists :-)
>
> --"J"
>
>
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622isreleased!)

2009-11-10T09:03:42Z

Ok, at least with a quick run I've verified that pulse capture isn't
working. If I use the ALSA driver (which will use the ALSA/pulse
adapter) capture works (albeit time compressed, I sound like Mickey
Mouse). With native pulse capture no playback and it loops trying to
play back endlessly.

I'll start with this and then move on to the Vivox client. Thanks for
this, it will be a big help.

Mike

On Tue, 2009-11-10 at 11:08 -0500, Jason Daly wrote:

> Mike Dickson wrote:
> > Can someone point me to a simple capture client w/source that uses
> > OpenAL-Soft for the capture? Starting with Vivox SLVoice directly is
> > going to be a pain since it's binary only..
> >
>
> Here's a really simple test app that I wrote. It captures audio for
> three seconds, pauses, then captures three more seconds. At the end it
> plays back what was captured.
>
> A lot of the values are hard-coded, so you may need to tweak it to get
> what you're looking for.
>
> --"J"
>

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622isreleased!)

2009-11-10T08:22:34Z

Thanks so much! This should get me pointed in the right direction.

Mike

On Tue, 2009-11-10 at 11:08 -0500, Jason Daly wrote:

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622isreleased!)

2009-11-10T08:08:25Z

Mike Dickson wrote:
> Can someone point me to a simple capture client w/source that uses
> OpenAL-Soft for the capture? Starting with Vivox SLVoice directly is
> going to be a pain since it's binary only..
>

Here's a really simple test app that I wrote. It captures audio for
three seconds, pauses, then captures three more seconds. At the end it
plays back what was captured.

A lot of the values are hard-coded, so you may need to tweak it to get
what you're looking for.

--"J"

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <AL/al.h>
#include <AL/alc.h>
#include <sys/time.h>

int main(void)
{
const ALCchar * devices;
ALCchar * ptr;
ALCdevice * mainDev;
ALCcontext * mainContext;
ALCdevice * captureDev;
ALubyte captureBuffer[655360];
ALubyte *captureBufPtr;
ALint samplesAvailable;
ALint samplesCaptured;
time_t currentTime;
time_t lastTime;
ALuint buffer;
ALuint source;
ALint playState;
int i;

// Print the list of capture devices
printf("Available playback devices:\n");
devices = alcGetString(NULL, ALC_DEVICE_SPECIFIER);
ptr = devices;
while (ptr[0] != NULL)
{
printf(" %s\n", ptr);
ptr += strlen(ptr) + 1;
}

// Open a playback device and create a context first
printf("Opening playback device:\n");
mainDev = alcOpenDevice(NULL);
if (mainDev == NULL)
{
printf("Unable to open playback device!\n");
exit(1);
}
devices = alcGetString(mainDev, ALC_DEVICE_SPECIFIER);
printf(" opened device '%s'\n", devices);
mainContext = alcCreateContext(mainDev, NULL);
if (mainContext == NULL)
{
printf("Unable to create playback context!\n");
exit(1);
}
printf(" created playback context\n");

// Make the playback context current
alcMakeContextCurrent(mainContext);
alcProcessContext(mainContext);

// Print the list of capture devices
printf("Available capture devices:\n");
devices = alcGetString(NULL, ALC_CAPTURE_DEVICE_SPECIFIER);
ptr = devices;
while (ptr[0] != NULL)
{
printf(" %s\n", ptr);
ptr += strlen(ptr) + 1;
}

// Open the default device
printf("Opening capture device:\n");
captureDev = alcCaptureOpenDevice(NULL, 8000, AL_FORMAT_MONO16, 800);
if (captureDev == NULL)
{
printf(" Unable to open device!\n");
exit(1);
}
devices = alcGetString(captureDev, ALC_CAPTURE_DEVICE_SPECIFIER);
printf(" opened device %s\n", devices);

// Wait for three seconds to prompt the user
for (i = 3; i > 0; i--)
{
printf("Starting capture in %d...\r", i);
fflush(stdout);
lastTime = time(NULL);
currentTime = lastTime;
while (currentTime == lastTime)
{
currentTime = time(NULL);
usleep(100000);
}
}

printf("Starting capture NOW!\n");
fflush(stdout);
lastTime = currentTime;

// Capture (roughly) five seconds of audio
alcCaptureStart(captureDev);
samplesCaptured = 0;
captureBufPtr = captureBuffer;
while (currentTime < (lastTime + 5))
{
// Get the number of samples available
alcGetIntegerv(captureDev, ALC_CAPTURE_SAMPLES, 1, &samplesAvailable);

// Copy the samples to our capture buffer
if (samplesAvailable > 0)
{
alcCaptureSamples(captureDev, captureBufPtr, samplesAvailable);
samplesCaptured += samplesAvailable;
printf("Captured %d samples (adding %d)\r", samplesCaptured,
samplesAvailable);
fflush(stdout);

// Advance the buffer (two bytes per sample * number of samples)
captureBufPtr += samplesAvailable * 2;
}

// Wait for a bit
usleep(10000);

// Update the clock
currentTime = time(NULL);
}
printf("\nPausing capture.\n");
alcCaptureStop(captureDev);

// Wait for three seconds to prompt the user
for (i = 3; i > 0; i--)
{
printf("Resuming capture in %d...\r", i);
fflush(stdout);
lastTime = time(NULL);
currentTime = lastTime;
while (currentTime == lastTime)
{
currentTime = time(NULL);
usleep(100000);
}
}

printf("Resuming capture NOW!\n");
fflush(stdout);
lastTime = currentTime;

// Capture (roughly) five seconds of audio
alcCaptureStart(captureDev);
while (currentTime < (lastTime + 5))
{
// Get the number of samples available
alcGetIntegerv(captureDev, ALC_CAPTURE_SAMPLES, 1, &samplesAvailable);

// Copy the samples to our capture buffer
if (samplesAvailable > 0)
{
alcCaptureSamples(captureDev, captureBufPtr, samplesAvailable);
samplesCaptured += samplesAvailable;
printf("Captured %d samples (adding %d)\r", samplesCaptured,
samplesAvailable);
fflush(stdout);

// Advance the buffer (two bytes per sample * number of samples)
captureBufPtr += samplesAvailable * 2;
}

// Wait for a bit
usleep(10000);

// Update the clock
currentTime = time(NULL);
}

printf("\nDone capturing.\n");
alcCaptureStop(captureDev);

// Play back the captured data
printf("Starting playback...\n");
fflush(stdout);

// Generate an OpenAL buffer for the captured data
alGenBuffers(1, &buffer);
alGenSources(1, &source);
alBufferData(buffer, AL_FORMAT_MONO16, captureBuffer,
samplesCaptured*2, 22050);
alSourcei(source, AL_BUFFER, buffer);
alSourcePlay(source);

// Wait for the source to stop playing
playState = AL_PLAYING;
while (playState == AL_PLAYING)
{
printf(" source %d is playing...\r", source);
fflush(stdout);
alGetSourcei(source, AL_SOURCE_STATE, &playState);
usleep(100000);
}
printf("\nDone with playback.\n");
fflush(stdout);

// Shut down OpenAL
alDeleteSources(1, &source);
alDeleteBuffers(1, &buffer);
alcMakeContextCurrent(NULL);
alcCloseDevice(mainDev);
alcCaptureCloseDevice(captureDev);
}

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 isreleased!)

2009-11-10T07:52:14Z

Can someone point me to a simple capture client w/source that uses
OpenAL-Soft for the capture? Starting with Vivox SLVoice directly is
going to be a pain since it's binary only..

Mike

On Mon, 2009-11-09 at 19:57 -0500, Jason Daly wrote:

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: OpenAL SDK header compatibility

2009-11-10T07:42:41Z

Hi Chris,

I've made a note here. Next time we refresh the SDK we'll roll this
change in.

Dan
Creative Labs (UK) Ltd.
Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

Creative Labs UK Ltd company number 2658256 registered in England and Wales
at 79 Knightsbridge, London SW1X 7RB

openal-devel-bounces@... wrote on 11/10/2009 01:13:31
PM:

> Just something of note, in case there's going to be an SDK update.
> The headers
> efx.h and xram.h declare their function pointer types using __cdecl, as
> opposed to the more appropriate AL_APIENTRY. Under Windows these arethe
same
> thing, but that's not guaranteed for other OSs (non-Windows systems use
the
> system/compiler default calling convention). Additionally, the
> __cdecl keyword
> doesn't tend to be valid for non-Windows compilers.
>
> Given that OpenAL Soft supports EFX for Linux/Unix systems, it would be
very
> nice if these could be changed so developers can more easily use the
headers
> in cross-platform code.
>
> Thanks in advance. :)
> - Chris
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

> ForwardSourceID:NT00076ADE

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

OpenAL SDK header compatibility

2009-11-10T05:13:31Z

Just something of note, in case there's going to be an SDK update. The headers
efx.h and xram.h declare their function pointer types using __cdecl, as
opposed to the more appropriate AL_APIENTRY. Under Windows these are the same
thing, but that's not guaranteed for other OSs (non-Windows systems use the
system/compiler default calling convention). Additionally, the __cdecl keyword
doesn't tend to be valid for non-Windows compilers.

Given that OpenAL Soft supports EFX for Linux/Unix systems, it would be very
nice if these could be changed so developers can more easily use the headers
in cross-platform code.

Thanks in advance. :)
- Chris
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 isreleased!)

2009-11-09T16:57:49Z

Chris Robinson wrote:

On Monday 09 November 2009 5:01:46 am Mike Dickson wrote:

Great release!

The pulseaudio support for output is working great for the apps I've
tried.  Much better performance overall than using the ALSA emulation.
I do still have problems with pulseaudio capture, specifically with
Vivox/secondlife.  I'd like to help with that if possible but I'm new to
the OpenAL sources so I hope an occasional question to the list is fine.


There shouldn't be any issue about asking here. Thanks for wanting to look 
into it. :)

No problem at all. That's one reason why the openal-devel list exists :-)

--"J"

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Pulse capture (was Re: OpenAL Soft 1.10.622 is released!)

2009-11-09T15:50:37Z

It's the vivox client I'm using with SecondLife at least to start.
Behavior is similar to the pulse output stuff before the large patchset.
It looks like it gets connected but no data. I've only just started to
mess with it, hopefully can dig deeper tonite. I'll follow up with
findings then.

Mike

On Mon, 2009-11-09 at 15:33 -0800, Chris Robinson wrote:

> On Monday 09 November 2009 5:01:46 am Mike Dickson wrote:
> > Great release!
> >
> > The pulseaudio support for output is working great for the apps I've
> > tried. Much better performance overall than using the ALSA emulation.
> > I do still have problems with pulseaudio capture, specifically with
> > Vivox/secondlife. I'd like to help with that if possible but I'm new to
> > the OpenAL sources so I hope an occasional question to the list is fine.
>
> There shouldn't be any issue about asking here. Thanks for wanting to look
> into it. :)
>
> What's the problem you're seeing with pulseaudio capture? I'm not sure if I
> have any working microphones laying around to test it myself.. need to look
> around more.
> _______________________________________________
> Openal-devel mailing list
> Openal-devel@...
> http://opensource.creative.com/mailman/listinfo/openal-devel

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Pulse capture (was Re: OpenAL Soft 1.10.622 is released!)

2009-11-09T15:33:26Z

On Monday 09 November 2009 5:01:46 am Mike Dickson wrote:
> Great release!
>
> The pulseaudio support for output is working great for the apps I've
> tried. Much better performance overall than using the ALSA emulation.
> I do still have problems with pulseaudio capture, specifically with
> Vivox/secondlife. I'd like to help with that if possible but I'm new to
> the OpenAL sources so I hope an occasional question to the list is fine.

There shouldn't be any issue about asking here. Thanks for wanting to look
into it. :)

What's the problem you're seeing with pulseaudio capture? I'm not sure if I
have any working microphones laying around to test it myself.. need to look
around more.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: OpenAL Soft 1.10.622 is released!

2009-11-09T05:01:46Z

Great release!

The pulseaudio support for output is working great for the apps I've
tried. Much better performance overall than using the ALSA emulation.
I do still have problems with pulseaudio capture, specifically with
Vivox/secondlife. I'd like to help with that if possible but I'm new to
the OpenAL sources so I hope an occasional question to the list is fine.

Mike

On Sun, 2009-11-08 at 23:46 -0800, Chris Robinson wrote:
> May we forget about 1.9...
>
> http://kcat.strangesoft.net/openal.html
>
> Hopefully, finally, for real, fixed the PulseAudio backend this time. Also
> fixed the OSS and Solaris backends. 7.1 output should work properly again, and
> fixed a problem/potential crash when setting an AL_EFFECT_NULL effect on an
> auxiliary slot.

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

OpenAL Soft 1.10.622 is released!

2009-11-08T23:46:42Z

May we forget about 1.9...

http://kcat.strangesoft.net/openal.html

Hopefully, finally, for real, fixed the PulseAudio backend this time. Also
fixed the OSS and Solaris backends. 7.1 output should work properly again, and
fixed a problem/potential crash when setting an AL_EFFECT_NULL effect on an
auxiliary slot.

In terms of features, there's only a few. Backend libraries are only loaded
when they're needed now, so unused backends won't hold their shared libs in
memory, and devices provided by them are automatically added and removed as
the libs are installed and uninstalled. Additionally, multiple contexts per
device are now supported.

Given multiple contexts, it's now possible to change certain device parameters
on the fly. Creating a new context with certain attributes (eg. ALC_FREQUENCY,
and perhaps ALC_REFRESH in the future) will change the device parameters, and
consequently affects all contexts on the device.

Now I'll try to get back to taking care of those proposed extensions. It may
be possible to see alcSuspendContext/alcProcessContext properly supported, as
well.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

OpenAL Soft 1.10 will be sooner than expected

2009-10-29T15:48:40Z

It turns out some bad issues popped up in 1.9, and I'd like to get a fixed
version out relatively soon. However, one of the issues is with PulseAudio not
playing sound. This is something I experience myself with the latest GIT
version of OpenAL Soft, however I'm not very familiar with Pulse, I can't find
a cause from reading the code and the online docs, and asking around for help
in #pulseaudio on FreeNode IRC didn't yield anything helpful. I don't know if
it's a problem with the code, or if PulseAudio is just being PulseAudio (as I
also have issues getting paplay to output sound, too).

So, if anyone reading is familiar with coding PulseAudio, it would be very
helpful if you could check out the latest GIT/SVN version of OpenAL Soft and
have a look through PulseAudio's code (in Alc/pulseaudio.c). Also, if anyone
/uses/ PulseAudio, checking out the latest GIT/SVN version and just seeing if
it woks would be helpful too (please note the PulseAudio version you use, and
any abnormal settings).

The GIT repo is here:
git://repo.or.cz/openal-soft.git
And the SVN repo is on Creative's server:
svn://connect.creativelabs.com/OpenAL

Thanks in advance!
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Downloading Mac Source

2009-10-28T16:05:22Z

I don't know if the problem was ever dealt with but this :

svn co svn://connect.creativelabs.com/OpenAL/tags/MacOSX1-2_Spec1-1

still results in this:

svn: Can't open 'C:\WINDOWS\TEMP\report.tmp': Access is denied.

on my macbook...

- David

Re: AL_EXT_source_distance_model revisit

2009-10-20T10:39:59Z

On Monday 19 October 2009 3:20:30 pm you wrote:
> You never know how a developer will decide to use a published API :-)
> So while 'normally' you probably wouldn't use these 2 mechanisms
> together, almost certainly someone will, so it's important to document
> the expected behavior.

Right. And in that case, alDistanceModel will reset every source's distance
model, whether one was explicitly set on it or not. It needs to reset the
model for generated sources to maintain backwards compatibility, and I don't
personally see a reason to special-case sources that had a distance model
explicitly set.

Though if people recommends otherwise, I won't complain too much. It's just an
extra flag per source that's set in alSourcei[v] with AL_DISTANCE_MODEL, and
checked in alDistanceModel.

Or perhaps another option I just thought of.. have an alEnable/alDisable
context state for per-source distance models. When disabled (default) the
context's model is used, otherwise the source's model is. Then alDistanceModel
has no explicit effect on source state, but the enable says which should be
used. Eg:

alSourcei(sID, AL_DISTANCE_MODEL, AL_LINEAR_DISTANCE_CLAMPED);
alDistanceModel(AL_NONE);
... AL_NONE is used for all sources ...

alEnable(AL_SOURCE_DISTANCE_MODEL);
... now linear distance clamped is used for sID, inverse distance clamped for
other sources ...

alDisable(AL_SOURCE_DISTANCE_MODEL);
... now AL_NONE is used for all sources ...

alGetSourceiv(sID, AL_DISTANCE_MODEL, &val);
... gives val == AL_LINEAR_DISTANCE_CLAMPED ...
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Get setting of Sound Blaster X-Fi Elite Pro

2009-10-20T01:51:18Z

Hi Rosemma,

The APIs to set and get these properties have not been published I'm
afraid, so it is not possible for you to control them from your own
application.

Dan
Creative Labs (UK) Ltd.

Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.

Creative Labs UK Ltd company number 2658256 registered in England and Wales
at 79 Knightsbridge, London SW1X 7RB

"GARIO Rosemma
(C.R.F.)"
<rosemma.gario@co To
nsulenti.crf.it> "openal-devel@...
Sent by: om"
openal-devel-boun <openal-devel@...
ces@... om>
eative.com cc

Subject
10/19/2009 04:31 [Openal-devel] Get setting of Sound
PM Blaster X-Fi Elite Pro

Dear All,
we have the sound blaster X-Fi Elite Pro installed on PC HP xw8600 with
Windows XP 64 SO.
We would get, with an our external program written in C++, the values
visualized by Creative Console that we launch selecting from menu
creative->SoundBlaster X-fi->Creative console utility. In particular, we
need to get the values managed by equalizer, and wave and MIDI synthesizer
gains. We tried with OpenAl library manual but we didn’t find anything
which describes such possibility. We don’t have a good know-how regarding
Open Al library…
Please Could you help us??
Are there any class methods / functions which could allow us to get such
values set by creative routine, and to overwrite them?

Best Regards
Rosemma Gario

p.s.
Sorry to my bad english

Gario Rosemma
Physical Ergonomics

Tel +39 011 9083890
e-mail: rosemma.gario@...

----------Internet E-Mail confidentiality
footer-------------------------------------------------
Le informazioni contenute in questo messaggio e-mail sono destinate
esclusivamente alla persone o enti cui è stata indirizzato e può contenere
informazioni riservate. E’ vietato ogni diffusione o altro utilizzo o
azione basata sul presente messaggio da parte di persone o enti diverse dal
destinatario, se non espressamente autorizzate dal mittente. Se avete
ricevuto questo messaggio per errore, siete pregati di contattare
immediatamente il mittente via e-mail e di cancellarlo da ogni vostro
computer.
The information transmitted in this e-mail message is intended only for the
person or entity to which it is addressed and may contain confidential
information.Any retransmission, dissemination or other use of, or taking of
any action in reliance upon, this information by person or entity other
than the intended recipient, if not clearly authorized by the sender, is
prohibited.If you have received this communication in error, please notify
the sender immediately by e-mail and delete the message from any computer.

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

ForwardSourceID:NT000763C6

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Get setting of Sound Blaster X-Fi Elite Pro

2009-10-19T08:31:47Z

Dear All,

we have the sound blaster X-Fi Elite Pro installed on PC HP xw8600 with Windows XP 64 SO.

We would get, with an our external program written in C++, the values visualized by Creative Console that we launch selecting from menu creative->SoundBlaster X-fi->Creative console utility. In particular, we need to get the values managed by equalizer, and wave and MIDI synthesizer gains. We tried with OpenAl library manual but we didn’t find anything which describes such possibility. We don’t have a good know-how regarding Open Al library…

Please Could you help us??

Are there any class methods / functions which could allow us to get such values set by creative routine, and to overwrite them?

Best Regards

Rosemma Gario

p.s.

Sorry to my bad english

Gario Rosemma

Physical Ergonomics

Tel +39 011 9083890

e-mail: rosemma.gario@...

----------Internet E-Mail confidentiality footer-------------------------------------------------
Le informazioni contenute in questo messaggio e-mail sono destinate esclusivamente alla persone o enti cui è stata indirizzato e può contenere informazioni riservate. E’ vietato ogni diffusione o altro utilizzo o azione basata sul presente messaggio da parte di persone o enti diverse dal destinatario, se non espressamente autorizzate dal mittente. Se avete ricevuto questo messaggio per errore, siete pregati di contattare immediatamente il mittente via e-mail e di cancellarlo da ogni vostro computer.

The information transmitted in this e-mail message is intended only for the person or entity to which it is addressed and may contain confidential information.Any retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by person or entity other than the intended recipient, if not clearly authorized by the sender, is prohibited.If you have received this communication in error, please notify the sender immediately by e-mail and delete the message from any computer.

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: AL_EXT_source_distance_model revisit

2009-10-15T22:41:17Z

On Thursday 15 October 2009 11:11:24 am Bob Aron wrote:
> • What happens when some of the sources are set to something other
> than the default and then the application calls alDistanceModel()?

All existing and newly-generated sources are set to the model given to
alDistanceModel, regardless if anything specific was set on the source.
Normally an app shouldn't use alDistanceModel if it's also using
AL_EXT_source_distance_model (except perhaps to set a global default on
initialization), so I don't think it really matters. Having alDistanceModel
simply reset all sources seems to be the simplest method while maintaining
backwards compatibility with code not aware of the extension. Especially since
there would be no way to "unset" a specific model to make alDistanceModel
affect it again.

> • What is the purpose of having different distance models for each
> source?

Different sounds may want different rolloff properties. For instance, some
sounds may want to follow a more natural inverse distance rolloff, while
others may want to use linear or a manual method to ensure reaching 0/min gain
at max distance (without losing EFX air absorption).

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: Issues with openal-soft 1.9.563 using pulse

2009-10-15T22:05:10Z

On Thursday 15 October 2009 5:50:40 pm Andres Mejia wrote:
> There are some issues that occur when using pulse as the backend driver for
> openal. For one, an application using openal will either hang (in the case
> of mplayer) or will not have any sound (in the case of warzone2100 and
> supertuxkart).
>
> This message appears in the terminal for each application.
> AL lib: pulseaudio.c:370: tlength (14544) is not a multiple of minreq
> (4096)!

That message is currently harmless, though it is a less than optimal response
(the total buffer size isn't a multiple of the period/update size).

> Second issue is mainly with mplayer. Aside from mplayer hanging, mplayer
> also always exits with this message.
> Inconsistency detected by ld.so: dl-close.c: 719: _dl_close: Assertion
> `map->l_init_called' failed!
>
> Setting openal to not use pulse will not give these issues.

Can't say I've seen this, though. Unfortunately, the PulseAudio backend is not
that well tested.. I don't use Pulse, and I can't leave it installed because
it interferes with normal playback (in particular, KDE4 likes auto-starting
it, which makes it disable my default dmix device until I restart KDE, at
which point it tries to restart Pulse again, etc). And it doesn't seem to work
correctly even when it is installed.

If anyone else can test and fix it, though, I'll gladly accept patches. But as
it is, I can't see anything wrong. The last test I was able to do showed that
Pulse simply wasn't calling the write callback even though everything looked
to be set up as it should.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Issues with openal-soft 1.9.563 using pulse

2009-10-15T17:50:40Z

There are some issues that occur when using pulse as the backend driver for
openal. For one, an application using openal will either hang (in the case of
mplayer) or will not have any sound (in the case of warzone2100 and
supertuxkart).

This message appears in the terminal for each application.
AL lib: pulseaudio.c:370: tlength (14544) is not a multiple of minreq (4096)!

Second issue is mainly with mplayer. Aside from mplayer hanging, mplayer also
always exits with this message.
Inconsistency detected by ld.so: dl-close.c: 719: _dl_close: Assertion `map-
>l_init_called' failed!

Setting openal to not use pulse will not give these issues.

--
Regards,
Andres
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: AL_EXT_source_distance_model revisit

2009-10-15T11:11:24Z

• What happens when some of the sources are set to something other than the default and then the application calls alDistanceModel()?

Do all the sources then switch to the new default? including those that had been explicitly set to some 'non-default' distance model already. If not, then the source object will have to maintain state not only for which distance model it should be using, but also whether it was explicitly set.

• What is the purpose of having different distance models for each source?

-bob

On Oct 15, 2009, at 10:21 AM, Chris Robinson wrote:

Poking about this one, first.

http://kcat.strangesoft.net/openal-extensions/EXT_source_distance_model.txt

Seems to be the simplest to handle, as it just makes a given source's distance
calculation use a source property value instead of the context property value.
Any issues with it that I may have missed? If not, I can go ahead and finalize
it.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

____________________________________________

CoreAudio Team • Apple Inc.

baron@...

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

AL_EXT_source_distance_model revisit

2009-10-15T10:21:50Z

Poking about this one, first.

http://kcat.strangesoft.net/openal-extensions/EXT_source_distance_model.txt

Seems to be the simplest to handle, as it just makes a given source's distance
calculation use a source property value instead of the context property value.
Any issues with it that I may have missed? If not, I can go ahead and finalize
it.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: OpenAL Soft 1.9.563 released!

2009-09-26T05:38:17Z

Great job, as always!

The additional flexibility in frequencies / sample formats is very welcome.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

OpenAL Soft 1.9.563 released!

2009-09-26T03:21:38Z

Next release up and ready for download.

http://kcat.strangesoft.net/openal.html

Lots of changes in this release. They include initial support for
ALC_EXT_disconnect on some backends (mainly ALSA, OSS, Solaris, and the Wave
Writer). It can also output 32-bit float for backends that can handle it
(ALSA, DSound, PortAudio, and PulseAudio), and capture can take the mono and
stereo float formats (ALSA and PulseAudio only). The ALC_FREQUENCY context
attribute will now try to change the playback rate of the device, setting a
rate that matches as closely as possible.

Of important note for users that have config files, there's been some changes.
The backend-specific 'periods' options will no longer work.. instead, it's
been made a global option. Additionally, the poorly named 'refresh' option is
deprecated and will be removed for the next version. It's replaced by the
period_size option, which is the number of sample frames mixed for every sound
update. It is multiplied by the periods to get the full buffer size in sample
frames. Ie..
buffer_size = periods*period_size
The old 'refresh' option is analogous to the buffer_size value, so if
period_size is left unset, you will get:
period_size = refresh/periods
The default is 4 periods of 1K frames each.

Current plans for OpenAL Soft 1.10 are multiple contexts per device, and
hopefully finalizing the ALC_EXT_thread_local_context extension (and the
others; which, incidentally, is first on the agenda). I'd like to see OpenAL
get more modular so that multiple plugins, that use OpenAL, can operate within
a single program without tripping all over each other.

Feel free to toss questions and/or comments my way. Thanks for looking!
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: ALC_ENUMERATE_ALL_EXT and pluggable sound devices

2009-09-25T11:13:37Z

Chris Robinson wrote:
> Also, those things I mentioned aren't merely cosmetic changes. You can't free
> and rebuild the lists for the device types that aren't being queried..
> otherwise the application can be holding pointers that become invalid, and it
> can crash if it tries to use them. (...)
>

You were right. Sorry, I didn't understand in code what you were saying.
By inspecting the Router code more closely, I clarified that I should
have done what you said...

The only difference from what you said is that I didn't call Build*
function from DllMain function, as by calling from there the application
hangs on a call to alcGetString from Creative driver (I don't know why).
I maintained the initialization of device listings and strings on
alcGetString, alcOpenDevice and alcCaptureOpenDevice, as you can see in
the attached patch. The most important change was to break out the
BuildDeviceList() function into SearchImplementation(),
BuildDeviceList(), BuildCaptureDeviceList() and BuildAllDevicesList().

Please check out the patch against the r1789 from Creative OpenAL
repository for Router files.

Regards,

-- Guilherme Balena Versiani.

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

openal-r1789-pluggable-listing.patch.gz (8K) Download Attachment

Re: ALC_ENUMERATE_ALL_EXT and pluggable sound devices

2009-09-24T13:18:28Z

On Thursday 24 September 2009 12:43:17 pm Guilherme Balena Versiani wrote:
> > First is (obviously) to make sure you don't leak the previous strings
> > (change the malloc calls to realloc, or free the old pointers first).
> > Also be careful that querying the default devices will also trigger
> > rebuilding the list. (...)
>
> I take care of this. But I didn't make any cosmetic changes like you
> mentioned, breaking up *BuildDeviceList* function, as my work is just to
> put it working and not maintain the code... After you validate that this
> code is fine, and if really want that, I send you another patch.

Just to clarify, I'm not the one that maintains the router. That would be
Daniel Peacock.

Also, those things I mentioned aren't merely cosmetic changes. You can't free
and rebuild the lists for the device types that aren't being queried..
otherwise the application can be holding pointers that become invalid, and it
can crash if it tries to use them. Eg..

const char *caplist = alcGetString(NULL, ALC_CAPTURE_DEVICE_SPECIFIER);
const char *devlist = alcGetString(NULL, ALC_DEVICE_SPECIFIER);

while(*devlist) {
printf("%s\n", devlist);
devlist += strlen(devlist)+1;
}
while(*caplist) { // crash; the capture device list was freed and allocated
// somewhere else during the ALC_DEVICE_SPECIFIER query
printf("%s\n", caplist);
caplist += strlen(caplist)+1;
}

Only the list being queried should be rebuilt. It's the same issue with
querying the default device.. only the default device string should be redone,
otherwise the other strings and lists the app is holding become invalid and
will crash when used.

> What I done:
>
> - In the start of *BuildDeviceList* there were a clause verifying
> first if the global variables was initialized. I just cleaned up them
> using free() and set them to NULL: *g_pDeviceList*,
> *g_pCaptureDeviceList*, and *g_pAllDevicesList*, and force their
> initialization every time *BuildDeviceList* is called.

You need to take care of the default device strings, too. Otherwise they're
leaked when FindDevice allocates new memory for them.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: ALC_ENUMERATE_ALL_EXT and pluggable sound devices

2009-09-24T12:43:17Z

Chris Robinson wrote:
> I'm not too sure if the router code on SVN is still up to date or not. I
> *think* I read it was, or at least wasn't changed significantly, but that was
> a while ago. I know the wrap_oal driver code isn't up-to-date.
>

Well, then I am using the last revision at Creative repository (*r1789*).

> If you're going to modify the router code on SVN, there's some things you need
> to be very careful of. These things bit me pretty hard when I was implementing
> it for OpenAL Soft.
>
> First is (obviously) to make sure you don't leak the previous strings (change
> the malloc calls to realloc, or free the old pointers first). Also be careful
> that querying the default devices will also trigger rebuilding the list. (...)

I take care of this. But I didn't make any cosmetic changes like you
mentioned, breaking up *BuildDeviceList* function, as my work is just to
put it working and not maintain the code... After you validate that this
code is fine, and if really want that, I send you another patch.

What I done:

- In the start of *BuildDeviceList* there were a clause verifying
first if the global variables was initialized. I just cleaned up them
using free() and set them to NULL: *g_pDeviceList*,
*g_pCaptureDeviceList*, and *g_pAllDevicesList*, and force their
initialization every time *BuildDeviceList* is called.
- I note a *BUG* in Creative driver for Windows when enumerating the
capture devices: it does not append the final '0' to the device string
list. Then I call *alcGetString* (for this driver) twice: once to get
the string pointer and to make it all zeroes, and another to get the
string list. This is a *very ugly hack*, but it does the work (I tested
using the latest Creative driver for a SoundBlaster soundcard I have).

It follows attached this simple change to be validated. Please help me
to check if this have any impact on other implementations.

Regards,

-- Guilherme Balena Versiani.

Index: OpenAL-Windows/Router/alc.cpp
===================================================================
--- OpenAL-Windows/Router/alc.cpp (revision 1789)
+++ OpenAL-Windows/Router/alc.cpp (working copy)
@@ -371,9 +371,27 @@
bool bUsedWrapper = false;
ALDEVICE *pDevice = NULL;

+ /// Always build the list ...
+ if (g_pDeviceList != NULL)
+ {
+ free(g_pDeviceList);
+ g_pDeviceList = NULL;
+ }
+
+ if (g_pCaptureDeviceList != NULL)
+ {
+ free(g_pCaptureDeviceList);
+ g_pCaptureDeviceList = NULL;
+ }
+
+ if (g_pAllDevicesList != NULL)
+ {
+ free(g_pAllDevicesList);
+ g_pAllDevicesList = NULL;
+ }
+
// Only build the list once ...
- if (((g_pDeviceList == NULL) && (waveOutGetNumDevs())) ||
- ((g_pCaptureDeviceList == NULL) && (waveInGetNumDevs())))
+ if ( (waveOutGetNumDevs()) || (waveInGetNumDevs()) )
{
//
// Directory[0] is the directory containing OpenAL32.dll
@@ -531,10 +549,23 @@
// Skip native AL component (will contain same Capture List as the wrap_oal component)
if (alcIsExtensionPresentFxn(NULL, "ALC_EXT_CAPTURE")) {
// this DLL supports capture -- so add complete list of capture devices
+
+ // Ugly hack: zero memory first, as Creative driver
+ // does not add the final '0' to the listing.
specifier = alcGetStringFxn(0, ALC_CAPTURE_DEVICE_SPECIFIER);
if ((specifier) && strlen(specifier))
{
do {
+ int len = strlen((char *)specifier);
+ memset((void *)specifier, 0, len);
+ specifier += len + 1;
+ } while (strlen((char *)specifier) > 0);
+ }
+
+ specifier = alcGetStringFxn(0, ALC_CAPTURE_DEVICE_SPECIFIER);
+ if ((specifier) && strlen(specifier))
+ {
+ do {
AddDevice(specifier, searchName, &g_pCaptureDeviceList);
specifier += strlen((char *)specifier) + 1;
} while (strlen((char *)specifier) > 0);

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: ALC_ENUMERATE_ALL_EXT and pluggable sound devices

2009-09-24T11:13:14Z

On Thursday 24 September 2009 10:16:12 am Guilherme Balena Versiani wrote:
> Does soft_oal.dll built from GIT current support updating the device
> list for every call to alcGetString? (Surely I will test, but if you
> have any directions, it would be fine)

Yes. It ultimately relies on DirectSound (for playback) and WinMM (for
capture) to actually enumerate new devices when queried, but AFAIK, they
should.

> > FWIW, the router itself can't directly support ALC_EXT_disconnect. The
> > ALC_CONNECTED token only works on non-NULL device handles and the rest of
> > the behavior is specific to the given device (nothing the router
> > explicitly handles). The router just needs to not assume a static device
> > list from the drivers.
>
> That said, I will start to make changes to OpenAL Router for Windows (at
> first place) to support this behavior. Could you tell me if there is
> some new version of OpenAL Router other than the official repository at
> Creative?

I'm not too sure if the router code on SVN is still up to date or not. I
*think* I read it was, or at least wasn't changed significantly, but that was
a while ago. I know the wrap_oal driver code isn't up-to-date.

If you're going to modify the router code on SVN, there's some things you need
to be very careful of. These things bit me pretty hard when I was implementing
it for OpenAL Soft.

First is (obviously) to make sure you don't leak the previous strings (change
the malloc calls to realloc, or free the old pointers first). Also be careful
that querying the default devices will also trigger rebuilding the list. You
can't have that happen, or else code like this:

const char *strlist = alcGetString(NULL, ALC_DEVICE_SPECIFIER);
const char *strdef = alcGetString(NULL, ALC_DEFAULT_DEVICE_SPECIFIER);

could leave strlist as an invalid pointer. Additionally, querying the device
list will change the default device, so this can fail, too:

const char *strdef = alcGetString(NULL, ALC_DEFAULT_DEVICE_SPECIFIER);
const char *strlist = alcGetString(NULL, ALC_DEVICE_SPECIFIER);

The way I handled this was to only build the list when the list was queried,
and find the default device from the existing list when that was queried (ie.
don't rebuild the whole list when the default device is requested, and don't
change the default device when the device list is requested).

As a consequence of this method, it should be encouraged to query the device
list first, before the default device name, or else the default device name
may be a disconnected device not found in the device list. I know some code
likes to query the default first, then the list.

One more point is, be careful to only rebuild the list being queried. Or else
this:

const char *pblist = alcGetString(NULL, ALC_DEVICE_SPECIFIER);
const char *caplist = alcGetString(NULL, ALC_CAPTURE_DEVICE_SPECIFIER);

can leave pblist as an invalid pointer due to the capture device list query
changing the playback device list.

Essentially, you need to break BuildDeviceList() into six functions..
BuildDeviceList - query the DLLs and build the playback device list
BuildCaptureDeviceList - query the DLLs and build the capture device list
BuildAllDevicesList - query the DLLs and build the all-devices list
FindDefaultDevice - find the default device in the playback device list
FindDefaultCaptureDevice - find the default device in the capture device list
FindDefaultAllDevices - find the default device in the all-devices list

Call the three Build* functions in DllMain under DLL_PROCESS_ATTACH (so an app
that queries the default device first has something to look in), and make sure
to call the appropriate one for the various alcGetString queries.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: ALC_ENUMERATE_ALL_EXT and pluggable sound devices

2009-09-24T10:16:12Z

Chris Robinson wrote:
> The GIT version of OpenAL Soft does:
> http://kcat.strangesoft.net/openal.html
>

That's fine. I will try to use it and make some tests.

> For having the device strings change, the router will need to be modified to
> requery the DLLs on behalf of the app. Dan said that could happen in the near
> future. The individual drivers (wrap_oal.dll, ct_oal.dll, soft_oal.dll, etc)
> will also need to support updating the device list when queried. The upcoming
> 1.9 release of OpenAL Soft will. Hopefully wrap_oal.dll (and ct_oal.dll as
> needed) can do that soon, too.
>

Does soft_oal.dll built from GIT current support updating the device
list for every call to alcGetString? (Surely I will test, but if you
have any directions, it would be fine)

> FWIW, the router itself can't directly support ALC_EXT_disconnect. The
> ALC_CONNECTED token only works on non-NULL device handles and the rest of the
> behavior is specific to the given device (nothing the router explicitly
> handles). The router just needs to not assume a static device list from the
> drivers.
>

That said, I will start to make changes to OpenAL Router for Windows (at
first place) to support this behavior. Could you tell me if there is
some new version of OpenAL Router other than the official repository at
Creative?

Regards,

-- Guilherme Balena Versiani.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

Re: ALC_ENUMERATE_ALL_EXT and pluggable sound devices

2009-09-24T04:27:32Z

On Wednesday 23 September 2009 11:22:22 am Guilherme Balena Versiani wrote:
> Do you know where can I find an implementation that supports
> ALC_EXT_disconnect? Is this extension multiplatform (I mean it is
> available)?

The GIT version of OpenAL Soft does:
http://kcat.strangesoft.net/openal.html

The Windows backends don't really make use of it, though. I'm not sure how
DSound reports an opened device being irrecoverably lost, so I wouldn't know
what to watch for except errors that won't go away.. but I think that will get
false positives from devices that can't be shared and are just temporarily
taken by another process.

> Can you explain me how the ALC_EXT_disconnect combines with OpenAL32.lib
> Router (Windows Router)? The problem I reported involves to change it, even
> if the OpenAL driver implementation supports ALC_EXT_disconnect...

At its most fundamental level, it should work with the router. You open a
device as normal, pass the handle to alcGetIntegerv with ALC_CONNECTED, and
the router should pass it to the device's implementation which reports on the
device's status. Calling alcIsExtensionPresent with the opened device will
report if the extension is supported on that device.

For having the device strings change, the router will need to be modified to
requery the DLLs on behalf of the app. Dan said that could happen in the near
future. The individual drivers (wrap_oal.dll, ct_oal.dll, soft_oal.dll, etc)
will also need to support updating the device list when queried. The upcoming
1.9 release of OpenAL Soft will. Hopefully wrap_oal.dll (and ct_oal.dll as
needed) can do that soon, too.

FWIW, the router itself can't directly support ALC_EXT_disconnect. The
ALC_CONNECTED token only works on non-NULL device handles and the rest of the
behavior is specific to the given device (nothing the router explicitly
handles). The router just needs to not assume a static device list from the
drivers.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel