What can I do to improve the quality of my digital audio?

quadzilla

Ah, yes, because an IP network is much more reliable than a direct connection. Look, we can sit and argue about whether jitter and latency make a difference over a network, or you can accept that the manufacturers of all networked audio equipment (both IP and every other) have decided that they do. I believe that you're the one struggling since you failed to grasp the point of that link (you stated jitter doesn't make a difference, I cannot agree for the reasons listed in the description of what jitter is in the link), but it's obvious that neither of us are going to agree with the other on this issue.

Not sure what you mean by "****" though. I've been quite careful not to let you get behind me.

But just to sum up, and for the last time, I don't believe that buffering is a fix-all, though it can at least somewhat mitigate issues in a network, without regard to the transport mechanism. From what you've posted, you state that in a properly designed and implemented networked audio application (key words here being properly designed and implemented, which is a very, very rare thing), that jitter and latency either don't exist, or at least are not issues. This is probably a debate that causes almost, or even as much, disagreement as the arguments of tube vs solid state, or cables do/don't make any difference. Either way, those on opposite sides never seem to agree, and this is the end of my participation in this argument.

The one point I will agree on, and which I suggested several posts ago, is let the OP either enjoy what he has, or try a few simple tests to see if he can detect any difference. It's really sort of up to him.

Jeff_J

Dude, everyone just chill...

Just get a couple of LessLoss's Blackbodies and enjoy the vast improvement in your digital sound already!

bopicasso

Just a couple, now that is a cheap upgrade! lol

doctorcilantro

Amherst wrote: »

What audio device that can handle IP, that you know of that does not contain a packet buffer?

I know of none and why IP is not in the sound quality equation. Sorry fellas but all of the IP discussion is pure fallacy as it pertains to the quality of audio.

From my experience, I agree, but please calm down. I don't think Quad was insulting you mate.

nedh84

Hmm we aren't talking about streaming internet radio, these programs are designed to work on a home network where speeds are fast. I'm positive they have a buffer. When my bandwidth sucks on my ps3 (rare occurrence) the music stops all together. It doesn't "degrade". After a second it buffers up and works fine again.

Also I can't imagine they would design it using UDP instead of TCP. Are these media servers using UDP?

I never had any quality issues streaming to my ps3 from my media center.

nedh84

Maximus666 wrote: »

I agree... although we need to be careful sometimes, as I've heard from what I consider a reputable source that they could hear a difference in the sound between optical and coax links. Which made me scratch my head, because other than imperfections in the fibre optic cable, I just can't see how that's possible over such a short link (although to be perfectly honest, almost all of my experience lies in long-haul single mode, at 10+ Gbps). Any ideas there?



Please give me your perspective on that. I've read and heard differing opinions all over the place. I must also admit that I can't see how the claims are possible (but on the other hand I don't have "golden ears"), except in the case where the "old" cables were compromising the signal quality. In which case 20 feet of lamp cord would have been an improvement.

Maximus666 I haven't had the pleasure of running the experiments myself but I do believe it is entirely possible that quality analog audio cables do in fact make a difference. I'll explain my reasoning by comparing it to a digital signal.


Digital signals: We can agree that the signals are compromised by 0's and 1's. On/100% and Off/0%. Now when the signal is traveling it may not be a perfect 100% 1/On signal. A switch is smart enough to realize that this 75% signal is not a 0% and so it computes it properly as On. I may not be explaining this right but this explains why having an ethernet cable over 100ft requires placing a switch as a repeater to re-amplify the signals of (0's, 1's). Because digital works in absolutes and not shades of grey the computer devices can interpret the signals/data to be 0's 1's with high levels of accuracy.


Analog signals: These signals are basically all raw data, shades of grey. It doesn't take a lot of feet to mess up an analog signal (typically adding a few feet of cable won't ruin your signal as much as the quality of the cable itself). Banana plugs, interconnects, all sorts of things can slightly interfere with our signal.

Now this whole topic is very subjective but many of the audiophiles that I trust believe in using high quality audio cables. Their experience has led me in the right direction numerous times in my quest for the perfect sound. If you have any audio friends maybe borrow some cables from them. I suggest giving it a shot yourself on your two front speakers and stick with 2 channel for the testing.

If you don't hear a difference then great, you just saved yourself some cash. If you do hear a difference then don't worry about upgrading the cable on the surround speakers. Just upgrade the two fronts. Maybe the center channel.

doctorcilantro

nedh84 wrote: »

Hmm we aren't talking about streaming internet radio, these programs are designed to work on a home network where speeds are fast. I'm positive they have a buffer. When my bandwidth sucks on my ps3 (rare occurrence) the music stops all together. It doesn't "degrade". After a second it buffers up and works fine again.

Also I can't imagine they would design it using UDP instead of TCP. Are these media servers using UDP?

I never had any quality issues streaming to my ps3 from my media center.

J. River has some of the most advanced library serving for high quality audio. They use a TCP port (I burned a CD over WAN the other day too!)

If you have a high end card, like a Lynx, you can monitor the mixer's dropout counter.

If there is a data shortfall due to the network, you'll see "buffering".

You can reproduce audio artifacts i.e. Glitches or crackles by lowering you main buffer in software or ASIO buffer for example. Proof that the network can't cause a degragated stream, just one which may cause the listener to observe buffering.

nedh84

Does the J. River media center transcode ALAC and FLAC? Also does it stream to PS3?

doctorcilantro

nedh84 wrote: »

Does the J. River media center transcode ALAC and FLAC?

Flac, no problem and every other format except for m4a like ALAC; you need to manually install the DC-Bass source filter for ALAC. Quicktime can be used by Jr if installed for some codecs using the m4a container IIRC - if you don't have DC-Bass installed - but that doesn't give you all the features like replay gain, audio analysis (peak value. bpm, etc.). You can set to never convert, always convert format: uncompressed, high mp3, medium mp3, and low mp3, or convert if needed: uncompressed, high mp3, medium mp3, and low mp3. Basically allowing you to stream a FLAC and decode on target PC (client), or decode on server to PCM first. Maybe over WAN with a powerful client, it would help to never convert and send the FLAC over WAN due to bandwidth issues.

Apple has made it painfully difficult for small companies like JR to integrate iPod transfer; I just stream .flac or .ape from home to my iPhone using JR WebPlay feature.


And yes, you can use their powerful DLNA server to push audio to your PS3 and have the server decode all formats to lossless PCM before bitstreaming. I think the PS3 will simply show up as another unique zone.

nedh84

That is pretty cool

doctorcilantro

nedh84 wrote: »

That is pretty cool

It's really the tip of the iceberg. You can actually use an app in the 3rd party plugins section of the forum to sync itunes and JR; it acts as an intermediary and sync to your ipod. Keeps ratings and stats synced etc.

Library Server, Treemote, Sync, WebRemote & WebPlay, the powerful database (their test library is 1 million tracks), and custom metadata and view schemes are my top choice features.

I'm editing metadata from work right now, and when I close JRMC, this client will look at my database at home and sync back any tag changes.

I have had my run ins the some staff there, but most are very helpful and friendly.

nedh84

The only thing keeping me back is the msrp of 50 dollars for JRMC. Currently I'm using a free program called Tversity for streaming my music. I'm not sure if it buffers but it seems to fulfill my needs.

doctorcilantro

I understand, but I would pay $100 per year to use JRMC.

I'll try to add some screenshots to my gallery; the possibilities are endless.

doctorcilantro

I put up some screenshots; maybe I should start a new thread. Sorry if I hijacked this one, but they have given great care to network-based digital playback ...anyway....please continue!

Amherst

quadzilla wrote: »

Ah, yes, because an IP network is much more reliable than a direct connection. Look, we can sit and argue about whether jitter and latency make a difference over a network, or you can accept that the manufacturers of all networked audio equipment (both IP and every other) have decided that they do. I believe that you're the one struggling since you failed to grasp the point of that link (you stated jitter doesn't make a difference, I cannot agree for the reasons listed in the description of what jitter is in the link), but it's obvious that neither of us are going to agree with the other on this issue.

Not sure what you mean by "****" though. I've been quite careful not to let you get behind me.

But just to sum up, and for the last time, I don't believe that buffering is a fix-all, though it can at least somewhat mitigate issues in a network, without regard to the transport mechanism. From what you've posted, you state that in a properly designed and implemented networked audio application (key words here being properly designed and implemented, which is a very, very rare thing), that jitter and latency either don't exist, or at least are not issues. This is probably a debate that causes almost, or even as much, disagreement as the arguments of tube vs solid state, or cables do/don't make any difference. Either way, those on opposite sides never seem to agree, and this is the end of my participation in this argument.

The one point I will agree on, and which I suggested several posts ago, is let the OP either enjoy what he has, or try a few simple tests to see if he can detect any difference. It's really sort of up to him.

Thinking you are walking away after another dumb post....not today, I haven't been drinking, so let's discuss.
I would like to say I'm glad you edited the statement from your post where you attest to the general unreliability of an IP network, someone got to you to straighten that up...Yes? Glaring inexperience and lack of knowledge made on your part pertaining to the subject matter there.


Let's try and separate some truth from fiction here.

First this statement:

quadzilla wrote: »

Ah, yes, because an IP network is much more reliable than a direct connection.

This is probably as much true as it is false, but in the scheme of things and this thread... it doesn't really matter.


Next:

quadzilla wrote: »

Look, we can sit and argue about whether jitter and latency make a difference over a network,

Here starts the fiction since jitter technically does not exist.
In your defense the term is used waaay too frequently, even amongst network engineers, and even in Cisco documentation to describe what is actually correctly defined as packet delay variation. Here in this link is a little wiki primmer as to why. http://en.wikipedia.org/wiki/Packet_delay_variation. PDV is the technically correct acronym.
It is important that the term jitter not be used when referring to an IP network for a bunch of sound reasons. First and foremost is the example of this thread and how it can get intermixed with digital audio transmission over toslink ect.
The final word on this matter is directly addressed by the IETF. The IETF or Internet Engineering Task Force are the ones who approve the protocols worldwide that are involved with the discussion at hand and I personally accept the following synopsis that the term jitter as is being used here as incorrect. Pay particular attention to section 1.1 of this link:
http://www.ietf.org/rfc/rfc3393.txt

Also another snippet from wikipedia:
Packet jitter in computer networks
Main article: Packet delay variation
"In the context of computer networks, the term jitter is often used as a measure of the variability over time of the packet latency across a network. A network with constant latency has no variation (or jitter).[2] Packet jitter is expressed as an average of the deviation from the network mean latency. However, for this use, the term is imprecise. The standards-based term is packet delay variation (PDV).[3] PDV is an important quality of service factor in assessment of network performance."
The bottom line here is the term jitter is real bad, for audio folks especially, to use when describing PDV on an IP network.
It serves nothing but to confuse.



OK, now more fiction:

quadzilla wrote: »

....or you can accept that the manufacturers of all networked audio equipment (both IP and every other) have decided that they do."

No idea why you would make this up...delirious perhaps?

AND some more fiction:

quadzilla wrote: »

I believe that you're the one struggling since you failed to grasp the point of that link (you stated jitter doesn't make a difference, I cannot agree for the reasons listed in the description of what jitter is in the link), but it's obvious that neither of us are going to agree with the other on this issue.

THE FACTS are your link has no application within an IP network, what else can be said is as already posted it strictly applies to digital audio transmission. You want to try and blur the lines between two different systems and this point is where your failure to comprehend lies.



More fiction:

quadzilla wrote: »

Not sure what you mean by "****" though. I've been quite careful not to let you get behind me.

At least here I am unable to call fiction, you at least state an opinion, albeit incorrectly.

quadzilla wrote: »

But just to sum up, and for the last time, I don't believe that buffering is a fix-all, though it can at least somewhat mitigate issues in a network, without regard to the transport mechanism.

My experience and knowledge on this subject say modern day networks and buffers(audio buffers included) have little to no issues here. So I have to figure you're just inexperienced and clueless. This can be read in documentation as being an issue but in reality has loooog since been corrected. Say practically anything built in the past decade. BTW, I have a strong and lengthy background in networking....in case you decide my opinion not having weight.



Wow....BIG pile here:

quadzilla wrote: »

From what you've posted, you state that in a properly designed and implemented networked audio application (key words here being properly designed and implemented, which is a very, very rare thing), that jitter and latency either don't exist, or at least are not issues.

Plain just not stated....more delirium I guess.



Fiction Again:

quadzilla wrote: »

This is probably a debate that causes almost, or even as much, disagreement as the arguments of tube vs solid state, or cables do/don't make any difference. Either way, those on opposite sides never seem to agree, and this is the end of my participation in this argument.

Here is where you continue to blur lines between two different systems. There is much debate as we all know in regards to jitter over digital audio transmission ie toslink ect.



Fiction:

quadzilla wrote: »

The one point I will agree on, and which I suggested several posts ago, is let the OP either enjoy what he has, or try a few simple tests to see if he can detect any difference. It's really sort of up to him.

What can the OP test? Do you have any idea the sophistication of equipment needed to make a determination?
I'll just say here you may as well have another, cause you just don't get it!



So what does all this have to do with audio quality over an IP network? I think quite a bit (pun intended) and this is why.
The facts are that when streaming audio over an IP network there can be no changes in sound quality. Packets arrive whole or not at all. No in-betweens. This is unlike digital audio transmission (see Quads link above) where the stream can be interrupted at the bit level. So the purchase of nic cards,switches and routers is wasted money when trying to improve sound quality.

Here is an example of an audio steam (voice) over an IP network and dropped packets.

The graph represents the creation of an encoded audio signal, transmitted over an IP network, and then decoded to an analog signal again.
As you can see any received packets are whole, unchanged in any way, missing packets produce a void or silence as we hear it.

Decoders use an algorithm to provide a sort of "fill in" for any missing packets, these can vary from reinserting the packet prior to the one missing, all the way to guessing the information that is missing. In audio applications the logarithms generally insert silence for missing blocks of information. I'm sure there are some that handle this differently and I would stand corrected here for bad information if that is the case.

What needs to be understood that if there are any dropped packets on a network, the network has problems. Either bad cabling/connections or an end point failure/bad WIFi,switch,nic card ect.. Your network should not drop packets peroid. So if you have audio dropouts investigate further.

Some here want to question the buffer that handles delays, properly termed PDV's which are inherent on all networks. The best that can be said here is if somehow you think the buffer's that are built into modern day equipment is insufficient you must have bought a real POS, and I recommend the trash can for it.

__________________Enjoy the music you have just streamed, no worries.

nedh84

Wow that program is pretty cool doctorcilantro. You made me really want to buy it haha. Damn... Oh by the way.... can you override the sample rate of a cd track or mp3 file? That doesn't seem to make a whole lot of sense as I believe it is natively 44.2 Khz. Is it ideal to double it or quadruple it?

I noticed you have 192,000 selected as your sample rate but wouldn't that mean you are adding a conversion before outputting your sound to the speakers. This potentially can negatively affect your sound quality?

doctorcilantro

nedh84 wrote: »

Wow that program is pretty cool doctorcilantro. You made me really want to buy it haha. Damn... Oh by the way.... can you override the sample rate of a cd track or mp3 file? That doesn't seem to make a whole lot of sense as I believe it is natively 44.2 Khz. Is it ideal to double it or quadruple it?

I noticed you have 192,000 selected as your sample rate but wouldn't that mean you are adding a conversion before outputting your sound to the speakers. This potentially can negatively affect your sound quality?

no more hijacking for me...see new thread

doctorcilantro

If I try to use "play from memory" with a 192kHz file over LAN...J. river will pretty much freak out as it tries to load a massive chunk of data into memory.

If I disable this feature, which many tout as superior blah blah blah, I get flawless playback.

I have DPC screenshots showing how ASIO isn't routed properly from Server>network>Player>ASIO driver>hardware, but Server>network>Player>WASAPI driver>hardware results in incredibly low system latency.

Matt at JR has stated that WASAPI cuts out a lot of driver control, for lack of a better term, and the hardware has to decide what to do, hence you can sometimes get sync issues with WASAPI but it is more of an endpoint of chain communication with hardware issue if that makes sense.



Playback of a 192kHz over LS to the client. Lynx ASIO. Using USB remote to move up and down through album tiles with built thumbnails.




Playback of a 192kHz over LS to the client. WASAPI to Lynx Speakers. Using USB remote to move up and down through album tiles with built thumbnails.



Things get real nasty with a wifi device enabled but this is wired. In this case, this low power dual-core ION probably can't handle the ASIO driver and it's added complexity; WASAPI seems to dump it right through to my Lynx>external DAC. If there is a delay upon startup of playback on the client due to the server seeking for a file, JRMC buffers momentarily and accordingly.

I started with a 300mbps wifi connection and no amount of tweaking the networked helped; when I switched to WASAPI things were simplified and performed much better. Local ASIO playback of the same 192kHz file looks like the WASAPI conditions above; Paul at Lynx was a bit surprised by all this iirc.

Amherst wrote: »

Thinking you are walking away after another dumb post....not today, I haven't been drinking, so let's discuss.
I would like to say I'm glad you edited the statement from your post where you attest to the general unreliability of an IP network, someone got to you to straighten that up...Yes? Glaring inexperience and lack of knowledge made on your part pertaining to the subject matter there.


Let's try and separate some truth from fiction here.

First this statement:


This is probably as much true as it is false, but in the scheme of things and this thread... it doesn't really matter.


Next:



Here starts the fiction since jitter technically does not exist.
In your defense the term is used waaay too frequently, even amongst network engineers, and even in Cisco documentation to describe what is actually correctly defined as packet delay variation. Here in this link is a little wiki primmer as to why. http://en.wikipedia.org/wiki/Packet_delay_variation. PDV is the technically correct acronym.


What needs to be understood that if there are any dropped packets on a network, the network has problems. Either bad cabling/connections or an end point failure/bad WIFi,switch,nic card ect.. Your network should not drop packets peroid. So if you have audio dropouts investigate further.

Some here want to question the buffer that handles delays, properly termed PDV's which are inherent on all networks. The best that can be said here is if somehow you think the buffer's that are built into modern day equipment is insufficient you must have bought a real POS, and I recommend the trash can for it.

__________________Enjoy the music you have just streamed, no worries.

jefcully

I Understand yr enthusiasm about yr new AQ type 4 speaker cables with MIT AVt-3. I have read it about a lot and it has really great surround sound,as i'm been told by friends..if u really want to upgrade it then it's yr decision,but u seem satisfy by yr current configuration as well.I Would like to stick it with yr current system if it's all right to u.

bopicasso

You can stick it with my current system, I give you my permission. lol

jinjuku

nedh84 wrote: »

I may not be explaining this right but this explains why having an ethernet cable over 100ft requires placing a switch as a repeater to re-amplify the signals of (0's, 1's). Because digital works in absolutes and not shades of grey the computer devices can interpret the signals/data to be 0's 1's with high levels of accuracy.


Analog signals: These signals are basically all raw data, shades of grey. It doesn't take a lot of feet to mess up an analog signal (typically adding a few feet of cable won't ruin your signal as much as the quality of the cable itself). Banana plugs, interconnects, all sorts of things can slightly interfere with our signal.

It's every 328 feet BTW. With an analog signal there is no error checking you get warts and all.

With any serious layer 3 switch I would just tag certain traffic for bandwidth shaping and be done with it. If you are have audio problems with loss-less or a full bit perfect rip then you have other issues.

I am not sure why latency is being discussed in a properly configured LAN. I am interested in the mechanical laser head in a CD player VS the mechanical head in a HD far as seek times re-calibration etc. Never mind an SSD drive. We are in most cases talking about the weakest link in the chain. That isn't a properly configured switch nor properly terminated Ethernet cabling.

jinjuku

doctorcilantro wrote: »

If I try to use "play from memory" with a 192kHz file over LAN...J. river will pretty much freak out as it tries to load a massive chunk of data into memory.

If I disable this feature, which many tout as superior blah blah blah, I get flawless playback.

I have DPC screenshots showing how ASIO isn't routed properly from Server>network>Player>ASIO driver>hardware, but Server>network>Player>WASAPI driver>hardware results in incredibly low system latency.

Matt at JR has stated that WASAPI cuts out a lot of driver control, for lack of a better term, and the hardware has to decide what to do, hence you can sometimes get sync issues with WASAPI but it is more of an endpoint of chain communication with hardware issue if that makes sense.


Playback of a 192kHz over LS to the client. Lynx ASIO. Using USB remote to move up and down through album tiles with built thumbnails.

WASAPI>ASIO>K-Mixer. Agreed. MS has done a great job with WASAPI. Years ago you had to manually implement ASIO to by-pass the horrible k-mixer.

jinjuku

quadzilla wrote: »

Yes, you can run two NICs in the PC. I wasn't suggesting though that you use the cross-over permanently. It's just a step to see if there's an improvement or not.

There isn't anything that I would consider a nice router available to the home market. Although one other step you could try would be to just ping the PS/3 and see if the response time varies any. If it does, you're getting jitter on the ethernet connection. The problem though is that you're running Windows, and that rounds to the nearest millisecond instead of showing the exact time. Here's my pinging my gateway across an ethernet connection from a linux box, which actually shows the exact time:

rob@gir:~$ ping blackrock
PING blackrock.lan.robhughes.com (192.168.1.1) 56(84) bytes of data.
64 bytes from blackrock.lan.robhughes.com (192.168.1.1): icmp_seq=1 ttl=64 time=4.47 ms
64 bytes from blackrock.lan.robhughes.com (192.168.1.1): icmp_seq=2 ttl=64 time=3.47 ms
64 bytes from blackrock.lan.robhughes.com (192.168.1.1): icmp_seq=3 ttl=64 time=3.49 ms
64 bytes from blackrock.lan.robhughes.com (192.168.1.1): icmp_seq=4 ttl=64 time=3.55 ms

So as you can see, even wired directly to my gateway, I'm getting slightly varying response times, which means jitter, which means I wouldn't use ethernet as an audio transport.

What it means is that you would have a jitter buffer say in the 250/500 ms second range. I believe this sort of thing is built into Windows MCE and Media player. I know in my Shoretel phone system I can manually assign the jitter buffer value.

If you have any TCP windowing errors (not assuming UDP) you would have that cushion. so even a latent packet of say 80ms isn't going to impact your playback.

doctorcilantro

davide256 wrote: »

I wouldn't trust a LAN connection to send signal to the DAC for fidelity unless the DAC is ethernet aware for packet loss and jitter with buffers/ timing to sequence, and correct for jitter. Any other IP traffic stream can interfere causing jitter and packet loss. If you have these things, LAN speeds at 100mbps make the actual bandwidth used inconsequential and cabling in between just effects how much work the DAC has to do to maintain sequencing and eliminate jitter.

The Transporter is the only DAC I am aware (and sqeezeboxes?) that are fed direct by ethernet; I'm sure their are others.

Most people have hardware and software involved before the DAC as we discussed here.

You can use better software like JRiver to push audio to sqeezeboxes or PS3s...that might help the situation.