Re: [proaudio] Real-time for audio |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/proaudio Archives
]
- To: proaudio@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [proaudio] Real-time for audio
- From: Mark Knecht <markknecht@xxxxxxxxx>
- Date: Mon, 10 May 2010 13:34:16 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4vemkc1AzxelxtXymxHfX0Axz3vQN0s8ig7kp6/NfYc=; b=SxIDkCo/ffAPE2E6cGYwQIIiNt3luw97bAeej/EfShAcvWrMmiQDb1xWmrVg3T7Blz U5vOc4sCfyYFjvTaBvxK9/3cP9RyxG16HOty99gJzVKxHHB3UUgtqdgLHqcflvPtMSi7 8tsFyN/ROGtWhAvkvK7a4j9qHqf+a3d4gVfyM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=I+rIRdauRbkYiEdWRq4sh5E+MeiN0SBIplDPHDk6zvVGSzIw3XsGircbiedEriqb5Q H8vnSS0N0WwhoZWPpNkWdSDLRMharV+gMpHA7PVn4bvQXIzssS9Qrvm1Km72Wv6qQZWk p5aqx+dQSXKdrlpE4VCfYwnvDQM2RkOrKgoKQ=
On Mon, May 10, 2010 at 1:06 PM, Grant <emailgrant@xxxxxxxxx> wrote:
>> <SNIP>
>>> It sounds like real-time lowers both latency and jitter. Jitter
>>> absolutely affects sound quality. I wonder if jitter could be the
>>> cause of all this.
>>
>> If a system is exhibiting severe jitter, possibly more typical in
>> consumer level sound cards and assuming that's the sort of card you
>> are using, then possibly the real-time kernel helps. I wouldn't argue
>> that at all.
>
> Do you have a good concept of how latency and jitter are related? I'd
> like to know more about that.
>
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.
<SNIP>
>
>> As for the wave vs FLAC thing one must prove that we're talking apples
>> to apples. Wave is lossless by definition. (As far as I know.) It's
>> just 16 or 24-bit words bits packed into a file. FLAC may or may not
>> be lossless depending on how it's encoded. If it's lossless, and if
>> it's encoded from the exact same original data then the two formats
>> should produce exactly the bit stream and if the bit streams are
>> identical, and if they are delivered to exactly the same reproduction
>> hardware at the same settings on the same day at the same time then
>> they are going to produce the same sound.
>
> But one could conceivably produce higher latency and/or jitter than
> the other, no? Also FLAC is lossless by definition. That's what the
> L stands for. :)
>
> - Grant
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.
Cheers,
Mark