GSIF2 drivers are developed for many cards - its host support it would need though I guess. Part of the problem might be Steinberg - they developed ASIO didn't they? And Microsoft push WDM - there's a monopoly there standing in the way of develpment.
(same issue for DWave btw - no enough just to push for cards to support it if hosts and other audio apps don't - you need both)
Bob L tells truth about Windows auido drivers
-
- KVRAF
- 37549 posts since 14 Sep, 2002 from In teh net
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Effectively, Bob would need to sell or give DWave to a company large enough to make it happen, which sucks because the two companies you mentioned have vested interest in their own technologies.
Greg
Greg
-
- KVRist
- 210 posts since 10 May, 2001 from The Netherlands
In my opinion, the biggest chance to get this to a real standard is by making Dwave as open as possible:
- Making the specification open and public.
- Create an open-source reference implemention of a common Dwave driver. This way, audio card companies can take this as base and tweak it for their own cards.
- Create an open-source reference implemention of a Dwave client application / library.
This kind of stuff should make it easier to adapt the Dwave specification.
- Making the specification open and public.
- Create an open-source reference implemention of a common Dwave driver. This way, audio card companies can take this as base and tweak it for their own cards.
- Create an open-source reference implemention of a Dwave client application / library.
This kind of stuff should make it easier to adapt the Dwave specification.
Last edited by Durk on Tue Sep 07, 2004 12:33 pm, edited 1 time in total.
-
- KVRer
- Topic Starter
- 9 posts since 29 May, 2004
First,I took it upon myself to "spread" this info.
Bob Lentini was answering a question about why he doesnt prefer ASIO in SawStudio forum.
The basic information he supplies is critcal in IMO.
Why we get clicks and pops when recording and playback should be the most important issue to us.
I was not aware of the ASIO and WDM driver architecture and found Bob's reply to be most intriguing.
When ASIO first came out no one was supporting that but it slowly became more popular. (remeber supply & demand? )
This will not be easy and quick ...I'm sure of that.
But,there is positive feedback from Sydec customers using the Dwave driver.
Bob Lentini with RML Labs is the developer of Dwave.
If you goto Sydec's site and look at the Mixtreme 192 audio card you will see an audio card that has Dwave implemented.
I am ordering one this weekend!!
- As Robert Randolph stated,this is not proprietary to SAWStudio.Bob states above he would like to see other Co.'s help develop and test this Driver.
Bob Lentini was answering a question about why he doesnt prefer ASIO in SawStudio forum.
The basic information he supplies is critcal in IMO.
Why we get clicks and pops when recording and playback should be the most important issue to us.
I was not aware of the ASIO and WDM driver architecture and found Bob's reply to be most intriguing.
When ASIO first came out no one was supporting that but it slowly became more popular. (remeber supply & demand? )
This will not be easy and quick ...I'm sure of that.
But,there is positive feedback from Sydec customers using the Dwave driver.
Bob Lentini with RML Labs is the developer of Dwave.
If you goto Sydec's site and look at the Mixtreme 192 audio card you will see an audio card that has Dwave implemented.
I am ordering one this weekend!!
- As Robert Randolph stated,this is not proprietary to SAWStudio.Bob states above he would like to see other Co.'s help develop and test this Driver.
-
- KVRer
- 1 posts since 7 Sep, 2004
Hi
I havent looked at the specs (cant find them), but somebody will need to explain me how buffering loads of buffers in advance to the card is going to improve latency
I think this proposed driver could have advantages over ASIO but only for sequencer record/playback, not for low latency live action.
The idea of having to switching drivers depending on the job at hand is pretty scary imho
I havent looked at the specs (cant find them), but somebody will need to explain me how buffering loads of buffers in advance to the card is going to improve latency
I think this proposed driver could have advantages over ASIO but only for sequencer record/playback, not for low latency live action.
The idea of having to switching drivers depending on the job at hand is pretty scary imho
-
- KVRAF
- 4735 posts since 18 Jul, 2002 from London, UK
Sigh... if it ain't broke, don't fix it.
ASIO is not perfect (making it mandatory for apps to support a dozen different byte formats is a royal PITA, for example), but it's versatile, and not half as bad as it's being made out to be. For example, quite a few ASIO drivers can and do support extra buffers (not just the one). You can trade off latency against interruptibility. There's nothing to stop an ASIO driver from being multi-client (again, there's a latency tradeoff, and some extra work for the driver writer). CoreAudio follows the same broad model as ASIO, but doesn't restrict you to two primary buffers and is generally more elegant, as you'd expect.
vedgy is spot-on... for an app like SAW, this new model might be better, but for a pseudo-realtime audio engine like most of today's DAWS have, it's unusable.
If you're getting clicks and pops, turn up your I/O buffer size or buffer queue length in the ASIO driver (yes, ASIO is only double-buffered at the API level, but that doesn't preclude larger buffers in the driver itself), fix your computer, or demand a better ASIO driver from your sound card manufacturer.
GSIF is a different beast again... it's a driver where the interface (API) between the driver and application runs in kernel mode, and the app's audio rendering engine is thereby able to run at a very low level. It gives the lowest possible latencies, but anyone that thinks that running a ton of half-tested, mostly-stable-most-of-the-time VST plug-ins in kernel mode is a good idea should have their head examined (bluescreen city, here we come). Works OK for Giga, as they're a single vendor with the resources and expertise to do it right... for anything VST, it would be a nightmare.
ASIO is not perfect (making it mandatory for apps to support a dozen different byte formats is a royal PITA, for example), but it's versatile, and not half as bad as it's being made out to be. For example, quite a few ASIO drivers can and do support extra buffers (not just the one). You can trade off latency against interruptibility. There's nothing to stop an ASIO driver from being multi-client (again, there's a latency tradeoff, and some extra work for the driver writer). CoreAudio follows the same broad model as ASIO, but doesn't restrict you to two primary buffers and is generally more elegant, as you'd expect.
vedgy is spot-on... for an app like SAW, this new model might be better, but for a pseudo-realtime audio engine like most of today's DAWS have, it's unusable.
If you're getting clicks and pops, turn up your I/O buffer size or buffer queue length in the ASIO driver (yes, ASIO is only double-buffered at the API level, but that doesn't preclude larger buffers in the driver itself), fix your computer, or demand a better ASIO driver from your sound card manufacturer.
GSIF is a different beast again... it's a driver where the interface (API) between the driver and application runs in kernel mode, and the app's audio rendering engine is thereby able to run at a very low level. It gives the lowest possible latencies, but anyone that thinks that running a ton of half-tested, mostly-stable-most-of-the-time VST plug-ins in kernel mode is a good idea should have their head examined (bluescreen city, here we come). Works OK for Giga, as they're a single vendor with the resources and expertise to do it right... for anything VST, it would be a nightmare.
-
- KVRist
- 222 posts since 7 Apr, 2003 from San Francisco, CA
OK, I am not up to speed with the latest driver technology so I can't say much about that.
I have a lot of respect for Bob Lentini, he is really a great person that is obviously very smart at what he does. In the past I have actually written two plugins for SAW when it was still using it's own proprietary API (does it still have that?). The two plugins were Stereo Enhancer and Multiband Dynamics if anyone remembers those.
Anyway, during the development of these plugins I actually got to speak to Bob on the phone once or twice. Really nice person, loves what he does and is always ready to help out. One thing that struck me about him though was that he was an "old school" type programmer. This is why SAW is mostly (completely?) written in machine language. While that has one advantage (speed) it has many disadvantages. Mostly that it makes development/debugging difficult and slow, it makes it a pain to add new features, difficult to support multiple data types, difficult to make architectural changes, etc. But that's a topic for another thread...
At the time I wanted to use floating point inside my Multiband Dynamics plug-in, and since the stream of samples was integer, I needed to convert it to float and back again afterwards. That didn't actually add too much to the processing time so it was not a big problem really. But I did talk to Bob about SAW supporting floating point math in future versions, but he was adamant that he will never support floating point as it will never be fast enough. Bob had some custom-designed fixed-point math implementation that he insisted would always be faster than any floating-point math. Using fixed-point math is a multi-step process for every single operation you do, and I am 100% sure at some point doing floating-point math vs fixed point math became faster. Bob said he did some of his own benchmarks and found that floating point math was way too slow. But his results didn't compare well with my own findings, and I got to the conclusion that the benchmarks he was stating was obviously quite a few years old and dated. He was just very hardheaded about it and at the time refused to believe that processors could have evolved to the point that floating point was useable for DSP work.
Anyway, my point is that Bob is somewhat of an odd one out. He is very smart, yet quite old school in his thinking. Hearing that he hates multi-formats makes sense. My point is that you have to take these things into account when he talks about this type of stuff. Obviously ASIO is not ideal for SAW, but as Angus points out, other apps don't have big issues with it. I'm sure ASIO is not perfect, but not as bad as Bob makes it sound. I'm not sure a mass migration away from ASIO to a driver model that works better for SAW is necessarily the smartest thing to undertake.
BitFlipper
I have a lot of respect for Bob Lentini, he is really a great person that is obviously very smart at what he does. In the past I have actually written two plugins for SAW when it was still using it's own proprietary API (does it still have that?). The two plugins were Stereo Enhancer and Multiband Dynamics if anyone remembers those.
Anyway, during the development of these plugins I actually got to speak to Bob on the phone once or twice. Really nice person, loves what he does and is always ready to help out. One thing that struck me about him though was that he was an "old school" type programmer. This is why SAW is mostly (completely?) written in machine language. While that has one advantage (speed) it has many disadvantages. Mostly that it makes development/debugging difficult and slow, it makes it a pain to add new features, difficult to support multiple data types, difficult to make architectural changes, etc. But that's a topic for another thread...
At the time I wanted to use floating point inside my Multiband Dynamics plug-in, and since the stream of samples was integer, I needed to convert it to float and back again afterwards. That didn't actually add too much to the processing time so it was not a big problem really. But I did talk to Bob about SAW supporting floating point math in future versions, but he was adamant that he will never support floating point as it will never be fast enough. Bob had some custom-designed fixed-point math implementation that he insisted would always be faster than any floating-point math. Using fixed-point math is a multi-step process for every single operation you do, and I am 100% sure at some point doing floating-point math vs fixed point math became faster. Bob said he did some of his own benchmarks and found that floating point math was way too slow. But his results didn't compare well with my own findings, and I got to the conclusion that the benchmarks he was stating was obviously quite a few years old and dated. He was just very hardheaded about it and at the time refused to believe that processors could have evolved to the point that floating point was useable for DSP work.
Anyway, my point is that Bob is somewhat of an odd one out. He is very smart, yet quite old school in his thinking. Hearing that he hates multi-formats makes sense. My point is that you have to take these things into account when he talks about this type of stuff. Obviously ASIO is not ideal for SAW, but as Angus points out, other apps don't have big issues with it. I'm sure ASIO is not perfect, but not as bad as Bob makes it sound. I'm not sure a mass migration away from ASIO to a driver model that works better for SAW is necessarily the smartest thing to undertake.
BitFlipper