[Openal] OpenAL Soft 1.10 will be sooner than expected

[Chris Robinson]

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.