[Scott Dorsey]

Mike Rivers wrote:

I'm not sure what API you're talking about. Since you mentioned MME and
ASIO, I suspect that this is a fancy name for the sound card driver.

Right, the problem is that Windows only sees what comes OUT of the driver,
and what you want to see is the raw data that goes INTO the driver.

This means you need a fancy nonstandard driver, or you need to bit-bang
the hardware directly. Because what comes OUT of the driver is only the
decoded data and minimal information about sample rate.

It may be that it's necessary to talk directly to the sound card in
order to get all the data since the standard way to write a sound card
ignores a lot of that stuff (and everybody tries to do what everybody
else does). This may be why the RME utility that displays the channel
data bits and only works with their cards. I don't know what all it
shows. They never seem to have anything set up at trade shows to
demonstrate it to me (sorry Mr. RME guy who hangs out here - I didn't
intend to insult your show folks, they just didn't have or know that
they had what I wanted to see) and I don't own any RME I/O hardware so
I can't see for myself.

Right. This is the problem. You can write something like this pretty
easily, but it'll only work with the hardware you designed it for, because
there is no actual standard for the soundcard hardware.

If the driver is where the channel data stops, then the answer is to
write a driver that will pass it on to anyone interested. There really
shouldn't be any harm in that should there? If all sound card drivers
passed all the data, then a generic program should be able to use it.

They don't, because Windows doesn't care about the data, and the sound
card drivers are all built to provide what the Windows API requires and
nothing else.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."