[PATCH 1/5] winepulse.drv: Expose audio devices to the application.

[Zebediah Figura]

On 2/9/22 09:56, Gabriel Ivăncescu wrote:
> On 09/02/2022 17:26, Huw Davies wrote:
>> On Wed, Feb 09, 2022 at 04:10:54PM +0200, Gabriel Ivăncescu wrote:
>>> This exposes the actual devices (and virtual sinks/sources) as reported by
>>> PulseAudio to an application, allowing it to select the devices itself and,
>>> for example, record from (or render to) two devices at the same time. The
>>> "PulseAudio" device (which is movable) is still the default, as before.
>>>
>>> It keeps a list of the devices on the unixlib side, which then stores the
>>> device type, pulse name and display (friendly) name into the registry,
>>> for persistent settings of an app to identify the device by guid. The
>>> keys are stored under HKLM\Software\Wine\Drivers\winepulse.drv\devices,
>>> with the following format:
>>>
>>>     <type>,<pulse device name>
>>>
>>> Where <type> is a single character, which is either 0 (for output/sinks)
>>> or 1 (for input/sources), and <pulse device name> is the device name that
>>> PulseAudio uses to identify the device. The "name" value is stored under
>>> this key which is the display name of the device. When enumerating the
>>> devices, the "name" is taken and a GUID is generated if it's missing or
>>> invalid under the "guid" value of the same key; this preserves the GUID
>>> for the same device unless the registry key is cleaned.
>>>
>>> Based on a patch by Mark Harmstone <mark at harmstone.com>, with changes by
>>> Sebastian Lackner <sebastian at fds-team.de>.
>>
>> Why are you storing this in the registry?  It would likely be simpler
>> to add a get_endpoint_ids() syscall.  See the core audio driver for an
>> example.
>>
>> Huw.
>>
> 
> I've been rebasing it for wine-staging, and I add the name to the
> registry because AFAIK Zeb didn't want to add another syscall if it
> could be avoided. Note that we'll still have to store the "guid" since
> it has to be persistent, so it would only avoid the "name" value.
> 
> I see coreaudio does it similar to how I had it originally with a unix
> syscall, so probably I should go with that.
> 

Well, not exactly. I mentioned that because the patches were using the 
registry anyway, and I figured it made more sense not to do the same 
thing in two different ways.

My assumption is that the point of storing it in the registry is so that 
it would persist across reboots. E.g. if a Windows program has been 
configured to use a specific audio endpoint GUID, and stores that 
information in its configuration file somewhere, that it would continue 
to do so after being restarted.

I didn't actually verify that these GUIDs are persistent on Windows, 
though, and I don't know that we have any programs that do this. It was 
definitely just a guess on my part.