EzAudDac Alpha release: Cheap DACing!

[Things]

Can you use the easylaze drivers for Spaghetti aswell? I'll download the update and hve a play around.

[drlava]

It's all the same thing. For programs that support the audio DAC natively, you just use the EzAudDac.dll. For programs that dont, but support easylase, you rename the EzAudDac.dll to easylase.dll. It's that simple.

For example, carmangary includes this DLL in the drivers folder of spaghetti when you download and install it. So to update it, you replace the EzAudDac.dll that came with spaghetti with the new version.

[Things]

After having a chat to drlava on laserchat, I fixed up my blanking and decided to try out the new driver. The result = everything is ALOT smoother! I have tested it with Laser tennis, Laseroids and Spaghetti, and it is a huge improvement on all of the programs. If you dont already have the new driver, I highly recommend you download it !

Nice work Lava!

EDIT: Do you think there is any way you could "Merge" the blanking channels, in the driver itself? I tried setting R, G and B to all channel 4, but then it did nothing

[drlava]

Upadte to 1.01.. should improve LDS performance and maybe Spaghetti and HE-L

[OldGrumpy]

I can't remember if the scan speed has to be set up front with the mamba API. If so, I don't like that because not all software uses the same scan speed for every frame. That might be might only complaint.

Sorry to nullify your complaint You can set the scanspeed anytime you like. Just make sure not to try to change it while sending a frame to the device (setting it on one device while feeding a frame to another one is okay of course, just don't use multiple threads to talk to the same device simultaneously).

[OldGrumpy]

They use double buffering internally, yes but for example the easylase has to be polled to make sure its buffer isn't full, where what could be done is have the driver call a hook in the program whenever it is ready for a new frame, so polling wouldn't be necessary and the program fills the alternate buffers directly.

In a multithreaded environment, there should be dedicated worker threads for each device doing the feeding so there is no real need for additional feedback, just stuff it into the thread's queue (and check for dead devices via timeouts, of course). Less work, better timing, smaller code - elegant.

[keeperx]

once you change this once, you should not have to change it again.
if not i found this handy little tool for vista users (they[we] have the most problems)
http://www.download.com/Vista-Audio-...-10877705.html

[Things]

I was playing around with LFI player this night, but I noticed my laser output kept stopping. so I checked the ExAudDac log file, and it had this "writeframe timed out while waiting for loop thread freeing"

Any idea;s?

[drlava]

Yeah I noticed the same thing and am looking into it. Do you have a dual or single core CPU?

This message is logged when the frame data can't be written to the output buffer within 5ms. It returns an error to the calling program (LFI player) which for now treats it as a fatal error and stops output all together. I experienced this at home on what I'd consider an 'adequate' single core machine, but have never experienced it on my development machine which is dual core. The wait duration will probably be increased to longer than 5ms before an error is returned, so this should help prevent the error on machines that are heavily multitasking where there aren't many timeslices to go around. Also, The error in LFI player can be treated as non-fatal and a retry attempted.

[James Lehman]

Since there is something weird going on with the codecs in MS, that seem to make it impossible to play 6 channel wave on some Windows machines, would it be possible to add the ability to play waves through your driver?

James.