Re: [proaudio] Real-Time for audio playback?

[Grant <emailgrant@xxxxxxxxx>]

> <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