Nabble - OpenAL - User

iPhone OpenAL implementation

2009-11-25T13:27:25Z

Hi,
I am creating audio games for the iPhone and would like to know if
the iPhone implements Open AL features like HRTF from a mono source.
Specifically, I want to play stereo binaural sound files for the
environment, and have mono emitters processed with 3d audio techniques
such as HRTF, doppler, etc. Perhaps someone could point me to
documentation?

Kind regards,

Greg

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

Re: Learning OpenAL

2009-11-25T11:30:25Z

On Wed, 2009-11-25 at 12:58 -0500, Jason Daly wrote:
> No problem. I can't imagine why none of us brought it up in August
> when
> you asked the first time :-)
>
> --"J"

Surprised you even remembered!

--
Kip Warner -- Software Developer
President & CEO Kshatra Corp.
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

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

signature.asc (204 bytes) Download Attachment

Re: Learning OpenAL

2009-11-25T09:58:34Z

Kip Warner wrote:
> Thanks Jason. I should have looked at Creative's stuff first.
>
>

No problem. I can't imagine why none of us brought it up in August when
you asked the first time :-)

--"J"

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

Re: Learning OpenAL

2009-11-24T18:04:22Z

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

> Hi, Kip,
>
> Probably the most comprehensive document put out about OpenAL is the
> OpenAL Programmer's Guide by Creative. You can find it here:
>
> http://connect.creativelabs.com/openal/Documentation/Forms/AllItems.aspx
>
>
> That page also has the formal specifications for OpenAL and ALUT.
>
>
> Hope this helps...
>
> --"J"

Thanks Jason. I should have looked at Creative's stuff first.

--
Kip Warner -- Software Developer
President & CEO Kshatra Corp.
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

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

signature.asc (204 bytes) Download Attachment

Re: Learning OpenAL

2009-11-24T15:10:49Z

Kip Warner wrote:
> Greetings Everyone,
>
> I desire to become proficient at a professional level with the OpenAL
> API and its usage. Since there is no official OpenAL book (well - there
> was, but never made it to print), does anyone recommend some other
> comprehensive resource? Right now I have access to "Beginning Game Audio
> Programming" which is about as close as I can find to it since it covers
> some of it.
>

Hi, Kip,

Probably the most comprehensive document put out about OpenAL is the
OpenAL Programmer's Guide by Creative. You can find it here:

http://connect.creativelabs.com/openal/Documentation/Forms/AllItems.aspx

That page also has the formal specifications for OpenAL and ALUT.

Hope this helps...

--"J"

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

Learning OpenAL

2009-11-24T12:48:55Z

Greetings Everyone,

I desire to become proficient at a professional level with the OpenAL
API and its usage. Since there is no official OpenAL book (well - there
was, but never made it to print), does anyone recommend some other
comprehensive resource? Right now I have access to "Beginning Game Audio
Programming" which is about as close as I can find to it since it covers
some of it.

Appreciated.

--
Kip Warner -- Software Developer
President & CEO Kshatra Corp.
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com

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

signature.asc (204 bytes) Download Attachment

Re: Support for Loop Points

2009-11-23T14:01:04Z

On Monday 23 November 2009 1:06:29 pm developer@... wrote:
> On the wishlist for a very long time:
> http://connect.creativelabs.com/openal/Lists/Wishlist/DispForm.aspx?ID=21
>
> Wanted to ask if there is any progress regarding that matter?

Speaking personally, it wouldn't be too hard to handle this in OpenAL Soft. We
would have to discuss some details though (eg. how should the loop points be
specified). I have a few other extensions I'm trying to get cleared away, and
I just yesterday did some internal reworking to see how feasible the requested
Matrix Operations extension would be, but I can try to come up with something
to propose after working through some of the stuff (if nobody else does by
then).
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Support for Loop Points

2009-11-23T13:06:29Z

On the wishlist for a very long time:
http://connect.creativelabs.com/openal/Lists/Wishlist/DispForm.aspx?ID=21

Wanted to ask if there is any progress regarding that matter?

Also read in the specs file for OpenAL:
B.8. Loop Point Extension
In external file now.

for whatever that means?

Thanks,
Jochen

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

Re: [Openal-devel] 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 mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

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 mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

problem in moving 1 source on 4 speakers

2009-11-05T03:07:23Z

Hello.
I'm a newbie of the list.
My issue is that I cant' move a single sound source around me when
using 4 speakers around me, i.e in the XZ plane according to OpenAL
specs.
I have MacOSX Leopard and use AudioMidi Setup under MacOSX to
configure the speaker setup first, then I launch my executable, which
uses the dynamic libraries downloaded from the macport version of
OpenAL 1.0.0

I do succeed in moving the source left to right and viceversa when
only stereo is set up. In order to move the source, I play the sound
first and then just overwrite the SourcePos vector and call:

alSourcefv(Source, AL_POSITION, SourcePos);

But when I change the speaker configuration to four speakers (through
AudioMidi Setup) and restart the executable, the first two channels
are correctly rendered (front left and front right, as it were
stereo), while the back channels sound very weak and the sound
amplitude seems uncorrelated with the position I give in input. What
could be the issue? Did I forget to speacify somewhere the speaker
configuration or everything should be done by the AudioMidiSetup?

I add that my soundcard normally works fine on my system using Ardour
per Mac while playing multichannel audio, i.e. the 4 channels are
correctly addressed, so a priori it may not be a harware or mixer
problem.

Thanks so much.

--

Luca

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

Re: Re: PCM.rear missing

2009-11-05T01:06:03Z

Hi Chris,

sorry, I mixed up 2 problems I had ( and have now resolved ).

First Problem: No Surround Sound on the Onboard Soundcard of the Shuttle SX58H7

* Driver Problem. Driver ( alsa 1.0.21 ) only supports stereo at the moment

Second Problem: No pcm.rear - Device:

* In earlier linux ( or alsa) - Distributions, there was a default rear - device for every sound-card ( listed when calling "aplay -L" )

* In newer versions it doesn't exist any more, but with some ALSA-configuration knowledge one could build it himself.

Best regards

Thomas

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

Re: Re: Re: PCM.rear missing

2009-11-04T00:15:18Z

On Tuesday 03 November 2009 11:44:39 pm Schneider, Thomas wrote:

> Yesterday I recognized it's not just PCM.rear missing, but also the rear
> speakers also don't play any sound in surround-Mode.
> To be application-independent I tried this with following command (
> trying surround40 surround51,surround71, ...):
>
> speaker-test -c 4 -twav -Dplug:surround40
>
> on my new Shuttle SX58H7.
> First try was with Debian Lenny, second try with a Live Ubuntu 9.10 ,
> I have problems with both, I only get sound out of the front speakers (
> telling "front-left" and "front-right" in the speaker-test example)
>
> It's not a problem of the speakers. Parallel to my new Shuttle SX58H7, I
> also have a Shuttle SP35P2 ( with installed Debian Etch)
> where I can get surround Sound ( and also have the PCM.rear listed when
> calling "aplay -L"

Sounds like a driver problem, to me. Check alsamixer and see if there's any
rear or surround channels. If they're there, make sure the volume is up and
unmuted. If PulseAudio is installed, you might need to check through it for
the volume controls.

You'd probably have better luck asking in ALSA-related forums and such,
though.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: Re: PCM.rear missing

2009-11-03T23:44:39Z

Hi Chris,

thanks for your response.

I don't think it's an OpenAL-Problem, because I don't have the devices any more, also when using aplay / speaker-test etc,

but since here are lots of sound specialists in the mailing list, I thought I could get help here.

Yesterday I recognized it's not just PCM.rear missing, but also the rear speakers also don't play any sound in surround-Mode.

To be application-independent I tried this with following command ( trying surround40 surround51,surround71, ...):

speaker-test -c 4 -twav -Dplug:surround40

on my new Shuttle SX58H7.

First try was with Debian Lenny, second try with a Live Ubuntu 9.10 ,

I have problems with both, I only get sound out of the front speakers ( telling "front-left" and "front-right" in the speaker-test example)

It's not a problem of the speakers. Parallel to my new Shuttle SX58H7, I also have a Shuttle SP35P2 ( with installed Debian Etch)

where I can get surround Sound ( and also have the PCM.rear listed when calling "aplay -L"

Does anyone have the same problems with surround sound on new linuxes?

Best regards

Thomas

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

Re: (no subject)

2009-11-03T21:06:33Z

On Tuesday 03 November 2009 2:27:22 pm Timofei Timofeeff wrote:
> i would like to cancel openal,how cani do this?thank u

If you want to unsubscribe from the list, the directions are on the bottom of
the page here:

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

(no subject)

2009-11-03T14:27:22Z

i would like to cancel openal,how cani do this?thank u

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

Re: PCM.rear missing

2009-11-03T09:46:11Z

On Tuesday 03 November 2009 6:19:52 am Schneider, Thomas wrote:
> I recently switched from Debian Etch to Debian Lenny, and just
> recognized that some of the pcm-devices I was using earlier are missing
> in the new version.
> With Debian Etch I could use the "front" and "rear" Device independent,
> also from within OpenAL-soft. With debian etch the "rear" device is no
> more available..
>
> Does anyone know the reason for this?

Hi.

How were you selecting the devices? OpenAL Soft should only enumerate the
available hw:x,y devices, as well as the 'default' device, from ALSA. The
"front" and "rear" plug devices shouldn't have been listed.

Semi-recent versions of OpenAL Soft changed it so the separate hardware
devices will only be listed with the ALC_ENUMERATE_ALL_EXT extension, though
the device-specific strings will still work as long as the app passes them
through (use the openal-info utility to see what OpenAL Soft will recognize).
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

PCM.rear missing

2009-11-03T06:19:52Z

Hi,

I recently switched from Debian Etch to Debian Lenny, and just recognized that some of the pcm-devices I was using earlier are missing in the new version.

With Debian Etch I could use the "front" and "rear" Device independent, also from within OpenAL-soft. With debian etch the "rear" device is no more available..

Does anyone know the reason for this?

Best regards

Thomas

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-11-01T09:16:45Z

On Sunday 01 November 2009 3:42:44 am Ludwig Nussel wrote:
> Chris Robinson wrote:
> > I reverted the locking changes, but I redid it in a way that should be
> > better compatible with newer, unpatched Pulse libs.
>
> The workaround works. Still that pulseaudio change looks wrong to me.

The change may or may not be wrong, but the behavior is right according to the
docs. The main thing I'd say is wrong is that the callback is called
synchronously, but given that it is, the signal call should block since it's
told to wait for acceptance.

> Yes, great! I can can confirm that. Thanks!

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-11-01T04:02:15Z

Ludwig Nussel wrote:

> Chris Robinson wrote:
> > FWIW, one of the issues with 1.9 was that exiting an app would print out the
> > error:
> > Inconsistency detected by ld.so: dl-close.c: 731: _dl_close: Assertion
> > `map->l_init_called' failed!
> >
> > I never found what caused it (probably dlclose getting called with a bad
> > handle), but it doesn't seem to happen anymore with the latest GIT.
>
> Yes, I see that error too with Chromium BSU with latest git.

It's not openal-soft's fault. The error is caused by the
compatibility library I install for libopenal.so.0. It's an empty
library that links against libopenal.so.1. I could have solved it
with a symlink but then rpm doesn't generate the automatic
dependencies.

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-11-01T03:42:44Z

Chris Robinson wrote:

> An update on things.
>
> On Saturday 31 October 2009 1:02:04 pm Ludwig Nussel wrote:
> > - the locking change moved the call to
> > ppa_stream_set_write_callback() downwards. I guess it needs to be
> > done before ppa_stream_connect_playback() though as pulseaudio
> > doesn't call the callback otherwise. However, with that locking
> > change openal runs in a deadlock if
> > ppa_stream_set_write_callback() is called earlier. So the locking
> > change was either incomplete or wrong :-). Which in turn brings
> > back the question whether the behavior change in pulseaudio
> > was correct. I've reverted it locally and ioquake3 works fine now.
>
> I reverted the locking changes, but I redid it in a way that should be better
> compatible with newer, unpatched Pulse libs.

The workaround works. Still that pulseaudio change looks wrong to me.

> > - The change to stream_write_callback() was wrong, it didn't pass
> > 'len' to ppa_stream_write() but rather data->attr.minreq only. I
> > really don't know the first thing about that stuff but I guess
> > pulseaudio didn't play because it waited for more data.
>
> I changed the callback to do all full-sized updates given the amount of data
> PulseAudio wants. This seemed to help fix the stalls I get during playback.
>
> Both ioquake3 and Chromium are working with the PulseAudio backend for me,
> now.

Yes, great! I can can confirm that. Thanks!

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-31T18:22:59Z

An update on things.

On Saturday 31 October 2009 1:02:04 pm Ludwig Nussel wrote:
> - the locking change moved the call to
> ppa_stream_set_write_callback() downwards. I guess it needs to be
> done before ppa_stream_connect_playback() though as pulseaudio
> doesn't call the callback otherwise. However, with that locking
> change openal runs in a deadlock if
> ppa_stream_set_write_callback() is called earlier. So the locking
> change was either incomplete or wrong :-). Which in turn brings
> back the question whether the behavior change in pulseaudio
> was correct. I've reverted it locally and ioquake3 works fine now.

I reverted the locking changes, but I redid it in a way that should be better
compatible with newer, unpatched Pulse libs.

> - The change to stream_write_callback() was wrong, it didn't pass
> 'len' to ppa_stream_write() but rather data->attr.minreq only. I
> really don't know the first thing about that stuff but I guess
> pulseaudio didn't play because it waited for more data.

I changed the callback to do all full-sized updates given the amount of data
PulseAudio wants. This seemed to help fix the stalls I get during playback.

Both ioquake3 and Chromium are working with the PulseAudio backend for me,
now.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-31T13:52:56Z

On Saturday 31 October 2009 1:02:04 pm Ludwig Nussel wrote:

> Chris Robinson wrote:
> > Yeah. PulseAudio is supposed to call it regularly as more sound data is
> > needed to fill the buffer, but it doesn't seem to call it properly/at
> > all. Haven't been able to find out why since everything returns success,
> > and the change that broke it should be inconsequential.
>
> Problems identified:
> - The change to stream_write_callback() was wrong, it didn't pass
> 'len' to ppa_stream_write() but rather data->attr.minreq only. I
> really don't know the first thing about that stuff but I guess
> pulseaudio didn't play because it waited for more data.

It uses the minreq field to mix the proper amount. Since OpenAL's ALC_REFRESH
parameter basically defines how often updates occur per second, it makes sense
to update with 'frequency/refresh' samples at a time. And with the minreq set
when requesting buffer attributes, PulseAudio shouldn't call the callback
until that many bytes are needed.

> - the locking change moved the call to
> ppa_stream_set_write_callback() downwards. I guess it needs to be
> done before ppa_stream_connect_playback() though as pulseaudio
> doesn't call the callback otherwise. However, with that locking
> change openal runs in a deadlock if
> ppa_stream_set_write_callback() is called earlier. So the locking
> change was either incomplete or wrong :-). Which in turn brings
> back the question whether the behavior change in pulseaudio
> was correct. I've reverted it locally and ioquake3 works fine now.

The deadlock probably occurs because pulse_open, pulse_reset_playback,
pulse_open_capture will unlock the mainloop as it sleeps to wait for a
context/stream status change. When it does that, it would allow the main loop
to lock itself and call the write callback. The write callback then tries to
mix, which grabs the OpenAL lock and gets blocked, since the thread opening
the device has it locked. The thread opening the device tries to continue, but
gets blocked when trying to re-acquire the mainloop lock.

That's why I don't set the write callback until after the stream is connected,
so it won't try to sneak in a mix before the thread opening the device has
acknowledged the connection. It may be possible to not unlock/relock the
mainloop while it's waiting, but I don't know if the mainloop implicitly locks
while handling status updates. But it doesn't make sense that the write
callback won't be called if it's not set before the connection attempt is
made.

Out of curiosity, does capture work with the PulseAudio backend? The read
callback isn't set until the app requests to start capture, which is well
after the device is fully opened and the stream is connected.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-31T13:26:58Z

On Saturday 31 October 2009 12:35:59 pm Ludwig Nussel wrote:
> Ok, that assertion was wrong. The invalid free is caused by
> Alc.c: 660 free(device->szDeviceName);
> And then same thing again in pulse_close(). Since no other backend
> calls free itself on the device name that call should be removed
> from pulseaudio.c I guess.

Ah yeah, pulse_close shouldn't need to free the device string. It's harmless
for playback since it's set to NULL right after being freed, so subsequent
free attempts no-op (being that free(NULL) is valid). But
alcCaptureCloseDevice doesn't set it to NULL after freeing, which is before
the backend is closed which tries to free it again.

Thanks for catching that.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-31T13:02:04Z

Chris Robinson wrote:
> On Friday 30 October 2009 11:39:49 am Ludwig Nussel wrote:
> > No, still no sound with that patch. I've added additional printfs in
> > stream_write_callback() and it looks like it's never called. Whereas I
> > suppose it should be called all the time as long as the app plays sound?
>
> Yeah. PulseAudio is supposed to call it regularly as more sound data is needed
> to fill the buffer, but it doesn't seem to call it properly/at all. Haven't
> been able to find out why since everything returns success, and the change
> that broke it should be inconsequential.

Problems identified:
- The change to stream_write_callback() was wrong, it didn't pass
'len' to ppa_stream_write() but rather data->attr.minreq only. I
really don't know the first thing about that stuff but I guess
pulseaudio didn't play because it waited for more data.
- the locking change moved the call to
ppa_stream_set_write_callback() downwards. I guess it needs to be
done before ppa_stream_connect_playback() though as pulseaudio
doesn't call the callback otherwise. However, with that locking
change openal runs in a deadlock if
ppa_stream_set_write_callback() is called earlier. So the locking
change was either incomplete or wrong :-). Which in turn brings
back the question whether the behavior change in pulseaudio
was correct. I've reverted it locally and ioquake3 works fine now.

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/

[attachment removed]
[attachment removed]
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-31T12:35:59Z

Ludwig Nussel wrote:
> Also 1.9 aborts with an invalid free when exiting ioquake3. Looks like
> pulse_close is called with the same pointer twice, once for playback
> and then for capture.

Ok, that assertion was wrong. The invalid free is caused by
Alc.c: 660 free(device->szDeviceName);
And then same thing again in pulse_close(). Since no other backend
calls free itself on the device name that call should be removed
from pulseaudio.c I guess.

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-31T02:33:39Z

On Friday 30 October 2009 9:49:36 am Ludwig Nussel wrote:
> Yes, I see that error too with Chromium BSU with latest git. ioquake3
> openal code was changed lately, maybe it does something wrong.

I checked those apps, and I don't have any problems with Chromium BSU. Even
ran it in valgrind, and nothing abnormal showed up pointing to OpenAL.
ioquake3 even ran fine, although I once did get the error
*** glibc detected *** .: corrupted double-linked list: 0x09d744a0 ***
on shutdown, with a backtrace pointing into libGLcore (nVidia 190.42 drivers).

Would it be possible for you to run it in Valgrind and provide a log where the
error shows up?
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T11:59:12Z

On Friday 30 October 2009 11:39:49 am Ludwig Nussel wrote:
> No, still no sound with that patch. I've added additional printfs in
> stream_write_callback() and it looks like it's never called. Whereas I
> suppose it should be called all the time as long as the app plays sound?

Yeah. PulseAudio is supposed to call it regularly as more sound data is needed
to fill the buffer, but it doesn't seem to call it properly/at all. Haven't
been able to find out why since everything returns success, and the change
that broke it should be inconsequential.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T11:39:49Z

Chris Robinson wrote:
> On Friday 30 October 2009 9:49:36 am Ludwig Nussel wrote:
> > Yes, I see that error too with Chromium BSU with latest git.
>
> Latest git of OpenAL Soft? Better look into that..

Yes.

> > > According to another person that uses PulseAudio, SecondLife stopped
> > > playing sound for him in 1.9 and a GIT bisect named this as the first bad
> > > commit: http://repo.or.cz/w/openal-
> > > soft.git?a=commitdiff;h=bdbdbcea26d4a12d4d3f76ad3724f2ad12a55358
> > >
> > > Reverting that doesn't fix it for me, however as I said, I seem to have
> > > other issues with PulseAudio playing sound, so it may or may not work for
> > > others.
> >
> > I can confirm that the revision before that commit still plays sound.
>
> Does reverting the patch fix it? It doesn't seem to revert cleanly, so I
> attached a patch that does it.

No, still no sound with that patch. I've added additional printfs in
stream_write_callback() and it looks like it's never called. Whereas I suppose
it should be called all the time as long as the app plays sound?

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T10:33:40Z

On Friday 30 October 2009 9:49:36 am Ludwig Nussel wrote:
> Yes, I see that error too with Chromium BSU with latest git.

Latest git of OpenAL Soft? Better look into that..

> > According to another person that uses PulseAudio, SecondLife stopped
> > playing sound for him in 1.9 and a GIT bisect named this as the first bad
> > commit: http://repo.or.cz/w/openal-
> > soft.git?a=commitdiff;h=bdbdbcea26d4a12d4d3f76ad3724f2ad12a55358
> >
> > Reverting that doesn't fix it for me, however as I said, I seem to have
> > other issues with PulseAudio playing sound, so it may or may not work for
> > others.
>
> I can confirm that the revision before that commit still plays sound.

Does reverting the patch fix it? It doesn't seem to revert cleanly, so I
attached a patch that does it.

[revert-bad-commit.diff]

diff --git a/Alc/pulseaudio.c b/Alc/pulseaudio.c index d5dcf1d..cc70440 100644 --- a/Alc/pulseaudio.c +++ b/Alc/pulseaudio.c @@ -76,7 +76,6 @@ MAKE_FUNC(pa_threaded_mainloop_accept); MAKE_FUNC(pa_stream_set_write_callback); MAKE_FUNC(pa_threaded_mainloop_new); MAKE_FUNC(pa_context_connect); -MAKE_FUNC(pa_stream_get_buffer_attr); MAKE_FUNC(pa_stream_set_read_callback); MAKE_FUNC(pa_stream_set_state_callback); MAKE_FUNC(pa_stream_new); @@ -187,7 +186,6 @@ LOAD_FUNC(pa_threaded_mainloop_accept); LOAD_FUNC(pa_stream_set_write_callback); LOAD_FUNC(pa_threaded_mainloop_new); LOAD_FUNC(pa_context_connect); -LOAD_FUNC(pa_stream_get_buffer_attr); LOAD_FUNC(pa_stream_set_read_callback); LOAD_FUNC(pa_stream_set_state_callback); LOAD_FUNC(pa_stream_new); @@ -218,12 +216,10 @@ static void stream_write_callback(pa_stream *stream, size_t len, void *pdata) // { ALCdevice *Device = pdata; pulse_data *data = Device->ExtraData; - void *buf = ppa_xmalloc0(data->attr.minreq); - (void)len; + void *buf = ppa_xmalloc0(len); - aluMixData(Device, buf, data->attr.minreq/data->frame_size); - ppa_stream_write(stream, buf, data->attr.minreq, ppa_xfree, 0, - PA_SEEK_RELATIVE); + aluMixData(Device, buf, len/data->frame_size); + ppa_stream_write(stream, buf, len, ppa_xfree, 0, PA_SEEK_RELATIVE); } //}}} static void stream_read_callback(pa_stream *stream, size_t length, void *pdata) //{{{ @@ -398,13 +394,16 @@ static ALCboolean pulse_reset_playback(ALCdevice *device) //{{{ data->frame_size = aluBytesFromFormat(device->Format) * aluChannelsFromFormat(device->Format); - data->attr.minreq = data->frame_size * device->UpdateSize; + data->attr.minreq = -1; data->attr.prebuf = -1; data->attr.maxlength = -1; - data->attr.fragsize = -1; - data->attr.tlength = data->attr.minreq * device->NumUpdates; + data->attr.fragsize = data->frame_size * device->UpdateSize; + data->attr.tlength = data->attr.fragsize * device->NumUpdates; data->stream_name = "Playback Stream"; + data->spec.rate = device->Frequency; + data->spec.channels = aluChannelsFromFormat(device->Format); + switch(aluBytesFromFormat(device->Format)) { case 1: @@ -421,8 +420,6 @@ static ALCboolean pulse_reset_playback(ALCdevice *device) //{{{ ppa_threaded_mainloop_unlock(data->loop); return ALC_FALSE; } - data->spec.rate = device->Frequency; - data->spec.channels = aluChannelsFromFormat(device->Format); if(ppa_sample_spec_valid(&data->spec) == 0) { @@ -472,13 +469,6 @@ static ALCboolean pulse_reset_playback(ALCdevice *device) //{{{ ppa_threaded_mainloop_lock(data->loop); } - data->attr = *(ppa_stream_get_buffer_attr(data->stream)); - if((data->attr.tlength%data->attr.minreq) != 0) - AL_PRINT("tlength (%d) is not a multiple of minreq (%d)!\n", - data->attr.tlength, data->attr.minreq); - device->UpdateSize = data->attr.minreq; - device->NumUpdates = data->attr.tlength/data->attr.minreq; - ppa_stream_set_write_callback(data->stream, stream_write_callback, device); ppa_threaded_mainloop_unlock(data->loop);

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T09:49:36Z

Chris Robinson wrote:

> On Friday 30 October 2009 6:32:07 am Ludwig Nussel wrote:
> > Ludwig Nussel wrote:
> > > Also 1.9 aborts with an invalid free when exiting ioquake3. Looks
> > > like
> > > pulse_close is called with the same pointer twice, once for playback
> > > and then for capture.
>
> A capture device shouldn't be able to have the same handle as a playback
> device, and there shouldn't be a way for an invalid/recently closed device
> handle to be closed again. The close function would error.
>
> It would be more likely that there's something in the pulse backend that isn't
> properly set up, so closing it may try to free something it shouldn't. I'll
> try to check it out to see if it happens here in the latest GIT.
>
> FWIW, one of the issues with 1.9 was that exiting an app would print out the
> error:
> Inconsistency detected by ld.so: dl-close.c: 731: _dl_close: Assertion
> `map->l_init_called' failed!
>
> I never found what caused it (probably dlclose getting called with a bad
> handle), but it doesn't seem to happen anymore with the latest GIT.

Yes, I see that error too with Chromium BSU with latest git. ioquake3 openal
code was changed lately, maybe it does something wrong.

> > Still investigating which change caused openal-soft to not play sound
> > anymore...
>
> According to another person that uses PulseAudio, SecondLife stopped playing
> sound for him in 1.9 and a GIT bisect named this as the first bad commit:
> http://repo.or.cz/w/openal-
> soft.git?a=commitdiff;h=bdbdbcea26d4a12d4d3f76ad3724f2ad12a55358
>
> Reverting that doesn't fix it for me, however as I said, I seem to have other
> issues with PulseAudio playing sound, so it may or may not work for others.

I can confirm that the revision before that commit still plays sound.

cu
Ludwig

--
(o_ Ludwig Nussel
//\ SUSE LINUX Products GmbH, Development
V_/_ http://www.suse.de/

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

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T08:13:31Z

On Friday 30 October 2009 6:32:07 am Ludwig Nussel wrote:
> Ludwig Nussel wrote:
> > Also 1.9 aborts with an invalid free when exiting ioquake3. Looks
> > like
> > pulse_close is called with the same pointer twice, once for playback
> > and then for capture.

A capture device shouldn't be able to have the same handle as a playback
device, and there shouldn't be a way for an invalid/recently closed device
handle to be closed again. The close function would error.

It would be more likely that there's something in the pulse backend that isn't
properly set up, so closing it may try to free something it shouldn't. I'll
try to check it out to see if it happens here in the latest GIT.

FWIW, one of the issues with 1.9 was that exiting an app would print out the
error:
Inconsistency detected by ld.so: dl-close.c: 731: _dl_close: Assertion
`map->l_init_called' failed!

I never found what caused it (probably dlclose getting called with a bad
handle), but it doesn't seem to happen anymore with the latest GIT.

> Wrt locking, guess this change to openal-soft was made to avoid the
> deadlock:
> http://repo.or.cz/w/openal-soft.git?a=commitdiff;h=617b6728d3bf4f3922f8770
> 2260d848b9ae88340

Yup.

> And this change in pulseaudio causes the deadlock:
> http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=4f5e2b745ea357e2b5c
> 815ff33a556505a7d1f18
> If I apply the reverse change of that to pulseaudio
> 0.9.19 openal-soft 1.8.466 doesn't lock up anymore. I wonder if the
> openal-soft code actually was buggy or this change to pulseaudio is.
> CC'd Lennart

That looks like it. The issue was that pa_context_connect/pa_stream_connect
would synchronously call the state change callback to set it to 'connecting',
where pa_threaded_mainloop_signal would be called to wait for acceptance of
the state change. But since that same thread is what's used to accept the
signal, it could never be accepted.

> Still investigating which change caused openal-soft to not play sound
> anymore...

According to another person that uses PulseAudio, SecondLife stopped playing
sound for him in 1.9 and a GIT bisect named this as the first bad commit:
http://repo.or.cz/w/openal-
soft.git?a=commitdiff;h=bdbdbcea26d4a12d4d3f76ad3724f2ad12a55358

Reverting that doesn't fix it for me, however as I said, I seem to have other
issues with PulseAudio playing sound, so it may or may not work for others.
It's odd though, since the main changes were setting fragsize to -1, which it
should be anyway since the docs say it's unused for playback, and setting
minreq to the update size which should be completely valid.
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T06:32:07Z

Ludwig Nussel wrote:

> Chris Robinson wrote:
> > 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).
>
> Unfortunately I noticed only yesterday that there are problems. openSUSE 11.2
> is about to ship (RC2) and openal-soft is broken there atm. 1.8.466 locks up
> waiting for some mutex and 1.9.563 doesn't play sound. Current git version also
> stays silent. pulseaudio version is 0.9.19, paplay works. Also 1.9
> aborts with an invalid free when exiting ioquake3. Looks like
> pulse_close is called with the same pointer twice, once for playback
> and then for capture.
>
> openal-soft 1.8.466 did work just fine with with pulseaudio 0.9.14
> on openSUSE 11.1 though. openal-soft git head on 11.1 doesn't play
> sound either.

Wrt locking, guess this change to openal-soft was made to avoid the deadlock:
http://repo.or.cz/w/openal-soft.git?a=commitdiff;h=617b6728d3bf4f3922f87702260d848b9ae88340

And this change in pulseaudio causes the deadlock:
http://git.0pointer.de/?p=pulseaudio.git;a=commitdiff;h=4f5e2b745ea357e2b5c815ff33a556505a7d1f18
If I apply the reverse change of that to pulseaudio 0.9.19 openal-soft 1.8.466
doesn't lock up anymore. I wonder if the openal-soft code actually was
buggy or this change to pulseaudio is.
CC'd Lennart

Still investigating which change caused openal-soft to not play sound
anymore...

cu
Ludwig

--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

Re: OpenAL Soft 1.10 will be sooner than expected

2009-10-30T02:51:57Z

Chris Robinson wrote:
> 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).

Unfortunately I noticed only yesterday that there are problems. openSUSE 11.2
is about to ship (RC2) and openal-soft is broken there atm. 1.8.466 locks up
waiting for some mutex and 1.9.563 doesn't play sound. Current git version also
stays silent. pulseaudio version is 0.9.19, paplay works. Also 1.9
aborts with an invalid free when exiting ioquake3. Looks like
pulse_close is called with the same pointer twice, once for playback
and then for capture.

openal-soft 1.8.466 did work just fine with with pulseaudio 0.9.14
on openSUSE 11.1 though. openal-soft git head on 11.1 doesn't play
sound either.

cu
Ludwig

--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal

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 mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal