Is the IVI driver architecture suitable for integration of ASIO capable hardware?

[pbr]

ASIO requires a single threaded application for audio data processing.
The ASIO hardware driver notifies the application with a function call
whenever data is ready for processing and assumes that processing is
done immediately and completed before the next notifying call.
Studying the IVI documentation, it seems to me that in general,
instruments are slaved (requests coming from 'above').
Is there a possibility to integrate devices that take a 'master' role
and drive the dataprocessing part of an application from 'below' ?

[Glenn Burnside]

I'm not familiar with ASIO, but it sounds like what you're describing is a callback function that the application registers with the driver - is that correct? There's really nothing in the IVI Architecture that would prevent you from doing that in your driver. Device configuration generally goes from the app to the instrument, but the IVI class specifications typically provide two ways to get data from a device - a synchronous Read mechanism that acquires and returns the data, and a polling mechanism by which the application can determine when data is available, and then pull it back from the instrument. This isn't quite what you're describing, but I think it's close in spirit.

I'm curious to know, though, where you are planning on fitting this device in
to IVI - are you intending to write an instrument driver for it? If so, what is the I/O mechanism from the driver to the instrument - is it message based, register based, or based on some vendor-provided API? Would you be using VISA? What's the bus type (GPIB, Serial, TCP/IP, USB, etc?)

With some more specifics about the instrument, I'm sure we could come up with a way to expose this notification mechanism in a reasonable manner in the driver API.

[pbr]

ASIO is a defacto standard for low latency multichannel digital audio
I/O. You can get more information at www.steinberg.net (search for
ASIO). Dedicated hardware is based on different bus types (PCI,
Firewire, USB) and comes with a ASIO capable driver.
Using ASIO, Audiodata is tranfered with a synchronous call from the
driver to the app whenever data is ready for processing. This calls
for a singletreaded app as far as the dataprocessing goes. The polling
mechanism is not suitable if you think of a stream of 24 simultaneous
audio channels sampled at 96kHz/24 bit that need to be analyzed for
e.g. dropouts.

What i'm planning is to write an IVI driver to be able to integrated
any ASIO capable device into the NI toolchain. The I/O mechanism must
be based on the
ASIO 2.0 API (synchronous call from the ASIO driver to
the overlying SW whenever databuffers are ready for processing, all
dataprocessing in a single thread)

[Glenn Burnside]

From what I've been able to learn so far about ASIO and how it's used (I'm still waiting for steinberg to send me the download info for the SDK), I'm not sure that an IVI driver is really necessary - but maybe I need to know more about what you mean by "the NI toolchain". Are you looking for something that integrates ASIO with NI hardware, software, or both? Are you trying to use ASIO devices from LabVIEW, or another NI development environment? Or are you trying to use LabVIEW or some other NI product from existing ASIO-based applications like cubase?
It looks like the ASIO API itself is already acting like a hardware abstraction and interchangeability layer, which is the primary purpose of the IVI architecture. But since there is already
a well-defined API for ASIO devices, we might be able to come up with simpler ways to integrate it into NI software rather than trying to create an IVI driver around it - which would be a rather complicated process.

[pbr]

Your statement about the ASIO API is correct. What I mean by "the NI
toolchain" is to use Teststand together with LabWindows or LabVIEW to
set up an automated regressiontesting framework for ASIO devices and
dedicated hardware drivers. I did not decide on a specific product yet
and used TestStand, LabWindows and MeasurementStudio for trial runs.
As far as I can see now, NI hardware would not be involved. Using
Labwiew from Cubase is not an issue.

[Glenn Burnside]

Given your intended use, I don't think an IVI driver is going to really add any value to the integration with NI software - it should be trivial to use the ASIO SDK from either Labwindows/CVI or Measurement Studio. Alternatively, you could create a dll out of the sdk's .h and .c files, and use that .dll directly from either LabVIEW or TestStand, both of which support direct calls into dynamic libraries. If you were to generate a dll, it would also be straightforward to create a set of wrapper VI's in LabVIEW around the dll calls, which would make use in LabVIEW more straightforward.
If you were to create an IVI driver, you would still need to make calls to the driver's dll from either LabVIEW or TestStand, since this woul
d be a non-class-compliant driver. The class driver support built into those two environments would not make using this particular IVI driver any easier than any other library.

[pbr]

I already went the straightforward way calling the dll directly from
LabWindows/CVI or MeasurementStudio. I was lacking a certain comfort
regarding integration though. That's why I came up with the idea of
building an IVI driver.
Today, I tried to build corresponding wrapper VI's but I had no
success until now. Since I still am a newbie to the NI world, any hint
to useful documentation regarding wrapper VI's around dll calls would
be much appreciated 😉

[gagi1]

Here is some documentation:

An Overview of Accessing DLLs or Shared Libraries from LabVIEW

Using External Code in LabVIEW

NI Developer Zone

I hope this helps.

Best Regards,

Vesna Jadric