where is a copy of atlstr.h ??
in [Visual C]
|
From: John Carson on 30 Dec 2005 15:01 "Robert Macy" <macy(a)california.com> wrote in message news:1135960196.578243.286870(a)g44g2000cwa.googlegroups.com > Putting my question in as general terms as possible. > > The Hardware is a "standard" PC containing a commercially available > soundcard. In which the OS must be Win XP. > The soundcard has ASIO drivers built in and using C++ and the > Steinberg SDK for ASIO it is possible to exercise the soundcard > directly. > > It seemed reasonable that C++ can be used, along with "standard" > Windows interfaces to make this hardware system into a viable > instrumentation prototype for demonstrating various activities. > > I envisioned that 3 threads are necessary: > 1) ASIO interface and data manipulation > 2) Display > 3) Control > > Question: Are the tools that I have, and the libraries available to me > in those tools, sufficient to accomplish my end goals? > > Where should I be looking for great samples of similar programs? > > - Robert - As I thought might be the case, I don't have the knowledge to answer your question (which would have been better posed as a new thread). I have no experience at all in programming sound cards. I also don't know what you mean by an "instrumentation prototype for demonstrating various activities". You can write almost any Windows software with the tools you have, but my lack of knowledge concerning your specific goals makes me reluctant to give a definitive answer. (Personally, I would be downloading VC++ Express 2005; I have no experience of it, but it does have an IDE and I would find the lack of one intolerable.) As for sample programs, I don't know how "similar" you require them to be. My first port of call is always Google. www.codeproject.com is also a source of huge amounts of Windows code. -- John Carson
From: Robert Macy on 30 Dec 2005 19:03 John, The soundcard is almost secondary here, except for the fact that the presence of the soundcard makes everything real-time. Every 50 mS two buffers, each containing 9600 samples of 24 bit digitized signals, are appearing that need to be "attended to". *AND two similar outgoing buffers need to be filled. It's a bit of a time crunch on the 500MHz machine. However, the custom code I described earlier actually does all and is finished in less than 17 mS each 50 mS cycle, so I have time left over. But I was amazed that many of the "packaged" displays ate up the remaining 33mS very quickly. The main activity remaining for the hardware is to provide a means for the Operator to change operating parameters using some kind of pictures, or table of values. And to display the selected resulting data in a meaningful manner. Every 50mS put up a constantly changing display. With the ability to modify/change the display for example, freeze, zoom in/out, scale change, select WHAT is displayed, click and drag zooming, etc.etc. The soundcard's presence is really secondary to what I now need to do. The source of the data could have been a huge file stored on disk. Hopefully, my problem has been reduced to one of INPUT/OUTPUT using the PC. So I'm stuck trying to add controls and displays. Any experience with "slick and fast" GUIs? Thank you for the codeproject URL, will go there and look around. - Robert -
From: John Carson on 30 Dec 2005 22:02 "Robert Macy" <macy(a)california.com> wrote in message news:1135981639.472329.31860(a)g14g2000cwa.googlegroups.com > John, > > The soundcard is almost secondary here, except for the fact that the > presence of the soundcard makes everything real-time. Every 50 mS two > buffers, each containing 9600 samples of 24 bit digitized signals, are > appearing that need to be "attended to". *AND two similar outgoing > buffers need to be filled. > > It's a bit of a time crunch on the 500MHz machine. However, the > custom code I described earlier actually does all and is finished in > less than 17 mS each 50 mS cycle, so I have time left over. But I > was amazed that many of the "packaged" displays ate up the remaining > 33mS very quickly. > > The main activity remaining for the hardware is to provide a means for > the Operator to change operating parameters using some kind of > pictures, or table of values. And to display the selected resulting > data in a meaningful manner. Every 50mS put up a constantly changing > display. With the ability to modify/change the display for example, > freeze, zoom in/out, scale change, select WHAT is displayed, click and > drag zooming, etc.etc. > > The soundcard's presence is really secondary to what I now need to do. > The source of the data could have been a huge file stored on disk. > Hopefully, my problem has been reduced to one of INPUT/OUTPUT using > the PC. So I'm stuck trying to add controls and displays. > > Any experience with "slick and fast" GUIs? I have done quite a bit of GUI programming. If you want a slick and fast GUI, then Win32 programming is a very good fit. Nothing in Windows is strictly real time because its multi-threaded nature means all sorts of stuff is going on in the background, eating up processor time in unpredictable ways. But you will get closest to it with Win32 programming. -- John Carson
From: Alexander Grigoriev on 31 Dec 2005 11:26 Filling and submitting a buffer every 50 ms is nothing even for 100 MHz machine. For smooth sound handling, run your sound code in a separate thread with higher priority. Use event notification for wave out, not window message. "Robert Macy" <macy(a)california.com> wrote in message news:1135981639.472329.31860(a)g14g2000cwa.googlegroups.com... > John, > > The soundcard is almost secondary here, except for the fact that the > presence of the soundcard makes everything real-time. Every 50 mS two > buffers, each containing 9600 samples of 24 bit digitized signals, are > appearing that need to be "attended to". *AND two similar outgoing > buffers need to be filled. > > It's a bit of a time crunch on the 500MHz machine. However, the custom > code I described earlier actually does all and is finished in less than > 17 mS each 50 mS cycle, so I have time left over. But I was amazed > that many of the "packaged" displays ate up the remaining 33mS very > quickly. > > The main activity remaining for the hardware is to provide a means for > the Operator to change operating parameters using some kind of > pictures, or table of values. And to display the selected resulting > data in a meaningful manner. Every 50mS put up a constantly changing > display. With the ability to modify/change the display for example, > freeze, zoom in/out, scale change, select WHAT is displayed, click and > drag zooming, etc.etc. > > The soundcard's presence is really secondary to what I now need to do. > The source of the data could have been a huge file stored on disk. > Hopefully, my problem has been reduced to one of INPUT/OUTPUT using the > PC. So I'm stuck trying to add controls and displays. > > Any experience with "slick and fast" GUIs? > > Thank you for the codeproject URL, will go there and look around. > > - Robert - >
From: Robert Macy on 31 Dec 2005 17:08
Loading and unloading is a piece of cake. But you can't imagine how much number crunching occurs every cycle before display. We're talking some major processing. Thank you for the suggestion, ...uh, what is wave out versus window message? Unknown terms to me. - Robert - |