Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago 这个问题确实存在，目前确实不知道如何避免这个问题。因��
�JAVA程序占用的CPU比别的程序多，
所以当CPU不够用的时候，影响就特别明显。Original comment by hadeslee...@gmail.com on 13 Aug 2009 at 3:09
GoogleCodeExporter
commented
9 years ago 其实这个是windows自己的毛病了，用千千静听一样有这个问题�
��是windows的调度程序的问题。
当然，java可能会加重它的严重程度。Original comment by tianzho...@gmail.com on 19 Aug 2009 at 5:03
GoogleCodeExporter
commented
9 years ago 我觉得这个问题可以通过把javax.sound.sampled.SourceDataLine的缓冲�
��置大一点来进行缓解。
目前BasicPlayer:openLine方法中缓冲区使用的是默认的设置，因此
如果把这个缓冲去设置大一些的话，应该可以降低一下cpu
usage。参见以下叙述（excerpt from Java Sound Programmer Guide）
Setting Up the SourceDataLine for Playback
Opening the SourceDataLine is also similar to opening a Clip, in that the
purpose is once again to reserve the line. However, you use a different method,
inherited from DataLine:
void open(AudioFormat format)
Notice that when you open a SourceDataLine, you don't associate any sound data
with the line yet, unlike opening a Clip. Instead, you just specify the format
of the audio data you want to play. The system chooses a default buffer length.
You can also stipulate a certain buffer length in bytes, using this variant:
void open(AudioFormat format, int bufferSize)
For consistency with similar methods, the buffersize argument is expressed in
bytes, but it must correspond to an integral number of frames.
How would you select a buffer size? It depends on your program's needs.
To start with, shorter buffer sizes mean less latency. When you send new data,
you hear it sooner. For some application programs, particularly highly
interactive ones, this kind of responsiveness is important. For example, in a
game, the onset of playback might need to be tightly synchronized with a visual
event. Such programs might need a latency of less than 0.1 second. As another
example, a conferencing application needs to avoid delays in both playback and
capture. However, many application programs can afford a greater delay, up to a
second or more, because it doesn't matter exactly when the sound starts
playing, as long as the delay doesn't confuse or annoy the user. This might be
the case for an application program that streams a large audio file using
one-second buffers. The user probably won't care if playback takes a second to
start, because the sound itself lasts so long and the experience isn't highly
interactive.
On the other hand, shorter buffer sizes also mean a greater risk that you'll
fail to write data fast enough into the buffer. If that happens, the audio data
will contain discontinuities, which will probably be audible as clicks or
breakups in the sound. Shorter buffer sizes also mean that your program has to
work harder to keep the buffers filled, resulting in more intensive CPU usage.
This can slow down the execution of other threads in your program, not to
mention other programs.
So an optimal value for the buffer size is one that minimizes latency just to
the degree that's acceptable for your application program, while keeping it
large enough to reduce the risk of buffer underflow and to avoid unnecessary
consumption of CPU resources. For a program like a conferencing application,
delays are more annoying than low-fidelity sound, so a small buffer size is
preferable. For streaming music, an initial delay is acceptable, but breakups
in the sound are not. Thus for streaming music a larger buffer size—say, a
second—is preferable. (Note that high sample rates make the buffers larger in
terms of the number of bytes, which are the units for measuring buffer size in
the DataLine API.)
Instead of using the open method described above, it's also possible to open a
SourceDataLine using Line's open() method, without arguments. In this case, the
line is opened with its default audio format and buffer size. However, you
can't change these later. If you want to know the line's default audio format
and buffer size, you can invoke DataLine's getFormat and getBufferSize methods,
even before the line has ever been opened. Original comment by hellog...@gmail.com on 17 Aug 2010 at 3:40
Original issue reported on code.google.com by
changlu_...@163.comon 12 Aug 2009 at 7:21