Using a Presonus Quantum Thunderbolt 2 Audio Interface...HELP

[joevt]

Well, to be sure, I added applealc with the ALC1220 profile and now osx finds my display as an output source (I already had lilu and green and so on). No change in the VRS8 situation. Ain't this a B.

The graphics card has it's own HD Audio device (controls audio to attached displays). The HD Audio device of the motherboard should also be working (controls audio to headphone, microphone, 5.1 audio jacks of the motherboard).

 

[MyTosh]

The graphics card has it's own HD Audio device (controls audio to attached displays). The HD Audio device of the motherboard should also be working (controls audio to headphone, microphone, 5.1 audio jacks of the motherboard).

Oh yes. I had one line wrong in my config.plist. I fixed it and now the mobo's audio also shows up. No VRS8 luck.

In Audio Midi Setup the VRS8 part says 0 ins / 0 outs and it tells that the clock source is "offline device". So basically OSX thinks the VRS8 is offline.

 

[luckyal]

So @joevt - based on your expert opinion and everything you know so far - do you think this is a Thunderbolt specific issue and at this point based on what @MyTosh says:

I asked the Slate team about it, and I was assured that the same driver we already have works for both thunderbolt and the pcie card in osx already in every version up to date.

1. Should we both focus on implementing the PCIe card since the driver is the same (and the device appears via both connections in IOReg)?
2. Should we focus our efforts on an SSDT like @kgp says? (assuming a TH3 iplementation - not sure if this is needed for PCIe)
or
3. Is this specifically a VRS-8 driver issue?
or
4. Does this look like an underlying IOKit driver issue that is specific to Hackintosh. (UAD, Focusrite and many others as described in this thread are working just fine)

This problem had me going down a few bunny trails and I found that others had issues such as one described (and solved via a workaround) in this post on Insanelymac. Obviously the thread is specific to USB, but I wonder if there is something similar going on here with respect to the system drivers, especially in light of the fact that I'm missing a bunch of Thunderbolt specific drivers relative to a real Mac (as I mentioned in Post #44). Again, the fact that UAD and Focusrite drivers are getting around whatever issue there is, tells me that there may be something else going on. Thoughts?

 

[MyTosh]

On a side note, when you open the VRS8 Panel and go to Help, it says: "Help isn't available for VRS8 Panel". I bet it isn't!

 

[joevt]

We can assume the kext is loading and running because it adds VRS8 properties to the IORegistry ("VRS8EngineUID_5" to Root and "VRS8PciAddr_0" and "VRS8PciAddr_1" to the IOPCI2PCIBridge of pci1b21,1080). This is done by the net_egosys_driver_VRS8Audio::initHardware(IOService*) method (see IOAudioDevice::initHardware(IOService*)). This is the same method that looks for the Thunderbolt properties.

The net_egosys_driver_VRS8Audio IOAudioDevice is the first thing that should get attached to pci1412,1724@0 but it doesn't exist in the Hackintosh PCI or Thunderbolt case.

Check the log for messages reported by VRS8 drivers and apps:

log show --predicate 'senderImagePath CONTAINS "VRS8" OR (process == "kernel" AND eventMessage CONTAINS "VRS8")' --last boot --source --info --debug --signpost

 

[luckyal]

Check the log for messages reported by VRS8 drivers and apps

Which log? The code you post, is that an extract from those log messages?

 

[luckyal]

We can assume the kext is loading and running because it adds VRS8 properties to the IORegistry ("VRS8EngineUID_5" to Root and "VRS8PciAddr_0" and "VRS8PciAddr_1" to the IOPCI2PCIBridge of pci1b21,1080). This is done by the net_egosys_driver_VRS8Audio::initHardware(IOService*) method (see IOAudioDevice::initHardware(IOService*)). This is the same method that looks for the Thunderbolt properties.

Also, I don't see anything with "VRS8" or "net_egosys" in IORegistry Explorer at all. Where do you see this? Are you sure you're not looking at the Macbook Pro IOReg dump?

 

[joevt]

Which log? The code you post, is that an extract from those log messages?

log is a command you enter in Terminal.app. Use "man log" to learn more about the log command. You can tell it's a command because of all the -- parameters. -- is usually used for full name parameters and - is usually used by short name parameters but a command can use anything it wants for a parameter.

Also, I don't see anything with "VRS8" or "net_egosys" in IORegistry Explorer at all. Where do you see this? Are you sure you're not looking at the Macbook Pro IOReg dump?

ioreg is easier to search than IORegistryExplorer.app for property names and values. The property names exist in the ioreg for all three setups (MacBook Pro, Hackintosh PCI, Hackintosh Thunderbolt). The "net_egosys_driver_VRS8Audio::initHardware" method name exists in the disassembly of the kext driver (using Hopper.app). IOAudioDevice::initHardware is documented in the Apple developer web pages.

 

[luckyal]

Check the log for messages reported by VRS8 drivers and apps

This is what I get when I ran your command:

[SIZE=3]iMac-i7-2:~ luckyal$ log show --predicate 'senderImagePath CONTAINS "VRS8" OR (process == "kernel" AND eventMessage CONTAINS "VRS8")' --last boot --source --info --debug --signpost
Filtering the log data using "senderImagePath CONTAINS "VRS8" OR (process == "kernel" AND composedMessage CONTAINS "VRS8")"
Timestamp                       Thread     Type        Activity             PID    TTL
2019-01-29 11:22:00.569064-0800 0x58c      Default     0x0                  0      0    <VRS8AudioDriver`net_egosys_driver_VRS8Audio::initHardware(IOService*)> kernel: (VRS8AudioDriver) AEsi::fEngineUID_startNo=5, fEngineUID=5
2019-01-29 11:22:02.416226-0800 0x58c      Default     0x0                  0      0    <VRS8AudioDriver`net_egosys_driver_VRS8AudioEngine::CreateAudioStream(IOAudioEngine*, _IOAudioStreamDirection, unsigned int, unsigned int, _IOAudioStreamFormat*, DmaPortIndex, unsigned int, char const*)> kernel: (VRS8AudioDriver) AEsiAudioEngine[]::CreateAudioStream() failed to allocate IOBufferMemoryDescriptor
2019-01-29 11:22:02.426047-0800 0x58c      Default     0x0                  0      0    <VRS8AudioDriver`net_egosys_driver_VRS8AudioEngineIn::initHardware(IOService*)> kernel: (VRS8AudioDriver) AEsiAudioEngineIn[]::initHardware(), failed to create all streams.
2019-01-29 11:22:02.435476-0800 0x58c      Default     0x0                  0      0    <VRS8AudioDriver`net_egosys_driver_VRS8AudioEngineIn::initHardware(IOService*)> kernel: (VRS8AudioDriver) AEsiAudioEngineIn: failed to create analogInputStream!
2019-01-29 11:22:02.444534-0800 0x58c      Default     0x0                  0      0    <VRS8AudioDriver`net_egosys_driver_VRS8Audio::initHardware(IOService*)> kernel: (VRS8AudioDriver) AEsiAudioDevice[<private>]::initHardware: failed!
2019-01-29 14:51:36.984948-0800 0x4cf8     Info        0x0                  552    0    <VRS8PanelHelper`-[ASLLogManager logWithFormat:]> VRS8PanelHelper: Did finish launching
2019-01-29 14:51:37.021611-0800 0x4cf8     Default     0x0                  552    0    <VRS8PanelHelper`-[AppDelegate coreAudioChange]> VRS8PanelHelper: coreAudioChange()::Plug/Unplug notification
2019-01-29 14:51:37.022782-0800 0x4cf8     Default     0x0                  552    0    <VRS8PanelHelper`-[AppDelegate coreAudioChange]> VRS8PanelHelper: coreAudioChange()::Unplug notification
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          7, Info:                1, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0[/SIZE]

 

[joevt]

This is what I get when I ran your command:

Seems that net_egosys_driver_VRS8AudioEngine::CreateAudioStream fails to allocate an IOBufferMemoryDescriptor which causes net_egosys_driver_VRS8AudioEngineIn::initHardware to fail which causes net_egosys_driver_VRS8Audio::initHardware to fail. But there's no way to tell why the IOBufferMemoryDescriptor could not be allocated without stepping through the code.

Log output from a MacBook Pro might show what the output from the Hackintosh is supposed to look like (but probably not how to fix it).

If the Slate people wanted to fix this, they would get their own Hackintosh or ask for your ioreg output and log results...