[openal] A 5.1 32-bit source kills a stereo 16-bit one on OpenAL Soft

[Leszek Godlewski]

Hey,

So I just checked – both sources keep incrementing their offsets and
rotating their buffers. There's nothing suspicious I can see in their
states. Here's the stereo source's state at a moment when both should be
playing but aren't:

AL_PITCH: 1.000000
AL_GAIN: 1.000000
AL_MIN_GAIN: 0.000000
AL_MAX_GAIN: 1.000000
AL_MAX_DISTANCE: 340282346638528859811704183484516925440.000000
AL_ROLLOFF_FACTOR: 1.000000
AL_CONE_OUTER_GAIN: 0.000000
AL_CONE_OUTER_GAINHF: 1.000000
AL_SEC_OFFSET: 0.017460
AL_CONE_INNER_ANGLE: 360.000000
AL_CONE_OUTER_ANGLE: 360.000000
AL_REFERENCE_DISTANCE: 1.000000
AL_AIR_ABSORPTION_FACTOR: 0.000000
AL_ROOM_ROLLOFF_FACTOR: 0.000000
AL_DOPPLER_FACTOR: 1.000000
AL_SOURCE_RELATIVE: 0
AL_LOOPING: 0
AL_BUFFER: 233047872
AL_SOURCE_STATE: 4114
AL_BUFFERS_QUEUED: 4
AL_BUFFERS_PROCESSED: 0
AL_SOURCE_TYPE: 4137
AL_BYTE_OFFSET: 12320
AL_DIRECT_FILTER: 0
AL_DIRECT_FILTER_GAINHF_AUTO: 1
AL_AUXILIARY_SEND_FILTER_GAIN_AUTO: 1
AL_AUXILIARY_SEND_FILTER_GAINHF_AUTO: 1
AL_DISTANCE_MODEL: 53250

AL_BUFFERS_PROCESSED is 0 because the custom mixer uses byte-tight
quadruple buffering and I just caught it in the middle of swapping. And the
5.1 one:

AL_PITCH: 1.000000
AL_GAIN: 1.000000
AL_MIN_GAIN: 0.000000
AL_MAX_GAIN: 1.000000
AL_MAX_DISTANCE: 340282346638528859811704183484516925440.000000
AL_ROLLOFF_FACTOR: 1.000000
AL_CONE_OUTER_GAIN: 0.000000
AL_CONE_OUTER_GAINHF: 1.000000
AL_SEC_OFFSET: 1.793946
AL_CONE_INNER_ANGLE: 360.000000
AL_CONE_OUTER_ANGLE: 360.000000
AL_REFERENCE_DISTANCE: 1.000000
AL_AIR_ABSORPTION_FACTOR: 0.000000
AL_ROOM_ROLLOFF_FACTOR: 0.000000
AL_DOPPLER_FACTOR: 1.000000
AL_SOURCE_RELATIVE: 0
AL_LOOPING: 0
AL_BUFFER: 398383424
AL_SOURCE_STATE: 4114
AL_BUFFERS_QUEUED: 148
AL_BUFFERS_PROCESSED: 106
AL_SOURCE_TYPE: 4137
AL_BYTE_OFFSET: 1898712
AL_DIRECT_FILTER: 0
AL_DIRECT_FILTER_GAINHF_AUTO: 1
AL_AUXILIARY_SEND_FILTER_GAIN_AUTO: 1
AL_AUXILIARY_SEND_FILTER_GAINHF_AUTO: 1
AL_DISTANCE_MODEL: 53250

As you can see, the states are pretty much identical. Upgrading to OpenAL
Soft 1.16 doesn't change anything.

Any suggestions?

Or is anyone willing to have a look at the case in point in exchange for a
Steam key maybe? :)

Regards,

Leszek

2014-10-05 22:22 GMT+02:00 Leszek Godlewski <lg at inequation.org>:

> Hi Chris,
>
> Thanks for replying. Well, if it's nothing known, I guess I'm onto
> something. :)
>
> Yes, the 5.1 keeps playing, stereo stream comes back the moment the 5.1 is
> stopped. I'm pretty sure the both sources keep incrementing their offsets,
> but I'll try dumping the entire source state tomorrow to see if there's
> anything out of the ordinary in it. I'll also try 1.16.
>
> Regards,
>
> Leszek
>
> 2014-10-04 11:44 GMT+02:00 Chris Robinson <chris.kcat at gmail.com>:
>
>> On 10/03/2014 08:22 AM, Leszek Godlewski wrote:
>>
>>> Hi everyone,
>>>
>>> I'm experiencing a bug in OpenAL Soft 1.13 on Linux where with two
>>> sources
>>> playing, only one can be heard. The exact use case is as follows:
>>>
>>> [...]
>>>
>>> There are no other sources playing. Both sources have been put at (0,0,0)
>>> with AL_SOURCE_RELATIVE set to AL_TRUE, with AL_MAX_DISTANCE and
>>> AL_MIN_GAIN at 1.f. Preliminary debugging within OpenAL Soft shows that
>>> both sources are active (I've put breakpoints in aluMixData() and
>>> inspected
>>> the context).
>>>
>>
>> The 5.1 audio stream does play while the stereo stream goes quiet? Does
>> the stereo stream come back when the 5.1 stream ends? Do the sources
>> continue to increment their offset (querying the AL_SAMPLE_OFFSET source
>> property) when both are supposed to be playing?
>>
>> There shouldn't be any problem with playing a 5.1 and stereo stream at
>> the same time. The first thing I'd try is to update OpenAL Soft; the most
>> recent version is 1.16.
>> _______________________________________________
>> openal mailing list
>> openal at openal.org
>> http://openal.org/mailman/listinfo/openal
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20141006/dd646539/attachment-0001.html>