ASIO support

Alright, let's get this out of the way first:

37307166.jpg


My feature request is baseless? First of all, it is our (the community) feature request, and it is far from baseless. Granted, I will absolutely agree that a lot of the community currently exists out of people who don't really know what they're doing and don't know what they're asking for. However, responding like that simply because of that large portion of the community is just a huge disrespect to those who do take streaming seriously and care about the end product, which is live content of a certain level of quality.

Let's first look at your statement that "ASIO has no place in OBS". What is that based on? That's the biggest nonsense I've ever heard. Worst of all, you don't even elaborate. Please, at least contribute.

All the professional broadcasting software has ASIO support, because it is a big deal. It is really important, and the fact that you're so against having this in OBS, which is broadcasting software, really makes me worry about how much you're really contributing to advancing this piece of software, Muf.

You seem to have a strong opinion, and that's a good quality. However, you at the moment do not connect with the community and even talk down on their perfectly valid ideas. That makes you look very unprofessional, hence my doubts about your contribution to the project in terms of listening to user feedback. Implementing ASIO would be a huge step forward in terms of developing this program for potentially professional causes, whether you like it or not. Saying that ASIO has no place in OBS to me shows a tremendous amount of disconnect between what you personally want out of this project, and what the end-users expect out of broadcasting software.

So, in the end, it isn't just for me, or the guys requesting it. It is for the sake the future of OBS. For it to become a mature product it has to natively support several standards like ASIO, which is a professional standard supported in all professional broadcasting software. If you want to take OBS to that level, it would be wise to implement it.
 

Faruton

Developer
Reading the license for Steinberg's ASIO SDK, there are several requirements that make it prohibitively difficult to include in an open source product.

According to 2.2 of the ASIO SDK license:
  • 2.2. The licensee has no permission to sell, license, give-away and/or distribute the Licensed Software Developer Kit or parts of it in any way, on any medium, including the Internet, to any other person, including sub-licensors of the Licensee or companies where the Licensee has any involvement. This includes re-working this specification, or reverse-engineering any products based on this specification.

This requires that every user download the SDK and build a private version only valid for a single named Licensee.

Jim would also have to license directly from Steinberg as per 2.5 of the agreement:
  • 2.5. If the licensee is planning to publish a product under his own name or under the name of a third party, that is using parts or all of the Licensed Software Developer Kit, the Licensee is under the obligation to inform Steinberg about it by sending the signed 'Steinberg ASIO SDK Licensing Agreement' to Steinberg, either by mail, or by fax.

You might also argue that every plugin developer would also have to have a written agreement according to 2.5 and their definition of 'use' in section 2.1. Though I'm not a lawyer.
 

Muf

Forum Moderator
tl;dr I should probably have added "right now" to my statement.

I agree that ASIO support is something that will take OBS to the next level of professional use along with things like precise frame rates (right now we only support 24 fps, not 23.976, only 30, not 29.970, and only 60, not 59.960), direct output to Osprey/Decklink cards, higher audio sample rates, being able to preview/edit a scene that is not being broadcast, etc.

However, that is not right now, and right now there are more important things to do, like supporting Hauppauge cards, fixing OpenGL capture, etc. And the arguments being dragged in why ASIO would be a priority to implement ASAP are baseless, because anything you can do with ASIO you can do with WASAPI, albeit with a bit more latency (depending on the device -- WASAPI itself is already a huge improvement over DirectSound and invalidates many of the previous advantages of ASIO).


Also -- LOL at your use of that meme, as Jim has said that exact phrase to me in the past :P
 
Faruton said:
Reading the license for Steinberg's ASIO SDK, there are several requirements that make it prohibitively difficult to include in an open source product.

...

You might also argue that every plugin developer would also have to have a written agreement according to 2.5 and their definition of 'use' in section 2.1. Though I'm not a lawyer.

Look, now this is useful. I thought it might have had to do with licensing issues, but since I'm not fully aware of what encapsulates it is useful to at least mention it as a problem. You made it very clear, and I can now perfectly see as to why it is difficult to implement the ASIO standard. I also understand that this difficulty, due to its licensing nature, can play a role in deciding not to include it (for) now, and work on the base product itself first.

Muf said:
tl;dr I should probably have added "right now" to my statement.

...

Also -- LOL at your use of that meme, as Jim has said that exact phrase to me in the past :P

Oh absolutely. In my opinion ASIO is not a priority at all, but it would be nice to have in the final version or perhaps even later. Currently the base product is what needs the most attention. When I made the feature request, I was more or less curious as to whether it was on the development roadmap or not, and what the plans surrounding the matter are. It doesn't have to be implemented in the next release, haha. I haven't done much programming myself, but I know enough about it that I know it's not that easy to do ("Huehuehue, isn't it liek, #include <asio.dll>; or sumthin lol").

WASAPI would be great. Is that easier (in terms of licensing, OS integration and the like) to implement than ASIO? Is there currently already a way to make use of WASAPI, or is that a feature that's for an upcoming release?

Hahah. Seriously, ever since I saw that film I've been quoting it so much. That film is filled to the brim with great quotes, haha.

I've been using your tip about unchecking the IN item for the virtual audio cable. That works pretty well. I quickly tried making a similar setup in REAPER of what I usually do with (the rather wonky) VSTHost. It works with a much lower latency. I'll probably be using that tip, ha!
 

Muf

Forum Moderator
DryRoastedLemon said:
WASAPI would be great. Is that easier (in terms of licensing, OS integration and the like) to implement than ASIO? Is there currently already a way to make use of WASAPI, or is that a feature that's for an upcoming release?
OBS already uses WASAPI. It's the new audio API introduced in Vista, and the successor of Kernel Streaming. What could be done is WaveRT support added, which is a low-level extension of WASAPI that allows for the same low latency that ASIO provides.

DryRoastedLemon said:
I've been using your tip about unchecking the IN item for the virtual audio cable. That works pretty well. I quickly tried making a similar setup in REAPER of what I usually do with (the rather wonky) VSTHost. It works with a much lower latency. I'll probably be using that tip, ha!
Glad to hear it works for you. What's your specific preference towards REAPER? I've been using VSTHost but I'd like more of a "fire and forget" VST rack that remembers the settings for each VST. As it is now I have to load the config from a saved preset for each VST manually whenever I start up VSTHost.
 
Muf said:
OBS already uses WASAPI. It's the new audio API introduced in Vista, and the successor of Kernel Streaming. What could be done is WaveRT support added, which is a low-level extension of WASAPI that allows for the same low latency that ASIO provides.

...

Oh I see. Well, in that case that's good!

...

Glad to hear it works for you. What's your specific preference towards REAPER? I've been using VSTHost but I'd like more of a "fire and forget" VST rack that remembers the settings for each VST. As it is now I have to load the config from a saved preset for each VST manually whenever I start up VSTHost.

Oh, it's mainly because I'm more familiar with REAPER (for making music and such). I've also been using VSTHost, but then in combination with MME, which on my system seems to cause some latency. For some reason I can't get VSTHost to work nicely with ASIO4ALL (I'm not sure what's happening, all inputs and outputs are considered "beyond logic"). How did you get it to work?

You can actually save all the plugins with the settings in VSTHost. I ran into that problem before as well. It would load all the plugins, but none of the settings. Head into the Performance menu and enable "AutoSave Plugin Banks" and save your setup as a performance. The next time you load it up, all your plugins should show up with the settings intact.

In REAPER you'd basically just save a project file. You'd then create a track, assign the right input to it, arm the track and enable monitoring so that the audio is sent to the output you assigned in the settings (in my case a VB-Cable).
 

Muf

Forum Moderator
DryRoastedLemon said:
For some reason I can't get VSTHost to work nicely with ASIO4ALL (I'm not sure what's happening, all inputs and outputs are considered "beyond logic"). How did you get it to work?
Match all your bit depths and sample rates. If your device has a bit depth / sample rate setting in the driver, make sure it's set at the right values, and mirror the values in VAC. Make sure that "Allow applications to take exclusive control of this device" is enabled, but that no other application is currently blocking access (shut down Skype, Mumble and other notoriously intrusive applications). Once VSTHost/ASIO4ALL have established control of your audio devices, it's safe to start other programs again.
 

Muf

Forum Moderator
DryRoastedLemon said:
Did you try the AutoSave Plugin Banks thing to see if it worked?

Yeah, and it does work to save the settings, but it doesn't remember which VST I'm using (there's multiple VSTs in one DLL) so I keep getting the popup to select the VST from the DLL.
 
I'm no expert or anything but if ASIO is easy to implement but it's more of a money and licensing issue why not take an interest check and see if the people who want it can afford it collectively.

I did some research and it seems like if you get permission you may be able to write in and allow it in exchange for credit or because it's free to get the base ASIO you can leave ASIO unimplemented and create a simple way for people to put it in themselves, Audacity does something similar where there's instructions on how to add it into the source code.

http://wiki.audacityteam.org/index.php? ... _Interface
 
Muf said:
DryRoastedLemon said:
Did you try the AutoSave Plugin Banks thing to see if it worked?

Yeah, and it does work to save the settings, but it doesn't remember which VST I'm using (there's multiple VSTs in one DLL) so I keep getting the popup to select the VST from the DLL.

Ohh, I see. What VST are you using for that? Is it something like Guitar Rig, or another VST rack?

But yeah, otherwise you might want to check out REAPER. The product is not free, but it's nicely priced and has a demo online, if I'm not mistaken.
 

Muf

Forum Moderator
DryRoastedLemon said:
Ohh, I see. What VST are you using for that? Is it something like Guitar Rig, or another VST rack?
Waves Z-Noise and Waves C1 Comp. They both come from a bundle which is just one big DLL containing all the VSTs.
 

Kharay

Member
Smashbro29 said:
Muf said:
Smashbro29 said:
Since reading up on this more and more I gotta say, I could really use this.
No.

Educate me, why not?
TL;DR -- Because to the average Joe the benefits are marginal at best in comparison to the time required to add support for it. Given the fact the current audio subsystem of Windows 7 (and 8) offer largely the same kind of performance.

I personally would be more interested to actually know why you could really use this. ;)
 

paibox

heros in an halfshel
If I remember correctly, Smashbro has some issues with audio sync, but the problem is that if you had ASIO support and the audio would get routed through your sound card, you would still have exactly the same issue. The audio desync you were having with your Framemeister stuff is because of the way your sound card buffers data, the audio delay settings in OBS are what you'll want to adjust to combat this issue.

Also, I believe the latest test version of OBS fixed it so that the audio timing adjustment actually works for individual DirectShow devices again.
 
Kharay said:
I personally would be more interested to actually know why you could really use this. ;)

I got equipment that's held back considerably without the support. 24 bit audio has a lot more headroom, headroom is never a bad thing.

paibox said:
If I remember correctly, Smashbro has some issues with audio sync, but the problem is that if you had ASIO support and the audio would get routed through your sound card, you would still have exactly the same issue. The audio desync you were having with your Framemeister stuff is because of the way your sound card buffers data, the audio delay settings in OBS are what you'll want to adjust to combat this issue.

Also, I believe the latest test version of OBS fixed it so that the audio timing adjustment actually works for individual DirectShow devices again.

First off, nice to meet you man! Next, the audio issue was solved by delaying 100-something milliseconds and the issue, I believe is an issue with the card itself and not the signal I'm feeding it. It's unrelated is what I'm saying. The ASIO support is just something that would get me much higher quality because as it stands I'm just taking the sound device's monitor output and putting it in the blue port on my PC's soundcard which is still really nice but not the full potential of the device.
 

Muf

Forum Moderator
Smashbro29 said:
I got equipment that's held back considerably without the support. 24 bit audio has a lot more headroom, headroom is never a bad thing.
You don't need ASIO for 24 bit audio.
 
Top