Re: [proaudio] Real-time for audio

[Mark Knecht <markknecht@xxxxxxxxx>]

On Mon, May 10, 2010 at 1:50 PM, Grant <emailgrant@xxxxxxxxx> wrote:
>> Jitter and latency are completely unrelated generically. Latency is
>> just delay caused by any source. It might be Jack cycles, software
>> delays, etc. Latency is always a positive number and always delays the
>> arrival of your data at the destination.
>>
>> Jitter, on the other hand, is a _random_ change in the timing of each
>> clock cycle. It's caused by physical processes, such as variations in
>> how the crystal source and PLLs in your clock decide it's time to
>> switch between 1 and 0 or due to cabling in a noisy environment.
>> Typical consumer grade crystals might have a jitter or 200 PPM.
>> Industrial grade crystals might be spec'ed at 50 PPM and then further
>> screened to look for those with even less jitter. Still, if you work
>> out what 200PPM means in terms of data delivery is ain't much, but is
>> possibly audible.
>>
>> None the less and in general, for any system with a specific jitter I
>> can delay data and create more latency any time I want, therefore
>> jitter and latency are orthogonal.
>
> The quote I posted before about rtirq references both latency and
> jitter with regard to the software.  That makes me think real-time
> software can reduce jitter.  Is that not true?  Or maybe I'm
> misunderstanding your comment above?
>
> "With a measured worst case latency of five microseconds and with a
> typical jitter below one microsecond at an interrupt period of up to
> 100 kHz an rtirq-enhanced linux kernel may be usable for a broad range
> of hard real time control loop applications."
>
> http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/The-Linux-real-time-interrupt-patch/
>

OK - but that jitter doesn't have anything to do with sound being
produced. (As long as it doesn't create an xrun which it could I
suppose if it jumped WAY beyond 1 microsecond for some reason) The
only jitter that would effect the conversion of data to audio is the
sound card crystal's jitter which is what I was talking about.

Again, this all comes back to Jack delivering data to a sound card
FIFO and then the FIFO running that data through a D/A converter to
drive your audio equipment. The interrupt jitter would be something
that might effect a complete Jack cycle, but then you get an xrun and
we know we can hear those if the FIFO runs empty. However if you are
delivering Jack data packets every 5mS, and then one goes out at 6mS
and then next one is back on schedule so it goes out at 4mS then as
long as the sound card FIFO doesn't run empty you never know there's a
problem.

>> Yes, but IIRC the FLAC encoder has a flag to do lossy compression. I
>> could be wrong about that though and it's not important in this
>> conversation. My only point was to say I understand why a wave file
>> and an mp3 might be perceived as sounding different. I do not
>> understand why wave and FLAC should result in different bit streams
>> and I contend (clearly as this is maybe the 3rd time I've said it) ;-)
>> if the bit streams are identical and the equipment used to play them
>> is one system then the sound MUST be identical.
>
> But the bit streams can be identical and the sound can be audibly
> different because of jitter, right?  Couldn't WAV vs. FLAC playback
> conceivably produce difference levels of jitter?
>
> - Grant

Well, I suppose there is less data on disk with FLAC because it's
compressed, so there's less work for the system to do reading the data
from disk. However then FLAC has to be decompressed so the CPU has to
do more work to get it ready to go out to the sound card. However if
the disk reader and FLAC decoder are inside of a properly designed
Jack apps then the data is made ready and sent to the card and what's
sent to the card is identical, again because if the bit streams aren't
the same then this whole logic all falls apart.

If the system is underpowered and the disks or CPU usage cause huge
amounts of jitter in the interrupt timing then possibly it could end
up somehow, in the worst case, causing a problem, but I suspect that
would be really, really bad audio and not just some airy fairy 'WAV
sounds better then FLAC sounds better then WAV' comment. I don't
understand how that could occur and not cause an xrun because the
sound data path system timing is controlled by the sound card and not
by the system timers.

However, if the properly designed Jack app cannot get disk data in
time then you get an xrun and if it cannot decode the FLAC data in
time again you get an xrun so either way you have an indication that
those events happened. Here we're trying to determine is a properly
operating system using Jack and creating no xruns and playing FLAC or
WAV could sound different. I contend they cannot.

I hope it's clear I'm not arguing with you! I'm curious myself about
these things. I love high end audio. (With apologies to Florian!) ;-)

Cheers,
Mark