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

Gabriel Ivăncescu gabrielopcode at gmail.com
Wed Feb 9 09:56:59 CST 2022


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.



More information about the wine-devel mailing list