Member Avatar for donaldw

Hi all. Bear with me, I promise this will be hardware related in a minute...

I'm working on a project for which I need to generate some FSK. I'm doing so by using a sin(...) function to calculate the values along the wave for N periods of frequency A and M periods of frequency B, both of duration T, and storing them in a buffer. I tried using the waveOutWrite function to play the buffer that I created, but it ended up creating a complex sine wave which, for the most part, looked like I wanted it to (frequency wise) but it looked pretty fat and ugly on the oscilloscope. I zoomed in on it and it had another sine-looking wave running along the major sine wave, which made the FSK get all hosed up. To fix this, I ended up creating my own WAV file and put the data from the buffer in that, saved the file to disk and used PlaySound(...) to play it.

Here's where it gets hardware (I think...possibly) related. Take for instance the low bit frequency, 1562.5 Hz. When I play it on the development PC (a dell with what shows up as a microsoft sound device, SoundMax Integrated Digital HD Audio) it is coming out too fast and hoses up the FSK...it looks on the scope to be about 1572.3. When I play them from the device on which it's intended to be played (Intel board with RealTek ALC662 audio chip) it comes out dead on at 1562.5.

And here are my questions: Why the heck is it behaving like this? Does it have something to do with the dell audio device being integrated and perhaps running off of the system clock rather than a dedicated audio clock which could be messing up the sample rate or something whereas the RealTek has a dedicated audio chip which, presumably, has it's own clock rate?

As an interesting side note, as far as I can tell, the WAVEFORMATEX WAVEOUTCAPS only seems to support up to 44.1kHz sample rates, so that's what I'm using as of now, but the RealTek ALC662 data sheet says that it does up to 96kHz. When I used 96kHz (even though WAVEOUTCAPS doesn't seem to know about that frequency) for the sample rate with the waveOutWrite file, it made a simple sine wave that looked fine on the scope. Why would that behave that way? Is it because the chip knows about it and I'm telling the software to tell the chip to use that frequency and if the MS functions don't know about that frequency then it's their problem, not the software or the chip's? Is there something magical about the 96kHz frequency that makes it work (being the chip max or something) or would some other [evenly divisible] lower frequency likely also make a nice wave? (although none that I tried seemed to)

  • 1 Contributor
  • 1 Reply
  • 135 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by donaldw
Member Avatar for donaldw

I don't want to mark this as solved yet, since I don't know what is causing the behavior, but there have been some developments on this.

I've changed the code for building the buffer of values along the wave (the code for inserting fractional parts of wave periods, as they weren't getting inserted correctly and it was causing glitches in the waveform). I ran the software on the RealTek and the glitches were no longer present so, just for kicks, I ran it on the PC with the integrated audio and, BOOM, it works fine. All frequencies appear dead-on on the scope.

I didn't make any changes to the sound card (There was a power failure over the weekend though which outlasted the UPS battery, so everything got a restart) or change any code for generating or playing the frequency other than fixing the code for inserting and extra sample here and there. BUT, as the extra samples weren't getting inserted properly, there were too many or too few of them and the ChunkSize and SubChunk2Size weren't quite right with respect to the number of actual bytes in the file and there were some bogus values at the end of the buffer.

Would it be possible that the bad WAV header information was messing it up; like if when the file is opened for playback the header is read to determine sample rate, number of samples is calculated, etc. and it tries to fit the existing data into a certain amount of time that it should fill (which would be incorrect if the chunk sizes and number of samples in the file are off) and that would mess up the output frequency?

If that was the case though, why would it have been playing at the right frequency on the RealTek device all along though?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.