此播放器最大的bug

[GoogleCodeExporter]

不能实时播放音乐，如果电脑cpu处于忙的状态，播放音乐就��
�断断续续不连贯，比如打开个网页
音乐就会卡一下。
我是在window下运行的。

Original issue reported on code.google.com by changlu_...@163.com on 12 Aug 2009 at 7:21

[GoogleCodeExporter]

这个问题确实存在，目前确实不知道如何避免这个问题。因��
�JAVA程序占用的CPU比别的程序多，
所以当CPU不够用的时候，影响就特别明显。

Original comment by hadeslee...@gmail.com on 13 Aug 2009 at 3:09

• Changed state: Accepted

[GoogleCodeExporter]

其实这个是windows自己的毛病了，用千千静听一样有这个问题�
��是windows的调度程序的问题。
当然，java可能会加重它的严重程度。

Original comment by tianzho...@gmail.com on 19 Aug 2009 at 5:03

[GoogleCodeExporter]

我觉得这个问题可以通过把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