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@harmstone.com, with changes by Sebastian Lackner sebastian@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.