snottmonster;621922 Wrote: > Why would decreasing the buffer size have any positive impact on sound > quality? In fact, wouldn't setting it too low have an adverse effect > due to possible under-running and there then being insufficient data to > feed to the DAC?
On a pretty busy PC or Touch (if you'd run everything incl. flac decoding, wlan decryption, samba server, monitor management, asf.asf. local) you'd be right. The audio related process/tasks wouldn't get enough airtime. The buffers wouldn't be refilled in time. Consequence would be XRUNS (buffer underruns) causing nasty sounds. Beside that a smaller buffer would even cause a higher load due to much higher refill cycles - making things even worse!!! If you run the Touch the way I recommend, the processor is not that busy with sharing processing time anymore. The processor mainly channels a datastream from a to b. A processor is usually working in a sequential 1ms time slot mode. The kernel scheduler (the heart of a system) is in charge for making sure that every process gets a "fair" amount of processing time assigned. Process lock-ups must be avoided and huge idletimes (causing stuttering if you e.g. move windows on a Windows system) should also be avoided. Those assignments of processing time slots are not linear. It's not like getting a time slot every other ms for your process. If you'd followed my setup recommendations and applied my toolbox, you got rid of as much "shared" processor load as possible. No need to play fair any longer. And a lot of ms for exclusive audio streaming use. By shrinking the buffer to very low levels I claim most and even more processing time for the buffer management - feeding the sound device. To be on he save side Logitech had to choose 20.000. They have to make sure that no XRUNS occur under any load condition. It's the best compromise from their perspective. I'm managing (with my current setup) to run stable at 3400. Now. The final and the key question then is: Why should a smaller buffer should have any impact to the sound compared to a large buffer, even if considering that the system gets more stressed by that smaller buffer. I can't answer it. My theory is the following: I guess it is not the absolute load which is the key factor here. The processor actually doesn't even have to be that busy. It's more about the "share" factor of processing time. My guess is that this share factor has something to do with non-linearities. If I run the buffer at very low levels I achieve a slightly better linearity by getting more exclusive processing time assigned to the stream. And that's what's finally causing less jitter. -- soundcheck 'soundcheck's Touch Toolbox 2.0' (http://soundcheck-audio.blogspot.com/2011/01/soundchecks-squeezebox-touch-toolbox-20.html) || 'soundcheck's Touch Toolbox - Beta Blog' (http://soundcheck-audio.blogspot.com/2011/01/soundchecks-tt-beta-blog.html) ------------------------------------------------------------------------ soundcheck's Profile: http://forums.slimdevices.com/member.php?userid=34383 View this thread: http://forums.slimdevices.com/showthread.php?t=84742 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
