Once I was asked to make a portable program in Java which should do some
signal processing using the low level waveform I/O.

That appeared to be impossible because of many weird problems (mainly
with the different JVM drivers).

So, don't try to use Java for the signal processing, especially at the
waveform i/o level and in the real time. Java is not for that.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

What's the difference between "sampling frequency" and "fundamental  
frequency"?  If "fs" is your sampling frequency, then "fs/n" (i.e. "the  
inverse of this time value") is a meaningless "per second" value, because  
you've removed the "samples" part of the formula.

For example, let's consider a sampling rate of 10 Hz.  If you have 10  
samples, then your "fs/n" value is "1/second".  But if you have 20  
samples, without changing the actual sampling rate, your "fs/n" value is  
"0.5/second" or "1/(2 seconds)".  The actual sampling rate hasn't changed,  
but your calculated value -- whatever it's meant to represent -- is  
changing.

Obviously lengthing the amount of time so that you can get more samples  
doesn't actually change the sampling rate.  So if you're trying to use  
that "fs/n" to map back to some sort of useful number related to the rate  
at which you're sampling, or an audio frequency that you can record, it's  
not going to actually do that.  "fs/n" is an arbitrary value that is  
simply the reciprocal of the number of seconds over which you  
recorded...it has nothing to do with the underlying nature of the data  
you've recorded, other than being a direct (albeit inverse) measure of the  
time duration of the recording.

Perhaps you could be more specific about how you're doing the recording.  
A concise-but-complete code sample would not be unreasonable here.  That  
would allow us to precisely know just how you're capturing the audio data,  
as well as how you're calculating your frequencies.

From your paragraph about "fundamental frequency", I think there's a  
possibility that you're simply not calculating the "frequency" correctly.  
You should first be more clear about what frequency it is you really want  
to calculate (are you looking for the sampling frequency here?).  And you  
should show the code you're using to do that calculation.

Also, "PCM" is by itself somewhat ambiguous.  There are some PCM formats  
that do some rudimentary compression, by encoding each sample as a  
difference from the previous sample (and there are multiple variations on  
that technique).

If your frequency calculation is correct (which hasn't been shown to be  
true yet), and you can take the bytes you saved, group them in twos and  
send them back out to an audio playback interface that takes raw,  
uncompressed samples and they sound correct, then I'd agree something's  
fishy.  But I think it's more likely that either the calculation is simply  
wrong, or that if you treat those bytes as raw, uncompressed samples,  
you'll get garbage trying to play them back.

In other words, I think it's more likely there's a mistake on your part  
than that there's something fishy going on.  But then, I get the  
impression you know that.  :)  So really, the key here is for you to  
provide enough information for someone to explain what your mistake is.  
So far, you haven't.

Pete

You haven't said how long your audio clips are, or what you mean by
'getting frequencies'.  I assume you're analyzing them for frequency
content, and finding little or none below 7Hz?

Consider that most audio paths are AC coupled, because humans can't hear
much below 40Hz (or 60, or 20, depending on who you ask).  Given that, a
7Hz low-frequency cut off is generously low.

On Apr 13, 1:44 pm, "cpptutor2...@yahoo.com" <cpptutor2...@yahoo.com>
wrote:

Correct.  You have a sample window covering n/fs units
of time.

The fundamental frequency recorded depends on the contents
of the actual data, not merely this time value.  What does
depend on 1/(n/fs), the inverse of your time value, is the
frequency spacing between successive bins of a DFT/FFT
performed on a sample window of that given length in time
(perhaps proportional to a form of frequency "resolution").

Are you calling some sort of frequency analysis routine
in Java?  What is the form of the input and the result?
(scalar or complex vector, data type, data packing, and
etc.)

IMHO. YMMV.

Did you properly reconstruct the shorts or ints from the byte
data?  One way to tell is to look at the range of your
reconstructed data (the difference between maximum and minimum)
over an interval.  If the range is 32767 to 32768 (or 0 to
65536, or some such) that can be a strong hint that your bytes
are assembled backwards.  In this case, a plot of the data
should look like rail-to-rail noise.

However, in a later post you wrote:

Even (especially) after reading your later post, I don't
understand what you are saying.  From your later post, it seems
that 7 Hz is your bin resolution, so the first bin corresponds
to 7 Hz, the 2nd to 14 Hz, etc.  Are you saying that you don't
see a spike near bin 71 (500/7)?  Perhaps the amplitude of your
injected tone is too low compared to the amplitude of your
other signal (so the spike is there, it's just lost in the
noise).  What exactly is the problem?