AnsweredAssumed Answered

17.7.2 ReLive / Microphone Record Issues

Question asked by leyvin on Aug 3, 2017
Latest reply on Aug 7, 2017 by leyvin

ReLive-Issue.png

 

2017 08 03 14 09 - YouTube // ReLive Recording

RADEON SETTINGS 03 08 2017 14 09 28 - YouTube // Xbox DVR Recording

 

I recorded both via ReLive and Xbox DVR at the same time to showcase the issue better, and should be able to be played in side-by-side tabs remaining in-sync.

The issue is somewhat basic here. Regardless of the Headset there is simply nothing recorded via the Xbox One (or Xbox 360) Controller... Kinect (v1/v2 via USB 2/3) simply crash ReLive.

 

While the Headsets I have do "Technically" work to record via the Realtek Mic In (Back or Front) Ports... the reality is it's barely audible even with maximum boost and record levels, and it sounds like I'm trapped down a Robotic Toilet. That makes even C64 Vox Codec sound state of the art; thus not an option.

 

Now from the Systems perspective, I'm simply using a USB Headset... and thus it works in... well everything.

And I have no issues recording System or Game Audio; Zero. Bare in mind the "Output" is again said same Headset, which flicking through the forums beyond the obvious "Activate Mic Recording" (see Videos) responses seems to be the main caveat most are running into as an issue; and I'm feeling somewhat special in the case where many complain they can Record Game (Desktop) OR Microphone, just not both.

 

Honestly that as a problem would be a step up from just getting nothing... and feel free to crank up those audio settings to max, it's not simply very quiet... it's outright not recording anything.

 

< • >

 

Now as a short additional... is there an ETA on when you're going to Fix Multi-Adapter Support (in DirectX 12) when using an APU + Discreet GPU?

I get an Access Violation each time I attempt to create a Shared Heap.

2 Discreet GPU though... not an issue.

 

And no, I'm not talking Crossfire but MGPU (MDA) DirectX 12 functionality, it works very differently to Driver-Based AFR on two (near) identical GPU.

There was an issue introduced in Crimson Relive that created this 'Access Violation' issue when creating the Shared Heap Memory (think Software UMA) that allows 2 completely different GPU with different Processing Capabilities and VRAM Sizes; as if for example the R7 Graphics on the APU is merely handling FXAA, HBAO+, etc. it doesn't strictly need the *entire* scene just the data important to doing it's task between Barriers. It allows you to leverage additional Graphics more efficiently for performance uplifts; and the APU + Discreet GPU or Old GPU + New GPU are likely to be the most common scenarios; and realistically speaking the former is more likely than the latter because you don't need an extra PCI-E x16 Slot.

 

Still with Boards like the B350, which "Technically" don't support Crossfire but *do* have an additional PCI-E x16 Slot .. this opens up the likelihood of Multi-GPU Systems to be more commonly available but only really utilisable via said MGPU approaches. This as I noted does still work, but Scenario 1 doesn't.

With 7th Gen being quite popular amongst OEM Manufacturers like Dell / HP / etc. and Raven Ridge (Ryzen APUs) also expected towards the end of the year / early next year... well this is likely to become an ever increasingly likely Scenario to perhaps have resolved.

 

Given they're going to be up to 8C/16T Variants (thus likely also 16CU, which is why I'd imagine the RX 560 was bumped up to 16CU from the 14CU of the RX 460; so you're only making a single component for the SoC) .. this means you'll have Competent 1080p Gaming APU that also has the Processing Power to be paired with RX 580 / VEGA without really compromising performance; and having an extra 16CU just sat there on the CPU, be somewhat of a waste due to a Driver Bug that prevents Shared Memory.

Outcomes