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

[Mark Knecht <markknecht@xxxxxxxxx>]

On Tue, Dec 29, 2009 at 8:11 AM, Grant <emailgrant@xxxxxxxxx> wrote:
>> <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?

No correlation between jitter and latency. They are different animals
completely. A signal can be delayed by days and have no jitter, or can
be delayed very little time and have lots of jitter.

In that model 'jitter' is the cycle-to-cycle variation of the clock in
the Wavelength Proton USB DAC. Generally crystals in consumer
equipment might have a 100-200 ppm variation and that's what causes
the 'jitter'. Studio level equipment might have 20-50 ppm variations.

In a pure *playback* application 'latency' doesn't make much
difference. Other than when you first start your playback does it
matter that the sound file comes off the dosk and is heard in 5mS or
1S? Not really. Once the music is playing it doesn't matter.

Of course, if you're doing audio/video where you require voice to be
in sync with the picture then you want to keep the latency low, but
even at .25S you might not 'see' it.

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

You've got it right. Good quality equipment is where you start. Using
Jack allows you to monitor whether the buffers ever run dry. Smaller
buffers equate to lower latency but have nothing to do with jitter. If
I was going to purchase hardware I would look for two main
characteristics in semi-pro and above solutions:

1) DAC external to the PC - keeps internal PC electrical noise from
effecting the D/A conversion. Technically your USB device meets this
requirement.

2) Sound cards with a clock input - they all have crystals, but if you
can drive the device with a Word Clock or ADAT clock you can get much
lower jitter - basically as good as you want to pay for. Check out RME
cards for some great solutions in this area, but also ProSonus and
lots of other studio level companies now have semi-pro/consumer
devices that have these features.

Of course, getting the best possible D/A chip inside your device helps also....

One other thing you might want to explore as you investigate the
rt-sources kernel is that *disk* latency can actually be worse unless
you grant your audio driver higher priority than default. For
recording I use 1394 audio drives, not because they are faster (they
are) but because I know that the only data on them is audio and they
have their own driver in the Linux stack. I can grant the 1394 driver
higher RT priority and know that it will have no effect on system
operation in general. That way things like swap space access (yuck...)
and cron jobs, etc., don't get in the way of me moving data on and off
disk.

As always, ask any questions you might be interested in.

Cheers,
Mark