OpenAL Soft 1.10 will be sooner than expected

[Chris Robinson-5]

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

[Ludwig Nussel]

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

[Ludwig Nussel]

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

[Chris Robinson-5]

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

[Ludwig Nussel]

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

[Chris Robinson-5]

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

[Ludwig Nussel]

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

[Chris Robinson-5]

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

[Chris Robinson-5]

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

[Ludwig Nussel]

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

[Ludwig Nussel]

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

[Chris Robinson-5]

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

[Chris Robinson-5]

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

[Chris Robinson-5]

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

[Ludwig Nussel]

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

[Ludwig Nussel]

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

[Chris Robinson-5]

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