«

hello,

I have a big problem with cpu usage. when i listen microphone to record
what comes, cpu time is consumed apr. 80% everytime which seems
unnecessary. cpu is P4 2.8 GHz. i have lots of programs which does do as
executable from internet and none of them consumes so much. here is the
code, could ou please lead me to solve this problem?

AudioFormat format = new AudioFormat(
AudioFormat.Encoding.PCM_SIGNED, // Encoding technique
8000, // Sample Rate
16, // Number of bits
in each channel
2, // Number of
channels (2=stereo)
4, // Number of bytes
in each frame
8000, // Number of frames
per second
true );// formatControls.getFormat();

DataLine.Info info = new DataLine.Info(TargetDataLine.class, format);
line = (TargetDataLine) AudioSystem.getLine(info);
line.open(format, line.getBufferSize());
ByteArrayOutputStream out = new ByteArrayOutputStream();
int bufferLengthInBytes = bufferLengthInFrames * frameSizeInBytes;
byte[] data = new byte[bufferLengthInBytes];

while (true) {

if ((numBytesRead = line.read(data, 0, bufferLengthInBytes)) == -1) {
break;//here is the place where cpu is consumed!
}

out.write(data, 0, numBytesRead);
}

On Sun, 17 Aug 2008, black-white wrote:

> if ((numBytesRead = line.read(data, 0, bufferLengthInBytes)) == -1) {
> break;//here is the place where cpu is consumed!
> }

That's what we call a busy-wait, and it is indeed a very good way to waste
all your CPU time. You could try something like this:

while ((numBytesRead = line.read(data, 0, bufferLengthInBytes)) == -1) {
try {
Thread.sleep(t) ;
}
catch (InterruptedException e) {
// can probably ignore this
}
}

Where t is a duration in milliseconds. This basically means that your
program will wait for a while before trying to read data again. It won't
be consuming CPU while it waits.

The problem is picking the right value for t. If it's too long, you run
the risk of the line's buffer overflowing while the reader thread sleeps.
If it's too short, you'll use too much CPU time.

I'd set it based on a calculation of how long the buffer will take to
fill. Like this:

float dataRate = format.getFrameRate() * format.getFrameSize() ; // in bytes per second
float timeToFill = line.getBufferSize() / dataRate ; // in seconds
long t = (long)((timeToFill * f) * 1000) ;

Where f is a fraction, saying how full you want the buffer to get between
reads; i'd set it to 0.5, so the buffer will be half full. That should
mean that if your thread is a bit slow at waking up, there's still little
chance of overflow. You might need to adjust this downwards if you find
there are overflow problems.

Another option would be to set the time adaptively, based on how long the
last sleep was, and how full the buffer got. That's a bit more
complicated, but you can probably work it out.

The underlying problem is that there's no way to read data from a line in
a blocking way. This is a design fault in the library, sadly.

tom

--
History, I believe, furnishes no example of a priest-ridden people
maintaining a free civil government. -- Thomas Jefferson

Call line.start()

hello tom,

thanks a lot fr your detailed description. morrow n the company i will
try what you suggested and i am sure it will be much more better

Tom Anderson wrote:
> On Sun, 17 Aug 2008, black-white wrote:
>
>> if ((numBytesRead = line.read(data, 0,
>> bufferLengthInBytes)) == -1) {
>> break;//here is the place where cpu is consumed!
>> }
>
> That's what we call a busy-wait, and it is indeed a very good way to
> waste all your CPU time. You could try something like this:
>
> while ((numBytesRead = line.read(data, 0, bufferLengthInBytes)) == -1) {
> try {
> Thread.sleep(t) ;
> }
> catch (InterruptedException e) {
> // can probably ignore this
> }
> }
>
> Where t is a duration in milliseconds. This basically means that your
> program will wait for a while before trying to read data again. It won't
> be consuming CPU while it waits.
>
> The problem is picking the right value for t. If it's too long, you run
> the risk of the line's buffer overflowing while the reader thread
> sleeps. If it's too short, you'll use too much CPU time.
>
> I'd set it based on a calculation of how long the buffer will take to
> fill. Like this:
>
> float dataRate = format.getFrameRate() * format.getFrameSize() ; // in
> bytes per second
> float timeToFill = line.getBufferSize() / dataRate ; // in seconds
> long t = (long)((timeToFill * f) * 1000) ;
>
> Where f is a fraction, saying how full you want the buffer to get
> between reads; i'd set it to 0.5, so the buffer will be half full. That
> should mean that if your thread is a bit slow at waking up, there's
> still little chance of overflow. You might need to adjust this downwards
> if you find there are overflow problems.
>
> Another option would be to set the time adaptively, based on how long
> the last sleep was, and how full the buffer got. That's a bit more
> complicated, but you can probably work it out.
>
> The underlying problem is that there's no way to read data from a line
> in a blocking way. This is a design fault in the library, sadly.
>
> tom
>

jolz, thanks for your answer but i had no problem with running of line,
i had just cpu time wasting problem.

jolz wrote:
> Call line.start()

> jolz, thanks for your answer but i had no problem with running of line,

Are you sure ?
The read()'s doc says:
"This method blocks until the requested amount of data has been read".
So there should be high CPU usage (at least with large enough buffers).
But without start() numBytesRead will be allways 0 and the loop will
behave like while (true) { }

> That's what we call a busy-wait

No it's not.

>, and it is indeed a very good way to
> waste all your CPU time.

There is no CPU time being used here at all actually. There is
wall-clock time being spent while the read() method blocks. Not the same
thing.

> while ((numBytesRead = line.read(data, 0, bufferLengthInBytes)) == -1) {
> try {
> Thread.sleep(t) ;
> }
> catch (InterruptedException e) {
> // can probably ignore this
> }
> }
>
> Where t is a duration in milliseconds. This basically means that your
> program will wait for a while before trying to read data again. It won't
> be consuming CPU while it waits.

Excuse me but this is all nonsense. The read() will return -1 at the end
of the stream. At this point there will *never* be any more data on the
stream.

jolz wrote:
>
> Are you sure ?
> The read()'s doc says:
> "This method blocks until the requested amount of data has been read".
> So there should be high CPU usage (at least with large enough buffers).

Why? Blocking doesn't consume any CPU.

jolz wrote:
>> jolz, thanks for your answer but i had no problem with running of line,
>
> Are you sure ?
> The read()'s doc says:
> "This method blocks until the requested amount of data has been read".
> So there should be high CPU usage (at least with large enough buffers).
> But without start() numBytesRead will be allways 0 and the loop will
> behave like while (true) { }

On Sun, 17 Aug 2008 12:44:59 +0300, black-white
<> wrote, quoted or indirectly quoted
someone who said :

> could ou please lead me to solve this problem?

You might try a different sound card. You might find one that does
some of the work in hardware that your current one is doing with
software, or that has a clever driver to use the aux cpu, leaving the
main one free to run Java. See if you can borrow a high end one to
see if it makes any difference.

--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com