Hello Rick, Thanks for your explanation of using Direct X. I am curious about the many methods of sound I/O available under Windows - could you please tell us why the simpler wave type interface would be unsuitable, e.g. waveInPrepareHeader/waveOutOpen etc.
Thanks, David On Sun, 2012-05-20 at 12:02 -0400, Rick Muething wrote: > David/All, > > I’ll answer this on a separate thread cause it gets too confusing when > mixed in with the other comments. > > In .NET I have used Microsoft’s Direct X. Direct X is a large (and > cumbersome) beast is you use all its capabilities , graphics, > animations, sounds, etc but what is normally done for sound cards is > just use a component of Direct X called Direct Sound. This is much > smaller and manageable and I have had good luck with it over the > years. On the down side there isn’t (or at least wasn’t last time I > checked a few years ago) much help in the way of descriptions and > examples. I had to plow through some obscure documents and do a lot > of trial and error and get a some clarifications from some of the > Microsoft forums. > > Basically this is what you need to be able to do with a sound card for > DSP work like you would encounter in CODEC2 or the FDMDV modem: > > 1) Have the OS be able to enumerate the installed sound cards and how > to describe and identify them. Sounds easy enough but... > a) Some sound cards have different names for the capture and > playback....those are actually two different devices in Windows. > b) You have to make sure you can differentiate between two > identical installed sound cards...e.g. two or more SignaLink USBs > plugged in. It isn’t that rare and some chip sets report the same > “friendly name” to the OS. I ended up tagging on some unique > characters extracted from the driver GUID to make otherwise identical > names appear different to the user. > > 2) You have to be able to set the parameters desired for the sound > card. In Direct X these include: > For capture devices: > Buffer size > Sample size in bytes (most sound cards are 16 bit ...some are > now 20, 22, or 24 bits) > Sample rate (samples per second) best to generally stick with > the cardinal rates of 48000, 96000, 192000 and decimate from there if > needed. > Mono or Stereo. (Stereo not supported on most ham radios of > course) > Notify size: this tells the driver what size chunks to > interrupt the program with (usually in a separate “acquisition > thread”) . Notify size is usually set to a binary value of samples. > e.g. 1024, 4096 etc. There is no absolute guarantee you will always > get this number of samples ...a higher priority task may interrupt and > you could get an integer multiple of the Notify size. In any case you > shouldn’t ever miss any samples > > For Playback devices similar parameters but no notify size. In > every sound card I have seen you can treat playback and capture as two > different devices. > > 3) You may also have to interact with the Windows mixer that controls > the volume etc. Some sound card drivers use the mixer...some do not. > I prefer not to use the mixer if possible...little things like a > Windows auto update may reset some volume levels for instance! > > 4) Playing with the Playback device. There are basically two methods > both are useful. > > a) Play a file: You create a file (usually a standard > formatted .wav file the file header specifies the sample rate, > bytes/sample, mono stereo etc.) You tell the Playback device in Direct > X to play the file. You can abort the play, check on status (e.g. is > it actually playing now or not) etc. > > b) Play a stream. You can define a stream in Direct X which has > basically all the characteristics of a file but it is a dynamic buffer > (FIFO). You can append samples to the stream before or while it is > playing. Once samples are played the by the playback device they are > purged from the buffer. This has two major advantages: > 1) It doesn’t use disk space or require disk access but an > efficient thread-safe buffer manager > 2) You can continuously stream data ...very important for > something like continuous voice. When the stream ends (runs out of > data) the playback device automatically goes back to the not playing > status. > Although I originally used a) above for the last couple of > years all the WINMOR and V4 work use b) even though they are not > continuous (sending typically 3- 6 second “frames”) . The streams > just have less overhead and work well as long as you don’t try and > feed in samples a lot faster than you are playing of course! > > Basically you need about half a dozen fairly simple .NET utility > functions to control the above. I would be willing to build a little > demo application that demos all the above. > > There are some other drivers for sound cards on Windows but when you > stick with Direct X any device plugged in generally works > automatically with either the generic driver or Windows finds the > required driver. For example plug in a Icom IC-7200 into the USB port > and there is a USB sound card (24 bits in this case if needed) that > can be enumerated and looks and works just like any other Windows > sound card. > > So as an application a VOX (or PTT) operated application would need > to: > > 1) Allow the user to select the voice input capture device. This would > be a microphone plugged into the computers sound card or more > conveniently a wireless head phone/mic that appears as a USB type > capture device. > > 2) Allow the user to select the received and decoded voice playback > device. Again either the computers speakers or the earphones of the > wireless headphones above. > > 3) Allow the user to select the playback device to the radio. This > could be a generic sound card in the computer, a device like a > SignaLink USB with an isolated interface or the built in sound card of > a radio like the IC-7200 or TS-590S. > > 4) Allow the user to select the capture device from the radio audio. > Either the speaker, AUX audio out or in the case of the new radios the > actual built in sound card in the radio. > > 5) Then the app would have to: > For transmit: > Stream the microphone sound samples into the CODEC2 encoder > Stream the output of the CODEC2 in the FDMDV modulator > Stream the output of the FDMDV modulator into the Radio > playback device > Activate the PTT if required. > > For Receive: > Stream the audio from the radio to the FDMDV demodulator > Stream the demodulator output to the CODEC2 decoder > Stream the output of the CODEC2 decoder to the Speaker or > headphone playback device. > > Although this all requires continuous streaming it’s a lot easier than > an ARQ type system with constant Data/Command and ACK/NAK cycles. > > Over the next week I’ll try and cut and paste up some VB.NET (C isn’t > that much different in this case) examples with comments on the half > dozen or so functions needed. > > 73, > > Rick Muething, KN6KB > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
