Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><strong>Make sure the thread is blocking for input.</strong></p> <p>The thread takes up 100% of the CPU time if it doesn't block. Blocking will cause the thread to go to sleep until there is some external stimulus to wake it up. Whenever you have a dedicated thread to process input, you need to make sure that it's blocking on that input so that it will sleep like this, exactly in order to avoid the thread taking up 100% of the CPU time in its loop.</p> <p>In this specific case, if <code>Line</code> is a <code>javax.sound.sampled.TargetDataLine</code>, then the <code>read()</code> method is where you should be doing your blocking. According to the API, "This method blocks until the requseted amount of data has been read," but "if the data line is closed, stopped, drained, or flushed before the requested amount has been read, the method no longer blocks, but returns the number of bytes read thus far."</p> <p>So, there are a couple of possibilities. I don't see your definition of <code>Line</code>, so it's possible that you are flushing or draining the line in some code that you didn't include. If you did that, you should refactor your solution to not use those methods.</p> <p>The other possibility is that, since you're always reading only two bytes at a time, you're not reading enough to cause it to block. Basically, there are always two bytes available because it takes too long to process the two bytes you read, that there are always another two bytes available. Try increasing the size of the buffer to read more like 4kb at a time. See if that causes the loop to run less frequently, and block more frequently.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload