Missing PKEYs for audio device/endpoint properties

[agausmann]

• Device Properties
• Audio Endpiont Properties

I'm currently working backwards from an IPropertyStore obtained from an audio device to find the properties I need, and manually creating constants for them. In Rust, for example:

// {A45C254E-DF1C-4EFD-8020-67D146A850E0} 14
const PKEY_Device_FriendlyName: PROPERTYKEY = PROPERTYKEY {
    fmtid: Guid::from_values(
        0xA45C254E,
        0xDF1C,
        0x4EFD,
        [0x80, 0x20, 0x67, 0xD1, 0x46, 0xA8, 0x50, 0xE0],
    ),
    pid: 14,
};

[sotteson1]

Hey @kennykerr and @AArnott, this is a weird one because it's like a guid constant but with an extra parameter (pid). I'm currently making a change to scrape a bunch of guid constants I wasn't getting before, and I would like to express them in metadata like this (since ECMA-335 doesn't allow for guid constants):

Copied from ilspy.exe output: (I wish it would use hex numbers, but oh well)

[Guid(1340228757u, 10446, 18720, 164, 196, 229, 86, 225, 240, 223, 42)]
public static Guid CLSID_CToc;

I would have to do something custom for PROPERTYKEY. Hopefully it's the only one we'll have to do. I hate doing special cases like this but I'm not sure of a better way to get PROPERTYKEY constants into metadata.

[PropertyKey(0xa45c254e, 0xdf1c, 0x4efd, 0x80, 0x20, 0x67, 0xd1, 0x46, 0xa8, 0x50, 0xe0, 14)]
public static PROPERTYKEY DEVPKEY_Device_FriendlyName;

It would be up to the projections to know how to populate that into the PROPERTYKEY struct. Or, does anyone have a better idea?

[kennykerr]

Wow, DEVPROPKEY is a monstrosity.

I like doing this for GUIDs because they're a well known type and should reduce binary size.

The other thing really feels hacky, but I don't have a better idea.