[openal] 1.16.0 info bug?

[LAM]

On Thu, Aug 28, 2014 at 12:00 PM, <openal-request at openal.org> wrote:

> Send openal mailing list submissions to
>         openal at openal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://openal.org/mailman/listinfo/openal
> or, via email, send a message with subject or body 'help' to
>         openal-request at openal.org
>
> You can reach the person managing the list at
>         openal-owner at openal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openal digest..."
>
>
> Today's Topics:
>
>    1. Re: 1.16.0 info bug? (Chris Robinson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 27 Aug 2014 16:10:46 -0700
> From: Chris Robinson <chris.kcat at gmail.com>
> To: openal mailing list <openal at openal.org>
> Subject: Re: [openal] 1.16.0 info bug?
> Message-ID: <53FE6576.90700 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 08/27/2014 11:49 AM, LAM wrote:
> > Also note in the output that it turns
> > out the identifier code is exactly the same for the dupe, if that helps.
>
> Indeed. Odd that it works with 1.15.1 then, since the problem is that
> Windows is returning a different IMMDevice pointer for the default
> device query. This should actually be causing a buffer overrun in 1.15.1
> since it only allocated enough space for the number of reported devices,
> while the default would get added twice.
>
> So then I wonder what's the correct way to test if two IMMDevices refer
> to the same endpoint. The device ID is a stringified UID of some kind,
> which theoretically can be equal even if a case-insensitive compare
> fails. MSDN also says apps should treat the ID string as 'opaque', and
> not try to parse it since it can change between systems.
>

OK, well I guess it's all no big deal, as my game works perfectly well (if
not better) with 1.16.0 now. Just chalk it up to yet another Windows quirk,
I suppose. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20140828/321099f8/attachment.html>