Java Audio question - PLEASE HELP

On Apr 13, 1:44 pm, "cpptutor2...@yahoo.com" <cpptutor2...@yahoo.com>
wrote:
> Now, from simple DSP principles, we know that if the number of samples
> collected is 'n' and the sampling frequency is 'fs', then the time
> needed to collect these 'n' samples is n/fs,

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

> and the fundamental
> frequency recorded is the inverse of this time value.

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.

Kenneth P. Turvey wrote:
> On Sun, 13 Apr 2008 18:23:35 -0500, Vladimir Vassilevsky wrote:
>> The task was a special modem operating via the sound card continuously.
>> It worked fine in Win32/C++, however they wanted to make it platform
>> independent in Java, so they could use the same code in Windows and for
>> the different flavors of Linux. There were problems with the
>> interruptions of the continuous flow of the waveform data depending on
>> the particular JVM and the particular drivers.
> 
> That's strange.  I could see garbage collection being a problem, but one 
> would think that such things have a sufficient buffer to make short 
> delays inconsequential.  I guess not. 

GC is very efficient but had poor real time characteristics.

Often the problems can be resolved by tuning the GC via the many
JVM parameters to do so.

Arne

Arne Vajhøj wrote:
> Kenneth P. Turvey wrote:
> 
>> On Sun, 13 Apr 2008 18:23:35 -0500, Vladimir Vassilevsky wrote:
>>
>>> The task was a special modem operating via the sound card continuously.
>>> It worked fine in Win32/C++, however they wanted to make it platform
>>> independent in Java, so they could use the same code in Windows and for
>>> the different flavors of Linux. There were problems with the
>>> interruptions of the continuous flow of the waveform data depending on
>>> the particular JVM and the particular drivers.
>>
>>
>> That's strange.  I could see garbage collection being a problem, but 
>> one would think that such things have a sufficient buffer to make 
>> short delays inconsequential.  I guess not. 
> 
> 
> GC is very efficient but had poor real time characteristics.
> 
> Often the problems can be resolved by tuning the GC via the many
> JVM parameters to do so.

Exactly. To make it work, I had to tweak many not so obvious parameters 
depending on the particular OS, JVM and drivers. That broke the whole 
idea of being independent from the platform.


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

Vladimir Vassilevsky wrote:
(snip)
> Arne Vajhøj wrote:
(snip)

>> GC is very efficient but had poor real time characteristics.

>> Often the problems can be resolved by tuning the GC via the many
>> JVM parameters to do so.

> Exactly. To make it work, I had to tweak many not so obvious parameters 
> depending on the particular OS, JVM and drivers. That broke the whole 
> idea of being independent from the platform.

Platform independence, or even a different model of the same platform,
has always excluded speed.  That is, a program may run faster or slower
but it will give the correct output (bits).  Unfortunately, audio
depends not only on the bits but the speed.

-- glen

Peter Duniho wrote:
> On Sun, 13 Apr 2008 13:44:36 -0700, cpptutor2000@yahoo.com  
> <cpptutor2000@yahoo.com> wrote:

>> [...]
>> Now, from simple DSP principles, we know that if the number of samples
>> collected is 'n' and the sampling frequency is 'fs', then the time
>> needed to collect these 'n' samples is n/fs, and the fundamental
>> frequency recorded is the inverse of this time value.

> 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.

If you have n samples and sampling frequency fs then fs/n is the
lowest frequency you get from, for example, an FFT.  That is,
the lowest frequency periodic in n samples.  Whether that should
be called fundamental or not, I don't know.

-- glen

Vladimir Vassilevsky wrote:
> Arne Vajhøj wrote:
>> GC is very efficient but had poor real time characteristics.
>>
>> Often the problems can be resolved by tuning the GC via the many
>> JVM parameters to do so.
> 
> Exactly. To make it work, I had to tweak many not so obvious parameters 
> depending on the particular OS, JVM and drivers. That broke the whole 
> idea of being independent from the platform.

You did not have to change the code or even rebuild just the
modify the configuration.

It happen - also for other problem domains than real time.

Arne

With reference to all the postings I am sorry I have caused confusion
about what I meant by the 'fundamental frequency' etc., May I give a
simple example?

For a given signal being sampled for analysis, the number of points
obtained and the time between samples combine to determine the total
length of time taken to examine the signal. The following definitions
apply:
   fs = sample rate in Hz
   dT = 1/fs = interval between samples
   N = number of samples taken
   T = N x dT = total time period

   f1 = 1/T = frequency of the first harmonic in Hz
Keeping these points in mind, I have found that f1 in my case is
around 7 Hz. I am NOT measuring 7 Hz. If I were to take an FFT of the
collected data, then I can expect to get peaks that are harmonics of 7
Hz. That is if I were to detect if the 500.0 Hz signal of the tone
generator was being picked up, I would have look for the 500/7
harmonic of 7 Hz. I hope I have made myself clear about what I am
trying to do.


On Apr 13, 4:14 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
> On Sun, 13 Apr 2008 13:44:36 -0700, cpptutor2...@yahoo.com
>
> <cpptutor2...@yahoo.com> wrote:
> > [...]
> > Now, from simple DSP principles, we know that if the number of samples
> > collected is 'n' and the sampling frequency is 'fs', then the time
> > needed to collect these 'n' samples is n/fs, and the fundamental
> > frequency recorded is the inverse of this time value.
>
> 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.
>
> > However, I am only getting frequencies as low as 7 Hz, or 8Hz, which
> > is just absurd. Could someone please tell me if I am doing something
> > totally incorrect, or where the flaw in my reasoning is. Any help
> > would be greatly appreciated. Thanks in advance for your help.
>
> 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

cpptutor2000@yahoo.com wrote:
> With reference to all the postings I am sorry I have caused confusion
> about what I meant by the 'fundamental frequency' etc., May I give a
> simple example?

Sure, but please do not top-post, and please do trim what you quote.

> For a given signal being sampled for analysis, the number of points
> obtained and the time between samples combine to determine the total
> length of time taken to examine the signal. The following definitions
> apply:
>    fs = sample rate in Hz
>    dT = 1/fs = interval between samples
>    N = number of samples taken
>    T = N x dT = total time period
> 
>    f1 = 1/T = frequency of the first harmonic in Hz

So if you accumulated twice as many samples, over twice as long, your 
fundamental frequency would be halved?  That is not sensible.

-- 
Lew

On Apr 22, 8:48 pm, "cpptutor2...@yahoo.com" <cpptutor2...@yahoo.com>
wrote:
> With reference to all the postings I am sorry I have caused confusion
> about what I meant by the 'fundamental frequency' etc., May I give a
> simple example?
>
> For a given signal being sampled for analysis, the number of points
> obtained and the time between samples combine to determine the total
> length of time taken to examine the signal. The following definitions
> apply:
>    fs = sample rate in Hz
>    dT = 1/fs = interval between samples
>    N = number of samples taken
>    T = N x dT = total time period
>
>    f1 = 1/T = frequency of the first harmonic in Hz
> Keeping these points in mind, I have found that f1 in my case is
> around 7 Hz. I am NOT measuring 7 Hz. If I were to take an FFT of the
> collected data, then I can expect to get peaks that are harmonics of 7
> Hz. That is if I were to detect if the 500.0 Hz signal of the tone
> generator was being picked up, I would have look for the 500/7
> harmonic of 7 Hz. I hope I have made myself clear about what I am
> trying to do.

You are using non-standard DSP vocabulary.  500 Hz is your
fundamental, not 7 Hz.  7 Hz might be your DFT bin separation,
bin resolution, or spacing.

You also never answered whether you tried plotting your
data after the type conversion to make sure you didn't
clip or wrap it.

<cpptutor2000@yahoo.com> wrote in message 
news:20ba17a5-a7b6-4e9a-a369-070f7b6efad1@d45g2000hsc.googlegroups.com...

> Could some DSP or Java guru please help me ? I have a simple 
> Java
> application that records audio signals and does simple 
> analysis on the
> collected data. I am using PCM encoding, with sampling 
> frequency 16000
> Hz, 16 bits resolution, single or mono channel, little endian 
> and
> signed.

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.

>
> The data is read into a ByteArrayOutputStream and then as 
> soon as I
> stop recording, the stream contents are written to a byte 
> array, using
> 'toByteArray()'. After that, I can get the size of this byte 
> array,
> which gives me the total number of bytes collected, keeping 
> in mind
> that I am using 16 bit resolution, i.e., each sound sample is 
> 16 bits
> long. I am using a software tone generator, with the 
> frequency set at
> 500.0 Hertz.
>
> Now, from simple DSP principles, we know that if the number 
> of samples
> collected is 'n' and the sampling frequency is 'fs', then the 
> time
> needed to collect these 'n' samples is n/fs, and the 
> fundamental
> frequency recorded is the inverse of this time value.
>
> However, I am only getting frequencies as low as 7 Hz, or 
> 8Hz, which
> is just absurd.

However, in a later post you wrote:

> f1 = 1/T = frequency of the first harmonic in Hz
> Keeping these points in mind, I have found that
> f1 in my case is around 7 Hz. I am NOT measuring
> 7 Hz. If I were to take an FFT of the collected
> data, then I can expect to get peaks that are
> harmonics of 7 Hz. That is if I were to detect
> if the 500.0 Hz signal of the tone generator was
> being picked up, I would have look for the 500/7
> harmonic of 7 Hz. I hope I have made myself clear
> about what I am trying to do.

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?