Ideal sound card for multichannel scan and modulations.

[The_Doctor]

I don't know a damn thing about what you-all are talking about, but I have 2 home recording studios (1 PC based) and the cure to latency in sound-cards is ASIO.

Fwiw.

Agreed. ASIO's good. Latency less than an ear can perceive let alone an eye. Actually even DirectSound is ok, and nearly everything in Windows can use that if programmed to. The main reason ASIO had to be invented as a general purpose way to cut past the OS to reach the I/O was that DirectSound is output only. No good for recording audio, but just what is needed for laser control.

Even WaveOut standard has low latency if special drivers are written. Not relevant to the idea of general purpose sound card outs for lasers, but Reality (Seer Systems, a synthesizer), and Cakewalk's WavePipe (Program-specific output driver for CakeWalk and Sonar programs) prove that no matter what part of a Windows system is used to route audio to a port, it is possible to get low latency and uninterrupted data flow, with many channels at once. Even from a modest system. Those apps were written originally for basic pentium systems.

[carmangary]

DirectSound uses WaveOut so it is no better. In fact, I don't think DirectSound supports more than 2 channels so it is worthless. I got screwed because I started out writing my laser soundcard driver using DirectSound and ran into that road block. (It may have been the .NET implementation of DirectSound with the limitation - I can't remember).

Anway, while switching to use WaveOut I found that DirectSound actually wraps the WaveOut function so to use WaveOut directly yielded a performance increase.

As far as latency goes, I got it down to 0.1 seconds in my application. In other words, I was creating real time XY coordinates and it would take 0.1 seconds to get to the output of the soundcard. The only reason was because each block I created contained 0.1 seconds worth of data. I probably could have decreased the time but at that point I gave up on it due to lack of interest... I decided to spend time writing the actual show software for the easy to program Popelscan dac instead. I'll eventually get back to the soundcard driver and my plan is to change from blocks of a set time to blocks containing frames. Not sure if that will work, though.

But to be honest, I may just abandon the soundcard idea all together due to lack of TTL outputs for driving other items.

[carmangary]

Oh yea, I forgot to ask... what is ASIO?

[steve-o]

http://en.wikipedia.org/wiki/Audio_stream_input_output

[carmangary]

ASIO sounds interesting. Maybe it will help with my TTL problem... I'll have to investiage.

[The_Doctor]

DirectSound uses WaveOut so it is no better. In fact, I don't think DirectSound supports more than 2 channels so it is worthless. I got screwed because I started out writing my laser soundcard driver using DirectSound and ran into that road block. (It may have been the .NET implementation of DirectSound with the limitation - I can't remember).

Anway, while switching to use WaveOut I found that DirectSound actually wraps the WaveOut function so to use WaveOut directly yielded a performance increase.

Sounds nasty. I think DirectSound is stereo pairs, but the number of pairs is only restricted by hardware or the drivers for it. Not worth using if it's just a wrapper for WaveOut though. But that's weird anyway, DirectSound is supposed to be useful to get lower latency that WaveOut, and several audio programs suggest its use for that reason. That is worth exploring further. It sounds like maybe it's like what Reality and Cakewalk do but ineptly, incompletely.

As far as latency goes, I got it down to 0.1 seconds in my application. In other words, I was creating real time XY coordinates and it would take 0.1 seconds to get to the output of the soundcard. The only reason was because each block I created contained 0.1 seconds worth of data. I probably could have decreased the time but at that point I gave up on it due to lack of interest... I decided to spend time writing the actual show software for the easy to program Popelscan dac instead. I'll eventually get back to the soundcard driver and my plan is to change from blocks of a set time to blocks containing frames. Not sure if that will work, though.

But to be honest, I may just abandon the soundcard idea all together due to lack of TTL outputs for driving other items.

Don't give up. All that TTL is is a 5V nominal output with a low or high within set limits, and a current sink or source capability adequate to drive further TTL standard inputs up to a specified number at one time, I forget how many. It's an old standard, most modern IC's exceed it easily. Even if the output of an audio DAC won't meet spec precisely, you wouldn't need it to, it would be a waste. With 65536 possible values (or more in a 24 bit audio output), you have enough accuracy to generate several TTL standard outs. If you allow 256 steps per TTL output (multiplied by 1,2,4,8,16,32,64,128 for each switched bit), it takes only an 8-bit ADC to resolve 8 switched data lines per channel. It might even be accurate enough to make 8 bit proportional control if you allow a small margin to accomodate errors. You could get maybe 192 or better steps on each of 8 lines per audio channel, which is a damn sight better, and faster, than MIDI. I think an 8-bit ADC board will be a cheap way to add TTL outputs to any spare audio out channel. 16 of them per stereo pair.

Edit:
Setting the value for the 8-bit ADC for the TTL switched signals is easy too, no matter what your sound card bit depth is. All it needs to do is have a known voltage for maximum input (all 8 output bits set on). A small software change in the overall signal level will make a standard 24 bit card put out the right voltage when the wave is fully positive, either by adjusting the scale directly or by a later software attenuator control. Pro gear has enough local control to scale to that value. A small preset pot on the ADC analog input will also solve all problems with level matching.

[The_Doctor]

Gary, you can use any of these:

TLC0820A Texas Instruments
ADC0820C National Semiconductor
AD7820K Analog Devices

While it doesn't sound sensible to convert to analog only to go back to digital, in this context it is. Those are VERY cheap ways to take advantage of a very flexible situation. Just encode your 8 bits onto a wave signal of arbitrary bit depth in software (use the 8 msb's), then put one of those IC's on the output port for that channel, and you get 8 fast digital switch outputs. If you find triggering errors at threshold, just add/subtract a fixed lsb value to offset the total so it triggers cleanly. That way you'll have a very neat code fix that saves end users from having to tweak their signal voltage offset to get clean switching signals.

I put in a post on sci.electronics.components asking for suggestions for the ideal IC for this, but the more I look, the more it seems I already found it, cheap, multisourced, faster than most laser's TTL inputs can take, so it should be ideal. If the DC bypassed wave out of a sound card has a +2.25V offset as most do, you can ground the Vref input on the ADC (or add a simple preset pot to make Vref if it hasn't). Any clocking needed is internal, nothing need be done there.

[carmangary]

Thanks Doc. That will save me a lot of time investigating which chip to use. Actually, you are right that using the ADC wouldn't be bad. Since an output offset/amp would need to be built to get the correct signal levels it wouldn't be hard to slap an ADC chip on there as well.

My next hurdle is that the cheap sound cards I find have 5.1 analog out but are capable of 7.1 out but only using the SPDIF port. 5.1 is enough for XYRGB+TTL channels but I want Audio(L)Audio(R) also so I really want to get the 7.1 working. But, if i can't figure it out or if it turns out to be a hassle I might be able to sync up two sound cards (1 music and 1 modified for laser) instead. Maybe the ASIO might help here.

[The_Doctor]

Audio is more critically sensitive to the noise inside the PC, so why not send that out on S/PDIF? It's also the one signal not likely to go with the others, so different cabling would likely be used no matter what else was done.

I don't think ASIO will change what happens at program coding level, so far as I know. Probably just improves the streaming to and from I/O. Latency, buffering options are all set in the ASIO driver for this. Some cards might use WaveOut better than others use ASIO, at least regarding fluency of dataflow, absence of glitches. We won't really know which are best unless there is general support for whatever the OS can find to connect through. That's the best chance of building up useful info from many people.

There does seem to be a difference in port pair addressing. On the Layla24 I can address any pair the usual way, by selecting it in the 'Sound Mapper' or the equivalent selector where a program offers a local router, as most pro audio apps do. The other is what seems to happen with multichannel wave file formats, and with dedicated 5:1 or 7:1 units, where you don't see separate stereo pairs in the routing selector, just one entry for that device. Software for sound cards would need to allow the end user to choose individual pairs for situations where they have that option in hardware.

[carmangary]

I'm definitely for using S/PDIF but I don't know how to decode it. There's probably a chip that will do it but I would have to find one.

I don't know what ASIO would offer to be honest. I don't think it latency is even an issue unless using multiple hardware. The thing I like about a 7.1 card is that the entire data stream can be encoded into one block (sound + coordinates + color + TTL effects) of a multichannel WAV file. There is absolutely no chance that they can be out of sync at the output. Using multiple hardware opens a can of worms and you are at the mercy of the OS as far as synchronization goes. I don't really want to go there but if I have to I'm wondering if ASIO will help.