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. 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. 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.
Java Audio question - PLEASE HELP
Started by ●April 13, 2008
Reply by ●April 13, 20082008-04-13
cpptutor2000@yahoo.com wrote:> 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. > > 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. 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.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
Reply by ●April 13, 20082008-04-13
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. 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
Reply by ●April 13, 20082008-04-13
On Sun, 13 Apr 2008 13:44:36 -0700, cpptutor2000@yahoo.com wrote:> 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. > > 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. 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.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. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply by ●April 13, 20082008-04-13
Tim Wescott wrote:> 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. >That's a good point, actually. Even if Java were a DSP system, which it isn't, you're still at the mercy of whatever cheap-ass hardware is on the motherboard of your PC. I doubt its up to even a low-end studio rig. If you're using some sort of audio equipment run by Java that's not a PC, then you need to contact the manufacturer, 'cause there's no way we're going to know more than the maker.
Reply by ●April 13, 20082008-04-13
On Sun, 13 Apr 2008 16:07:41 -0500, Vladimir Vassilevsky wrote:> cpptutor2000@yahoo.com wrote: > >> 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. >> >> 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. 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. > > 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.Can you elaborate on what the problems were. This really shouldn't be a problem for Java. I just can't imagine why it would be. -- Kenneth P. Turvey <kt-usenet@squeakydolphin.com>
Reply by ●April 13, 20082008-04-13
On Sun, 13 Apr 2008 15:43:30 -0700, Mark Space <markspace@sbc.global.net> wrote:> Tim Wescott wrote: > >> 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. >> > > That's a good point, actually.Well, it's a good point if the OP actually meant he's trying to detect frequencies as low as 7 Hz. However, given that he specifically said he's using a 500 Hz tone generator, software-based no less, there's nothing about his post that makes me think he expects to see actual output frequencies of anything other than 500 Hz, or that the hardware limitations might apply. That said, yes...if there's hardware involved and if the OP is actually trying to get frequencies as low as 7 Hz, well...that's just unrealistic. :) Pete
Reply by ●April 13, 20082008-04-13
Kenneth P. Turvey wrote:> On Sun, 13 Apr 2008 16:07:41 -0500, Vladimir Vassilevsky wrote: > >> >>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. > > > Can you elaborate on what the problems were. This really shouldn't be a > problem for Java. I just can't imagine why it would be. >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. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●April 13, 20082008-04-13
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. -- Kenneth P. Turvey <kt-usenet@squeakydolphin.com>
Reply by ●April 13, 20082008-04-13
On Sun, 13 Apr 2008 15:55:54 -0700, Peter Duniho wrote:> On Sun, 13 Apr 2008 15:43:30 -0700, Mark Space > <markspace@sbc.global.net> wrote: > >> Tim Wescott wrote: >> >>> 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. >>> >>> >> That's a good point, actually. > > Well, it's a good point if the OP actually meant he's trying to detect > frequencies as low as 7 Hz. > > However, given that he specifically said he's using a 500 Hz tone > generator, software-based no less, there's nothing about his post that > makes me think he expects to see actual output frequencies of anything > other than 500 Hz, or that the hardware limitations might apply. > > That said, yes...if there's hardware involved and if the OP is actually > trying to get frequencies as low as 7 Hz, well...that's just > unrealistic. :) > > PeteWhich is why I asked the OP (who we haven't heard back from) to clarify. It sounds like he doesn't quite know what he's doing. -- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html