界面处理还是延用了
bugd
的组件，为了方便修改，这次在
lib
文件夹里直接使用了
tcl
文件，而不是以往用到的
tbc
。总之，这一系列的程序应该都是
foobar-like
的。音频处理方面使用了
snack
，也有人用
lame
的，但是
lame
没有专门的模块，需要
dll
来调用，因此不是很方便，就更别提文档了。在
http://www.speech.kth.se/snack/
中有详细的文档和例子，很容易上手。另外，也可以参考
snackAmp
的源代码。在功能上，和我的设想有类似之处，比如说除了普通的播放之外，还可以作为网络服务器，提供在线广播收听。
OK
，要做到这步显然是需要花大功夫的，目前先作为一个正常的播放器来解决。但恰恰使这个“正常”让我花费了好大功夫。故障的表现是这样的，当使用
snack
播放音乐时，无论是最小化、最大化
snack
程序还是其他的任何桌面窗体，播放都会卡一下。但是，当我使用
snackAmp
来播放的时候却不会有这个现象，而它也是调用
snack
的。
起初，我的想法是可能
snackAmp
中的
snack
版本和我使用的不一样，于是做了替换，结果依旧。之后，我怀疑是因为
snack
的原始
Tk
界面占用资源，于是将它
withdraw
了，也没有作用。没办法之下，研究起
snackAmp
的源代码起来。话说回来，这个程序写得真是糟糕，虽然分成了几十个
package
，但是相关性太高，到了你中有我我中有你的境界
,
绝大多数根本无法重用，看起来也云里雾里。最后终于定位到了
macro
中的
Play
和
soundCtrol
中的
play
两个函数，仔细分析之下发现真正涉及到播放的部分竟然非常普通，没有特别之处。打印出来的
snack::sound
对象属性基本雷同。
事实上，我忽略了最重要也是最有效的工具，文档。当发给
snack
和
snackAmp
作者的
email
石沉大海数日之后，我万念俱灰，却偶尔发现了在
manual
关于
snack
：：
audio
的
playLatency
介绍中有一句“
A low value makes new sound
samples reach the loudspeakers quickly at the risk of gaps in the output stream
”。不会是它吧！连忙对比了默认状态下和
snackAmp
中的
playLantency
参数，一个
250
，一个
2000
，
8
倍！就是这个！问题迎刃而解。