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

[Huw Davies]

On Wed, Feb 09, 2022 at 10:23:16AM -0600, Zebediah Figura wrote:
> 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.

In the CoreAudio (and in the upcoming ALSA) driver, I'm generating and
persisting the GUIDs on the PE-side.  I guess these could be done in
the unixlib, but I didn't see much advantage in doing so.  Either way,
I think the clean way to get the list of endpoints is via a syscall.

Huw.