The appearent conflict here is in the definition of "real time". For the video capture application we only need to keep up with the average data rate and if the system stops reading data for a few tens of milliseconds and lets it buffer in the capture hardware then it is OK because nothing is lost. The only criteria for success is "nothing is lost".
The SDR application is a little more time critical because it needs to play the proceed audio. But again it can be buffered and we'd never notice a 50 millisecond lag in audio and for radio a 100 ms lag might go unnoticed But there is a category of what engineers ca "hard real time". Home computer users don't normally use their PCs for hard real time applications. This would be things like controlling a walking robot, guiding an anti aircraft missile or just about any time a computer is inside the feedback loop of a control system. These are all engineering and science applications that home users wouldn't see. A "harder" real time use that people DO see in home use is music. If you try to do multi-track recording in a home music studio with windows. This can be done but people have to do thinks like (1) remove everything non music related from the PC and disconnect it from the network. (2) replace the audio subsystem software with special real-time ASIO audio drivers. Then it can work So ""real-time" has a wide range of meanings, video capture is about the easiest to do and being embedded in a servo control loop the hardest On Tue, Mar 26, 2013 at 6:08 PM, David I. Emery <d...@dieconsulting.com> wrote: > On Tue, Mar 26, 2013 at 07:39:51PM +0100, Alberto di Bene wrote: >> On 3/26/2013 7:21 PM, Dan Kemppainen wrote: >> >> >Keep in mind, we are after all, taking about windows. An operating >> >system that IS NOT real time operating system. (You think it is, try >> >move a continuous stream of a few 6+ MBytes/Sec data to it!) >> >> Well, the Perseus SDR, when set to its maximum sampling rate after the DDC, >> sends >> the I and Q continuous streams (24 bit/sample each), to the PC at a rate of >> 2 MHz. This >> means 12 MBytes/sec via a high speed USB2 port. Using one the many >> available SDR >> programs, those 12 MBytes/sec are received, FIR and FFT are applied, >> demodulation >> algorithms are used, and there are no glitches in the final audio... if >> even a single sample >> would be lost, you would ear immediately the artifact.... >> >> Windows is not as bad as somebody would depict it... :-) > > I have been using Windows for digital video analysis and > capture for years... often capture multiple 70-80 mb/s transport streams > by the hour from USB and PCI sources and output similar for testing. > > It works. > > Does take buffering and tuning in the code, and some in the > hardware. > > > > -- > Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass > 02493 > "An empty zombie mind with a forlorn barely readable weatherbeaten > 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in > celebration of what could have been, but wasn't and is not to be now either." > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Chris Albertson Redondo Beach, California _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.