> <SNIP> >> >> Thanks Mark and Emery. I don't think my post was very well written. >> >> One of the ways to increase sound quality in digital audio playback is >> reducing jitter. In the following thread, Dynobot brings up how he >> used the real-time kernel to reduce latency and improve sound quality: >> >> http://www.computeraudiophile.com/content/Linux-audio >> >> Shouldn't reducing latency reduce jitter and thereby improve sound >> quality? I realize we are talking about very small changes in >> quality, but I'm interested in seeing Linux fully optimized for >> digital audio playback. >> >> - Grant > > There are a lot of sources of jitter. I don't know what effect the > kernel has on overall jitter. I wouldn't have thought it to be very > large though as typically jitter is a hardware issue. Of course, if > some sound card is using the system to set its timing then the kernel > could be a big source.
I use the Wavelength Proton USB DAC which runs in ASYNC mode so it uses it's own clock. > The overriding clock architecture of all the Alsa drivers is that the > sound card is in control of data flow using it's crystal based clock. > Basically, the card asks the system to fill a buffer and then the card > drains that buffer into your speakers. As long as the buffer isn't > starved then sound comes out on time. If the sound card clock has > jitter then it will appear in the sound, but even so I'm not sure that > this will be a big problem for home audiophile applications. (It is > for recording studios but even that is 50% political and possibly not > audible... > > What Jack sets up is a way for Jack-enabled applications to talk to > the sound card in a very deterministic way. Jack expects every app to > supply data on time and in the right format. Jack then mixes streams > if desired and sends the data on to the sound card, again on time and > in the right format. If you are running Jack then it can report to you > when this doesn't happen correctly and you can debug what the causes > are and fix them. This leads, in my experience, to better sound > because nothing is missing, but it doesn't reduce jitter, at least in > my systems. > > Jack and *most* Jack applications are real-time safe so that if you > run the real-time kernel with JAck you can get very low latencies. > This is important in recording applications, but not quite so > important in playback applications. (My opinion...) > > Jack runs perfectly with a non-real-time kernel. It just doesn't run > 'real time' because the kernel can stall you for long periods of time > while the sound card drains the buffer and you get clocks and pops. > That's what the real-time kernel, along with proper system > configuration for sound cards and audio apps, does for you. Would you say latency and jitter don't correspond because of the buffer? Can I monitor the buffer somehow to see if it ever runs out? How would you configure a system for the absolute lowest jitter for audio playback? Maybe nothing can be done besides choosing a low-jitter sound card and a playback app which uses a large buffer? - Grant
