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

bopicasso

I currently am using my computer as a media server for all my wav lossless music. Path of music:

HP desktop-cat5-Belkin Wireless G router-cat5-ps3-AQ type4 optical-MF V-dac-Ultimate type4 ICs-Krell

Kav 300i-AQ type 4-Dynaudio Audience 70s-ears


Im replacing the AQ type 4 speaker cables with MIT AVt-3. They are on the way.

Would a upgrade to the ethernet cables or to the pc help the quality of the music. Currently I am happy with the sound, but im always looking for a improvement.
Thanks for help in advance!!!!!

kawizx9r

Any sound treatments in your room?

bopicasso

No but that is not a option for now. It is in our living room and my old lady would not approve. She barely deals with my audio addiction as it is lol.

nedh84

Unless your digital cables just aren't working then there is no need to upgrade digital cables. Digital signals aren't compromised like analog signals.

Analog cables are a different story.

Maximus666

nedh84 wrote: »

Unless your digital cables just aren't working then there is no need to upgrade digital cables. Digital signals aren't compromised like analog signals.

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?

nedh84 wrote: »

Analog cables are a different story.

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.

Fongolio

All looks pretty good. Perhaps an even better DAC may help things sound even better but that said the V-Dac garners very favorable reviews.

Just for information, I was using my PS3 for a music server but recently purchased a Mac Airport Express (the only mac of any kind of I've ever owned) and wired it with CAT-5 to my router and then to my computer and at the other end out through a Entech Number Cruncher DAC (cheap dac but I'm soon to be upgrading) and then to my pre-amp with outstanding results. It allows me to play all my flac files as well as wav. I-tunes is what the Airport is designed to use but I hate it and instead use a program called Airfoil which allows me to use any music player and almost any file extension with the Airport. Results have been outstanding.

davide256

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.

nooshinjohn

The best way to help digital is to go Analog IMHO... A tube DAC would warm things up nicely.

quadzilla

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.

+1 for this. Ethernet has a lot of mechanisms that make it a very good transport for IP, but it was never designed for something as sensitive as audio, even when that audio is streamed over IP. It's fine for voice with appropriate buffering mechanisms, as david said, and may be ok with music with the same buffering. You've also got that Belkin in there, which is really low-end as routers/switches go. I deal with high-end carrier-class stuff, and even those devices have problems with latency and packet loss. You could try getting a cross-over cable and plug the desktop directly into the PS/3 and see if that makes any difference. If it does, then you're getting latency somewhere in the data path, most likely the Belkin.

bopicasso

Once you go digital its hard to go back to a cd player. I have 400 albums on my pc in wav lossless. I can use my ps3 to randomly play my entire library. I might never own a cd player again for playing music.

bopicasso

quadzilla,
So what would you reccommend for a nice router that would perform for my application?
Im currently happy with the belkin, it is 3 years old and I have not had one issue with it.
My desktop needs to be connected to the router for internet access.

bopicasso

would I be able to install a network card in my desktop to have two ethernet connections, one directly to the ps3 and one to the router?
Or would a better router be a better option?

quadzilla

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.

Amherst

While reading this thread I'm left wondering if it is going down the right path.

First the packets transmitted inside your home network are not routed but simply switched on the network by the switching process inside your router if that is how you are set up. If this is the case, even the cheapest of units will have basically no effect on packet timings or loss. So I fail to see the concern in this regard.

Here, I run a media server that will receive ip packets from my laptop (laptop to wireless access point>access point wired to switch>switch wired to media server>media server optical to pre) and sounds nothing short of fantastic and never any dropouts.

The basic sound quality issue will mostly be determined by the unit handling digital to analog conversion in your case the MF V-dac.

bopicasso

Amherst, I am quite satisfied with the sound quality coming from my speakers when streaming music from my pc. I was just concerned if I was loosing any of the quality along the way.

Amherst

Yup...got ya. Just don't see any possible way to change any sound quality during the IP process, failures will cause packet loss (drop outs ), other than that quality is at the conversions. Quad is way off base by associating IP timing with jitter, they are in fact totally unrelated.

quadzilla

Amherst wrote: »

While reading this thread I'm left wondering if it is going down the right path.

First the packets transmitted inside your home network are not routed but simply switched on the network by the switching process inside your router if that is how you are set up. If this is the case, even the cheapest of units will have basically no effect on packet timings or loss. So I fail to see the concern in this regard.

Here, I run a media server that will receive ip packets from my laptop (laptop to wireless access point>access point wired to switch>switch wired to media server>media server optical to pre) and sounds nothing short of fantastic and never any dropouts.

The basic sound quality issue will mostly be determined by the unit handling digital to analog conversion in your case the MF V-dac.

Sorry, but this is absolutely untrue, and is a rather somewhat simplistic view of how networks function. Networking gear will always introduce at least some delay while processing the packet. Depending on the quality of the switch, this delay can be small (us) or larger up to 100ths or even 10ths of a millisecond, and will vary from packet to packet. This will have an effect on sound quality unless buffering is used to ensure that the decoder is never waiting on data. Add to that the fact that Windows is notoriously poor when it comes to heavy I/O (sorry Windows guys), and you're going to have jitter on the line. So again, buffering is the only way around that. Where my knowledge falls short is whether the PS/3 actually uses buffering or just decodes in real time for wav files played over the network. So the concern is here is not drop-outs, but jitter introduced by the transport medium. If no one else posting in this thread knows or cares what jitter is, then it's probably not germane to the conversation, and the OP should just go on and continue to enjoy his set up.

Either way, if the OP is happy with how it sounds, then that's the important part.

Amherst

Yes simplistic view presented intentionally, all are facts and completely true.

There is no jitter in the IP process.

The packet timings are handled by a buffer (stores packets), if jitter is encountered it will be after the IP process has occurred, not part of it, and in no way can affect sound quality.

Please see links: http://en.wikipedia.org/wiki/Jitter
http://en.wikipedia.org/wiki/Packet_delay_variation

davide256

Guys, some of us do this for a living The only signal path that provides timing for signal is a TDM circuit for device to device data transmission. Switches and Ethernet are definitely variable delay based on traffic and collisions. If you don't use a buffer with timing and sequencing you end up with signal degradation.... perhaps ok for casual listening but not what those who spend time tweaking for performance will settle for.

Amherst

davide256 wrote: »

Guys, some of us do this for a living The only signal path that provides timing for signal is a TDM circuit for device to device data transmission. Switches and Ethernet are definitely variable delay based on traffic and collisions. If you don't use a buffer with timing and sequencing you end up with signal degradation.... perhaps ok for casual listening but not what those who spend time tweaking for performance will settle for.

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.

quadzilla

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.

Yes, you're right. Jitter and packet latency have no effect on decoding. That must be why all the network audio classes I've taken spend so much time dealing with issues of jitter and packet latency on the network.

davide256

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.

a packet buffer does nothing to control timing and sequencing. Thats the recieving devices responsibility

Amherst

davide256 wrote: »

a packet buffer does nothing to control timing and sequencing. Thats the recieving devices responsibility

Timing and sequencing, what the hell are you trying to point out?
Please go on and explain how the audio quality is affected.

Amherst

quadzilla wrote: »

Yes, you're right. Jitter and packet latency have no effect on decoding. That must be why all the network audio classes I've taken spend so much time dealing with issues of jitter and packet latency on the network.

Quad if you dig deeper you will find those answers. BTW there is no jitter on the network that can be resolved.

doctorcilantro

Don't worry about using ethernet to transfer from a server to a client.

I'd suggest a free trial of J. River Media Center and use it to stream PCM to the PS3 via its DLNA server; it will protect against any dropouts etc.

I'm not sure why data shortfalls are being equivocated with jitter in some of these posts. Is that correct?

doctorcilantro

Data shortfalls can and will happen but that's why you have software with buffers, making network streaming possible.

I use a master server and stream 192kHZ @ 3-6000kbps (or even up to 100000kbps with mkv) streams to my client with no issues. WASAPI really does work better than ASIO; provides much lower system latency.

doctorcilantro

quadzilla wrote: »

+1 for this. Ethernet has a lot of mechanisms that make it a very good transport for IP, but it was never designed for something as sensitive as audio, even when that audio is streamed over IP. It's fine for voice with appropriate buffering mechanisms, as david said, and may be ok with music with the same buffering. You've also got that Belkin in there, which is really low-end as routers/switches go. I deal with high-end carrier-class stuff, and even those devices have problems with latency and packet loss. You could try getting a cross-over cable and plug the desktop directly into the PS/3 and see if that makes any difference. If it does, then you're getting latency somewhere in the data path, most likely the Belkin.

I suggest everyone trying the DPC latency checker and just look at ASIO vs. DirectSound vs. WASAPI when playing back a high bitrate file locally and then over wired lan.

WASAPI will equal local playback; it's a pretty amazing protocol.

You can run a VERY serious setup using J. River's Library Server. When I had the bandwidth at my old house I would use it to stream FLAC>PCM 96kHz over WAN to my headamp at work (30 miles away) with no problems.

quadzilla

Amherst wrote: »

Quad if you dig deeper you will find those answers. BTW there is no jitter on the network that can be resolved.

Message does not decode. Garbage in stream.

Amherst

Did I somehow insult you the way you just did me?

Nice intelligent response, you were trying to sell the OP on a router that will have no affect.

Tried to be nice about it but obviously you're %$)&^#. Suggest you stay in school.

quadzilla

doctorcilantro wrote: »

Don't worry about using ethernet to transfer from a server to a client.

I'd suggest a free trial of J. River Media Center and use it to stream PCM to the PS3 via its DLNA server; it will protect against any dropouts etc.

I'm not sure why data shortfalls are being equivocated with jitter in some of these posts. Is that correct?

Not sure about what others were getting at, but I can see varying amounts of latency even over local lans, even when going through no more than a single enterprise class switch. Yes, buffering should deal with that. Lost packets are a completely different issue. Again, assuming TCP is used and not UDP, the IP stack will handle the lost packets with no involvement from the application and they'll be restransmitted, but now they'll be received out of order. Again, buffering should handle that. If UDP is used, which is what most streaming mechanisms are based on, the transmitting host has no way to know if the receiving host ever got the packet, and it falls to the application to notify the sending application of lost packets and re-request those lost packets or to try to reconstruct the lost packets via CRC or some other error checking mechanism.

Or this: http://www.aviom.com/library/White-Papers/63_Managing-Jitter-Wander-and-Latency-in-Digital-Audio-Networks.pdf

So what I'm saying is there's a lot of stuff that buffering should handle, and that there is no other way to handle due to the limits of the transport mechanism, etc. But I also know just how often software doesn't quite do exactly what it's supposed to.

Amherst

quadzilla wrote: »

Not sure about what others were getting at, but I can see varying amounts of latency even over local lans, even when going through no more than a single enterprise class switch. Yes, buffering should deal with that. Lost packets are a completely different issue. Again, assuming TCP is used and not UDP, the IP stack will handle the lost packets with no involvement from the application and they'll be restransmitted, but now they'll be received out of order. Again, buffering should handle that. If UDP is used, which is what most streaming mechanisms are based on, the transmitting host has no way to know if the receiving host ever got the packet, and it falls to the application to notify the sending application of lost packets and re-request those lost packets or to try to reconstruct the lost packets via CRC or some other error checking mechanism.

Or this: http://www.aviom.com/library/White-Papers/63_Managing-Jitter-Wander-and-Latency-in-Digital-Audio-Networks.pdf

So what I'm saying is there's a lot of stuff that buffering should handle, and that there is no other way to handle due to the limits of the transport mechanism, etc. But I also know just how often software doesn't quite do exactly what it's supposed to.

Your link refers to Toslink and Coax digital audio. Has nothing to do with transmission over an IP network.

The post above clearly demonstrates that you are struggling with very basic networking theory. While you are ****, why not take this garbage to an appropriate forum and let the OP continue his quest for better sound.