Ragnar214 wrote:I'm thinking that maybe the Audio Files themselves may be to blame?
Nah, if something intrinsic to the client or the resources were to blame, then clearly everyone would have the problem, not just some people.
Ragnar214 wrote:You say "It doesn't change the total CPU usage of the audio thread, only how much audio it buffers at a time"
What I meant is that it doesn't change the total amount of work that the client has to do to produce the playable audio per unit of time, but only affects in how large batches it does that work.
To take your excellent analogy further, it would be like you were filling beer bottles with beer, and only get 6 bottles per minute from the bottle machine, it would be the question of whether you accumulate 10 or 20 bottles to fill at a time. Regardless of which you choose, you still only fill 6 bottles per minute over time, though. ^^
Ragnar214 wrote:I'm guessing the :audiobuf 1024 (1024 is the MB in memory set aside to buffer audio correct)?
The number is the number of samples to produce in one batch, so 1024 is (1024 samples * 2 audio channels * 2 bytes per sample = 4096 bytes). Since the sample rate is 44.1 kHz, 1024 samples means one buffer stretches ~23 ms, or that the client submits audio to the driver in ~43 buffers/second. It is good for audio latency if the number of audio-buffers/second isn't much less than the FPS the client renders in, so that audio intended for a certain frame doesn't have to wait for the last submitted buffer to finish playing, which is why I'm keen on keeping the audio buffer size at 1024 samples.
Ragnar214 wrote:I also don't see how an audio thread can affect the visuals and graphics.
Well, if the audio thread is using 100% CPU, then it could certainly starve the rendering threads for time. On the other hand, if you have a quad core CPU, there should be cores left over for those anyway, so yes, it does sound a bit strange.
.
