New router improves sound but .....

Pedro2

Well-known member
Nov 29, 2010
78
44
18,570
Visit site
Has anyone noticed an improvement in sq after purchasing a new router? I recently bought a Billion 7800N to replace a 5 year old Edimax. First the good news; I have noticed an improvement in SQ - it's not night and day but the sound stage is definitely improved and detail is more resolved.

However, access to my NAS using remote desktop is now not possible. Aaaaagh! V. annoying. Anyone experienced anything similar? (improved sound and/or problems of a computer based nature).
 
A

Anonymous

Guest
Pedro2 said:
Has anyone noticed an improvement in sq after purchasing a new router? I recently bought a Billion 7800N to replace a 5 year old Edimax.
No, not remotely.
 
A

Anonymous

Guest
The_Lhc said:
New router improves sound

No it doesn't.

It can, if there is more bandwidth and the old one didn't keep up (i.e. dropped packets, introduced jitter etc.) with streaming content.

Is the NAS in the same network segment or is it routed or even NATed? If so you may need to add some routing, permits in the access-lists and/or NAT rules depending on which is the case. It may als be that you need to set up your NAS to allow connections from a foreign subnet.
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
patrickvanham said:
The_Lhc said:
New router improves sound

No it doesn't.

It can,

It can't.

if there is more bandwidth and the old one didn't keep up (i.e. dropped packets,) with streaming content.

If that was the case playback would fail completely or be intermittent, that isn't the same as saying "the soundstage was improved".

introduced jitter etc.

You only get jitter in a digital audio stream, the router isn't handling audio (digital or otherwise), it's handling data packets (the contents of which it has little or no idea about), the concept of jitter in that kind of data doesn't even exist.
 
A

Anonymous

Guest
The_lhc is spot on.

Mind you, I'm beginning to think there's a market for audiophile ethernet packets...
 
A

Anonymous

Guest
The_Lhc said:
You only get jitter in a digital audio stream, the router isn't handling audio (digital or otherwise), it's handling data packets (the contents of which it has little or no idea about), the concept of jitter in that kind of data doesn't even exist.

If a NAS is used to stream an audio file via a router the audio stream is encapsulated into ethernet frames. If the links poor or insufficent bandwidth for that type of audie encoding it may drop or queue packets which will be noticeable as less control of the stream. Upgrading improves this.
 

hammill

New member
Mar 20, 2008
212
0
0
Visit site
Grottyash said:
The_lhc is spot on.

Mind you, I'm beginning to think there's a market for audiophile ethernet packets...
+1 Doubtless we will be lambasted for being narrow minded as we have not personally tested this....
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
patrickvanham said:
The_Lhc said:
You only get jitter in a digital audio stream, the router isn't handling audio (digital or otherwise), it's handling data packets (the contents of which it has little or no idea about), the concept of jitter in that kind of data doesn't even exist.

If a NAS is used to stream an audio file via a router the audio stream is encapsulated into ethernet frames. If the links poor or insufficent bandwidth for that type of audie encoding it may drop or queue packets which will be noticeable as less control of the stream.

"less control of the stream" - that doesn't even mean anything! It'll be noticable because you'll get drop outs (ie silence) in the sound because the streaming device can't buffer ahead far enough to play from memory whilst it waits for the network to catch up.

Upgrading improves this.

It might well do but that's not the same as improving the sound quality. That's improving the sound quantity, ie first there was no sound, then there was. That ISN'T what the OP is talking about however.
 
A

Anonymous

Guest
The_Lhc said:
"less control of the stream" - that doesn't even mean anything! It'll be noticable because you'll get drop outs (ie silence) in the sound because the streaming device can't buffer ahead far enough to play from memory whilst it waits for the network to catch up.

No, that's where you are wrong. Most people won't notice even 10% packet loss especially if the stream is mp3 or some other lossy compression. To an audiphile whisch uses uncompressed or lossless compression it would be audible but not as silence, to achieve audible silence it would have to drop several sequental packets, at least 30-50 depending on packetsize, although it would be less if Jumbo Frames are supported and used. It just sounds like something is missing when you have packetloss due to congestion since about 1 in 10 or 1 in 50 frames are missing.

The_Lhc said:
It might well do but that's not the same as improving the sound quality. That's improving the sound quantity, ie first there was no sound, then there was. That ISN'T what the OP is talking about however.

In the case of real-time ethernet streams case the quality is directly dependent on the quantity of frames that can be transmitted without queueing and without dropping.

Real-time streaming over ethernet has less to do with audio and much more to do with actual networking in a packet-switched environment. Perhaps you may consider consulting some networking literature in the discipline of real-time media.

Edit: re-reading my makes it look a bit offensive, there's none meant and I apologize if it comes across as such.

Did the hints regarding routing entries or NAT help the OP any?
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
patrickvanham said:
Perhaps you may consider consulting some networking literature in the discipline of real-time media.

I would but I'm too lazy to look for it myself, can you suggest some? I'm far from convinced but you've fleshed out the bones of your argument far more than most people do, so I'll do you the service of reading whatever you suggest.
 
A

Anonymous

Guest
patrickvanham said:
The_Lhc said:
"less control of the stream" - that doesn't even mean anything! It'll be noticable because you'll get drop outs (ie silence) in the sound because the streaming device can't buffer ahead far enough to play from memory whilst it waits for the network to catch up.

No, that's where you are wrong. Most people won't notice even 10% packet loss especially if the stream is mp3 or some other lossy compression. To an audiphile whisch uses uncompressed or lossless compression it would be audible but not as silence, to achieve audible silence it would have to drop several sequental packets, at least 30-50 depending on packetsize, although it would be less if Jumbo Frames are supported and used. It just sounds like something is missing when you have packetloss due to congestion since about 1 in 10 or 1 in 50 frames are missing.

The_Lhc said:
It might well do but that's not the same as improving the sound quality. That's improving the sound quantity, ie first there was no sound, then there was. That ISN'T what the OP is talking about however.

In the case of real-time ethernet streams case the quality is directly dependent on the quantity of frames that can be transmitted without queueing and without dropping.

Real-time streaming over ethernet has less to do with audio and much more to do with actual networking in a packet-switched environment. Perhaps you may consider consulting some networking literature in the discipline of real-time media.
The_lhc is correct. No packet drop is going to impact the type of thing the OP claims to hear, especially in a network which is going to have more than ample bandwidth and therefore minimal, if any, problems with packet loss.
 
A

Anonymous

Guest
I wouldn't worry about it. We're talking a normal household network here, and they've usually got bandwidth plus to spare. Besides, there's no packet marked 'soundstage'.
 
A

Anonymous

Guest
Grottyash said:
I wouldn't worry about it. We're talking a normal household network here, and they've usually got bandwidth plus to spare. Besides, there's no packet marked 'soundstage'.
:)
 
A

Anonymous

Guest
lost frames and re-transmission could account to jitter, if my assumption of jitter in digital audio is correct. This is because the time the dac receives the bits might be inconsistent with the reference time scale of the recording.

Other way to look at it is, if swapping a digital SPDIF/optical cable can bring about a difference in sonic characteristics, then the quality of the network-media used to stream packets defenitly could, as well.

Not to open an argument on the effect of digital cables, but the only point here is network media is as significant (or only as significant)
 
A

Anonymous

Guest
The_Lhc said:
THERE IS NO JITTER IN NETWORK TRAFFIC! Jitter is a digital audio phenomenon, networks don't carry audio, they carry data!

Jitter exists in both network terminology as well as audio.

In network terms, its the variation in delay. In audio terms, my understanding is, it is the deviation of the audio bit pattern from the supposed-to-be pattern due to various hinderences including transport/media-disk inaccuracies.

This is a good place to start:

http://en.wikipedia.org/wiki/Jitter

EDIT:

More info on network jitter in specific (warning:terribly boring).

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
indising said:
The_Lhc said:
THERE IS NO JITTER IN NETWORK TRAFFIC! Jitter is a digital audio phenomenon, networks don't carry audio, they carry data!

Jitter exists in both network terminology as well as audio.

In network terms, its the variation in delay. In audio terms, my understanding is, it is the deviation of the audio bit pattern from the supposed-to-be pattern due to various hinderences including transport/media-disk inaccuracies.

This is a good place to start:

http://en.wikipedia.org/wiki/Jitter

Excellent, wiki-tennis!

From that link:

Packet jitter in computer networks

Main article: Packet delay variation

From the first line of that link:

In computer networking packet delay variation (PDV) is the difference in end-to-end delay between selected packets in a flow with any lost packets being ignored. The effect is sometimes, incorrectly, referred to as jitter.

So I was right, no such thing as Network Jitter and it's NOTHING to do with audio jitter. Furthermore:

In multimedia streams, PDV can be removed by the choice of a properly sized play-out buffer at the receiver, which may only cause a detectable delay before the start of media playback.

Which means a properly designed streaming device will remove "network jitter" by buffering. Audio jitter only comes into effect when the playback device has converted the network packets into a PCM audio stream to be passed to a DAC (internal or external).
 

aliEnRIK

New member
Aug 27, 2008
92
0
0
Visit site
The_Lhc said:
In computer networking packet delay variation (PDV) is the difference in end-to-end delay between selected packets in a flow with any lost packets being ignored. The effect is sometimes, incorrectly, referred to as jitter.

DELAY is the time taken 'point ot point' in a network

JITTER is the 'variation' in the delay

I dont trust half of whats on wiki personally
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
aliEnRIK said:
The_Lhc said:
In computer networking packet delay variation (PDV) is the difference in end-to-end delay between selected packets in a flow with any lost packets being ignored. The effect is sometimes, incorrectly, referred to as jitter.

DELAY is the time taken 'point ot point' in a network

JITTER is the 'variation' in the delay

Err, yes, that's what that says?

I dont trust half of whats on wiki personally

Neither do I, just fighting fire with fire, live by the wiki, die by the wiki. In other words, "he started it sir!"
smiley-tongue-out.gif
 

aliEnRIK

New member
Aug 27, 2008
92
0
0
Visit site
The_Lhc said:
THERE IS NO JITTER IN NETWORK TRAFFIC! Jitter is a digital audio phenomenon, networks don't carry audio, they carry data!

There is jitter in everything digital (data in this case - which you wrongly say isnt susceptible to jitter). Google 'pingtest' to see if your online 'data' has jitter levels (hint - it does)

As a side note - To correctly read true (not that anything is that im aware of) 24 bit audio with no need for error correction / buffering you need to get it down to approx 0.5 picoseconds
 

The_Lhc

Well-known member
Oct 16, 2008
1,176
1
19,195
Visit site
aliEnRIK said:
The_Lhc said:
THERE IS NO JITTER IN NETWORK TRAFFIC! Jitter is a digital audio phenomenon, networks don't carry audio, they carry data!

There is jitter in everything digital (data in this case - which you wrongly say isnt susceptible to jitter). Google 'pingtest' to see if your online 'data' has jitter levels (hint - it does)

Yes but it doesn't bear any relationship to audio jitter, they're completely different things.

As a side note - To correctly read true (not that anything is that im aware of) 24 bit audio with no need for error correction / buffering you need to get it down to approx 0.5 picoseconds

I'd be surprised if there's any AV streaming system that doesn't use buffering to some extent.
 

aliEnRIK

New member
Aug 27, 2008
92
0
0
Visit site
The_Lhc said:
aliEnRIK said:
The_Lhc said:
In computer networking packet delay variation (PDV) is the difference in end-to-end delay between selected packets in a flow with any lost packets being ignored. The effect is sometimes, incorrectly, referred to as jitter.

DELAY is the time taken 'point ot point' in a network

JITTER is the 'variation' in the delay

Err, yes, that's what that says?

Thats not how I read what you put

Youve stated 'packet delay' is wrongly referred to as jitter (Which is possible in some cases - that isnt in dispute)

Thus everyone reading (Well me certainly) believes youve stated that jitter doesnt exist (it does)
 

TRENDING THREADS

Latest posts