最近发现日本有一内存播放器PlayPcmWin，感觉音质好于Foobar2000等播放器，有兴趣的朋友可试一试
http://code.google.com/p/bitspersampleconv2/downloads/listPlayPcmWin介绍：PlayPcmWin is yet another opensource audio player for audiophiles.
Features
Supports WASAPI exclusive mode playback. Bit-perfect capable.
Memory play. Load all PCM data onto the main memory before the playback starts.
Native C++ optimized code for the playback thread. C# .NET 4.0 WPF GUI for easy use.
Supports WAV(16, 24, 32bit), FLAC(16, 24bit), AIFF(16, 24bit) and AIFC-sowt formats.
Supports CUE sheets.
Gapless playback.
Source code available.
Supported Platforms: Windows Vista 64-bit, Windows 7 64-bit.
DownloadsStable version PlayPcmWin 3.0.57 x64 build installer
http://bitspersampleconv2.googlecode.com/files/PlayPcmWin357x64en.zipDevelopment version PlayPcmWin 3.0.59 x64 build installer
http://bitspersampleconv2.googlecode.com/files/PlayPcmWin359x64en.zipLicense
PlayPcmWin: MIT License
http://code.google.com/p/bitspersampleconv2/source/browse/trunk/PlayPcmWin/PlayPcmWinLicense.txtlibFLAC: New BSD License
http://code.google.com/p/bitspersampleconv2/source/browse/trunk/PlayPcmWin/libFlacLicense.txtScreenshots
What's the data feed mode? Which is better for the sound quality ?
Event driven data feed mode: Playback thread wakes up from sleep state by WASAPI buffer request event. Wake up interval of playback thread is specified by output latency time. Buffer refill sample size is latency time x sample rate (samples).
Timer driven data feed mode: Playback thread wakes up by timer event. Timer alarm interval is specified by output latency time / 2.
Theoretically, Event driven mode is more sophisticated method than timer driven mode. It minimizes CPU load and elongate sleep interval of the playback thread.
Generally speaking, Event driven mode is recommended for lower CPU load and less sound glitch.
In the real world, Several devices prefers event driven mode (On those devices, Timer driven mode lead to frequent click noise), Other a few devices prefers timer driven mode (Cannot use event mode at all). Most devices do work well on both mode.
About the render thread task typeFirst, Render means playback, Capture means recording
If you want to set 10 ms or fewer output latency, Pro Audio is preferred option. If you choose Pro Audio option, The render thread priority runs on the highest priority. It reduces the probability of output buffer underflow accidents but from the power consumption standpoint, It causes negative impact.
Render thread task type settings ultimately chooses the first parameter of AvSetMmThreadCharacteristics() function call of the playback thread.
If you choose None , the playback thread does not call AvSetMmThreadCharacteristics() at all.
Playback has lower priority than Pro Audio but higher priority than Audio. These difference is subtle, I think Playback is suitable for high CPU load environment such as background video transcoding or CGI rendering or other background number crunching tasks.
Very detailed description is available on these website:
http://msdn.microsoft.com/en-us/library/ms684247%28v=VS.85%29.aspxhttp://msdn.microsoft.com/en-us/library/bb614507.aspxExclusive or SharedI strongly recommend to choose exclusive mode for optimal sound quality. Exclusive mode bypasses windows mixer and numerous PCM data altering effects such as poor quality windows built-in software sample rate conversion.
If you experience sound stuttering on playbackWindows is complicated system and has wide variety of hardware and software. Very many factors are involved this type of problem.
The following page provides very useful troubleshooting regarding to playback glitch on Windows. I recommend to check your system according to this guide.
http://www.native-instruments.com/knowledge/questions/847/Windows+7+Tuning+Tips+for+audio+processing
