SDK for DACs

[carmangary]

I'm just using Windows Media Player right now because it is freely available and only takes a few lines of code to get it going. I may switch to something that I can embed in the future but there is no reason to right now. WMP has all the features I need and is easy.

Your app sounds pretty cool. A bit of a different direction than mine since the basis of mine is to use ILDA files that have already been created. Basically, for the non-artistic types (like me) who just want to take other ILDA files and make a show out of them. Buy maybe in the future I would do something different to allow more flexibility. But your features sound nice.

I don't support the new RGB ILDA files. I just learned it even existed from this forum a week or so ago. I'll eventually add support but so far I haven't even found a file that uses it so there is no hurry.

[Zoof]

I didn't know WMP had an API or could be used like that. Probably the easiest way to play music with your own code - clever solution.
Sounds like our projects are complementary and compatible ( once you can read ILDA RGB format ). My app will also save to the standard palette but it doesn't work out well with a lot of the colors. And since I started this whole RGB project to get as many colors as possible I'll be using the rgb format. All I need to do now is implement a color shifting routine to shift the colors so that Mamba will get the colors right

[The_Doctor]

Two different DAC's with no way to signal to a source that they want more data? That's like RS-232 without flow control. Hard to imagine that something so obvious has been missed. Possible further agrument in favour of sound cards?

[Zoof]

It would be interesting to know which DACS do have a data request... and come with an API.
DACs that do have that must have the hardware polling function included in the driver - so would it be an improvement other than programming convenience?

[carmangary]

I asked Showtacle (makers of the Moncha DAC) why they don't send a signal when it is OK to send new data and the answer I got was that they actually tried it and it just made performance worse. I took this as meaning that there is too much latency in sending the signal back from the DAC to the host. I'm not really sure why that is.

A dac driver wouldn't necessarily have to poll the DAC if everything was designed correctly. Most (if not all) USB DACs have microprocessors on board so that know exactly when it is OK to receive a new frame and they should be able to send an event back to the host computer as a notification.

One of these days someone will get it right.

[The_Doctor]

Could be that timing is critical, and stopping anything to send a signal back might cause jitter in a very simple system. If so, then they ought to at least have a larger buffer unless you use directly synchronised hardware connections.

There are only two ways to manage feeding a buffer from an asynchronous output: anticipate and predict, or get a signal back to say when it's getting low. If they don't want to send signals back, they need to give the controlling system (and programmer) a bit of leeway, a single frame buffer really isn't enough, it leaves you a window of a fraction of a second, and you have to manage that with what amounts to an open loop control! They might tell you they ran into problems making it send a signal back, but I'm not surprised, they are running it too tightly to allow anything other than direct hardware sync to be reliable.

As to whether the feedback offers other than convenience, I think it does. Reliability for one thing, it's the only way to match hardware sync. In RS-232 hardware flow control also offers better speed, but I doubt that's so important in modern serial data lines, most hardware can do higher speeds by far than when RS-232 was invented, and is often overspecifed just to get nice clean pulses, so putting the feedback signal in as return data won't slow anything down unless the system is already built in too restricting a form.


I think that even if you don't use sound cards, the makers of DAC's for laser shows should look closely at sound cards, because most of these problems have been solved before, and it's very similar tech.

[carmangary]

I'd be interested in understanding how USB soundcards handle this.

The Moncha DAC is double buffered. So you can send to the one buffer while the other hold the frame currently being drawn. One problem I found is that if the frame size is really small, it takes longer to send it to the DAC via USB than it does to actually display it.

[The_Doctor]

Padding bytes? I guess USB has to have a defined packet size or something, bigger than your smaller frames. I don't know USB though, it gives me the heebies even though it works, and I prefer NOT to know.

One thing is true though, it can't use hardware control, at least I'm fairly sure it can't bcause it's made to be versatile, so to do that through 4 wires, two of which are a supply and a ground, everything MUST be done through data. So the feedback must either be volunteered from the hardware at the far end, or requested by the host. I agree with you that if the makers get it right, the hardware should volunteer that info, otherwise the computer must clamour like kids in the back of a car saying 'are we there yet?'. If Moncha really IS run so tightly that they have trouble with signals, they have to volunteer that info, it's the only way to minimise traffic and get reliability.

Still seems really weird to me that laser systems that involve advance technical agonising over precise closed loop servo feedback can be expected to be controlled by a tiny one-frame buffer with no feedback at all to the data source! I really think that if I haven't grossly misunderstood this, then someone who really should know better has done. Don't blame yourself if you can't make it work. And if you can, tell us how. If you can do it despite the timing variability likely in USB, that has to be interesting.

One thought: the USB itself might be taking care of extra buffering. It might make that transparent to you, so all you see is the double buffering of the DAC. As the USB far end and the DAC itself ARE in direct hardware sync, that could be how they do this. Especially as the one manifestation that won't be transparent to you is latency, which you said you saw... (I imagine that description would also apply to USB sound cards, as they don't use an interrupt like PCI ones do, other than for the USB bus generally).

[carmangary]

The DAC has two buffers. I am not sure if you missed that I said that. One can be written to while the others data is displayed. So, you basically have the time interval that it takes for the first frame to be drawn to send the next frame, and so on. The Moncha doesn't make the user worry about which buffer is which, though. As long as the data is fed fast enough it will work out. But, if it is fed too fast (sending a third frame before the first can be drawn), data will be lost. I am currently handling it using performance counters since they have the required resolution. But, it requires some guesswork since I don't know what kind of latency there is within the DAC from the time I send a frame and the time it actually starts drawing it. So, I have it working but I need to go back and tweak it for the really short frames.

[Zoof]

When frames are fed into easylase at a too slow rate, meaning that writing to buffer 2 has not been completed when the DAC wants to start reading it, easylase will simply display the frame from buffer 1 again. Repeating it until writing to buffer 2 has been completed. Is that the same for the Moncha DAC?

With easylase writing too fast, meaning writing to the DAC while both buffers are full, will result in datajam and loss of data but that can easily be avoided by checking the status before writing a frame.

Can you check for data loss with Moncha or any other status info to synchronise with it? If not I can see the timing challenge you are facing is a big one.