You are not logged in. Please login or register.
RME User Forum → FireWire & USB series → Jitter <1ns
Just out of curiosity:
Why in the PCI audio interfaces it is specified that Jitter is <1ns while there is no mention to that in the Firewire or USB cards?
Thanks.
Carlos
It is, at several places.
In the web the word jitter appears in several places, but I can't find where is the Jitter <1ns statement present in internal cards:
https://archiv.rme-audio.de/download/fface800_e.pdf
Yes it is in the manual.
? Low Jitter Design: < 1 ns in PLL mode, all inputs
? Internal clock: 800 ps Jitter, Random Spread Spectrum
Interesting the different Jitter specifications:
HDSPe AIO and HDSP 9632:
Super low jitter design: < 1 ns in all clock modes
DIGI96/8 PAD:
Super low jitter design: < 1 ns in PLL mode (44.1 kHz, optical in)
Do all have the same jitter when playing audio (without any input used)?
Regards.
The PAD does not have such a spec. This value is only valid for SPDIF input mode under perfect conditions, as the card has no active jitter reduction (no SteadyClock).
All products with SteadyClock basically have the same jitter specs.
Ok. So all that jitter specifications in all cards (<1ns) refers to jitter that can come from input but not to the "hypothetical jitter" that could come from playing from hard disk.
Is that correct?
Thanks.
Hard Disk streaming does not cause jitter - the audio clock / crystal and associated PLL's cause jitter.
It's generally accepted that a descent internal clock is the best way to clock a unit if possible. SteadyClock should adequately take care of any external sync needs.
Sorry for the confusion, I though the "Jitter <1ns" was a specification for playing as well.
Well I believe that professionals use RME for DSP, mixing and recording, not reproduction.
So SteadyClock takes care of that needs, with active supression of jitter form an external clock. But jitter is present everywhere, as well in reproduction.
I don't know if they don't hear to it, don't care about it or don't know how to remove it to a point nobody hear it.
I use RME DIGI96/8 PAD only to play audio cause its low hardware jitter and I was interested to know if a new PCIe HDSP AIO or Fireface 800 could improve that aspect cause still there is a lot of jitter somewhere. But I believe RME sound engineers do the best they can do strictly adhering to the current interfaces and platforms they must develop for.
Regards.
Carlos
Hey carlos, can you explain the "here is a lot of jitter somewhere" further please ?
And what are you using to measure the jitter? (Besides your ears)?
I don't use any kind of instrumentation to measure jitter. For me it is something like people that become sick smelling some things.
Hey carlos, can you explain the "here is a lot of jitter somewhere" further please ?
Well, from what I hear the problem is in the buffer change (you can appreciate clearly at 46ms+ latencies).
I don't use latencies above 1.5ms (64 samples), but what exactly would you say you are hearing at these high buffers in the 2048 and 4096 sample range? And are you running buffers this high because you need the extra CPU power for mixing? Do you hear the same issues using WDM - or only ASIO? Just curious...
Well, I hear the sound compressed and noisy. With 23ms the sound is not as deep as with 46ms. Take in mind that with 46ms buffer you can play a 40Hz sound for 20ms. I know that changing buffer affect sound as well with the Fireface, but I just don't know if the firewire interface has the same limitations that PCI/PCIe has (async or sync?) apart from higher bus bandwidth.
I run highest possible buffer cause I can reach lower frequencies playing audio. With WDM may be it is more dynamic but have the same jitter overall.
There is neither any difference in audio quality between different latency settings or drivers, nor does this have anything to do with "jitter". And higher buffer settings don't "reach lower frequencies playing audio"...
Maybe you could tell us what exactly ou mean when you say "jitter"...
Regards
Daniel Fuchs
RME
With "jitter" I mean the audible sampling deviation while being bit perfect:
[----- Buffer 1 -----] [----- Buffer 2 -----][----- Buffer 3 -----] [----- Buffer 4 -----]
These short deviations results in compressed sound.
Jitter takes place between samples, not buffers. And it does not result in "compressed" sound...
I'm afraid I'm out of the discussion at this point, and I would like to delete it eventually, because it is OT here...
Regards
Daniel Fuchs
RME
Yes, jitter takes place between samples, but the deviation I talk about is between the last sample of Buffer x and the first sample of Buffer x+1.
I didn't want to enter into the classic audiophile discussion cause I believe it has no sense here. RME designers are sound engineers and computer engineers, not audiophiles. People that work with that they can measure don't have to believe people that hear things that are not measured.
I think RME has the lowest hardware jitter and that is why I can detect so easily this "unknown type of jitter" (that, for example, is lower when you set Realtime priority to your favourite audio application).
But sorry I wont reply more at this discussion cause it is off topic.
Regards.
"With 23ms the sound is not as deep as with 46ms."
This, I can relate to, I have heard this complaint a few times before.
As I see it, it has to do with small glitches, the lower the latency, the higher the risk it can happen.
It can happen on some systems, and not on others, standard daw optimization, IRQs etc apply.
Carlos: The jitter that you describe does not exist. If a buffer is too late to be played you will loose some samples, means you hear a click or drop out. If the buffer is ready to be played it will be played with the clock of the card, means the jitter then is identical to the sample jitter.
Ok. The fact is that WaveLab reports no dropouts, and I recorded the output to confirm that the data was identical as reported by WaveLab.
It is reported across the globe that there is something going on, but still it is not clear at what stage of the chain it is produced.
Could it be possible that the source power (5V) of the sound card could be interfered by other means, and then affecting the output sample timing?
The thing is that I know of a Fireface 800 powered by a DC to AC battery converter that has a similar behaviour.
I was also wondering, what the specification "Internal clock: 800 ps Jitter, Random Spread Spectrum" (FF UFX) exactly means.
Does it mean, that for the internal clock there was jitter added in order to distribute potential systematic jitter components over a broader frequency range?
If its's the internal clock, I assume, that the jitter is added in DA-conversion as well?
This Tech-info does not shed light on this topic, since this article seems to refer to a "SteadyClock" without the addition of jitter. Right?
http://www.rme-audio.de/support_techinf … teadyclock
Any clarifications appreciated
> If its's the internal clock, I assume, that the jitter is added in DA-conversion as well?
We do not add 'jitter' to the DA conversion. Anyway, the statement says exactly what it says, you got it right, and I don't see where it needs clarification then. Further technical details are not disclosed, sorry.
I got an email notification, that "wendicate " has responded to this thread. But there's no new post here.
--> Has this post been removed?
Regards
No such user here...
Regards
Daniel Fuchs
RME
Yes, that was spammer.
RME User Forum → FireWire & USB series → Jitter <1ns
Powered by PunBB, supported by Informer Technologies, Inc.