Re: PCI
Various threads here and at diyhifi consistently establish that standard optical interconnects are a good deal more jittery than coax, if mainly for the TX and RX components themselves and not so much the interconnect itself. It is a useful idea in case of ground loops and HF noise, but I think the transformer is the best solution. Adding transformer on the sound card side (there was already one on the DAC side) removed all noise problems from my setup: it looks great on the scope.
Only if the internal soundcard has RF shielding with no leaks. Good luck doing this.
I think that really good shielding is very difficult to do in the awful interference environment inside a PC case. Even small leaks in the shielding will compromise its effectiveness significantly. You'd optimally need a steel shield fully enclosing a secondary PCB rather than two halves covering portions of the card since that leaves the gap in between for the board to go through, and ferrite beads on all inputs and outputs going through the shield. You can't DIY that, only the card maker can do it.
Transformers on both S/PDIF sides and an ASRC's jitter attenuation work very well.
But then if you have a synchronous connection to the DAC, all the jitter implications remain. If it's asynchronous instead (implying an ASRC), then you're resampling twice, so what's the point.
Member
Joined 2003
Just thought I'd update since my curiosity has gotten the best of me. I checked my M-Audio card, and the transformer is at the SPDIF output. The SPDIF input has a 75 Ohm resistor to ground, and the signal goes through a cap to the CS8427 IC. That made my day, too bad my day is overDcibeL said:
Hi folks.
Are we getting anywhere here? The secret about audiophile software audio players has not been lifted yet.
The whole thing drifted towards (commmercial) soundcard or DAC discussions.
The pity, even if BlackCatSound, Nixie, or Eddy might own the perfect digital environment, others don't.
I own a USB-DDDAC, which, due to the PCM2707 design, offers limited manipulation on the receiving side. I did very well concentrating on the sending side.
(BTW. The results I figured out, were clearly audible also on a RME fireface)
As far as it comes to serious studio implementations, (what I consider reference for the time being ) They all run on masterclocks, slaving the PC and its interface card (such as Lynx AES16), via word or superclocks.
I havn't seen anybody coming up with this or a better solution yet.
IMO Most of the mentioned solutions are NON DIY. We are at DIY-Audio here and not at Audio-Asylum as Nixie mentioned earlier
Back to the topic:
The PC environment bears hundreds of sources, which mess around with the data stream. I'd never accept a statement - All players are equal - soundwise. They are not! The way how they are programmed has a lot of impact on the realtime stream or the buffer/interface management.
I do agree that the PC environment on its own is another, even bigger, source for
messing around with the stream.
I recently learned, thanx to Ross, that actually the operating system itself is one of the key issues to be discussed.
Under Linux most of the discussed issues, which are valid under Windows, doesn't apply to Linux. ( I am Linux newbie since a couple of weeks!)
Why don't discuss important interface and operating system parameters, which
are to be delivered by an operating system/application/audio-player/driver.
The below mentioned parameters have a clearly audible impact from my and some others experiences.
Such as:
Operating System
ASIO/Kernelstreaming (for Windows)
Interface drivers
Input output/buffers.
Realtime operation
Thread priorities
PC clocking
Sampling rate
Volume control (for direct DAC/AMP connections)
Full-File buffering
The features that have to be delivered by an operationg system, driver or application are IMO listed below:
1. The operating system should allow direct PCM access path to the sound device.
It must offer low latency operations. (The latency, even though not relevant for
audio-playback, shows clearly the capabilty of the involved drivers, to cope with
the data-stream.)
With Linux you can get as low as 0,5ms Latency!
For pure audio playback this value is even better.
With MS you end up at 12ms.
You need a highly sophisticated buffer management throughout the
process-chain to cope with such a slow system.
Vista will come up with some kind of exclusive mode to get around this problem.
We'll see, what it brings and if somebody implements it!
2. There are just a few proprietary interface drivers out there you'd call
well programmed and maintained, such as RME drivers. Still you need
Kernelstreaming to pass the Windows mixer by. Even these drivers will pass
on what they'll receive.
For USB-audio devices you need the www.usb-audio.com ASIO driver,
which replaces also poor usb-audio.sys, which inroduces heavy distortions/jitter.
With ASIO4ALL you'll never get around usb-audio.sys!
3. Applications need Plugin-support for ASIO drivers. It must be possible to allign
the ASIO driver parameters and the application parameters, otherwise you'll
catch servere problems on the interface.
With e.g. foobar I can load my ASIO driver. But I am not able to configure it!
Professional applications such as Cubase or Samplitude offer this feature.
Too small or too big buffers do have a great impact to the sound. E.g. Cracks
and so on are usually caused by buffer over-/underruns.
This issue under Linux is handled ways better than WIndows. You don't need
ASIO or KS any longer.
4. Under Windows giving your foreground processes lower priority than your
background processes, will improve the sound. Instead of putting
all the power on your UI, Windows should give e.g. the ASIO driver higher
priority. Set your application to Low through the task manager and turn off your
monitor and listen!
5. Doing full-file buffering of your tracks, while playing them back just takes
loads off your PC. Processing time, extra buffering, noise, power consumption
and vibrations, do cause this or that to your data stream.
6. I also upsampled offline my 44,1 material to 48kHz, by using Voxengo R8Brain
Pro. The result is IMO far superiour over any realtime sampling algorithm I came
across.
It is a known fact that 48kHz is a better match than 44,1 when it comes to pure
PCM streaming. (Especially the PCM2707 clocked with 12Mhz will love 48kHz
material).
7. Volume control
More and more people, me too, do realize that connecting your DAC right to the
AMP, is the way to go. The options and benefits are great. You can connect a
differential DAC-out right to differential AMP-in.
Transients and resolution are getting close to perfect.
Having a 24bit Dac and a 32bit float sw-volume control (e.g. J.River) is IMO a
highly recommened setup. But even on my 16 bit setup, playing at high
volumes in the range of -10db the advantages do beat all the disadvantages by
not runnuing the DAC at full-resolution.
Apologize for this long post! I do believe that the whole chain has to be looked at The SW-player plays IMO a serious role when discussing the whole chain, especially under Windows.
Under Linux, playback is mainly managed by ALSA or Jack, so most players don't differ because they are just a UI to ALSA or Jack. Still -- track-buffering and changing task-priorities will also make a difference under Linux.
Cheers
Are we getting anywhere here? The secret about audiophile software audio players has not been lifted yet.
The whole thing drifted towards (commmercial) soundcard or DAC discussions.
The pity, even if BlackCatSound, Nixie, or Eddy might own the perfect digital environment, others don't.
I own a USB-DDDAC, which, due to the PCM2707 design, offers limited manipulation on the receiving side. I did very well concentrating on the sending side.
(BTW. The results I figured out, were clearly audible also on a RME fireface)
As far as it comes to serious studio implementations, (what I consider reference for the time being ) They all run on masterclocks, slaving the PC and its interface card (such as Lynx AES16), via word or superclocks.
I havn't seen anybody coming up with this or a better solution yet.
IMO Most of the mentioned solutions are NON DIY. We are at DIY-Audio here and not at Audio-Asylum as Nixie mentioned earlier
Back to the topic:
The PC environment bears hundreds of sources, which mess around with the data stream. I'd never accept a statement - All players are equal - soundwise. They are not! The way how they are programmed has a lot of impact on the realtime stream or the buffer/interface management.
I do agree that the PC environment on its own is another, even bigger, source for
messing around with the stream.
I recently learned, thanx to Ross, that actually the operating system itself is one of the key issues to be discussed.
Under Linux most of the discussed issues, which are valid under Windows, doesn't apply to Linux. ( I am Linux newbie since a couple of weeks!)
Why don't discuss important interface and operating system parameters, which
are to be delivered by an operating system/application/audio-player/driver.
The below mentioned parameters have a clearly audible impact from my and some others experiences.
Such as:
Operating System
ASIO/Kernelstreaming (for Windows)
Interface drivers
Input output/buffers.
Realtime operation
Thread priorities
PC clocking
Sampling rate
Volume control (for direct DAC/AMP connections)
Full-File buffering
The features that have to be delivered by an operationg system, driver or application are IMO listed below:
1. The operating system should allow direct PCM access path to the sound device.
It must offer low latency operations. (The latency, even though not relevant for
audio-playback, shows clearly the capabilty of the involved drivers, to cope with
the data-stream.)
With Linux you can get as low as 0,5ms Latency!
For pure audio playback this value is even better.
With MS you end up at 12ms.
You need a highly sophisticated buffer management throughout the
process-chain to cope with such a slow system.
Vista will come up with some kind of exclusive mode to get around this problem.
We'll see, what it brings and if somebody implements it!
2. There are just a few proprietary interface drivers out there you'd call
well programmed and maintained, such as RME drivers. Still you need
Kernelstreaming to pass the Windows mixer by. Even these drivers will pass
on what they'll receive.
For USB-audio devices you need the www.usb-audio.com ASIO driver,
which replaces also poor usb-audio.sys, which inroduces heavy distortions/jitter.
With ASIO4ALL you'll never get around usb-audio.sys!
3. Applications need Plugin-support for ASIO drivers. It must be possible to allign
the ASIO driver parameters and the application parameters, otherwise you'll
catch servere problems on the interface.
With e.g. foobar I can load my ASIO driver. But I am not able to configure it!
Professional applications such as Cubase or Samplitude offer this feature.
Too small or too big buffers do have a great impact to the sound. E.g. Cracks
and so on are usually caused by buffer over-/underruns.
This issue under Linux is handled ways better than WIndows. You don't need
ASIO or KS any longer.
4. Under Windows giving your foreground processes lower priority than your
background processes, will improve the sound. Instead of putting
all the power on your UI, Windows should give e.g. the ASIO driver higher
priority. Set your application to Low through the task manager and turn off your
monitor and listen!
5. Doing full-file buffering of your tracks, while playing them back just takes
loads off your PC. Processing time, extra buffering, noise, power consumption
and vibrations, do cause this or that to your data stream.
6. I also upsampled offline my 44,1 material to 48kHz, by using Voxengo R8Brain
Pro. The result is IMO far superiour over any realtime sampling algorithm I came
across.
It is a known fact that 48kHz is a better match than 44,1 when it comes to pure
PCM streaming. (Especially the PCM2707 clocked with 12Mhz will love 48kHz
material).
7. Volume control
More and more people, me too, do realize that connecting your DAC right to the
AMP, is the way to go. The options and benefits are great. You can connect a
differential DAC-out right to differential AMP-in.
Transients and resolution are getting close to perfect.
Having a 24bit Dac and a 32bit float sw-volume control (e.g. J.River) is IMO a
highly recommened setup. But even on my 16 bit setup, playing at high
volumes in the range of -10db the advantages do beat all the disadvantages by
not runnuing the DAC at full-resolution.
Apologize for this long post! I do believe that the whole chain has to be looked at The SW-player plays IMO a serious role when discussing the whole chain, especially under Windows.
Under Linux, playback is mainly managed by ALSA or Jack, so most players don't differ because they are just a UI to ALSA or Jack. Still -- track-buffering and changing task-priorities will also make a difference under Linux.
Cheers
Soundcheck,
Please understand that for the PC areas you have posted above about which are to do with handling the digital data (all the IO functions) rather than manipulating the digital data (processing), the only 2 problem that could happen for the digital IO are either dropped data or data delivered out of proper time sequence.
Now for dropped data, you should assume that the PC architecture will guarantee the successful delivery of the data without dropping bits else the PC would be pretty disfunctional. For the second, where the data is delivered out of sync has the sound effect of clicks in the music or possibly even a short pause, and for most PCs due to the relative light load of managing a PCM stream, you would have to have a pretty misconfigured system to get clicks & pauses (temporal distortion - distortion in the time domain).
For manipulated (processed) data, if not done right it will impact the sound quality in many ways. Usually less is better here, and turn off any feature that may impact SQ through processing. I have highlighted these in your list:
Operating System - IO handling (except for mixer & volume) so unlikely to affect sound except for clicks if severly misconfigured.
ASIO/Kernelstreaming (for Windows) - Bypasses Windows mixer and volume control, which manipulate the data and can affect SQ.
Interface drivers - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Input output/buffers - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Realtime operation - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Thread priorities - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
PC clocking - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Sampling rate - Sound processing. Best set to the native rate of the source else re-sampling will occur somewhere (software or hardware). A decent re-sampler can subjectively help, at least by moving the Nyquist filter cutoff higher so it does not impact the SQ through phase delays close to the filter cutoff frequency. Also, some DACs will sound better depending what sampling rate is fed to them.
Volume control (for direct DAC/AMP connections) - In the digital domain it is sound processing. You will need a 24bit soundcard / DAC for this to work effectively on 16 bit sources else you will drop bits and add additional noise.
Full-File buffering - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Regards,
Dean
Please understand that for the PC areas you have posted above about which are to do with handling the digital data (all the IO functions) rather than manipulating the digital data (processing), the only 2 problem that could happen for the digital IO are either dropped data or data delivered out of proper time sequence.
Now for dropped data, you should assume that the PC architecture will guarantee the successful delivery of the data without dropping bits else the PC would be pretty disfunctional. For the second, where the data is delivered out of sync has the sound effect of clicks in the music or possibly even a short pause, and for most PCs due to the relative light load of managing a PCM stream, you would have to have a pretty misconfigured system to get clicks & pauses (temporal distortion - distortion in the time domain).
For manipulated (processed) data, if not done right it will impact the sound quality in many ways. Usually less is better here, and turn off any feature that may impact SQ through processing. I have highlighted these in your list:
Operating System - IO handling (except for mixer & volume) so unlikely to affect sound except for clicks if severly misconfigured.
ASIO/Kernelstreaming (for Windows) - Bypasses Windows mixer and volume control, which manipulate the data and can affect SQ.
Interface drivers - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Input output/buffers - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Realtime operation - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Thread priorities - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
PC clocking - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Sampling rate - Sound processing. Best set to the native rate of the source else re-sampling will occur somewhere (software or hardware). A decent re-sampler can subjectively help, at least by moving the Nyquist filter cutoff higher so it does not impact the SQ through phase delays close to the filter cutoff frequency. Also, some DACs will sound better depending what sampling rate is fed to them.
Volume control (for direct DAC/AMP connections) - In the digital domain it is sound processing. You will need a 24bit soundcard / DAC for this to work effectively on 16 bit sources else you will drop bits and add additional noise.
Full-File buffering - IO handling so unlikely to affect sound except for clicks if severly misconfigured.
Regards,
Dean
Soundcheck, How about if people verify that there software/hardware system is outputing bit perfect sound and just report back?
If the majority of people report that their system is already outputting bit-perfect sound, then maybe most PC's are already "Audiophile PC Audio Players".
There's nothing to DIY if your computer system is already doing things correctly.
If I understand correctly, everyone is having good luck with Linux(ALSA/JACK) and Windows(ASIO). And even some with good sound cards can't detect any problems with Windows and WDM and Windows Media Player.
I really think that if you get yourself a nice RME(have one) or Lynx(would like to have) you'd be set even if you use Windows. And an RME card for Linux is what the Brutefir guy recommends. They are unfortunately very expensive ($500-$1000).
Only when using cheap Via AC97 sound cards or MAUdio firewire solo on PC did I experience problems.
If someone knows of cheaper cards(M-Audio) that they can verify they are getting bitperfect output on that would be cool???
If the majority of people report that their system is already outputting bit-perfect sound, then maybe most PC's are already "Audiophile PC Audio Players".
There's nothing to DIY if your computer system is already doing things correctly.
If I understand correctly, everyone is having good luck with Linux(ALSA/JACK) and Windows(ASIO). And even some with good sound cards can't detect any problems with Windows and WDM and Windows Media Player.
I really think that if you get yourself a nice RME(have one) or Lynx(would like to have) you'd be set even if you use Windows. And an RME card for Linux is what the Brutefir guy recommends. They are unfortunately very expensive ($500-$1000).
Only when using cheap Via AC97 sound cards or MAUdio firewire solo on PC did I experience problems.
If someone knows of cheaper cards(M-Audio) that they can verify they are getting bitperfect output on that would be cool???
IME the M-Audio Audiophile 2496 is quite capable of outputting bit perfect pcm as evidenced by its ability to deliver uncorrupted HDCD format signals to my external dac. (Not trivial as any sort of resampling or processing strips the HDCD subcode. I don't use the 2496 hardware mixer option, but go straight out in order to accomplish this.)
I use ASIO which is natively supported by the 2496 and J River media center.
I have always understood that resampling from 44.1kHz to 48kHz was a very bad idea from a purely mathematical perspective, (causing blatant sampling inaccuracies) that infact no resampling is preferable unless you can resample to a minimum of somewhere around 2X.
Incidentally I don't believe my Audiophile 2496 has an internal spdif transformer on its output. Some versions may differ.. Caveat emptor..
I have experimented to a limited degree with resampling in ASIO from 44.1kHz/16 bit to 96KHz/24 bit, and admit to preferring the unresampled signal slightly.
I have a PS Audio Ultralink II dac (16 bit @ 32KHz/44.1KHz/48KHz and 20 bit HDCD @ 44.1KHz) and Zhaolu 2.5A (44.1kHz - 192K at 16 or 24 bit - limited to 96kHz by my sound card spdif output) For daily use I really prefer the Zhaolu - it's pretty amazing and very inexpensive.
I use ASIO which is natively supported by the 2496 and J River media center.
I have always understood that resampling from 44.1kHz to 48kHz was a very bad idea from a purely mathematical perspective, (causing blatant sampling inaccuracies) that infact no resampling is preferable unless you can resample to a minimum of somewhere around 2X.
Incidentally I don't believe my Audiophile 2496 has an internal spdif transformer on its output. Some versions may differ.. Caveat emptor..
I have experimented to a limited degree with resampling in ASIO from 44.1kHz/16 bit to 96KHz/24 bit, and admit to preferring the unresampled signal slightly.
I have a PS Audio Ultralink II dac (16 bit @ 32KHz/44.1KHz/48KHz and 20 bit HDCD @ 44.1KHz) and Zhaolu 2.5A (44.1kHz - 192K at 16 or 24 bit - limited to 96kHz by my sound card spdif output) For daily use I really prefer the Zhaolu - it's pretty amazing and very inexpensive.
Re: Re: PCI
And you think there is less RF outside the PC?
They are nothing like as bad as people think.
If you want fun try putting an unshielded microphone preamp inside a box with an unshielded 100mW S-band RF transmitter and a composite video decoder sat next to the ADC using the same power rails. Interferance is just not that much of an issue, even in that case.
I just had to ensure the mic preamp didn't share any earth vias with the composite decoder. It did in the previous design and you could hear the frame syncs. DOH!
Nixie said:
And you think there is less RF outside the PC?
They are nothing like as bad as people think.
If you want fun try putting an unshielded microphone preamp inside a box with an unshielded 100mW S-band RF transmitter and a composite video decoder sat next to the ADC using the same power rails. Interferance is just not that much of an issue, even in that case.
I just had to ensure the mic preamp didn't share any earth vias with the composite decoder. It did in the previous design and you could hear the frame syncs. DOH!
Daveis said:
First of all.
1. Please define Bit-Perfect!
How am I, or anybody else, is supposed to know or measure if the DAC chip receives a bit- and ,more important, time -perfect stream exactly the way it is stored in the source file!
You can measure certain stages in the path, but I am questioning if you can cover the whole path.
2. Just let me know how to identify the induced non-linarities on a (i) asynchronous link if you don't have a reference.
3. How do I know If I don't have a free floating/fading bit-stream out there
4. How do I know if that what is entering my soundcard is not already messed up.
Unfortunately I don't have the tools and skills to measure that. So I have to trust my ears!
The other day I had a discussion with a guy who is selling (Lavry asf.) and tweaking high-end prostudio stuff.
According to him all non master-slaved environments should be dropped.
I tend to agree. With synched FIFOs you can be sure that you don't loose
anything.
However, even with my "low-cost" setup the sound I hear at home greatly improved by tweaking the PC setup (newest Thinkpad T60P).
And by far beats anything else I had before (e.g. Naim CDX)
@ssmith
Some advise for your USB-audio DDDAC setup:
1.
Prepare yourself a dedicated HW-profile under Windows.
Call it Audio or similar.
There you can switch off, all devices/drivers you don't need for audio playback.
Network-card, Wireless, Pcmcia, Bluetooth asf.
Boot this one up!
2.
Switch-off all services (control-panel/administration/services) you don't need for your HW-audio-profile. You can do that dedicated to a certain HW-profile.
I managed to deactivate more than 50% of all activated services, which are just overhead.
You can even stop the Windows-Audio service. This way you make sure that Windows is not messing with your sound. JRMC will still work!
Cheers
Daveis: " ... On Thuneau's site many have had problems with Windows and firewire audio. ..."
These are common complaints and tips:
* MS Windows 98SE / 2K / XP loads an Internet TCP/IP protocol on top of the FireWire IEEE1394 hardware protocol on first installation ... and the common fix is to remove it (something usually done by the better FireWire audio software tools like ProTools, Stieinberg, etc. or from the Control Panel). This extra driver/software/protocol load often interfers with FireWire hardware performance. Dump it where possible. (Not a problem on Apple OS or Linux.)
* Usually FireWire add-in PCI / PCMCIA cards are well protected from the switching power supplies in the average PC ... but not all PCs and not all FireWire plug-in cards impliment the better design features and PS filtering. Look for FireWire cards using Texas Instrument, Agere', Oxford Semiconductor, Opti, Lucent chips & reference designs (or their licensees') = usually better design implimentations & PS filtering and on-board linear regulators. (For a while there VIA chips for both USB and FireWire absolutely would not work in audio = Compaq tech support has software fixes.)
* Peripherals: almost all external FireWire devices can "autoswitch" between bus power and self power ... For audio: always plug in the supplied wall wart = this overrides the bus power noise from the PC Power Supply, usually. Powering from the FireWire bus cable (or USB cable) from a PC will almost always be a noisy proposition. (All external FireWire peripherals run from + 10.5 to + 13.5 VDC sources = common mobile 12 volt batteries! ([+12 VDC bus power on pins 5 & 6 of the 6-pin cable connectors], making FW an easy choice for those Deadheads doing pirate recording into iPods and those making digital movies in the field!)
On Thuneau.com: "Truth is one, paths are many ..." - The Dali Lama
kevinkr: " IME the M-Audio Audiophile 2496 is quite capable of outputting bit perfect pcm as evidenced by its ability to deliver uncorrupted HDCD format signals to my external dac. (Not trivial as any sort of resampling or processing strips the HDCD subcode. I don't use the 2496 hardware mixer option, but go straight out in order to accomplish this.) ..."
Yes, not trivial at all ... and this feature / ability is why most CGI computer generated movie graphics, effects and cartoon rendering, etc. are done on FireWire hardware networks rather than EtherNet = fewer frames dropped, co-processing easily implimented, faster performance overall ( http://en.wikipedia.org/wiki/Maya_(software) ... FYI: 400 mbps FireWire is faster than 1000baseT Gigabit Ethernet in the bulk file transfer mode = movie files, high resolution audio, etc. ... 800 mbps FireWire = almost three times GigaBit Ethernet speed!)
All playback and ripping software works on either USB or FireWire (whether Windows, Mac or Linux). Check it out. Being totally hardware independant from software type & usage allows us DIYers to mix and match what works best for us ... and allows plenty of room for improvements. Any questions regarding condemnation or praise of one reproduction system over another should have a level playing field = and remain hardware independant. USB has its place in playback DAC devices and generally performs this function very, very well. FireWire has an advantage in bi-directional audio. Ethernet has a place for audio file storage and retreval and Internet upload / download and Internet radio, etc., etc. and does this function very, very well. When making comparisons, one should be aware that, for example, if "WinAmp works with my USB DAC but Foobar has problems with audio quality ..." this is almost certainly an operating system or software installation issue and Not The Hardware.
(Mercenary announcement: I built my first computer in 1980 for CGI graphics. http://industrialcomponent.com , http://usbstuff.com , http://firewirestuff.com are all my company's web sites.)
These are common complaints and tips:
* MS Windows 98SE / 2K / XP loads an Internet TCP/IP protocol on top of the FireWire IEEE1394 hardware protocol on first installation ... and the common fix is to remove it (something usually done by the better FireWire audio software tools like ProTools, Stieinberg, etc. or from the Control Panel). This extra driver/software/protocol load often interfers with FireWire hardware performance. Dump it where possible. (Not a problem on Apple OS or Linux.)
* Usually FireWire add-in PCI / PCMCIA cards are well protected from the switching power supplies in the average PC ... but not all PCs and not all FireWire plug-in cards impliment the better design features and PS filtering. Look for FireWire cards using Texas Instrument, Agere', Oxford Semiconductor, Opti, Lucent chips & reference designs (or their licensees') = usually better design implimentations & PS filtering and on-board linear regulators. (For a while there VIA chips for both USB and FireWire absolutely would not work in audio = Compaq tech support has software fixes.)
* Peripherals: almost all external FireWire devices can "autoswitch" between bus power and self power ... For audio: always plug in the supplied wall wart = this overrides the bus power noise from the PC Power Supply, usually. Powering from the FireWire bus cable (or USB cable) from a PC will almost always be a noisy proposition. (All external FireWire peripherals run from + 10.5 to + 13.5 VDC sources = common mobile 12 volt batteries! ([+12 VDC bus power on pins 5 & 6 of the 6-pin cable connectors], making FW an easy choice for those Deadheads doing pirate recording into iPods and those making digital movies in the field!)
On Thuneau.com: "Truth is one, paths are many ..." - The Dali Lama
kevinkr: " IME the M-Audio Audiophile 2496 is quite capable of outputting bit perfect pcm as evidenced by its ability to deliver uncorrupted HDCD format signals to my external dac. (Not trivial as any sort of resampling or processing strips the HDCD subcode. I don't use the 2496 hardware mixer option, but go straight out in order to accomplish this.) ..."
Yes, not trivial at all ... and this feature / ability is why most CGI computer generated movie graphics, effects and cartoon rendering, etc. are done on FireWire hardware networks rather than EtherNet = fewer frames dropped, co-processing easily implimented, faster performance overall ( http://en.wikipedia.org/wiki/Maya_(software) ... FYI: 400 mbps FireWire is faster than 1000baseT Gigabit Ethernet in the bulk file transfer mode = movie files, high resolution audio, etc. ... 800 mbps FireWire = almost three times GigaBit Ethernet speed!)
All playback and ripping software works on either USB or FireWire (whether Windows, Mac or Linux). Check it out. Being totally hardware independant from software type & usage allows us DIYers to mix and match what works best for us ... and allows plenty of room for improvements. Any questions regarding condemnation or praise of one reproduction system over another should have a level playing field = and remain hardware independant. USB has its place in playback DAC devices and generally performs this function very, very well. FireWire has an advantage in bi-directional audio. Ethernet has a place for audio file storage and retreval and Internet upload / download and Internet radio, etc., etc. and does this function very, very well. When making comparisons, one should be aware that, for example, if "WinAmp works with my USB DAC but Foobar has problems with audio quality ..." this is almost certainly an operating system or software installation issue and Not The Hardware.
(Mercenary announcement: I built my first computer in 1980 for CGI graphics. http://industrialcomponent.com , http://usbstuff.com , http://firewirestuff.com are all my company's web sites.)
FastEddy:
Thanks that was the tip I needed. Removing TCP/IP from binding with firewire may be the solution I needed to getting my Firewire solo working correctly under WinXP.
How many ouputs on the MAudio Auiophile 2496?
As far as measuring your soundcard for bit-perfect output...
I'd use some wavefile editor tool to create a simple sine wave. Play that out through my chain PC/crossover/ADAT and record with my Maudio field recorder just prior to the external DAC's I'm using. Then upload the file to the PC and visually inspect for problems.
But this has got me thinking that maybe I should remove my
RME ADAT to Alesis AI4 to Benchmark DAC1 setup
and replace with either an Maudio, RME, or Lynx card with XLR outputs?
To do that means running 50-feet of balanced line level signal rather than going over 50 feet of ADAT toslink cable. Any bets which one sounds better?
Thanks that was the tip I needed. Removing TCP/IP from binding with firewire may be the solution I needed to getting my Firewire solo working correctly under WinXP.
How many ouputs on the MAudio Auiophile 2496?
As far as measuring your soundcard for bit-perfect output...
I'd use some wavefile editor tool to create a simple sine wave. Play that out through my chain PC/crossover/ADAT and record with my Maudio field recorder just prior to the external DAC's I'm using. Then upload the file to the PC and visually inspect for problems.
But this has got me thinking that maybe I should remove my
RME ADAT to Alesis AI4 to Benchmark DAC1 setup
and replace with either an Maudio, RME, or Lynx card with XLR outputs?
To do that means running 50-feet of balanced line level signal rather than going over 50 feet of ADAT toslink cable. Any bets which one sounds better?
Daveis: " ... How many ouputs on the MAudio Audiophile 2496? ... As far as measuring your soundcard for bit-perfect output, I'd use some wavefile editor tool to create a simple sine wave. ..."
See http://www.m-audio.com/products/en_us/FirewireAudiophile-main.html ...
... and check out the very interesting software bundle: http://www.m-audio.com/index.php?do=products.bundled&ID=03958e3abee4f501c7f0690e4819e2ff ... music editor = can make sign waves ...
(Mercenary announcement: My company sells this device for US$240.00 plus shipping and we include the software bundle above plus some power line / data cable "Ferrite Bead" RF filters [ http://industrialcomponent.com/oem/3dalugkit.html = no extra charge ] ... phone orders only 1-877-446-8947 = 1-877-4 HOTWIRE :>)
See http://www.m-audio.com/products/en_us/FirewireAudiophile-main.html ...
... and check out the very interesting software bundle: http://www.m-audio.com/index.php?do=products.bundled&ID=03958e3abee4f501c7f0690e4819e2ff ... music editor = can make sign waves ...
(Mercenary announcement: My company sells this device for US$240.00 plus shipping and we include the software bundle above plus some power line / data cable "Ferrite Bead" RF filters [ http://industrialcomponent.com/oem/3dalugkit.html = no extra charge ] ... phone orders only 1-877-446-8947 = 1-877-4 HOTWIRE :>)
Firewire
Whilst there is considerable discussion on shakti stones etc. on audio asylum, the computer as source forum is essentially what folk on this thread want to start here. USB and firwire have been discussed extensively over there, and at a sensible level of discussion i.e. nothing to do with unexplainable stone properties.
Firewire is potentially a better audio interface than usb and spdif. However, the general comment seems to be that the oxford chipsets used in most firewire external dacs are clocked poorly through the arm processors the chipsets require to run, and have poorly implemented drivers due to the complexity of the interface. At the present time it appears a relatively jittery interface. Some one did also state that the oxford chips were better than TI.
USB is more developed in terms of its use as an audio interface and in terms of silicon solutions (i.e single chip).
Whilst specific firewire products may implement the interface better than others, and may out perform the best of the usb solutions, to me it is misleading to say that Firewire itself will lead to better results. It is also not great for a diy solution as the chipsets, last time i checked, are not available and mostly need firmware.
Of course, usb is not perfect, but many believe it sounds better than anything else - I would not be surprised if firewire can sound great too without having to overcome its current problems.
Fasteddy - Would be interested to hear of the specifics of the maudio implementation which may make it a better implementation, but Im not in position to purchase at the moment.
Blackcatsound - interested to hear that via chipsets have poor buffers. Are the buffers built into the chipsets, or do individual solutions vary? Could be the drivers. I have an equivalent to a chaintech av710 - can I assume an m-audio audiophile 2496 would have improved buffers although it still uses a similar via envy chipset to the chaintech?
Cheers
Whilst there is considerable discussion on shakti stones etc. on audio asylum, the computer as source forum is essentially what folk on this thread want to start here. USB and firwire have been discussed extensively over there, and at a sensible level of discussion i.e. nothing to do with unexplainable stone properties.
Firewire is potentially a better audio interface than usb and spdif. However, the general comment seems to be that the oxford chipsets used in most firewire external dacs are clocked poorly through the arm processors the chipsets require to run, and have poorly implemented drivers due to the complexity of the interface. At the present time it appears a relatively jittery interface. Some one did also state that the oxford chips were better than TI.
USB is more developed in terms of its use as an audio interface and in terms of silicon solutions (i.e single chip).
Whilst specific firewire products may implement the interface better than others, and may out perform the best of the usb solutions, to me it is misleading to say that Firewire itself will lead to better results. It is also not great for a diy solution as the chipsets, last time i checked, are not available and mostly need firmware.
Of course, usb is not perfect, but many believe it sounds better than anything else - I would not be surprised if firewire can sound great too without having to overcome its current problems.
Fasteddy - Would be interested to hear of the specifics of the maudio implementation which may make it a better implementation, but Im not in position to purchase at the moment.
Blackcatsound - interested to hear that via chipsets have poor buffers. Are the buffers built into the chipsets, or do individual solutions vary? Could be the drivers. I have an equivalent to a chaintech av710 - can I assume an m-audio audiophile 2496 would have improved buffers although it still uses a similar via envy chipset to the chaintech?
Cheers
Daveis said:
Are you all measuring Bit-Perfection this way??
What does it tell you about sound quality?
If your buffers are large enough, you should always achieve bit perfection.
Still your sound might be crappy.
IMO - The key issue is the timing of the stream and the related buffer handling!
rossco_50: " ... seems to be that the oxford chipsets used in most firewire external dacs are clocked poorly through the arm processors the chipsets require to run, and have poorly implemented drivers due to the complexity of the interface. At the present time it appears a relatively jittery interface. Some one did also state that the oxford chips were better than TI. ..."
I had not heard this. As far as I know the Oxford DAC / ADC chips are considered quite good. (They will be at the CES show in Las Vegas and I will ask them re: poor driver implimentations and jitter.)
And I believe that TI makes the very best FireWire host controllers and FireWire hub chips, but I don't believe their DAC / ADC chips enjoy top billing with DIYers ... http://focus.ti.com/docs/prod/folders/print/pcm3010.html .
....
" ... USB is more developed in terms of its use as an audio interface and in terms of silicon solutions ..."
USB = cheaper chips ... not!
USB = more developed ... as far as 24-bit audio goes, not!
USB = better sound ... possibly for the I2S / SPDIF scenario output only ... but not unless the implimentation has jitter under control and can handle all of the dropped packets during handshaking.
I do have my prejudices regarding USB, believeing that 16-bits just isn't good enough and 24-bit USB implimentations (other than via I2S & SPDIF) fail to work well, having huge jitter problems (much more so than just about anyone's implimentation of FireWire, Oxford or whoever).
I have to get into this argument vis a vis USB v. FireWire almost weekly. Ask any professional sound studio engineer which they have or use or desire. ( This: http://tascam.com/Products/dm3200.html = 32 audio tracks in, uses USB for command and control & configuration backup only, USB can't handle the whole data stream ... but FireWire can handle the whole load, data stream, command and control and backup for this: http://tascam.com/Products/FW-1884.html = 48 tracks in, each 24-bit/96k. )
Consider also: 16-bit A to D has about 80 db headroom/bandwidth, 24-bits A to D has greater than >>110 db headroom/bandwidth. (Comparing the 16-bit range is about from hushed crowd noise to the loadness of the trumpets and the 24-bit range of the hush of a pine forest to the threshold of pain.) 24-bit analog to digital rules, dude ... 16-bits just doesn't make it.
....
" ... Whilst there is considerable discussion on shakti stones etc. on audio asylum, the computer as source forum is essentially what folk on this thread want to start here. ..."
At the root of this and many PC audio discussions, here and at the Audio Asylum, USB has its place and FireWire has its place. They are different, technically and different in sound quality, bandwidth, performance, reliability and usability. These questions have come up regarding "the computer as source" and I would have answered pretty much same, same, here or there.
?? Shakti Stones ?? ... implying what, that there is some mystery here? Or that somehow someone here is shoveling it into deeper piles ?? ... Oh, contrare'
I had not heard this. As far as I know the Oxford DAC / ADC chips are considered quite good. (They will be at the CES show in Las Vegas and I will ask them re: poor driver implimentations and jitter.)
And I believe that TI makes the very best FireWire host controllers and FireWire hub chips, but I don't believe their DAC / ADC chips enjoy top billing with DIYers ... http://focus.ti.com/docs/prod/folders/print/pcm3010.html .
....
" ... USB is more developed in terms of its use as an audio interface and in terms of silicon solutions ..."
USB = cheaper chips ... not!
USB = more developed ... as far as 24-bit audio goes, not!
USB = better sound ... possibly for the I2S / SPDIF scenario output only ... but not unless the implimentation has jitter under control and can handle all of the dropped packets during handshaking.
I do have my prejudices regarding USB, believeing that 16-bits just isn't good enough and 24-bit USB implimentations (other than via I2S & SPDIF) fail to work well, having huge jitter problems (much more so than just about anyone's implimentation of FireWire, Oxford or whoever).
I have to get into this argument vis a vis USB v. FireWire almost weekly. Ask any professional sound studio engineer which they have or use or desire. ( This: http://tascam.com/Products/dm3200.html = 32 audio tracks in, uses USB for command and control & configuration backup only, USB can't handle the whole data stream ... but FireWire can handle the whole load, data stream, command and control and backup for this: http://tascam.com/Products/FW-1884.html = 48 tracks in, each 24-bit/96k.
)Consider also: 16-bit A to D has about 80 db headroom/bandwidth, 24-bits A to D has greater than >>110 db headroom/bandwidth. (Comparing the 16-bit range is about from hushed crowd noise to the loadness of the trumpets and the 24-bit range of the hush of a pine forest to the threshold of pain.) 24-bit analog to digital rules, dude ... 16-bits just doesn't make it.
....
" ... Whilst there is considerable discussion on shakti stones etc. on audio asylum, the computer as source forum is essentially what folk on this thread want to start here. ..."
At the root of this and many PC audio discussions, here and at the Audio Asylum, USB has its place and FireWire has its place. They are different, technically and different in sound quality, bandwidth, performance, reliability and usability. These questions have come up regarding "the computer as source" and I would have answered pretty much same, same, here or there.
?? Shakti Stones ?? ... implying what, that there is some mystery here? Or that somehow someone here is shoveling it into deeper piles ??
... Oh, contrare'soundcheck said:
Under Windows XP bypassing kmixer/software mixers/effects is of concern to people who want the best sound quality. One of the supposed effects of windows kmixer is that it harms the least significant bit of the music even when you have the volume at 100%. I've noticed that windows also seems to attenuate recorded sound at times.
Since this is a software concern, it's independent of hardware clock and buffers.
So you are questioning whether the clock/DAC in a USB or firewire sound card is as good as an external DAC?
For myself, USB is ruled out because I have chosen to do crossover(and maybe EQ/DRC) on the computer. That leaves me with either PCI or firewire.
FastEddy said:
There's no silver in Ethernet cables AFAIK. In thinnet/thicknet (10base2/10base5), it's simple Coax cable with vampire taps or AUI connectors. UTP (twisted pair) Category 3/4/5/5e/6 is copper. The category rating is based on the bandwidth of the cable, which is usually determined by the number of twists and the geometry of the twists in each of the 4 pairs. I would guess 99.99% of all networks run on twisted pair nowadays, as I haven't run into 10base2/5 in 15 years.
Most servers (old or new) use large power supplies because they are expected to power a fully-loaded configuration without requiring the PSU to be replaced. If you did need to replace the PSU, you either had an undersized power supply, or added more load to the server than the vendor intended. In many cases, the PSU size is also determined by what the cooling capacity of a server is. After all, most of that power winds up as heat, so even the biggest power supply won't matter if you can't cool the system down.
Almost all computer parts (motherboards, video cards, sound cards, drives, etc.) include on-board switching regulators that take the DC provided by the power supply and convert it into whatever they need (1.2-3.3v, 5v, etc.), so the actual PC power supply has much less of an effect than you think -- the performance of most sound cards comes down to how good their regulators are, and how well the decoupling is performed.
A power supply's size or noise has absolutely nothing to do with network performance. This is not to say that a PC power supply's noise cannot contaminate the ground, or that the ambient noise within a PC can't affect something like a sound card.
Back to the ASIO discussion
There is a whole forum over at head-fi regarding computers-as-source. I'm personally working on making a computer my primary source by ripping all my CDs to FLAC and feeding my monarchy DIP and respective DACs from the Toslink output. That's the easiest way to eliminate grounding/noise issues with PCs. I may eventually go the USB-to-S/PDIF route in the future. Most PCs have each individual USB port as it's own master port, so you shouldn't need to worry about any issues in the USB versus Firewire debate as long as your not trying to do bi-directional feeds over it (e.g. recording and playback over the same wire). Even then, on USB 2.0, you have a ton of bandwidth to play with, even as a "half-duplex" connection.
I really think this USB-versus-firewire disucssion is irrelevant. There is a very good article out there (perhaps linked to in this forum?) on how TI implemented their USB DAC/SPDIF chips, and why they work fairly well at what they do.
If the digital link is truly synchronous, there aren't any from the link itself. Duh.soundcheck said:
It's what's between the ears you can't trust. Time and again it's been demonstrated psychological bias has enormous power. The only way you can trust your ears is if you eliminate that bias, and blind testing is the only way to do that.
Indeed you don't lose anything. But you gain something: jitter. Even if you slave all circuits to the same one, you will still have jitter. Enjoy.
The optimal way is a fully asynchronous link to local memory on the DAC side that implements a FIFO with fully independent reads and writes, such that as the FIFO gets low it is refilled by the control requesting more data over the interface. Better yet, the FIFO will comprise multiple memory chips, such that the chip being synchronously read from for the DAC is different from the one being written to from the asynchronous link. This system then only depends on jitter created locally within the circuit, which can be extremely low. Any outside jitter can at most result in data loss, but that would really be an extreme case. Downside: cost and complexity of implementation.
In light of post #46, if this affects sound quality, there's something seriously wrong with your system.
That makes no sense unless you are talking about some bad hardware implemenation. Correct resampling with a good filter works regardless of the input and output frequencies. Such filtering is trivial to implement in software. So you may want to try using an audio editor or quality DSP plugin to resample your songs to the sound card's native frequency.kevinkr said:
I wonder how many people actually have systems with a noise floor low enough (and I mean the whole change, including speakers and listening environment) that it would make a difference. If you're dealing with 24-bit, then it's a complete non-issue as even DACs don't really achieve LSB performance in that case.Daveis said:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.