Thoughts around a Lejonklou Streamer

Conversations about Lejonklou Products and this Forum

Moderator: Staff

User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: The New Lejonklou Streamer

Post by doze84 »

Music Lover wrote:
doze84 wrote:
lejonklou wrote:We've gone much deeper into this than you think, doze84. In my opinion,

Data integrity is never a problem.
Optical transmission adds more problems than it solves.
Asynchronous USB is not particularity good.

It's not that difficult to get a nice sound. It's when trying to arrive at something really musical that the problems and inconsistencies begin. And most of the really important factors are in the domain that you just labeled "impossible". Hence the massive challenge.
What I meant to say was, that. " If every bit, gets to the other side with help of checksums, it's buffered correctly, and an optical cable is used, it's impossible that the feeder has any say in the matter." And I hope you agree with that or I'll soon do start to questions your sanity:D:D

The problem I guess, is that this has never been tested..
It was tested by me and Linnofil 2007, when Linn released the KDS.

And when we described our findings on various Linn forums, we were indeed labelled as insane.
Today, some of our statements seems accepted. That's good. Because it's facts.

I'm talking about optical usb here with correctly implemented error correction, not spdif or ethernet:)

Also there seems to be some confusion around the word async. It seems that there's an old variant that is unidirectional without re sending of lost packets(like spdif). That type is not bit perfect. Cambridge is arguing the new type that they use is bit perfect. I'm trying to figure out if it really is, or if it's a sales term. But I don't have time to dig into how the drivers are coded on e.g the Henry open-source dac(which claims to be async bit perfect).

Also when it comes to streaming there might be some preset rules here that has to be followed, that can make things less flexible. Maybe for example, Qubose and Spotify only let's out the data in a constant rate. Then a fail safe buffer might need a few seconds of buffering or so to assure new packets will reach the destination, and not get dropped, to achieve bit perfection. Noisy power supply in the computer can also cause more losses of packets, and require more re-sending, and that needs to have time to happen before the packets are written to the buffer and released to the clock/dac.
matthias
Very active member
Very active member
Posts: 2092
Joined: 2007-12-25 16:47
Location: Germany

Re: The New Lejonklou Streamer

Post by matthias »

Music Lover wrote:
matthias wrote: Interesting that a lot of music enthusiasts prefer a very good cd transport to a NAS.
Well, normally they use crap switch, crap cables, crap NAS, crap ripping etc =everything that's important.
Yes, some of them use crap, but not all. I do not think AS use crap in this review:

http://www.hifiplus.com/articles/dcs-ro ... ck/?page=3

Matt
Matt

MBP / Exposure pre + power (both modified) / JBL3677
User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: The New Lejonklou Streamer

Post by doze84 »

lejonklou wrote:
Regarding your other suggestions, do they all consist of a digital source feeding a DAC? If so, what's important to know is that in those scenarios, the digital source is where ALL the magic lies. Not in the DAC. In fact, if you have two different computers as digital sources and decide to find the ultimate DAC for them, you might find that one DAC sounds best with the first computer while another DAC sounds best with the second computer. And when you compare the combinations, you'll find it's the computer that sets the limits. And this happens more or less regardless of in how you transfer the signal from the computer to the DAC.

The NAS still rules if your aim is the best sound possible, but I agree that it's neither fun nor practical and they will most likely become rare in the future. But they do provide a key to performance because they are the point where static data is converted to a stream, by adding a clock. Bit perfect is no problem, correct data isn't (except you can still hunt for the best version of the file as in different mixes or rips of CDs), but when it starts moving, the challenge begins.
Now I'm starting to understand what you say. Sorry for not reading it throughly enough, it was so out of my imagination that it worked like this.

I feel understanding this is critical, so please correct me if I have misunderstood any part of this.

What you're saying is, that when a song for example in fubar is started on the nas, the nas also starts a clock with the signal, that make timestamps in the bitstream?

The PCM audio and stamps are sent togeather as one stream of packets, over tcp/ip into the buffer of the DS and continues to the dac, even if the buffer creates a short pause in the stream..

In other words, the tcp/ip packets looks different from different computers/nase's playing the exact same file.

This is a whole another story.

What solutions have you thought of to this?

I imagine this must be hi-jacked and tapped between the decoding of file codec and the conversion to PCM signal. Probably by patching tidal, spotify and fubar and windows and the whole world:D

Would any of these alternatives work?

1) Coding a virtual sound card that lets you chose a masterclock on the network.(Lejonklou DS)
https://www.audinate.com/products/softw ... -soundcard
(probably too late in the chain)
2) Modify an open source music player that choses another format than PCM to stream in..
Spannko
Very active member
Very active member
Posts: 2292
Joined: 2008-01-24 21:46
Location: North East of The Black Country, UK

Re: The New Lejonklou Streamer

Post by Spannko »

When I bought my Melco I think they were the only specialist HiFi NAS’s available. Now there are several alternatives I think it would be good to compare them all.
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

doze84 wrote:It sounds like you're saying that the nas adds a clock. But to my understanding nas uses Ethernet and TCP/IP to a DS and resends packets that gets errors, even when streaming from e.g Tidal. Hence this clock has no impact on the chain.
As soon as data starts moving, a clock is added. No clock is perfect, they all have inconsistencies - jitter. These inconsistencies will leave a trace - sometimes tiny, sometimes significant - in the final analogue audio that you listen to. This depite the old clocks no longer being present when the data reaches the DAC chip.

So while you are right that the previous clocks don’t impact the data being transferred over TCP/IP, they do in practice leave traces of jitter that survive the trip over the Ethernet (and even the Internet) into the final conversion to analogue. I would rather say that MOST clocks involved in the transfer of data have an impact on the musical result.

One solution could be to somehow “wash” the data. Buffering and reclocking, perhaps? In practice, you will still hear traces of the musical impact of previous clocks. The washing is not only imperfect, it also adds a new character of its own. So far I haven’t found any way of washing the data that works well in practice. But it sure would be extremely useful if it worked!

Another solution is to make the transfer of data as simple as possible, with very few and precise clocks. This works well. But then the odd intrinsic qualities that I mentioned in a previous post make their appearance. They seem to decide that some designs just sound better than others, even though it contradicts our theories. Like inserting additional, seemingly unnecessary steps into the middle of a simple and optimised chain.

There’s simply so much that I don’t understand.
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

doze84 wrote:What you're saying is, that when a song for example in fubar is started on the nas, the nas also starts a clock with the signal, that make timestamps in the bitstream?

The PCM audio and stamps are sent togeather as one stream of packets, over tcp/ip into the buffer of the DS and continues to the dac, even if the buffer creates a short pause in the stream.
No. But if you replace the words “timestamps” and “stamps” with the scientifically imprecise word “ripples”, your statements above are true, when judged from what you hear when listening to the audio after the conversion to analogue.

I don’t have intimate knowledge of TCP/IP and am unsure whether the packets will be identical from different computers and NASes. Perhaps someone here can tell us about the structure of the packets. But there are no timestamps and no information in the data about the high frequency clocks (and their inaccuracies) that are involved in the making of the packages.
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

I hope that the original poster will forgive me for renaming this topic. The original was “The New Lejonklou Streamer” and was probably appropriate at the time, but as the project is currently awaiting a blood transfusion, “Thoughts around a Lejonklou Streamer” seemed more fitting. /Fredrik
User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by doze84 »

Ok, I kind of forgot how a NAS worked, I was mostly thinking out of a song cast perspective, as if the NAS was a pc ..

Does Linn us upnp to stream files over to the DS, or do they just use uPNP to locate the files?
It says "control" on the web page.

If it is like you say, this big impact in picking NAS, there must be something seriously broken in this approach, that probably opens a stream/clock on the nas side or something.

I thought that the software in the Linn DS went to a folder shared from the NAS, took the whole file with tcp/ip and stuffed it into a ram memory, and then played it. But maybe not.

I stick to my approach that, if a NAS affects the musical performance, other than through electrical noise, the whole implementation is wrong. And must be avoided at any cost:) Maybe the error is in the upnp transfer protocol.

I'm brainstorming here, but I think you need to write your own transfer protocol. If you can't fix the issues with upnp.

It seems as soon as something is moving we get problems, like you said.

And two solution to this is could be:
1) Writing your own code that either fetches the hole file/playlist, stuffs it into a 8gb ram memory on the Dac. This completely removes the impact of the NAS. You can even have a isolated switches, that removes the connection to ethernetcable as soon as the files are over.

2) The dac-side, finds the file, starts loading the file into into a byte-array, that is 100% free of any timing. It just does it as fast as it can, and then starts the playback stream right before the dac-side has filled up 10mb of data is in the array..

Like this approach:
https://docs.microsoft.com/en-us/previo ... studio.41)

This works on wav, but I don't know if it works on flac.

I'm not sure if I know what I'm talking about, but if I manage to spark another idea in someones head, I'm happy:)
Charlie1
Very active member
Very active member
Posts: 4831
Joined: 2007-12-11 00:30
Location: UK

Re: Thoughts around a Lejonklou Streamer

Post by Charlie1 »

lejonklou wrote:I don’t have intimate knowledge of TCP/IP and am unsure whether the packets will be identical from different computers and NASes. Perhaps someone here can tell us about the structure of the packets. But there are no timestamps and no information in the data about the high frequency clocks (and their inaccuracies) that are involved in the making of the packages.
Sorry this turned into a monster post. You'll probably tell me it doesn't really answer the question anyway :) But, never know, might turn out useful.

TCP segments (layer-4) are usually no larger than 1460 Bytes, which is the size of the data payload within a 1500 Byte IP packet (layer-3). A 1500 Byte packet is usually the largest size packet supported by a network. Keeping the TCP MSS (max segment size) down to 1460 helps prevent the segment from being fragmented into multiple chunks of data. Whilst the TCP segment is most likely a chopped up piece of application (layer-7) data anyway, avoiding unnecessary fragmentation is simply more efficient, thereby increasing throughput and reducing CPU load on the devices that must, otherwise, temporarily store the fragments. Real-time data, such as voice and video, is normally sent via UDP, not TCP, so avoiding fragmentation is less about minimising latency and jitter.

The 1500 Byte IP Packet will fit into a standard Ethernet frame (layer-2). Frame sizes vary depending upon the underlying headers in use, but are typically 1518-1522 Bytes.

Some network devices support jumbo Ethernet frames (layer-2) of 9,000+ bytes, thereby encapsulating much larger IP packets without causing fragmentation. Obviously, a larger IP packet can hold a larger TCP segment. This approach is more likely found in a data centre where 40G/100G fabrics can make light work of these larger frame sizes and benefit from slightly greater efficiency. However, I'm not sure how common it is these days since every server would need to be configured with same jumbo size, and it would lead to fragmentation whenever communicating with devices outside the data centre. I think it's perhaps more common on back-end storage networks.

Sometimes, the IP packet data payload must be squeezed below 1460 Bytes. This happens when protocols, such as PPPoE (layer-2) and IPsec (layer-3) are used because they require additional headers.

Sometimes, you'll see a laptop set with a TCP MSS figure of approximately 1300 Bytes. Not 100% sure, but I think this is a manufacture setting, rather than a Windows or Mac OS setting. It helps the endpoint device account for any unforeseen IP Packet or Ethernet frame overheads and thereby avoid any fragmentation of the TCP segment. Bear in mind that most network communications require multiple hops, so the endpoint will not know there is an IPsec tunnel, for example, somewhere along the path between itself and the destination device. So this approach helps cover this off, just in case, whilst still maintaining a reasonably high TCP segment size.

An alternative approach can be configured on some network switches and routers. The network device can be configured to automatically re-negotiate the client TCP MSS whenever the switch knows that its outbound interface will not support the TCP MSS figure used by the endpoint client. One example is when PPPoE is used on an outbound Broadband interface of a domestic router. PPPoE requires an 8-byte header to be squeezed into the 1500 Byte payload of the frame, thus leaving just 1492 Bytes for the entire IP packet, thus reducing the IP packet data payload to 1452 Bytes. In this situation, the router would tell the endpoint to start using slightly smaller 1452 Byte TCP segments.

The final approach is called Path MTU Discovery, or pMTUd. This is a dynamic way to ascertain the maximum IP packet size (MTU) across all hops between source to destination. However, like fixing a laptop's TCP MSS, it must be configured on each endpoint so is not really a scaleable solution.

As I understand it, Ethernet based networks don't use any clocking. Time stamps are used to help measure latency and report on round-trip time (RTT) of data but that's all. The only time I recall clocking with IP networks was on E1/ISDN circuits which use Time Division Multiplexing and one end would be configured as the clock. I worked on ATM and Frame Relay as well but too long ago to recall whether they used any clocking.

Fredrik, why are there multiple clocks in the process? I just assumed it was all 'data' until it got to the digital streamer. It almost sounds like the NAS is playing the music to the streamer.

Just out of interest, anyone know what size IP packets the Linn streamers typically use?
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

doze84 wrote:I stick to my approach that, if a NAS affects the musical performance, other than through electrical noise, the whole implementation is wrong.
It's easy to jump to that conclusion, but there are challenges with all digital systems. The problems associated with USB are very similar.
doze84 wrote:I'm brainstorming here, but I think you need to write your own transfer protocol. If you can't fix the issues with upnp.
Already done. Works better but doesn't solve all problems. And using a custom protocol can result in massive amounts of work, trying to keep it bug free and working with lots of hardware.
doze84 wrote:And two solution to this is could be:
1) Writing your own code that either fetches the hole file/playlist, stuffs it into a 8gb ram memory on the Dac. This completely removes the impact of the NAS. You can even have a isolated switches, that removes the connection to ethernetcable as soon as the files are over.

2) The dac-side, finds the file, starts loading the file into into a byte-array, that is 100% free of any timing. It just does it as fast as it can, and then starts the playback stream right before the dac-side has filled up 10mb of data is in the array..
Number one we did. Unfortunately, the design with requesting the data from a NAS, passing a switch, sounds better. I think a solution could be to design the hardware in-house in much greater detail, tuning every parameter for optimal musicality. But this is too big an undertaking. I know a guy who can write his own machine code for how a processor reads, writes and shuffles data from memory chips. But that would rule out a lot of standard components and become extremely specialised. It would be like designing your own computer from scratch. Very complicated and risky. Technology moves so fast and parts are being discontinued in a matter of months.

Number two I don't quite understand. It sounds like a standard solution with a very small buffer to me? There is to my knowledge nothing that is "100% free of any timing (issues/inaccuracies)". There is nothing that's perfect, digital signals all have an analogue representation and as such are never perfect.

I really appreciate your ideas, many thanks!
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

Charlie1 wrote:Fredrik, why are there multiple clocks in the process? I just assumed it was all 'data' until it got to the digital streamer.
Thank you for the big chunk of facts, Charlie!

Data needs a clock to move around, doesn't it? Otherwise how do you read and write it?
User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by doze84 »

lejonklou wrote: It's easy to jump to that conclusion, but there are challenges with all digital systems. The problems associated with USB are very similar.
Before we start looking outside of science, and logic, I'm sure there are more stones to be turned inside.
That Linnofils lightbuls affects his sound, I'm sure that can be explained by science and noise beeing refed into the powerline. But you can't have ripples in a bitperfect stream. Because then it's not bit-perfect any more. This is easy to check with checksums or hashes, If it's not electrical interference from the NAS, it is data-loss somewhere. I think data integrity is a big problem.

The problem with USB dac's is that they start a PCM stream at the motherboard, and then tries to preserve that stream all the way to the dac. Which is impossible, when using the unstable streamer capability of usb.

Synchronous dac's, tries to slave the dac clock to the motherboard clock.
Classical asynchronous dac's tries to slave the motherboard clock to the dac masterclock. That clock can't follow very good.

Therefore, any good sounding usb-dac, needs to use a file transfer protocol, before starting any clock.
I don't know if that has been implemented correctly by HRT, HENRY and Cambridge.

If they are starting, a PCM stream at the computer, then they are not bit perfect, since there is clock information being sent in/with the stream.

This is why I still think an USB dac can be made to sound better than a Klimax DS.
Already done. Works better but doesn't solve all problems. And using a custom protocol can result in massive amounts of work, trying to keep it bug free and working with lots of hardware.
I guess most NAS'es support FTP, and that can be used?
What the software can do is, connecting to the ftp, create a hash of the file before starting to load it over and after the transfer, create a new hash. But I don't think this should be needed, since ftp already is using TCP/ip. And TCP/IP = bit perfect.


Number one we did. Unfortunately, the design with requesting the data from a NAS, passing a switch, sounds better. I think a solution could be to design the hardware in-house in much greater detail, tuning every parameter for optimal musicality. But this is too big an undertaking. I know a guy who can write his own machine code for how a processor reads, writes and shuffles data from memory chips. But that would rule out a lot of standard components and become extremely specialised. It would be like designing your own computer from scratch. Very complicated and risky. Technology moves so fast and parts are being discontinued in a matter of months.
Here questions must be asked. Why does it sound better streaming the data. It probably has to do with the design of the post-transfer pre-dac hardware/software and not the the choice of solution.
But I would much rather see a streaming solution over a file transfer protocol, if possible, than a downloading solution that takes forever:D
Number two I don't quite understand. It sounds like a standard solution with a very small buffer to me? There is to my knowledge nothing that is "100% free of any timing (issues/inaccuracies)". There is nothing that's perfect, digital signals all have an analogue representation and as such are never perfect.
I'm stil not sure how uPNP does it. It seems to create a stream with RTSP and transfer it with RTP at the NAS, which is a real-time streaming, time stamping protcol without recovery of lost packets. Than it's not bitperfect in other words. But some linn links, seeem to sugest uPNP uses tcp/ip. I'm not sure. Maybe it's rtp inside of tcp/ip:D

But what I meant here, was to use a filetransferprotcol(tcp/ip), to fill arrays byte by byte, for every packet that has been received. This prevents any clocking to start, that i suspect RTSP/RTP do. And since TCP/IP asssures packets to be recived in the right orders, I suspect this would be an error free way of doing streaming.


I just found this on the internet. RAAT. Have you looked into it? It requires no codec supports on the dac-side
and it doesn't allow a clock to be started on the source.
If Spotify and others implement this into their PC-software. PC is going to be gold again!
Unfortunately, both Airplay and Songcast have two fundamental problems related to sound quality. One is limited format support (no DSD) and that the clock is driven by the source, instead of the receiver (the endpoint surely will have the best crystal in the room).

We plan to solve these problems with the Roon Advanced Audio Transport (RAAT) protocol. The 20+ manufacturers we’ve spoken to, including Bel Canto that you mention, are loving our solution. It puts the audio in their hands, and the experience control in ours. It compromises nothing for quality, and puts very little burden on the manufacturer. It also allows for expansion, while never creating a lowest common denominator experience.
I really appreciate your ideas, many thanks!
Thank you I really appreciate you to allow me to express them, even though I'm sure I could be reading up more on things before writing.
Charlie1
Very active member
Very active member
Posts: 4831
Joined: 2007-12-11 00:30
Location: UK

Re: Thoughts around a Lejonklou Streamer

Post by Charlie1 »

lejonklou wrote:Data needs a clock to move around, doesn't it? Otherwise how do you read and write it?
I had to look that one up and, you're right, Ethernet does perform clocking at the physical level (layer-1). Not sure how the master is negotiated without digging deeper.

But this clocking doesn't really relate much to the layers above. I mean, just cos each bit must be sent at a synchronised time interval doesn't mean that it will be. Ethernet was originally designed as a shared medium and used with hubs, so the sender had to wait for a gap in communications before transmitting. Any transmitted signal might still collide with a signal sent by another endpoint, in which case, each sender would back off a random interval before attempting to re-send. Therefore, the packets would not be sent at a uniform rate.

Ethernet switches negate this because each interface is treated as a single point-to-point uplink, but they can create other problems, such as dropping TCP packets as a means to avoid congestion (i.e. buffer overflow), thereby triggering the TCP sender to back off. This creates a kind of sawtooth traffic pattern the TCP flows start to converge and ramp up at similar rates before congestion avoidance kicks in again: https://2.bp.blogspot.com/-t_7casRN0hk/ ... 1600/a.jpg

Congestion is unlikely within a small home network but domestic Internet circuits are a likely bottleneck and congestion point. Other than dropouts, is this likely to have a musical impact though - i.e. when bits don't arrive at a consistent uniform rate? I don't see how this is even possible when the application layer data stream is divided up into chunks by TCP at the transport layer (layer-4). It's always going to arrive at the destination endpoint in a fragmented fashion.

I am still curious about data washing and how multiple clocks might upset the music stream.
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

doze84: There's one thing you need to grasp: Bit perfect is not an issue. Not a problem whatsoever. That's basic. The real challenges are on another level. Start by reading about jitter. And please understand that digital signals are being transmitted by analogue waveforms.
Charlie1
Very active member
Very active member
Posts: 4831
Joined: 2007-12-11 00:30
Location: UK

Re: Thoughts around a Lejonklou Streamer

Post by Charlie1 »

lejonklou wrote:Start by reading about jitter. And please understand that digital signals are being transmitted by analogue waveforms.
Does the concern about jitter extend to the network infrastructure?
User avatar
lejonklou
Administrator
Administrator
Posts: 6523
Joined: 2007-01-30 10:38
Location: Sweden
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by lejonklou »

Charlie1 wrote:
lejonklou wrote:Start by reading about jitter. And please understand that digital signals are being transmitted by analogue waveforms.
Does the concern about jitter extend to the network infrastructure?
You tell me!

I think it depends on how we define jitter. It's easy to show how differences in quality can travel over the network without the data being affected. Either you categorize that as jitter (which might broaden the original definition) or you need to give it another label.
Charlie1
Very active member
Very active member
Posts: 4831
Joined: 2007-12-11 00:30
Location: UK

Re: Thoughts around a Lejonklou Streamer

Post by Charlie1 »

lejonklou wrote:I think it depends on how we define jitter. It's easy to show how differences in quality can travel over the network without the data being affected. Either you categorize that as jitter (which might broaden the original definition) or you need to give it another label.
My interpretation of jitter comes from networks that support voice-over-IP, in which case it means the variation in delay of received packets.

VoIP uses small-size UDP segments, not TCP. UDP isn't reliable so you'd need the application layer to detect any missing data and request it to be re-sent. I don't think voice applications bother with this though cos they are real-time and there's no time for re-sending missing data. I seem to recall about ~150ms one-way delay is acceptable for a voice call. Not sure about acceptable jitter values.
User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by doze84 »

lejonklou wrote:doze84: There's one thing you need to grasp: Bit perfect is not an issue. Not a problem whatsoever. That's basic. The real challenges are on another level. Start by reading about jitter. And please understand that digital signals are being transmitted by analogue waveforms.
You are arguing against your self here. The definition of jitter is that it is errors in the data. All jitter shows upp in the data, otherwise it's electrical noise and not jitter. (Unless there's a wider definition of the word that 'I havent herad of)

It feels like there is something fundamental that you miss here, but I don't know what it is. I trust all your listening tests, but the conclusions your draw doesn't add up. Bit perfect means that all data is preserved. If all data is preserved to the last step, and no streams are started until the last step, all is fine. Jitter is only a problem from the step where file-protocols can't be used any more, or from the step that a stream procol starts feeding. Clocks cause a lot of jitter all the way and it doesn't matter that there are analogue representations of data, when all harm is repaired by re-sent, verified packets. There is no harm to the music, what so ever. Arguing against this, is like arguing against that 1+1 is 2.

I'm persisting with this, because I would hate to see you look in the wrong places for answers. Or spend hundreds of hours optimizing a NAS, that doesn't impact the music.(other than electrical noise which can be fixed with optical bridge, unless that one also creates noise)

Your experience is that it impacts the music, because you've only heard faulty protocols speaking with the NAS.(or it's been electrical interference)
Last edited by doze84 on 2018-03-28 12:38, edited 1 time in total.
Music at Home
Active member
Active member
Posts: 120
Joined: 2008-10-09 16:10

Re: Thoughts around a Lejonklou Streamer

Post by Music at Home »

Doze84, There is a device in the receiver called a PHY chip. It's job is to translate the analog waveform on the Ethernet copper pairs into digital data. In order to do that, it needs to constantly adjust it's own clocks to match the clock that generated the analog waveform in the first place. Jitter and noise in the analog waveform causes the PHY chip to work harder, constantly adjusting itself so it can accurately track the incoming waveform and know exactly when to measure the "1"'s and "0"'s within the analog representation. The harder that job is the more noise is injected into the receiver and this noise can make it's way into the analog section of the device.

Noise in the transmitting device produces jitter in the output. So essentially, noise creates jitter and jitter creates noise and this cascades throughout the system.

I'm sure there are other effects at play as well but hopefully this helps to explain why bit perfect is not the end of the story
User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by doze84 »

Music at Home wrote:Doze84, There is a device in the receiver called a PHY chip. It's job is to translate the analog waveform on the Ethernet copper pairs into digital data. In order to do that, it needs to constantly adjust it's own clocks to match the clock that generated the analog waveform in the first place. Jitter and noise in the analog waveform causes the PHY chip to work harder, constantly adjusting itself so it can accurately track the incoming waveform and know exactly when to measure the "1"'s and "0"'s within the analog representation. The harder that job is the more noise is injected into the receiver and this noise can make it's way into the analog section of the device.

Noise in the transmitting device produces jitter in the output. So essentially, noise creates jitter and jitter creates noise and this cascades throughout the system.

I'm sure there are other effects at play as well but hopefully this helps to explain why bit perfect is not the end of the story
That is interesting. Then this chip needs to be chosen wisely, even if it were to be an optical link. Normally when speaking of jitter, it is jitter that makes it into the data because of clocks speaking at different speeds. That shows up in the data. This would be more electrical noise than jitter i would guess? Since TCP/IP would correct all jitter in the data. But I don't know how broad the definition of jitter, but I normally know what it is when speaking about audio transfer.(To answer the quote in the last post)
Charlie1
Very active member
Very active member
Posts: 4831
Joined: 2007-12-11 00:30
Location: UK

Re: Thoughts around a Lejonklou Streamer

Post by Charlie1 »

doze84 wrote:That is interesting. Then this chip needs to be chosen wisely, even if it were to be an optical link. Normally when speaking of jitter, it is jitter that makes it into the data because of clocks speaking at different speeds. That shows up in the data. This would be more electrical noise than jitter i would guess? Since TCP/IP would correct all jitter in the data. But I don't know how broad the definition of jitter, but I normally know what it is when speaking about audio transfer.(To answer the quote in the last post)
This doesn't seem right to me, especially comments like "Since TCP/IP would correct all jitter in the data". TCP/IP has no interest in the variation of delay that TCP segments/IP packets arrives. TCP will make sure it gets all the data, requesting any missing segments, but that's about it.
matthias
Very active member
Very active member
Posts: 2092
Joined: 2007-12-25 16:47
Location: Germany

Re: Thoughts around a Lejonklou Streamer

Post by matthias »

A comment from a very experienced contributor of the CA forum:

After years of fooling around with Corning Cables, FMCs and the Adnaco USB fiber solutions, I've gone all copper now. In the end, sound quality is best once the fiber was eliminated. Based on your response, I guess that these are all sub-optimal implementations of opto-electric interfaces.

Matt
Matt

MBP / Exposure pre + power (both modified) / JBL3677
User avatar
doze84
Active member
Active member
Posts: 103
Joined: 2009-05-21 13:09
Location: Östersund(Sweden)
Contact:

Re: Thoughts around a Lejonklou Streamer

Post by doze84 »

Charlie1 wrote:
doze84 wrote:That is interesting. Then this chip needs to be chosen wisely, even if it were to be an optical link. Normally when speaking of jitter, it is jitter that makes it into the data because of clocks speaking at different speeds. That shows up in the data. This would be more electrical noise than jitter i would guess? Since TCP/IP would correct all jitter in the data. But I don't know how broad the definition of jitter, but I normally know what it is when speaking about audio transfer.(To answer the quote in the last post)
This doesn't seem right to me, especially comments like "Since TCP/IP would correct all jitter in the data". TCP/IP has no interest in the variation of delay that TCP segments/IP packets arrives. TCP will make sure it gets all the data, requesting any missing segments, but that's about it.
The only definition of jitter I have heard of, is errors that makes it into the data. These errors comes from clocks speaking at different pace(which always is the case), or noise that manages to cause the pulse signal to vary so much that a 0 becomes a 1 somewhere. But since TCP/IP resends every packet that has even one tiny bit of error, jitter is not a problem, until the last step(buffer to dac).
Last edited by doze84 on 2018-03-28 12:56, edited 2 times in total.
Music at Home
Active member
Active member
Posts: 120
Joined: 2008-10-09 16:10

Re: Thoughts around a Lejonklou Streamer

Post by Music at Home »

TCP/IP is a transport protocol within the digital domain. Jitter exists in the physical Ethernet layer, which is analog. It's in the conversion from analog to digital that jitter is removed, but a by-product of that conversion is noise, which TCP/IP has no control over.

The best description I can find is here: https://www.audiostream.com/content/upt ... uzd7OMw.97

Please ignore the fact that the above article is talking about a USB interface, the reasoning is applicable to any digital transmission method where digital data is being converted to an analog representation to transport it from A to B and converted back to digital again and where the clocks at either end are independent and the receiving end therefore needs to constantly track the frequency and jitter of the transmitting clock. At this level, Ethernet and USB are very similar and physical layer converters, PHY devices, are required in both cases. This is all takes place at a lower level than TCP/IP, TCP/IP has no concept of what is taking place at this point of conversion, it only needs to see the resulting digital output from it
Charlie1
Very active member
Very active member
Posts: 4831
Joined: 2007-12-11 00:30
Location: UK

Re: Thoughts around a Lejonklou Streamer

Post by Charlie1 »

doze84 wrote:The only definition of jitter I have heard of, is errors that makes it into the data. These errors comes from clocks speaking at different pace(which always is the case), or noise that manages to cause the pulse signal to vary so much that a 0 becomes a 1 somewhere. But since TCP/IP resends every packet that has even one tiny bit of error, jitter is not a problem, until the last step(buffer to dac).
Fair enough. Sounds like we have very different understanding jitter. I suppose mine is better described as network jitter.
Post Reply