Rocksmith

To keep this alive - I just hooked up the game in default wine 3.14 Staging and - what never worked for me - the cable got detected. Been trying it in Proton 3.7.6 but failed. I noticed the Proton version doesn't list all devices - as stated below - in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MMDevices\Audio but only one for output and input each. The Rocksmith adapter wasn't listed. I noticed in my regular wine installation - it was there!
Anyway - after spending the night crawling lots of old and partly outdated tips I just gave it a shot and fired steam in wine and then Rocksmith and ... it worked! Might be that some additional packages I installed triggered it. Anyway - will do some more tests and update this entry with a fresh test result.

In HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture find the ALSA device relating to the Rocksmith cable and add the following keys:

"{1DA5D803-D492-4EDD-8C23-E0C0FFEE7F0E},0"=dword:00000004
"{B3F8FA53-0004-438E-9003-51A46E139BFC},2"="{1}.USB\\VID_12BA&PID_00FF&MI_00\\7&2443AC09&0&0000"

The first entry tells wine that this is a microphone, the second gives it's vendor and product id's.

Under PulseAudio, you have to add those two keys to the pulseaudio capture device, very strange, which is under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture\{25DA76D0-033C-4235-9002-19F48894AC6F}.

I still have no audio recording from the cable at this time. Output is fine.

Edit the dlls/winealsa.drv/mmdevdrv.c file and comment out the following lines:

if(mode != AUDCLNT_SHAREMODE_SHARED && mode != AUDCLNT_SHAREMODE_EXCLUSIVE)
return AUDCLNT_E_NOT_INITIALIZED;

You will be able to get input from the guitar, unfortunately, it's really bad and you won't get further.

I've added the registry keys, but the game still fails to detect the cable.

Is commenting these lines and re-compiling supposed to solve this problem? Or is it only to get audio captured if the cable is already detected?

I see
"{1DA5D803-D492-4EDD-8C23-E0C0FFEE7F0E},0"=dword:00000004
gets created automatically. However
"{B3F8FA53-0004-438E-9003-51A46E139BFC},2"="{1}.USB\\VID_12BA&PID_00FF&MI_00\\7&2443AC09&0&0000"
is always replaced by:
"{B3F8FA53-0004-438E-9003-51A46E139BFC},2"="{1}.USB\\VID_12BA&PID_00FF\\0&28D2DB3A"
every time the program is launched. Is that supposed to happen? Does it matter? Where did you get the 7&2443AC09 from?

This is all under [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Capture\{3524DE93-905E-446D-9A6E-C71A28D2DB3A}\Properties], despite using PulseAudio (well, Wine's using ALSA, and my .asoundrc defaults everything to pulse - not sure if you meant "pulse running and in use" or "wine with pulseaudio patches").

Added the following code to the start of MMDevice_GetPropValue:

LONG ret;

/* HACK for Rocksmith cable test */
const GUID *ffid = &PKEY_AudioEndpoint_FormFactor.fmtid;

if (id->Data1 == ffid->Data1 && id->Data2 == ffid->Data2 && id->Data3 == ffid->Data3 &&
id->Data4[0] == ffid->Data4[0] && id->Data4[1] == ffid->Data4[1] && id->Data4[2] == ffid->Data4[2] &&
id->Data4[3] == ffid->Data4[3] && id->Data4[4] == ffid->Data4[4] && id->Data4[5] == ffid->Data4[5] &&
id->Data4[6] == ffid->Data4[6] && id->Data4[7] == ffid->Data4[7] && key->pid == PKEY_AudioEndpoint_FormFactor.pid)
{
if (flow == eCapture)
{
pv->vt = VT_UI4;
pv->u.ulVal = Microphone;
}
else
{
pv->vt = VT_UI4;
pv->u.ulVal = Speakers;
}

return S_OK;
}
/* END HACK */

hr = MMDevPropStore_OpenPropKey(devguid, flow, ®key);

This still didn't detect the device.

Thanks, but this affects only RS2014, correct? If so, maybe you should create another game entry (RS2014) and become maintainer of that.
I was not able yet to get it working (RS2014) under Linux as there is atm no "no-cable"-patch available (small correction: they are but they dont work under wine).

No, this will actually affect both games. Both games use the same middleware and only the game itself was updated. The cable detection will be the same.

Now, after a few days of following wrong leads (GUID's) on MSDN, I found this

msdn.microsoft.com/en-us/library/windows/desktop/ee417014%28v=vs.85%29.aspx

which I believe they will have lifted and put into the game to detect the cable. I was right to add +wbemprox as the "cimv2" keeps popping up. I also believe this is being used as the guys who implemented the no-cable hack modified the dword with the pid/vid values in, the "pGuidProductFromDirectInput->Data1" in that link to make their cables work.

In essence, what we need to get this working is a way to add the PID_ff and VID_12ba into the registry so that that code can detect it properly.

Or best way, when the device is detected, put those values into the DIDEVICEINSTANCE::guidProduct element. This is done in the dinput dll for input devices.

When you get that working, you are my hero! This would mean rocksmith would work fully(?) with wine

Yes, it would be pretty damn cool as I think, once the audio is routed through jackd it would be fully playable with really low latencies. Possibly even better than on Windows.

Luke.

007e:trace:alsa:AUDDRV_GetAudioEndpoint {4b4e922f-b62b-42d8-9a3d-e4ee473607da} 0x86f0d20 0x32f948
007e:trace:alsa:get_alsa_name_by_guid Found matching device key: L"1,plughw:2,0"
007e:trace:mmdevapi:MMDevice_AddRef Refcount now 1
007e:trace:alsa:AudioClient_AddRef (0x8671dd0) Refcount now 1
007e:trace:alsa:AudioClient_GetMixFormat (0x8671dd0)->(0x32f94c)
007e:trace:alsa:dump_fmt wFormatTag: 0xfffe (WAVE_FORMAT_EXTENSIBLE)
007e:trace:alsa:dump_fmt nChannels: 2
007e:trace:alsa:dump_fmt nSamplesPerSec: 48000
007e:trace:alsa:dump_fmt nAvgBytesPerSec: 384000
007e:trace:alsa:dump_fmt nBlockAlign: 8
007e:trace:alsa:dump_fmt wBitsPerSample: 32
007e:trace:alsa:dump_fmt cbSize: 22
007e:trace:alsa:dump_fmt dwChannelMask: 00000003
007e:trace:alsa:dump_fmt Samples: 0020
007e:trace:alsa:dump_fmt SubFormat: {00000003-0000-0010-8000-00aa00389b71}
007e:trace:alsa:AudioClient_Release (0x8671dd0) Refcount now 0
007e:trace:alsa:AudioClient_Stop (0x8671dd0)
007e:trace:mmdevapi:MMDevice_Release Refcount now 0
007e:trace:mmdevapi:MMDevice_SetPropValue Blob 0x86f0dd8 40
007e:trace:mmdevapi:MMDevice_SetPropValue Writing L"{F19F064D-082C-4E27-BC73-6882A1BB8E4C},0" returned 0
007e:trace:mmdevapi:MMDevice_SetPropValue Blob 0x86f0dd8 40
007e:trace:mmdevapi:MMDevice_SetPropValue Writing L"{E4870E26-3CC5-4CD2-BA46-CA0A9A70ED04},3" returned 0
007e:trace:mmdevapi:MMDevEnum_QueryInterface (0x86f0ea0)->({a95664d2-9614-4f35-a746-de8db63617e6}, 0x32fb84)
007e:trace:mmdevapi:MMDevEnum_AddRef Refcount now 2
007e:trace:mmdevapi:MMDevEnum_AddRef Refcount now 3
007e:trace:mmdevapi:MMDevEnum_RegisterEndpointNotificationCallback (0x86f0ea0)->(0x12451cd0)
007e:trace:mmdevapi:MMDevEnum_Release Refcount now 2
007e:err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
007e:trace:mmdevapi:DllGetClassObject ({bcde0395-e52f-467c-8e3d-c4579291692e}, {00000001-0000-0000-c000-000000000046}, 0x32f82c)
007e:trace:mmdevapi:MMCF_CreateInstance (0x7c4bfc18, (nil), {a95664d2-9614-4f35-a746-de8db63617e6}, 0x8671e68)
007e:trace:mmdevapi:MMDevEnum_QueryInterface (0x86f0ea0)->({a95664d2-9614-4f35-a746-de8db63617e6}, 0x8671e68)
007e:trace:mmdevapi:MMDevEnum_AddRef Refcount now 3
007e:trace:mmdevapi:MMDevEnum_GetDefaultAudioEndpoint (0x86f0ea0)->(0,1,0x32f8f4)
007e:trace:mmdevapi:MMDevice_AddRef Refcount now 1
007e:trace:mmdevapi:MMDevice_GetId (0x8671840)->(0x32f8f8)
007e:trace:mmdevapi:MMDevice_GetId returning L"{0.0.0.00000000}.{BD12F083-8FC3-4629-8ECC-479A5CA0D81A}"
007e:trace:mmdevapi:MMDevice_Release Refcount now 0
007e:trace:mmdevapi:MMDevEnum_GetDefaultAudioEndpoint (0x86f0ea0)->(1,1,0x32f8f4)
007e:trace:mmdevapi:MMDevice_AddRef Refcount now 1
007e:trace:mmdevapi:MMDevice_GetId (0x86f1800)->(0x32f8f8)
007e:trace:mmdevapi:MMDevice_GetId returning L"{0.0.1.00000000}.{AC2B8964-242E-4C02-9A5A-29F7723ABA4A}"
007e:trace:mmdevapi:MMDevice_Release Refcount now 0
007e:trace:mmdevapi:MMDevEnum_EnumAudioEndpoints (0x86f0ea0)->(2,1,0x32f8e4)
007e:trace:mmdevapi:MMDevCol_GetCount (0x8671a70)->(0x8671e6c)
007e:trace:mmdevapi:MMDevCol_Item (0x8671a70)->(0, 0x8672888)
007e:trace:mmdevapi:MMDevice_AddRef Refcount now 1
007e:trace:mmdevapi:MMDevice_GetId (0x86f0d20)->(0x32f8f8)
007e:trace:mmdevapi:MMDevice_GetId returning L"{0.0.1.00000000}.{4B4E922F-B62B-42D8-9A3D-E4EE473607DA}"
007e:trace:mmdevapi:MMDevice_GetState (0x86f0d20)->(0x8672c8c)
007e:trace:mmdevapi:MMDevice_OpenPropertyStore (0x86f0d20)->(0,0x32f8ec)
007e:trace:mmdevapi:MMDevPropStore_GetValue (0x8671d10)->("{a45c254e-df1c-4efd-8020-67d146a850e0},14", 0x32f894)
007e:trace:mmdevapi:MMDevPropStore_GetValue (0x8671d10)->("{f19f064d-082c-4e27-bc73-6882a1bb8e4c},0", 0x32f8b8)
007e:trace:mmdevapi:MMDevPropStore_GetValue (0x8671d10)->("{1da5d803-d492-4edd-8c23-e0c0ffee7f0e},0", 0x32f884)
007e:warn:mmdevapi:MMDevice_GetPropValue Reading L"{1DA5D803-D492-4EDD-8C23-E0C0FFEE7F0E},0" returned 2
007e:trace:mmdevapi:MMDevPropStore_GetCount (0x8671d10)->(0x32f8b4)
007e:trace:mmdevapi:MMDevPropStore_GetCount Returning 5
007e:trace:mmdevapi:MMDevPropStore_GetAt (0x8671d10)->(0,0x32f8fc)
007e:trace:mmdevapi:MMDevPropStore_GetValue (0x8671d10)->("{233164c8-1b2c-4c7d-bc68-b671687a2567},1", 0x32f8a4)
007e:trace:mmdevapi:MMDevPropStore_GetAt (0x8671d10)->(1,0x32f8fc)
007e:trace:mmdevapi:MMDevPropStore_GetAt (0x8671d10)->(2,0x32f8fc)
007e:trace:mmdevapi:MMDevPropStore_GetAt (0x8671d10)->(3,0x32f8fc)
007e:trace:mmdevapi:MMDevPropStore_GetValue (0x8671d10)->("{e4870e26-3cc5-4cd2-ba46-ca0a9a70ed04},3", 0x32f8a4)
007e:trace:mmdevapi:MMDevPropStore_GetAt (0x8671d10)->(4,0x32f8fc)
007e:trace:mmdevapi:MMDevPropStore_GetValue (0x8671d10)->("{f19f064d-082c-4e27-bc73-6882a1bb8e4c},0", 0x32f8a4)
007e:trace:mmdevapi:MMDevPropStore_Release Refcount now 0
007e:trace:mmdevapi:MMDevice_QueryInterface (0x86f0d20)->({1be09788-6894-4089-8586-9a2a6c265ac5},0x32f8e8)
007e:trace:mmdevapi:MMEndpoint_AddRef (0x86f0d20)
007e:trace:mmdevapi:MMDevice_AddRef Refcount now 2
007e:trace:mmdevapi:MMEndpoint_GetDataFlow (0x86f0d20)->(0x8672c90)
007e:trace:mmdevapi:MMEndpoint_Release (0x86f0d20)
007e:trace:mmdevapi:MMDevice_Release Refcount now 1
007e:trace:mmdevapi:MMDevice_Activate (0x86f0d20)->(0x10f8aa4,1,(nil),0x32f8f8)
007e:trace:alsa:AUDDRV_GetAudioEndpoint {4b4e922f-b62b-42d8-9a3d-e4ee473607da} 0x86f0d20 0x32f8f8

Firstly, I'd like to say that I'm actually testing RS 2014, not the original, but as they're using the same Audio code (or similar), it should work for both versions.

My RT cable has GUID of 4b4e922f-b62b-42d8-9a3d-e4ee473607da on Wine.

The line: MMDevPropStore_GetValue (0x8671d10)->("{1da5d803-d492-4edd-8c23-e0c0ffee7f0e},0", 0x32f884) is failing returning a value of 2 which is not success.

According to MSDN, this line is wanting to know what kind of device this is, see msdn.microsoft.com/en-us/library/windows/desktop/dd316569%28v=vs.85%29.aspx, it should return Microphone for the RT cable. This is at least one reason why the game is not detecting the cable.