Starting cPlay
When you run cPlay (double-click desktop icon) for the first time, setup must be performed.
Playing audio with RealTime priority:
Using Cue Sheets which enables playlist playback is recommended.
Settings
Bottom left button in main screen brings up cPlay’s settings. ASIO settings button below depends on ASIO driver – Juli@ has no effect whilst RME, Lynx, EMU and ASIO4ALL gives access to ASIO control panel of driver. cPlay offers 2 channel output mapping only (this is a deliberate design choice).
For some changes to take effect (ASIO, Buffer, AWE and Output Rate), a restart is required. ASIO changes (from cPlay or external) will cause cPlay to stop (and a restart is required). This is an important safety measure.
When changing rates (e.g. 96 to 44.1), some ASIO soundcards will re-map its channels – cPlay tries to detect this (depending on ASIO driver) and informs you to reset left & right channels. Why? Soundcards using the ADAT interface use channel multiplexing (i.e. 96k gives 2x48k...) hence channels change with rate.
cMP setting disables file browse button (to prevent indefinite waits in cMP²).
Buffer
"DSP Buffer" at Auto (default), Small, Medium or Large is provided.
Guidance: CPUs with 2MB+ L2 cache, use Auto setting. Small is ideal for high output rates (above 96k) whilst Medium is best for 96k or lower. On CPUs offering less than 2MB L2 cache, Small is recommended for all output rates. 'Large' buffer setting is used by Auto when output rate is 48k or less. Processors with L2 cache size larger than 2MB, its worth testing Medium and Large settings (for any output rate).
"Tiny" buffer option offers lowest L2/L3 cache footprint enabling lower specification CPUs to be used with resampling. The 2MB L2/L3 cache requirement remains to produce highest quality 192k output. Auto only uses Small, Medium, or Large, i.e. Tiny must be manually selected. Tiny is highly recommended when using a VST plugin.
These buffer sizes work best with low ASIO latency setting (less than 512 samples).
Buffer setting affects resource consumption of CPU and RAM. This in turn affects power supply and the ground plane. Another key factor is how often the DSP thread is used to fill buffers. It's a periodic transaction and hence causes periodic jitter. Every player has this. Larger buffers require longer CPU bursts (especially so with SRC@145db). When using cMP, larger buffers cause slower UI responses, for example one gets a "slow" or "lazy" mouse with larger buffers. This is entirely by design in cMP² with Optimise set to "Critical". Try setting cMP's Optimise to "Player" or "Realtime" and you'll experience different results.
Therefore, different buffer sizes induce (by software) different jitter distortion (both in magnitude and frequency) causing audible differences.
SRC @145.68db SNR
cPlay can use the CPU intensive 145.68db SNR upsampler. A word of caution: do NOT attempt to use this on lightweight processors (anything less than E4xxx Core 2 Duo processor). A minimum of 2MB L2 cache is required. For example, the E2140 (1MB L2 cache) and Pentium 4 3GHz (1MB L2 cache) can only accomplish 44.1->96 - anything beyond this results in a locked/slow computer. There's a tradeoff here: more CPU power means more electrical inteference (and increased power consumption) thus reducing benefits of superior upsampling.
The E6300 (2MB L2 cache, 1.86GHz) processor comfortably copes with 192k upsampling with CPU load at ~40% (individual CPU core). cMP² using this setup operates with no CPU fan gives CPU temperatures of ~43°C. In cMP², no dropouts occur when Optimize is set to Critical. Intel's new E7xxx (based on 45nm technology) is an excellent choice offering low power consumption and brutal performance.
SoX Resampler Settings
SoX implementation in cPlay enjoys full optimisation as that for SRC (Secret Rabbit Code). This includes 128bit DSP processing and other optimisations. Only VHQ (Very High Quality, 175db rejection aka Stop Band) and HQ (High Quality, 125db rejection) converters are supported. SRC at 145db SNR (154db rejection) and 121db SNR (120db rejection) remains as before. SoX VHQ offers better than 170db SNR performance (see measurements below). Other SoX resampler options available in cPlay are (as per SoX Manual):
Using AWE
Physical RAM allocation method is used (for WAV RAM LOAD). This advanced technique requires LOCK privilege setting! AWE stands for Address Windowing Extensions - allocation occurs directly (system available RAM drops immediately). Windows may NOT allocate all 'Available RAM' - in which case, cPlay reverts to standard approach
Diagnostics will show whether AWE was successful at RAM allocation. Process Explorer or Task Manager will not show RAM allocated to cPlay's working storage, instead you'll see the reduction in Available RAM.
Make sure you have LOCK privileges set on your computer. Windows will not offer all "Available RAM" for AWE - in which case cPlay reverts to standard allocation. Adding additional RAM will prevent this. AWE offers the potential to load up to 4GB of RAM - not tested.
How 2 set LOCK privilege
Perform these steps exactly (applicable to XP SP2 Pro):
Lock privilege is now enabled. If this is not done, cPlay will fail on AWE and revert to standard RAM allocation. This is reported in Diagnostics only, i.e. "AWE allocation successful" message is given.
Keyboard Actions
Diagnostics
Incredible detail is provided when diagnostics is activated. Also, when cPlay encounters an error, diagnostics is displayed – it’s always a good idea to scroll to the bottom for important messages.
Here’s the initial startup diagnostics using Juli@:
Both Player (cPlay) and Driver (Juli@) support ASIO version 2.0. Latency at ‘preferred buffer’ level matches output latency (48 samples), output ready & hardware optimizations are done. Any advantage of RME’s off-host processing is negated here. Juli@ passes with flying colors!
For RME HDSP9652:
Disappointing to see only support for ASIO 1.0 and actual output latency differs from preferred buffer latency - it’s worse than Juli@. Ideally, both output and buffer latencies should be the same. Output ready & hardware optimizations are done.
For EMU 1212M:
This soundcard offers poor latency of 2ms (at any sample rate), preferred buffer latency doesn’t match output latency and no hardware optimization supported. Note that if you have an EMU card installed, do NOT disable it (in device manager) as this causes instability (as drivers remain operational)!
VST Plugin
VST is Steinberg's standard for applying DSP sound effects to audio streams. Effects can be absolutely anything one desires (stereo to mono, EQs, Stereo to 5.1., etc.). There's a huge selection - one needs to be careful as some have bad quality (bugs and/or process in integer causing quality loss). Used correctly, one could achieve excellent results. Another common acronym is VSTi which are DSP components that act like musical instruments.
Here's Steinberg's explanation of a VST plugin:
cPlay supports use of a single VST plugin (up to version 2.4.2, 2-in/max 8-out) in 32 bit float precision. Plugin is processed after resampling and volume (if used). For best results, use Tiny or Small buffer setting. ASIO performance is maintained for 2-in/2-out plugins (stereo output). For multi-channel output, best ASIO performance is achieved when latency is 64 samples or less.
Settings: