Audio sources

[nightmaar]

Hello OBS community!

Lots of gaming streamers are stucked with one problem—when you stream your game, you want to add music to video, but exclude talking of communication programs (e.g. Ventrilo, Mumble etc.).

So the idea to make an ability to choose audio sources for the stream, as interface of choosing windows (e.g. Audio Player, Game).

I don't know how this will be hard to program, but this feature is extremely useful.

 

[Warchamp7]

Virtual Audio Cables is useful for stuff like this.

 

[nightmaar]

I know about VAC, but this solution is too heavy and not an open source.

 

[Xerouz]

You can do a crude implementation on your system depending on your sound card and communication device setup. If you happen to use a USB headset, then you can separate them. I use a G35 headset for Skype. If I don't want people listening in on my Skype call, I do this:

Set your sound card to your default device. In my case, I use my Hi-Def audio out on my GTX 460. What then OBS will do is pick up anything set to rout to your default audio device for streaming. Then in Skype, you can set your output audio and mic to your headset (not default device). This then should allow you to communicate on Skype (or Mumble, Ventrilo) without your audience hearing.

The downside is, you'll have to reset the audio setting and restart your broadcast if you wish to allow communication later.

I think the implementation of sound sources seems like it would be way more difficult than telling OBS: "Hey, grab the sound from Spotify or Pandora, and leave Skype alone." I don't think sound is routed in the OS that way.

 

[R1CH]

Unfortunately the Windows API doesn't allow you to capture at an application granularity, only per-device. Virtual Audio Cable is the best way to handle it right now. Be careful when using VAC devices as inputs into OBS as it will cause timestamp issues.

 

[Fire]

Unfortunately the Windows API doesn't allow you to capture at an application granularity, only per-device. Virtual Audio Cable is the best way to handle it right now. Be careful when using VAC devices as inputs into OBS as it will cause timestamp issues.

Mind elaborating on this? My virtual mixing setup relies heavily on VAC as I run my microphone through a number of VST effects ( equalizer / notch filter, noise gate, compressor, hard limiter ), and have my system set up to use VAC as the main system device ( So I may set applications like Skype and Mumble to use their own line ) which I then forward directly to headset. I've not set this up yet since reinstalling Windows, so if there's a problem with it knowing ahead of time would help.

As for the topic of this thread, Being able to choose which device is the "speaker" ( Or have a DXTory styled on-the-fly audio source setup ) would be a handy thing. Default to the default audio device as usual, but give the option to change it.

 

[R1CH]

Using VAC as the default device can break your stream due to the way VAC timestamping works. As long as you don't have it as a default playback device for capturing things globally you should be ok.

 

[Fire]

Using VAC as the default device can break your stream due to the way VAC timestamping works. As long as you don't have it as a default playback device for capturing things globally you should be ok.

I guess I'll have to stick to xsplit until you guys can "fix" that then ( Never had a problem with it there, so I presume the issue doesn't exist ). Can't do separated audio from apps without it, and that's of extreme importance to me.

 

[Muf]

I would like to weigh in on this matter. First off, it is possible to capture audio per application in the same way that Game Capture works (using hooking). Jim has said he is fed up with hooking for the time being, and would prefer to explore alternative solutions.

Second, OBS works perfectly with VAC, as long as you use VAC as the "microphone" input in OBS, and don't use VAC as your default audio device. Like Fire, I also apply a number of VST effects to my microphone input using VSTHost, and route VSTHost's output to VAC using ASIO4ALL (believe me when I say the number of potential SNAFUs using this setup is immense). Miraculously, it works perfectly with OBS, and I'm able to share the VAC line between OBS and Skype/TeamSpeak without problems.

The only issue is that the VSTs introduce a small delay to the microphone audio, and OBS does not currently provide a way to delay video/audio separately, so the sound of my mouse clicks through my mic are delayed from the action seen in the stream video.

 

[Fire]

The only issue is that the VSTs introduce a small delay to the microphone audio, and OBS does not currently provide a way to delay video/audio separately, so the sound of my mouse clicks through my mic are delayed from the action seen in the stream video.

VST effect delay is dependant on what it does. For instance, my equalizer, noise gate, and compressor add no delay, but my hard limiter does ( buffer for lookahead, about 30ms ), as does the FIR filter I no longer use ( ~85ms ).

The delay you're seeing if none of your effects add delay is more than likely the natural delay introduced by virtual audio cable ( ~30ms ) and windows shared mode access ( 20ms )

I've not heard anything about hooking applications to steal per-application audio, do you have any more info on that?

 

[Lain]

I may have to make some sort of VAC-specific workaround to get it working properly (unless you use it as a mic as muf suggested, where it supposedly works)

 

[Muf]

VST effect delay is dependant on what it does. For instance, my equalizer, noise gate, and compressor add no delay, but my hard limiter does ( buffer for lookahead, about 30ms ), as does the FIR filter I no longer use ( ~85ms ).
The delay you're seeing if none of your effects add delay is more than likely the natural delay introduced by virtual audio cable ( ~30ms ) and windows shared mode access ( 20ms )

I know all about delay. I use a denoiser and a compressor, and together they add about 182ms of delay. Then there's whatever latency VSTHost, ASIO4ALL and VAC add. I usually just monitor my VAC line on earphones and clap my hands on camera to determine the total system latency.

I've not heard anything about hooking applications to steal per-application audio, do you have any more info on that?

It's quite similar to hooking Direct3D. You hook the IAudioRenderClient interface, and intercept GetBuffer to read the audio samples.

 

[Fire]

VST effect delay is dependant on what it does. For instance, my equalizer, noise gate, and compressor add no delay, but my hard limiter does ( buffer for lookahead, about 30ms ), as does the FIR filter I no longer use ( ~85ms ).
The delay you're seeing if none of your effects add delay is more than likely the natural delay introduced by virtual audio cable ( ~30ms ) and windows shared mode access ( 20ms )

I know all about delay. I use a denoiser and a compressor, and together they add about 182ms of delay. Then there's whatever latency VSTHost, ASIO4ALL and VAC add. I usually just monitor my VAC line on earphones and clap my hands on camera to determine the total system latency.

I've not heard anything about hooking applications to steal per-application audio, do you have any more info on that?

It's quite similar to hooking Direct3D. You hook the IAudioRenderClient interface, and intercept GetBuffer to read the audio samples.

Yeah the denoiser is the big problem there, they usually require a buffer to analyze the noise profile so they can apply that. I ended up shifting away from that and using a multiband compressor + a noise gate, with release and attack times tweaked, so when the gate it up my voice is coming through, which due to dynamic range compression shunts the general noise down low enough it's not an issue, then I have the release set high enough that the gate has already been closed by the time the noise would have reached an audible level again. no delay on that combo beside the inherent device delay.

 

[Muf]

Yeah the denoiser is the big problem there, they usually require a buffer to analyze the noise profile so they can apply that. I ended up shifting away from that and using a multiband compressor + a noise gate, with release and attack times tweaked, so when the gate it up my voice is coming through, which due to dynamic range compression shunts the general noise down low enough it's not an issue, then I have the release set high enough that the gate has already been closed by the time the noise would have reached an audible level again. no delay on that combo beside the inherent device delay.

I don't like the "sandy" sound of a noise gate without denoising. My fix for the latency is to use a 192KHz sampling rate, because the VST filters have a fixed amount of samples that they need to buffer; so the higher your sample rate, the lower your latency. Really though, with latency under a quarter of a second, you don't notice at all in Skype or TeamSpeak. I used to have much higher latency, and then you get the issue that you keep interrupting each other when you're trying to say something (quite funny but also very annoying).

 

[Fire]

Yeah the denoiser is the big problem there, they usually require a buffer to analyze the noise profile so they can apply that. I ended up shifting away from that and using a multiband compressor + a noise gate, with release and attack times tweaked, so when the gate it up my voice is coming through, which due to dynamic range compression shunts the general noise down low enough it's not an issue, then I have the release set high enough that the gate has already been closed by the time the noise would have reached an audible level again. no delay on that combo beside the inherent device delay.

I don't like the "sandy" sound of a noise gate without denoising. My fix for the latency is to use a 192KHz sampling rate, because the VST filters have a fixed amount of samples that they need to buffer; so the higher your sample rate, the lower your latency. Really though, with latency under a quarter of a second, you don't notice at all in Skype or TeamSpeak. I used to have much higher latency, and then you get the issue that you keep interrupting each other when you're trying to say something (quite funny but also very annoying).

Ah, I'd not thought about using a higher sampling rate ( Mainly because my microphone only supports a max of 48k ). You shouldn't have a sandy issue though unless your attack is too low ( Or release too long ), or you just have a massive amount of noise in your area.

Yeah the latency can easily become an issue, I think I had a one to two second delay in speech when I was initially flailing about trying to figure this stuff out. As funny as that was, trying to have quick conversations was as aggravating as talking on a cell phone.

 

[Muf]

You shouldn't have a sandy issue though unless your attack is too low ( Or release too long ), or you just have a massive amount of noise in your area.

I sit next to the whirring fans of a heavy-duty workstation, so you could have the best mic in the world and still get noise :)

 

[Fire]

You shouldn't have a sandy issue though unless your attack is too low ( Or release too long ), or you just have a massive amount of noise in your area.

I sit next to the whirring fans of a heavy-duty workstation, so you could have the best mic in the world and still get noise :)

Hahaha yeah true enough

 

[micechal]

If you open Windows's audio mixer, you can set volume level for any app independently, for example Opera and Foobar2000. Couldn't OBS do it in a similar way? I've heard something about WASAPI and loopback capture, but I don't know if it has any use in this situation :)