Does a file with jitter keep the jitter when saved to a hard drive?

[Bruce B]

Bruce, I'm not familiar with the RAVENNA spec., having only read the Wiki page you linked. Do you know whether the spec. contains special provisions to minimize jitter, ideally, by enabling the receiving end to direct packet flow control? I wonder because, at first glance, the spec. appears intended for handling streaming media over IP, and so, may only address limiting the latency of network packet forwarding. Limiting packet latency, of course, doesn't necessarily mean minimizing jitter.

I don't have a clue about the spec. Here is another link where they go more in-depth. No mention of jitter reduction.

Pyramix-Ravenna

 

[amirm]

Amir, problem with point 3 is that it does not differentiate between UDP and TCP, in streaming UDP will be the carrier for the music data while TCP is used by the application-server/application management, so the programs will never crash but audio data is still not guaranteed, although one is more likely to hear a glitch than any other issue.
Just to add most programs relying upon program type data nearly always use TCP or something similar, again to stop any possible crashes as you rightly point out.
But they do handle streaming differently (which is a combination of both TCP and UDP).

If you are reading your files to play from another computer or a NAS, you are using TCP, not UDP. TCP will perform retransmissions and if it fails in doing so, you will know it as you will get connection error.

UDP is an option for web streaming but since it requires you to open a path on your firewall, it is not used these days. So even there, you have TCP (or HTTP over TCP) and hence the same reliable operation of all the data or error.

 

[amirm]

Actually, that is not correct.

It is actually . I have managed the development of computers and software systems for 30 years. This is my professional opinion, not conjecture . Let me know if anyone telling you otherwise has the credentials to know what they talking about.

I started the thread to clarify a question that occurred to me as to whether it was possible if jitter in data could be saved along with the data. I was reasonably sure the answer was no, but wanted some clarification and validation. It is my fault I then sidetracked the thread with the Ethernet question.

However, the HD question occurred to me in another discussion regarding whether or not different Ethernet cables can affect sound quality. My initial thought is no, but there is anecdotal data that it does, and AudioQuest and others are selling 'better' Ethernet cables for this issue.

Answering this was the very purpose of my post. I explained that there is a possibility of changing cables and such impacting the noise and or clock signal out of the PC. That is the *only* way it can impact what you hear. It is *impossible* for it to be what you are saying, i.e. jitter being introduced in digital domain and accumulating.

The above is not like other matters in audio. If that fundamental aspect is not true, you are invalidating the entire field of digital design. It is not even subject to arguing let alone be true .

I think everyone knows that our perceptions can manufacture huge amount of audible differences. I post a "review" recently where the person said cat5e and cat6 sounded different and the former was "grayer" sounding. Hundred bucks says the cat5e cable was gray and that is why he thought the analog output of the system was grayer .

All I am trying to do is come up with some possible scenarios or reasons where this is technically possible, even if unlikely. Since an Ethernet cable, like any other cable, will attenuate the signal, or be subject to interference from outside sources, it certainly seems reasonable that the signal can be degraded enough to result in the receiver circuitry adding jitter as the musical data is reconstructed. The question is can this jitter make it to the DAC, or will it be eliminated as it travels through the rest of the circuit.

I gave you that "possible scenario." But you keep going to an *impossible* scenario. Why? Is that other explanation not satisfactory enough? And to repeat, the different cable may radiate the ethernet signal differently and that somehow bleeding into the DAC.

No one can *prove* to you that the above is impossible. But we can prove that your hypothesis is impossible. We are not giving you that detail because it requires being an electrical engineer to under. But trust me, this dog don't hunt. :

My assumption is, it depends. It depends on the topology used, and the ancillary equipment.

I doubt if people are imagining it. That is the argument used by cable deniers for every other cable. It wasn't true then, and I suspect it will not be true in this case, or at least in some implementations.

The moment we doubt that, then we are down a path that is not objective. No matter what kind of subjectivist you are, you have to allow some margin of error in your perception. Recall that I went down this path regardless in my post. I assumed there was a difference and provided a *theory* of where it could be. That is where you want to go with this. Not going after the jitter in the digital bits. That argument simply does not wash.

 

[Orb]

If you are reading your files to play from another computer or a NAS, you are using TCP, not UDP. TCP will perform retransmissions and if it fails in doing so, you will know it as you will get connection error.

UDP is an option for web streaming but since it requires you to open a path on your firewall, it is not used these days. So even there, you have TCP (or HTTP over TCP) and hence the same reliable operation of all the data or error.

From my experience nearly all real time streaming audio/media protocols utilise RTP and RTCP or something very similar, so a player and server will have multiple connections; TCP orientated ones for the application management (status of file played/streamed,synch of server-player from an application-file perspective,etc) and UDP for the real-time actual media data streaming.
This is still the behaviour whether push or pull and with players/NAS from my experience, beyond web streaming (right of you to mention that I agree) as UDP is integral to IP just like TCP.

Cheers
Orb

 

[Vincent Kars]

From my experience nearly all real time streaming audio/media protocols utilise RTP and RTCP or something very similar, so a player and server will have multiple connections; TCP orientated ones for the application management (status of file played/streamed,synch of server-player from an application-file perspective,etc) and UDP for the real-time actual media data streaming.
This is still the behaviour whether push or pull and with players/NAS from my experience, beyond web streaming (right of you to mention that I agree) as UDP is integral to IP just like TCP.

Cheers
Orb

Probably technically completely correct but is it apt when talking sound quality?
Indeed when it is about streaming AV most of the time they decided to use an efficient but as a consequence not a strict protocol.
Be it UPD or USB in isochronous mode, no bit perfect transmission guaranteed and no retry.
Small wonder, as it is audio, the result literary disappears into the air so why being strict?

I don’t think perceived differences has anything to do with the bits.
Even when using a non-strict protocol, bit errors are rare and if they happen it is POP, Crackle, etc,
The kind of phenomenon making you run to the volume control.
Bit errors are rare and if they happen it is loud and clear.

 

[BlueFox]

It is actually . I have managed the development of computers and software systems for 30 years. This is my professional opinion, not conjecture . Let me know if anyone telling you otherwise has the credentials to know what they talking about.

First, thank you for your time and answers. However, to be clear my "that is not correct" answer was in regard to the statement The difference is there but they are forming the wrong hypothesis of the digital data gathering jitter while it remains "at rest" (stored digital data). This is what we are dealing with in this thread.

I was asking a question, not assuming it gathers jitter while stored. While I studied hard drives 25 years ago in school, I have not even thought about them until recently. I couldn't remember how the data was encoded for the drive, so I was wondering if it were even possible. Thanks for the clarification.

It is *impossible* for it to be what you are saying, i.e. jitter being introduced in digital domain and accumulating.

I do not believe I ever said that. If so, my apologies. However, in an earlier post I did quote another site, and was wondering if that were true.

“The digital audio data must make its way through the system over wires/traces and sometimes through buffers, such as the buffer to drive the S/PDIF cable. Each of these buffers has finite reaction times and imprecise detection of changing signal levels. What this means is that even though the signal may not have much jitter coming into the buffer, it may exit with additional jitter.”

http://www.positive-feedback.com/Issue43/jitter.htm

So, you are saying that is not possible. Fine. That's all I needed. Thanks.

 

[amirm]

I do not believe I ever said that. If so, my apologies. However, in an earlier post I did quote another site, and was wondering if that were true.

“The digital audio data must make its way through the system over wires/traces and sometimes through buffers, such as the buffer to drive the S/PDIF cable. Each of these buffers has finite reaction times and imprecise detection of changing signal levels. What this means is that even though the signal may not have much jitter coming into the buffer, it may exit with additional jitter.”

http://www.positive-feedback.com/Issue43/jitter.htm

This is true although he could have picked better words to describe it. What he is talking about is what happens inside the DAC that is placed remotely from the computer using S/PDIF. That is an entirely different game as to what happens inside the computer.

Inside the DAC we operate on clock that is extracted from the incoming S/PDIF signal. That signal has jitter and that jitter carries forward to the DAC (with some filtering) as an analog value. Its manifestation is likewise analog output of the DAC.

Inside the computer, the chain is digital, analog, and then digital. By analog I mean signals traveling over wires inside the computer. Jitter then does exist on that wire too. It is just that our target there is a digital value. That digital value has no room or ability to store or carry forward any analog values. We either have a "1" or "0" as the logic goes. So jitter gets eliminated at every step like that.

Ethernet cable is for the computer. The signal while traveling on the wire is analog and has jitter. However, just like the computer, the end points are digital and hence jitter is eliminated.

Same with using one kind of compute storage type versus another.

It is therefore wrong to talk about computer side of things as picking up jitter.

So, you are saying that is not possible. Fine. That's all I needed. Thanks.[/QUOTE]

 

[amirm]

From my experience nearly all real time streaming audio/media protocols utilise RTP and RTCP or something very similar, so a player and server will have multiple connections; TCP orientated ones for the application management (status of file played/streamed,synch of server-player from an application-file perspective,etc) and UDP for the real-time actual media data streaming.
This is still the behaviour whether push or pull and with players/NAS from my experience, beyond web streaming (right of you to mention that I agree) as UDP is integral to IP just like TCP.

Cheers
Orb

That is not the case Orb. The file sharing protocols in Windows for example run on top of TCP, not UDP. The word "streaming" is a misnomer in computer audio. There is no streaming as in the proper use of that term. What happens is simple file transfer. It is just that the player can start playing while the file is still being transferred to it. So technically it can be called "streaming" but proper streaming has bandwidth control and these mechanisms do not. That is the reason for RTP/RTSP, etc.

So please don't go by your knowledge of "streaming." This is not the same thing. By the way, even on the web today as I mentioned, UDP has mostly been deprecated because of the firewall issue I talked about.

 

[Audioseduction]

If you are reading your files to play from another computer or a NAS, you are using TCP, not UDP. TCP will perform retransmissions and if it fails in doing so, you will know it as you will get connection error.

UDP is an option for web streaming but since it requires you to open a path on your firewall, it is not used these days. So even there, you have TCP (or HTTP over TCP) and hence the same reliable operation of all the data or error.

100% correct! I set a shared folder on my NAS and point my JRiver server to it for the music files. My gigabit LAN transfers files at 100+ MB/s. I'm using TCP/IP protocol.

 

[Audioseduction]

By the way, I have JRiver set to process the entire track and store the entire processed track into memory before it starts transferring it to the DAC. So as soon as the music starts playing I can disconnect the NAS from the network and the track will still play it’s entirely. Extra delay for this function is like 1 second.

 

[BlueFox]

This is true although he could have picked better words to describe it. What he is talking about is what happens inside the DAC that is placed remotely from the computer using S/PDIF. That is an entirely different game as to what happens inside the computer.

Yes. The phrase "drive the S/PDIF cable" in "The digital audio data must make its way through the system over wires/traces and sometimes through buffers, such as the buffer to drive the S/PDIF cable." is confusing since "drive" implies it is on the computer side. I was thinking it would be the sound card, which gets its data from the computer over some bus.

 

[Orb]

That is not the case Orb. The file sharing protocols in Windows for example run on top of TCP, not UDP. The word "streaming" is a misnomer in computer audio. There is no streaming as in the proper use of that term. What happens is simple file transfer. It is just that the player can start playing while the file is still being transferred to it. So technically it can be called "streaming" but proper streaming has bandwidth control and these mechanisms do not. That is the reason for RTP/RTSP, etc.

So please don't go by your knowledge of "streaming" This is not the same thing. By the way, even on the web today as I mentioned, UDP has mostly been deprecated because of the firewall issue I talked about.

Heya Amir,
sorry for late response.
Yeah agree there is a difference between file sharing (such as SMB or CIFS) protocols and Audio/Video/Vid Conferencing streaming protocols, as we both mentioned problem with such a thread as this is the point of perspective/context and this thread has a pretty wide spectrum it can cover.
Maybe to help show what I mean and coming from; Apple Airplay uses RTP/RTCP/RTSP or its own proprietary version of this meaning that TCP is used for control of application-session but audio and video streaming is done using UDP, as shown here search for protocols I mention and multiple search Airplay as uses multiple ports: http://support.apple.com/kb/HT6175?viewlocale=en_US

Furthermore upnp is exactly the same with regards to streaming video or audio, where the control-session is handled via TCP and the audio or video data is streamed UDP.
Quoting one part of the upnp Connection Manager Service that fits with where I am coming from with regards to my perspective (appreciate this is not the only solution and comes back to how large the scope and challenge is for this thread):
Worth noting that in general with UPNP the and playback architecture you have the user interface/application/control via the Control Point layer and the AV Transport that is "Out of Band" transfer protocol layer.

5.1.2. Application to RTSP/RTP/UDP streaming
5.1.2.1. ProtocolInfo definition
Streaming data via RTSP is defined by the Internet standard Request For Comment document entitled Real Time Streaming Protocol. (http://www.ietf.org/rfc/rfc2326.txt).
The actual Audio/Video data packets are sent out-of-band with respect to RTSP. RTSP does not require a particular protocol for this. Since usually RTP (http://www.ietf.org/rfc/rfc1889.txt) over UDP is used, we will define the protocol for RTSP-based streams as rtsp-rtp-udp. This ensures that two ConnectionManagers that can send and receive RTSP also send and receive using the same Audio/Video data Connection protocol.
RTP packets contain a standardized 7-bit payload type identifier, see http://www.iana.org/assignments/rtp-parameters or http://www.ietf.org/rfc/rfc1890.txt Each payload type has a unique encoding name.
This payload type name is used as the “content-format” of the protocol info string. An example of protocol information for RTSP over RTP over UDP with MPEG video payload is: rtsp-rtp-udp:*:MPV:*

But this fits in with my own experience from a development/engineering/implementation perspective for Ethernet/wireless in general/etc and goes beyond just Airplay/upnp/etc.
That said I appreciate your own extensive experience with media at Microsoft, so we are probably looking at this from different view/context due to the scale of this thread and forums are pretty clumsy mechanism for trying to discuss this well bah
Late here so apologies for any mistakes will correct in morning.
Cheers
Orb

 

[Habanero Monk]

This thread sprouted from a knock down drag out thread where I insisted there is no Ethernet jitter to worry about in non-realtime systems like Windows. This is where a allowable assumption of the Ethernet cable is passing spec and equipment is operating normally. All in regards to audio playback.

That the next time jitter is of issue is the SP/DIF or USB bus. I've publicly invited other Polk forum members, especially Darque Knight who teaches EE, here to discuss in an environment where ownership doesn't allow such invective to be De rigueur. I think it's inherently dangerous the position that has been taken as it relates to the handing out of advice to the unawares.

I pointed out that you can even start playback of audio on a computer, pause it, disconnect the Ethernet cable, and then hit play and you will hear music.

I went so far as to make a proof of concept video showing a link aggregate group and Cisco switch with JRiver playing back while I disconnected and reconnected cables among 3 NIC's in the team:

 

[amirm]

Welcome to the forum Habanaro. It would be our pleasure to host the discussion here. Look forward to seeing what argument is being made.

 

[Habanero Monk]

Welcome to the forum Habanaro. It would be our pleasure to host the discussion here. Look forward to seeing what argument is being made.

Thanks. I hope some do come here and participate. I've seen many, just like Blue Fox, post a paper to some research that:

1. Doesn't have anything to do with the actual topic
2. Post papers that they are reading/interpreting incorrectly
3. In some instances posting papers or write ups that not only are they interpreting incorrectly but actually support what I've been telling them

The state of misunderstanding, that when I have pointed it out, has been met with typical meting out of the label of Troll. It's been a very Twilight Zone experience to say the least.

I've actually been harangued for posting a PDF with MD5 hash and asking the posters to download the PDF, install the Checksum application, generate an MD5 hash and post the hash either make fun of me for the process or tell me a PDF isn't an audio file.

 

[Habanero Monk]

Yes. The phrase "drive the S/PDIF cable" in "The digital audio data must make its way through the system over wires/traces and sometimes through buffers, such as the buffer to drive the S/PDIF cable." is confusing since "drive" implies it is on the computer side. I was thinking it would be the sound card, which gets its data from the computer over some bus.

I explained to you at PF, prior to the date of your above post, that you were confusing buffers and why you where confusing them.

 

[amirm]

Thanks. I hope some do come here and participate. I've seen many, just like Blue Fox, post a paper to some research that:

1. Doesn't have anything to do with the actual topic
2. Post papers that they are reading/interpreting incorrectly
3. In some instances posting papers or write ups that not only are they interpreting incorrectly but actually support what I've been telling them

The state of misunderstanding, that when I have pointed it out, has been met with typical meting out of the label of Troll. It's been a very Twilight Zone experience to say the least.

I've actually been harangued for posting a PDF with MD5 hash and asking the posters to download the PDF, install the Checksum application, generate an MD5 hash and post the hash either make fun of me for the process or tell me a PDF isn't an audio file.

Let's hope they do come.

For now, an easier way to show the problem does not exist is to use the binary comparison tool "comp" in Windows. You run it from a command prompt. It will perform a bit for bit comparison. Audio files copied will always pass such a test so there can't be any argument of noise getting injected into the target file.

 

[Habanero Monk]

I gave you that "possible scenario." But you keep going to an *impossible* scenario. Why? Is that other explanation not satisfactory enough? And to repeat, the different cable may radiate the ethernet signal differently and that somehow bleeding into the DAC.

Thanks for that tidbit. I went into this in detail with Bluefox and some others and here is the question I asked:

When you have an Ethernet cable of some tonal difference in the system and you are using one of the many popular players that exist out there that buffer the incoming data. Is the tonal difference there 100% of the time, or only when transmitting.

I also asked in follow up: If playing back from buffer and you disconnect the cable does the tonal difference go away?

T.I. wrote an engineering application note where they even mentioned single ended connectivity in the network and that was the AC adapter for the switch.

I went so far as to order a $350 AudioQuest Ethernet cable and certified BJC CAT5e and CAT6. I'll be darned if I could hear a difference. I tentatively have a September 27th date with a forum member that insist they can hear the difference, and with an 86% probability pick it out in 30 toss of the dice. It's been rescheduled a few times by the participant but hoping it comes to actualization.

 

[Habanero Monk]

Let's hope they do come.

For now, an easier way to show the problem does not exist is to use the binary comparison tool "comp" in Windows. You run it from a command prompt. It will perform a bit for bit comparison. Audio files copied will always pass such a test so there can't be any argument of noise getting injected into the target file.

That was tried along with a *Nix tool offered up also. I offered to turn up an Ubuntu server on Digital Ocean and host some music files (Public Domain or Creative Commons or other such license) and allow members to both FTP and even stream and do some comparison with other members, do this in a very broadcast and transparent way.

It degenerated into the typical slamming and name calling. Stupidity is ignorance willingly left uncorrected.

 

[Habanero Monk]

Just so you know what was being dealt with (and you can't tell them any different, I tried and was slammed yet again)

Darque Knight introduced fast transient noise and another member decided to run with it.