Ideal sound card for multichannel scan and modulations.

[carmangary]

Actually, a sound card does more processing than you think and requires quite a bit less CPU power than it does to run something like Popelscan. With a soundcard, you simply feed it a block of data and it handles the timing required to play it back. This is analogous to feeding a DAC an entire frame and then have it worry about proper timing, etc. With Popelscan, the CPU is responsible for timing and that is a big deal because at 30000 pps the timeslice is very small... much less than the resolution of a Windows timer. So, you have to loop and check constantly. That's very CPU intensive. But with the soundcard, you just fill a block and pass it on and then worry about the next one.

I don't know what all the Pangolin cards do but if it handles things like blanking delays and all then that is pretty cool and is definitely advanced. However, it wouldn't be too bad to do that in real time in software.

The only thing I don't like about soundcards is that you have to feed them a block and that results in latency. You also have to make sure that you feed it fast enough. I haven't worked much on my soundcard driver but I think I should change it so that a frame is a block and keep 3 or 4 on cue. That results in less than 1/2 delay for the most part.

Delay itself isn't too bad unless you are performing live. It can run into some problems I guess.

But, what is cool about WAV is that you can create a multichannel wav file with stereo music on channels 1&2 and the laser show on channels 3 through 8 or whatever. XYRGB + other. "Other" could be fed to a ADC to give you several TTL outputs. Or, you could simply dedicate the entire WAV to the lasershow.

You can then take your lasershow hardware and wav file and play it back on any computer using windows media player!!!!

[buffo]

Carmangary;

True, modern sound cards do have quite a bit of processing power, but they pale in comparison to the hardware that the Pangolin board packs...

It's actually a fully-functional computer, complete with a CPU, it's own custom operating system, it's own memory, it's own drive controller, etc... The show runs *entirely* on the board. You don't just feed it blocks of data, you feed it the entire show and it does the rest. This is why a computer running a Pangolin show can actually crash while playing, and the show will not be affected. Once you start the show the board runs EVERYTHING. (Remember, it's a fully-functional computer on a card!)

In fact, once you load the show onto the board and start it playing, you can actually remove the board from the host computer so long as you figure out how to keep it supplied with power. (How's that for amazing?) For those of you that saw the Pink Floyd Laser Spectacular show - the show was running off two CD-2000 units. No computer needed! Just a CD-rom drive and a Pangolin Intro card in a small box with a power supply. The board has enough firmware to load it's operating system from the CD and then load the show files from the same disc. Give it a time-code start signal, and away you go!

Now, I'm sure you could eventually emulate all the features of a Pangolin board in software, given enough time and effort, but who has the sort of experienced manpower to throw at such a project?

Adam

[The_Doctor]

Ok, break it down to basic elements...
Scan stream for X and Y, and Z for blanking/proportional intensity modulation.
Timing master to sync them.
Level setting for matching to standard scan systems (driver board inputs).
ILDA standard differential outputs.
Precise setting of absolute point rate, controllable either by incoming data or device specific setting.

The Layla24 can do all this.

Now consider delays. These need finer resolution than the point rate, but even the older Layla can do this, given up to 96 KHz (Kpps). That's three chances to adjust delay offset at 30Kpps rates, and two at nearly 50Kpps. Double this resolution the moment you use a newer 192 KHz unit. All of this can be handled by basic sound sample data streams and sound card drivers. Ears can detect FAR smaller latencies than eyes can. We can easily resolve anything over 5 ms by ear, that's 200 Hz. Our eyes are duped with frame rates as low as 25 Hz, as the history of cinema and TV demonstrates. Audio systems are more than good enough, even at 16 bit depth for most work, and Layla 24 does 24 bits, that's 256 times the dynamic range, and newer units can handle 32 bit floating point. Some laser scanner coders are happy with 8 bits and suggest that 12 is more than needed. Given the low cost of 16 bit sound systems, it makes sense to use them (maps neatly to 16 bit colour control for RGB too), especially as the fast rates needed are also easy to buy, eight channels at a time, at prices that the laser biz would consider as spare change.

To emulate Pangolin, all that is needed is to use a multi-channel sound card with DC-blocking methods bypassed, and enough output voltage swing (+/- 10V ought to cut it, I think, Layla 24 does this, as does all pro gear with +4 dB outputs). You also need a good fast software driver that takes care to maintain a steady stream, but most pro gear does this to standards that would embarrass many industry DAC's that cost thousands. The details of computing trace routing for efficient scanning and blanking, and dwell points and such, can all be described with fairly simple coding like Lua or Basic can do, the tricky bit is getting that output quickly and reliably to a hardware output. Pangolin solved that by doing it ALL in hardware where possible, but any good look at the electronics industry shows that this is an increasingly difficult and expensive policy to maintain.

Ideally, I'd like to see wxLua (Lua with wxWidgets) have fast realtime multichannel sound output, so I don't have to become an uberGeek to code my own. The only things that can't hitch an easy ride on the pro sound industry are the scan-specific computations, and the user interface, both of which are problems ideally solved in software. A 1U rack containing an ITX mainboard with flash memory on IDE interface instead of hard drive, with a 1U sound unit, both contained in something the size and weight of a small briefcase, that would seem like an ideal system to me.

[carmangary]

The Pangolin card is analogous to a frame grabber card that I worked extensively with. The card would allow you to connect a camera to it and it could snap a picture and then do OCR functions or find patterns or other intensive functions all on the card. You could stick it into an old 486 and get the same performance as you would get if you put it into the latest Pentium based computer. The card cost well over $1000. But, you can take a webcam and with some freeware software on the web, you can do the same thing for $40. It isn't as fast on the old 486 but on a new computer you get about the same results as when it is run on the card.

Anyway, I am just saying that all of that onboard processing is nice but it just makes things harder. It also gives Pangolin a nice edge in that in order to use their hardware you need to use their software and vice versa. Not a bad business model for Pangolin! But not good at all for the entry point consumer. Some clever individuals can create a low cost hardware software package that can do everything that is needed and more. At the end of the day, all that matters is that what is shown on the wall is what you want. Who cares if it is done on a high end card or a cheap shoe string homebrew system?

[carmangary]

Hey Doctor, for a software solution, in order to boost performance I think it would make more sense to compute dwell points, blanking speeds, etc, at the time the ilda (or whatever) file is read in. This doesn't work when creating real time visuals but it certainly does for the other cases. The driver could easily have an API function that creates a frame based on hardware settings when given an input frame. This function could simply be called for each frame as it is loaded before the show starts or in the case of dynamic visuals, it could be called before sending the frame to the hardware.

Man, the more this is talked about the more it makes me want to continue the work I have already done on this. I definitely think that those of us with our heads into this should get together and build something.

[buffo]

You guys are missing the point. I'm not arguing that using a sound card (Layla 24 or otherwise) is a bad idea for a laser show controller. It is, in fact, a very good idea. (Laserboy is a product based on this very idea.)

No, my point was that it is USELESS to try and write a sound card driver for the Pangolin software as the Doctor originally suggested:

What is really needed is some nice legal hack, under the interoperability clause of the DMCA, to make Pangolin talk to a sound card driver.

I agree that a sound card is more than adequate for outputting laser frames, and for just about any other laser show software out there it would be a very interesting project. (In fact, in my post I suggested Mamba Black, since it already supports 3rd party drivers and is otherwise a pretty decent laser show software package.)

But for the *Pangolin* software, it's a pointless concept - because of the way the software and hardware work together. (Or, more accurately, the way the software programs everything on the hardware and then basically sits back and does nothing while the card does everything.)

Seriously - why bother trying to write a sound card driver for Pangolin when you're also going to have to re-write the software to emulate all the hardware processing done on the board? (Indeed, re-write the way the software works, period...) Woudn't it be easier to start with software that already supports 3rd party DACs?

From a historical perspective, I'll bet that Pangolin originally went with all-hardware processing because of the limits of software processing in the early days. (Even the Amiga had it's limits. ) However, now that computer speeds have increased to the point where software processing is quite feasible, one might think that they'd abandon the custom hardware. But dedicated hardware is often times more stable than a software solution, and it offers a good bit of market protection as well. (No point in pirating the software if you need the hardware to use it, right? ) So I can see why Pangolin continues to use dedicated hardware. Given the market that their in (high-end equipment for commercial service), I'd say they made the right choice.

Adam

[DZ]

Ok, I can't help but comment on this argument. There is no doubt that a sound card idea would work. It would probably work great and be relatively inexpensive. There would be several pro's to this idea, as well as many con's. I for one, prefer to have the qm2000 operating system handle running the show over a wintel platform. I have yet to this day had a qm2000 lockup or error out in any way. It is a very solid platform.

It also gives Pangolin a nice edge in that in order to use their hardware you need to use their software and vice versa.

This is actually quite far from the truth. You can write your own software to interface and work with the qm2000. If you are really good with writing code, you can buy an intro and write your own software to access the tools found in the professional level. I knew a guy who had a qm32 intro card and wrote his own abstract program to take advatage of the full abstract capabilites of a pro card.

Oh and here are some more examples of why its best to run off-board processing:



David-Diehard Pango fan

[dave]

(Laserboy is a product based on this very idea.)

I was just thinking about laserboy actually.

http://www.akrobiz.com/laserboy/

In fact, i think James is a member here, maybe he has some pointers you guys would be interested in?

[The_Doctor]

Hey Doctor, for a software solution, in order to boost performance I think it would make more sense to compute dwell points, blanking speeds, etc, at the time the ilda (or whatever) file is read in. This doesn't work when creating real time visuals but it certainly does for the other cases.

It could work for realtime too, but the computation might be tricky. So long as it's fast enough to insert into the stream it will work, remember, it only needs to fit within the latency out eyes detect for the interruption to go un-noticed, and any inserted samples would be equal in number on all channels, so no sync upsets occur. My guess is that a simple calculation can look at the X and Y step size/direction changes to detect them, work out what the angular change will be in 2D, and insert dwell points accordingly. I found that for WideMoves and regular polygon geometry, it's best to have an equal value of samples for dwell regardless of drawn angle, and to only change for given speeds and scan angles, but I have no idea what would be needed for other scanners.

The driver could easily have an API function that creates a frame based on hardware settings when given an input frame. This function could simply be called for each frame as it is loaded before the show starts or in the case of dynamic visuals, it could be called before sending the frame to the hardware.

This would work, but I think one of the nice things with sound cards is it allows thinking in terms of synthesizers and waveforms, breaking down the notion of frames the way free jazz ignores bar lines. (Frames would then just be a repeated pattern of appropriate length). If my WideMove efforts are anything to go by, and similar rules apply to other scanners, the dwell can be added for every detected draw, according to scan speed and angle. I bet it only works that easily on WideMoves because their step response is similar over large differences in step size, but as you say, a simple look-up table for values for known galvos can be added. Given what can be done in audio processing without apparent interruption to a realtime stream, I'd say that a per-traced-line calculation is going to consume so little time and CPU power that it will barely be noticeable, as it's a small repeat operation, and all data and code would probably sit in the L1 CPU cache during runtime.

Man, the more this is talked about the more it makes me want to continue the work I have already done on this. I definitely think that those of us with our heads into this should get together and build something.

You're way out of my league. I read a few of your posts on computing here, I'd be fumbling where you could fly. The best I can do is show you my Lua code for generating wave files. It's very simple, just defines and draws rotating regular polygons, but I also added code to accept an array (read, 'frame') and rotate that too. I'd have continued further, but disappointment with WideMove inaccuracies kind of killed the joy. I ended up spending days on Usenet proving that I really had a problem.....

You guys are missing the point. I'm not arguing that using a sound card (Layla 24 or otherwise) is a bad idea for a laser show controller. It is, in fact, a very good idea. (Laserboy is a product based on this very idea.)

No, my point was that it is USELESS to try and write a sound card driver for the Pangolin software as the Doctor originally suggested

I agreed with you entirely, I just hadn't first realised the amount of hardware basis for Pangolin. Having realised that the software sends only the required orders for the hardware, and will apparently do so on W3.1 (might be wrong here though), I decided that it might be that someone who didn't like the interface might have no choice but to consider the complete system in a new way, so I went off on the new tack. Essentially, instead of looking at what Pangolin achieves between software and hardware, I looked at what it must do between hardware and scan driver board and mod/blank inputs. Given that software for audio computes its logarithmic levels in software, I realised that a pro level sound unit has multiple highly linear 24 bit ports capable of up to +/- 12V swing on true differential outputs, all controllable by software! This isn't just good, it's an idealists dream.

I agree that it's better to write new software rather than try to emulate Pangolin directly. I'd just had a bit of wishful thinking that Pangolin in some form might have a software version of its entire process, and be limiting it to specific hardware for legal and commercial purposes alone. I think you're right about their choice of technical reasons though, given how long ago they started.

It was never their only option though. The Seer Systems 'Reality' synthesizer and CakeWalk Pro Audio are two programs that faced simliar (worse) critical timing and streaming problems, and they couldn't justify lots of expensive dedicated hardware. They HAD to solve this on a basic Pentium machine with far lesser hardware than we have now, and they DID solve it. The accuracy required for the clean sawtooth waves from Reality is FAR more demanding than any timing a laser show will ever face unless it's doing high definition raster scanning. For now, all we need is sound cards whose drivers are well written to support wave drive with low latency, without need for specialised drivers to bypass that system. I've found that the coders who really solved the timing and streaming problems were those who did not try to bypass Wave and force us to use DirectSound or Asio, because although those other drivers are apparently faster, the difference is small, and the CakeWalk and Reality systems, working WITH the sound card Wave drivers in ways I'm not qualified to understand, managed to avoid conflicts, dropouts, and high CPU usage spikes. I'll leave that subject now cos I really am way out of my depth.

I bet I can make an ITX machine that small and that cool. Given a few £££ I haven't got... I recently built and sold one, to get money for laser bits.
That thing about coding for the hardware is cool though, I really like that. It could allow the kind of simple coding I can do in wxLua to send useful signals to it, if I could make it do so in real time. By analogy it would be like Lua script controlling a game engine. Similar things can be done on an ITX machine though, if you run Linux, given the way it addresses any device as if it were a file. Windows isn't so much fun, and is utterly out of my league, but cross-platform systems based on wxWidgets seem to be the way to go here.

[Astroguy]

This is actually quite far from the truth. You can write your own software to interface and work with the qm2000. If you are really good with writing code, you can buy an intro and write your own software to access the tools found in the professional level. I knew a guy who had a qm32 intro card and wrote his own abstract program to take advatage of the full abstract capabilites of a pro card.

In fact I use Mamba Black with the QM2000 card. You can download the file needed from there website. I am not sure if it is taking advantage of the onboard CPU or not.