bigsqueaks
New Member
I am using virtual audio cables to separate my games audio from my desktop sources. I'm using audiorepeater from Virtual Audio Cables to transfer virtual audio cable line wave out ports to virtual audio cable Line 1. I connect Line 1 to my usb headset. My game does not allow the selection of the audio output device so in order to do that in Windows 10, you can click on the speaker in the taskbar notification area, select Line 2 (Virtual Audio Cable), and then start the game. Once the game is started it's output will stick to Line 2. Then I select Line 1 (Virtual Audio Cable) from the speaker and all applications without settings for audio output will default to Line 1.
In OBS, I believe there is a difference between
A) selecting the audio playback device from Settings > Audio > Desktop Audio Device > Line 2 (Virtual Audio Cable) and
B) from Sources > Add Audio Input Source > Device > Line 2 (Virtual Audio Cable).
I have tested with Both A and B simultaneously enabled and one or the other deleted or disabled. Method A works always but Method B is finnicky.
I believe the difference is that A uses shared-mode connections and B uses or attempts to use exclusive-mode connections. I thought they both used the WASAPI level but now I'm not sure at all. I tried to view source code for answers but I'm inexperienced at this.
Break break I just did a bunch of testing. I was trying to figure out OBS's behavior in regards to what level of audio interface it is using (WDM/KS or DirectSound/WASAPI) and shared vs exclusive modes but I'm not sure I'm able to pin it down at this point because the behavior is eratic (maybe OBS has fall-back upon failures?). I'm going to give some examples to try to illustrate the problem.
1) Obs is closed. The game is running and rendering (producing source audio) on Line 2 (Virtual Audio Cable). Desktop Audio Device 2 is set to Line 2 (Virtual Audio Cable). Source Line2Test is set to Line 2 (Virtual Audio Cable). Audio Repeater (Kernel Streaming) Wave In is Virtual Cable 2, Wave Out is Virtual Cable 1 and started.
Result: Both desktop Audio 2 and Line2Test are receiving audio from the game on Line 2.
4) Audio Repeater (MME) and OBS (sources box source for Line 2 Virtual Audio Cable) behave similarly. If Audio Repeater (KS) is the first capture device for Line 2 (Virtual Audio Cable), then trying to start Audio Repeater (MME) gives error "Cannot open input device (4 - The specified device is already in use)" and OBS (sources Line 2) does not receive audio. But, Audio Repeater (KS) can be started after either Audio Repeater (MME) or OBS is started and are capturing Line (2).
Here is why the implementation of OBS Audio Input Capture in the Sources box may be a problem, from the Virtual Audio Cable documentation.
Audio Repeater KS request exclusive-mode KS (kernel streaming)/low-level connection to the pin. This is documented in Virtual Audio Cable help files and is because KS only supports exclusive-mode access.
Audio Repeater MME requests shared-mode MME/high-level connection to the pin and is served by System Audio Engine (actual engine varies by operating system, this is a historical name).
I recommend the behavior for Desktop Audio Device and Sources be the same if possible to prevent the confusion I'm going through.
In OBS, I believe there is a difference between
A) selecting the audio playback device from Settings > Audio > Desktop Audio Device > Line 2 (Virtual Audio Cable) and
B) from Sources > Add Audio Input Source > Device > Line 2 (Virtual Audio Cable).
I have tested with Both A and B simultaneously enabled and one or the other deleted or disabled. Method A works always but Method B is finnicky.
I believe the difference is that A uses shared-mode connections and B uses or attempts to use exclusive-mode connections. I thought they both used the WASAPI level but now I'm not sure at all. I tried to view source code for answers but I'm inexperienced at this.
Break break I just did a bunch of testing. I was trying to figure out OBS's behavior in regards to what level of audio interface it is using (WDM/KS or DirectSound/WASAPI) and shared vs exclusive modes but I'm not sure I'm able to pin it down at this point because the behavior is eratic (maybe OBS has fall-back upon failures?). I'm going to give some examples to try to illustrate the problem.
1) Obs is closed. The game is running and rendering (producing source audio) on Line 2 (Virtual Audio Cable). Desktop Audio Device 2 is set to Line 2 (Virtual Audio Cable). Source Line2Test is set to Line 2 (Virtual Audio Cable). Audio Repeater (Kernel Streaming) Wave In is Virtual Cable 2, Wave Out is Virtual Cable 1 and started.
1. Start OBS.
<snip>
Result: Desktop Audio 2 is receiving sound from the game on Line 2 (Virtual Audio Cable), clearly by the mixer level in OBS. Line2Test is not receiving audio from the game like I would expect.
2. Stop Audio Repeater. "Audio Repeater (Kernel Streaming) Wave In is Virtual Cable 2, Wave Out is Virtual Cable 1"
Result: A new process ID appears for Virtual Audio Cable (Line 2) in the info window for Line 2 of Virtual Audio Control Panel.
4. Press Start on Audio Repeater "Audio Repeater (Kernel Streaming) Wave In is Virtual Cable 2, Wave Out is Virtual Cable 1"
Result: No changes in OBS, it continues to work. A new process ID appears for Virtual Audio Cable (Line 2), from audio repeater. Starting and Stopping Audio repeater (Kernel Streaming) is the workaround I could use if I wanted to add Audio Input Source (Line 2 Virtual Audio Cable) by the Sources box.
2) Same conditions as 1), except: Audio Repeater (MME) Wave In (Line 2) and Wave Out (Line 1) is started instead of Audio Repeater (Kernel Streaming).
Code:
22:40:34.165: WASAPI: Device 'Line 2 (Virtual Audio Cable)' initialized
Code:
22:40:34.413: [WASAPISource::TryInitialize]:[Line 2 (Virtual Audio Cable)] Failed to get initialize audio client: 8889000A
22:40:34.413: [WASAPISource::WASAPISource] Device '{0.0.1.00000000}.{797c2b00-6da3-436f-932a-3a6daa2222f0}' not found. Waiting for device
2. Stop Audio Repeater. "Audio Repeater (Kernel Streaming) Wave In is Virtual Cable 2, Wave Out is Virtual Cable 1"
Result: A new process ID appears for Virtual Audio Cable (Line 2) in the info window for Line 2 of Virtual Audio Control Panel.
Code:
22:44:27.192: WASAPI: Device 'Line 2 (Virtual Audio Cable)' initialized
Result: No changes in OBS, it continues to work. A new process ID appears for Virtual Audio Cable (Line 2), from audio repeater. Starting and Stopping Audio repeater (Kernel Streaming) is the workaround I could use if I wanted to add Audio Input Source (Line 2 Virtual Audio Cable) by the Sources box.
1. Start OBS.
Result: Both Desktop Audio 2 and Line2Test are receiving audio from the game on Line 2.
3) Same conditions as 1) except: Audio Repeater (MME) Wave In (Line 2) and Wave Out (Line 1) is started AND THEN Audio Repeater (Kernel Streaming) Wave In (Line 2) and Wave Out (Line 1) is started.
Code:
23:08:40.430: WASAPI: Device 'Line 1 (Virtual Audio Cable)' initialized
23:08:40.440: WASAPI: Device 'Line 2 (Virtual Audio Cable)' initialized
23:08:40.465: WASAPI: Device 'Line 5 (Virtual Audio Cable)' initialized
23:08:40.479: WASAPI: Device 'Line 1 (Virtual Audio Cable)' initialized
23:08:40.479: [Media Source 'background_noise']: settings:
23:08:40.479: input: I:/Documents/My Projects/Terraria_videos/obsvideos/background_noise.flv
23:08:40.479: input_format: (null)
23:08:40.479: is_looping: yes
23:08:40.479: is_forcing_scale: yes
23:08:40.479: is_hw_decoding: yes
23:08:40.479: is_clear_on_media_end: yes
23:08:40.479: restart_on_activate: yes
23:08:40.506: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds
23:08:40.521: WASAPI: Device 'Line (Steinberg UR22mkII )' initialized
23:08:40.521: source 'AT2035_nofilter' enabled push-to-mute
23:08:40.572: WASAPI: Device 'Microphone (Realtek High Definition Audio)' initialized
23:08:40.572: source 'Headsetmic' enabled push-to-mute
23:08:40.578: WASAPI: Device 'Line (Steinberg UR22mkII )' initialized
23:08:40.601: WASAPI: Device 'Line 2 (Virtual Audio Cable)' initialized
Code:
23:00:35.245: WASAPI: Device 'Line 1 (Virtual Audio Cable)' initialized
23:00:35.258: WASAPI: Device 'Line 2 (Virtual Audio Cable)' initialized
23:00:35.287: WASAPI: Device 'Line 5 (Virtual Audio Cable)' initialized
23:00:35.300: WASAPI: Device 'Line 1 (Virtual Audio Cable)' initialized
23:00:35.300: [Media Source 'background_noise']: settings:
23:00:35.300: input: I:/Documents/My Projects/Terraria_videos/obsvideos/background_noise.flv
23:00:35.300: input_format: (null)
23:00:35.300: is_looping: yes
23:00:35.300: is_forcing_scale: yes
23:00:35.300: is_hw_decoding: yes
23:00:35.300: is_clear_on_media_end: yes
23:00:35.300: restart_on_activate: yes
23:00:35.344: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds
23:00:35.405: WASAPI: Device 'Line (Steinberg UR22mkII )' initialized
23:00:35.405: source 'AT2035_nofilter' enabled push-to-mute
23:00:35.492: WASAPI: Device 'Microphone (Realtek High Definition Audio)' initialized
23:00:35.492: source 'Headsetmic' enabled push-to-mute
23:00:35.499: WASAPI: Device 'Line (Steinberg UR22mkII )' initialized
23:00:35.533: WASAPI: Device 'Line 2 (Virtual Audio Cable)' initialized
Here is why the implementation of OBS Audio Input Capture in the Sources box may be a problem, from the Virtual Audio Cable documentation.
Windows 6.x systems have a common bug that prevents System Audio Engine from creating its common capture (recording) pin instance for shared-mode access if there are some active (allocated) pin instances (streams). For example, it occurs if you have started recording using KS interface (KS version of Audio Repeater, ASIO4ALL or something like) and then try to start recording using a higher-level interface (MME, DS, WASAPI) in shared mode. As a workaround, start the higher-level interface first then start KS recording..
Audio Repeater KS request exclusive-mode KS (kernel streaming)/low-level connection to the pin. This is documented in Virtual Audio Cable help files and is because KS only supports exclusive-mode access.
Audio Repeater MME requests shared-mode MME/high-level connection to the pin and is served by System Audio Engine (actual engine varies by operating system, this is a historical name).
Only exclusive-mode connection allows the application to become VAC client, create its own pin instance and an associated data stream. For each exclusive-mode connection, an additional stream is counted by the recording/playback stream counter.
I recommend the behavior for Desktop Audio Device and Sources be the same if possible to prevent the confusion I'm going through.