" ... Sadly, FastEddy, appeals to rationality or any attempt to objectify performance in this arena are only likely to excite a furore of objections based ultimately on no more satisfactory assertion than that it is impossible to absolutely sure about anything. ..."
"Truth is one, paths are many." - The Dahlia Lama
===
" ... chips available that convert Firewire signal to SPDIF or I2S? ..."
Refer:
http://focus.ti.com/docs/toolsw/folders/print/dem-dai1606.html (eval. board)
http://focus.ti.com/docs/prod/folders/print/tsb43ca43a.html (FW i/o)
But there are plenty of other makers as well of SPDIF converters. Just try for the 24 bit / 96K or better handling (Dolby 5.x or better)
As long as one is interested in the SPDIF/I2P interfaces, there is another device of serious interest: An HDMI Audio breakout box. If the HDMI chip is a pass through w/ 2 or more ports, then it could also be used for long line length extension and/or HDMI splitter ...
"Truth is one, paths are many." - The Dahlia Lama
===
" ... chips available that convert Firewire signal to SPDIF or I2S? ..."
Refer:
http://focus.ti.com/docs/toolsw/folders/print/dem-dai1606.html (eval. board)
http://focus.ti.com/docs/prod/folders/print/tsb43ca43a.html (FW i/o)
But there are plenty of other makers as well of SPDIF converters. Just try for the 24 bit / 96K or better handling (Dolby 5.x or better)
As long as one is interested in the SPDIF/I2P interfaces, there is another device of serious interest: An HDMI Audio breakout box. If the HDMI chip is a pass through w/ 2 or more ports, then it could also be used for long line length extension and/or HDMI splitter ...
I just read the topic on USB jitter.
"USB Jitter - How Much?? "
http://www.head-fi.org/forums/f46/usb-jitter-how-much-82591/
However, the jitter comparsion between USB and 1394 interfaces is anticipated.
"USB Jitter - How Much?? "
http://www.head-fi.org/forums/f46/usb-jitter-how-much-82591/
However, the jitter comparsion between USB and 1394 interfaces is anticipated.
FastEddy said:" ... Sadly, FastEddy, appeals to rationality or any attempt to objectify performance in this arena are only likely to excite a furore of objections based ultimately on no more satisfactory assertion than that it is impossible to absolutely sure about anything. ..."
"Truth is one, paths are many." - The Dahlia Lama
===
" ... chips available that convert Firewire signal to SPDIF or I2S? ..."
Refer:
http://focus.ti.com/docs/toolsw/folders/print/dem-dai1606.html (eval. board)
http://focus.ti.com/docs/prod/folders/print/tsb43ca43a.html (FW i/o)
But there are plenty of other makers as well of SPDIF converters. Just try for the 24 bit / 96K or better handling (Dolby 5.x or better)
As long as one is interested in the SPDIF/I2P interfaces, there is another device of serious interest: An HDMI Audio breakout box. If the HDMI chip is a pass through w/ 2 or more ports, then it could also be used for long line length extension and/or HDMI splitter ...
I'm not interested in boxes or ready made devices, but the chip that I could implement in my own DAC. The links you posted are of no use.
"And no excuse for bad spelling" - Dalai Lama 😉
" ... the jitter comparsion between USB and 1394 interfaces is anticipated. ..."
Generally accepted is that FireWire 1394a has almost no "jitter" to about a factor of 10X to 100x less than USB "jitter" and handshaking. This is why singers have trouble with USB mics verses FW interfaced mics.
USB handshaking problems like these also cause many other aspects of USB makers' "promises" to be suspect. Like the promise of 64 devices in a USB chain where 8 nodes are optimum, 16 nodes impractically slow, 20 or more nodes are unreliable. Please do not misunderstand USB's proper place in the digital world: It is perfect for keyboards, mice, scanners, printers, slow interfaces, thumb drives, single frame graphics, etc., basic I/O ... but not streaming of data, audio or video. For streaming data, audio and video, FireWire 1394a is actually faster than 1000baseT gigabit Ethernet
Generally accepted is that FireWire 1394a has almost no "jitter" to about a factor of 10X to 100x less than USB "jitter" and handshaking. This is why singers have trouble with USB mics verses FW interfaced mics.
USB handshaking problems like these also cause many other aspects of USB makers' "promises" to be suspect. Like the promise of 64 devices in a USB chain where 8 nodes are optimum, 16 nodes impractically slow, 20 or more nodes are unreliable. Please do not misunderstand USB's proper place in the digital world: It is perfect for keyboards, mice, scanners, printers, slow interfaces, thumb drives, single frame graphics, etc., basic I/O ... but not streaming of data, audio or video. For streaming data, audio and video, FireWire 1394a is actually faster than 1000baseT gigabit Ethernet
FastEddy, are you getting jitter confused with letency or "glitches" in audio? If not, I don't see how jitter would bother a singer (I am a singer)?
I mean, jitter is not really audible in an obvious way. A CD player for instance that has "high" jitter of say 1000ps (of which there are many) will still play a CD ok, but the same CD player with a clock upgrade that takes the jitter down to say 50ps should make it sound better.
Jitter is not a click, pop, or a freeze in audio.
I mean, jitter is not really audible in an obvious way. A CD player for instance that has "high" jitter of say 1000ps (of which there are many) will still play a CD ok, but the same CD player with a clock upgrade that takes the jitter down to say 50ps should make it sound better.
Jitter is not a click, pop, or a freeze in audio.
" ... FastEddy, are you getting jitter confused with letency or "glitches" in audio? ..."
Of course. But then the phone calls I get do as well. "Jitter" in quotes can lovingly be refereed to as anything involving a delay .... like enough that a singer will notice from the monitors from the digital record / monitor / playback source, which will throw many good singers into apoplexy and insist that the old analog equipment be hooked back up ... It is bothersome = just like that unpleasant delay in long distance phone calls.
I know what real jitter : ""Jitter is an unwanted variation of one or more characteristics of a periodic signal in electronics and telecommunications. ..." ... and USB jitter is serious enough that many folks spend way too much time messing about with USB chips and their peculiarities ... when choosing another protocol [like FireWire 1394a] would solve the problem = no worry, mate.
That CD player & chips you mention with the 1000 peco second [1 microsecond] "jitter" is an instance where USB v. FireWire is not the problem ... An Oxford 911 I/O equipped dual port USB & FireWire bridge hooked to that good CD & chips would give you an opportunity to see the minor differences in digital pass through. ... But we are talking about DACs, and no matter how good the USB DAC is that you may eventually connect to that CD / DVD drive, et al, it is not going to nearly equal the FireWire DAC/ADC results after the digital audio is passed through your favorite CPU ... FW does a better job of recording (ripping) too = much better. THX anyone?
= FireWire [over fiber !]
Of course. But then the phone calls I get do as well. "Jitter" in quotes can lovingly be refereed to as anything involving a delay .... like enough that a singer will notice from the monitors from the digital record / monitor / playback source, which will throw many good singers into apoplexy and insist that the old analog equipment be hooked back up ... It is bothersome = just like that unpleasant delay in long distance phone calls.
I know what real jitter : ""Jitter is an unwanted variation of one or more characteristics of a periodic signal in electronics and telecommunications. ..." ... and USB jitter is serious enough that many folks spend way too much time messing about with USB chips and their peculiarities ... when choosing another protocol [like FireWire 1394a] would solve the problem = no worry, mate.
That CD player & chips you mention with the 1000 peco second [1 microsecond] "jitter" is an instance where USB v. FireWire is not the problem ... An Oxford 911 I/O equipped dual port USB & FireWire bridge hooked to that good CD & chips would give you an opportunity to see the minor differences in digital pass through. ... But we are talking about DACs, and no matter how good the USB DAC is that you may eventually connect to that CD / DVD drive, et al, it is not going to nearly equal the FireWire DAC/ADC results after the digital audio is passed through your favorite CPU ... FW does a better job of recording (ripping) too = much better. THX anyone?
An externally hosted image should be here but it was not working when we last tested it.
= USB
Thanks for clearing up what you were referring too when talking about jitter. I am not aware which protocol (USB or Firewire) has the lowest inherent jitter (digital deviation)? I assume Firwire is better though, as the Denon Link etc are derived from Firewire. It's a shame there has not become a Firewire based solution for consumer digital audio.
Most people looking at DAC's on here are wanting them for Hi-Fi purposes and are not concerned with latency at all. Of course interrupted audio (pauses or skips etc) would be a problem and I'm sure that if there were more "Hi-Fi style" Firewire DAC's on the market, they would be was as popular or more so than the USB ones that exist already. However, I have not heard of anyone on any Hi-Fi forum claim that they have glitches with their USB DAC's.
For music production, the device is being taxed a lot more, as it will be working with multiple channels of audio and duplexing etc, but for Hi-Fi playback, it just has to play back one stereo (in most cases) track, which does not prove a problem with USB.
I'm sure that when USB is implemented correctly, it must be very good, otherwise Benchmark would have gone with Firewire for their VERY popular DAC-1.
I would love to go the Firewire route as I have always been a fan of it (I am a recording musician as well as a video editor). I have not used either a Firewire or USB2 recording interface (only PCI), so I am not aware of any issues with USB. It is good to know, as I will keep that in mind when looking for a recoding interface.
The JAVS DAC-1 Overture I am looking at interests me as a USB DAC & USB to SPDIF converter, however, I would prefer it to be Firewire as opposed to USB.
Thanks
Most people looking at DAC's on here are wanting them for Hi-Fi purposes and are not concerned with latency at all. Of course interrupted audio (pauses or skips etc) would be a problem and I'm sure that if there were more "Hi-Fi style" Firewire DAC's on the market, they would be was as popular or more so than the USB ones that exist already. However, I have not heard of anyone on any Hi-Fi forum claim that they have glitches with their USB DAC's.
For music production, the device is being taxed a lot more, as it will be working with multiple channels of audio and duplexing etc, but for Hi-Fi playback, it just has to play back one stereo (in most cases) track, which does not prove a problem with USB.
I'm sure that when USB is implemented correctly, it must be very good, otherwise Benchmark would have gone with Firewire for their VERY popular DAC-1.
I would love to go the Firewire route as I have always been a fan of it (I am a recording musician as well as a video editor). I have not used either a Firewire or USB2 recording interface (only PCI), so I am not aware of any issues with USB. It is good to know, as I will keep that in mind when looking for a recoding interface.
The JAVS DAC-1 Overture I am looking at interests me as a USB DAC & USB to SPDIF converter, however, I would prefer it to be Firewire as opposed to USB.
Thanks
J. Dunn produced a paper on firewire and jitter. It's a bit too technical for me, but it might interest you: http://www.nanophon.com/audio/1394_sampling_jitter.pdf
" It's a bit too technical for me, but it might interest you: http://www.nanophon.com/audio/1394_sampling_jitter.pdf "
Me too ... but it was reports like these that got the pros interested in FireWire in the first place. Apple "invented" FireWire / IEEE1394 / iLink (1995) as an upgrade to alternate protocols that could not perform the tasks of reliable, peer to peer, bi-directional data transfers for video, audio, co-processing, CGI rendering, etc. If the chip set is right, FW can transfer the data from up to 8 higher resolution web cam feeds on a single cable and everyone in the industry has seen FireWire play four DVD movies at once across a single connection at the CES, AES and IEEE trade shows. 😱
Me too ... but it was reports like these that got the pros interested in FireWire in the first place. Apple "invented" FireWire / IEEE1394 / iLink (1995) as an upgrade to alternate protocols that could not perform the tasks of reliable, peer to peer, bi-directional data transfers for video, audio, co-processing, CGI rendering, etc. If the chip set is right, FW can transfer the data from up to 8 higher resolution web cam feeds on a single cable and everyone in the industry has seen FireWire play four DVD movies at once across a single connection at the CES, AES and IEEE trade shows. 😱
Thanks for the link:
A lot of it is way over my head though. Seems avery good and clear paper though for thjose who do understand it and may be someone can summerise it for us? Is Firewire better than USB regarding jitter?
Cheers
A lot of it is way over my head though. Seems avery good and clear paper though for thjose who do understand it and may be someone can summerise it for us? Is Firewire better than USB regarding jitter?
Cheers
" ... Is Firewire better than USB regarding jitter? ..." Generally, definitely, yes, by a factor of 10x or more.
So, FastEddy, does your company make any low jitter (accurate clock) Firewire based DAC's or Firewire to SPDIF converters?
I'm very pleased with my Xindak DAC-5 and just want a way of getting audio from my PC into that DAC (only has Coaxial and Optical SPDIF inputs) with the least jitter possible. Has to work with 2 channel audio up to 24/96 (192KHz is a bonus).
Could anyone add Firewire input to my DAC-5?
Cheers
I'm very pleased with my Xindak DAC-5 and just want a way of getting audio from my PC into that DAC (only has Coaxial and Optical SPDIF inputs) with the least jitter possible. Has to work with 2 channel audio up to 24/96 (192KHz is a bonus).
Could anyone add Firewire input to my DAC-5?
Cheers
" .... does your company make any low jitter (accurate clock) Firewire based DAC's or Firewire to SPDIF converters? ..."
This is a bit mercenary :
We distribute but do not manufacture anything. http://industrialcomponent.com / USBStuff.com / FireWireStuff.com / 3DotAudio.com and more (Online catalogs for USB and FireWire since 1996 ... before USB and FireWire were available from Apple. 😀 )
BUT we do recommend devices from others as well ... like Rolandus.com/edirol/ and Tascam.com, etc. We have many of the M-Audio.com and EchoAudio.com devices in our catalog(s) ... My personal favorite is the AudioFire 4 @ http://echoaudio.com/Products/FireWire/AudioFire4/index.php ... but the truth is that any above make devices for 24 bit / 96K multichannel I/O and all have noise floors greater than 100 db and bandwidths better than 105 db.
EOMA = end of mercenary announcement. 😎
(I would like to purchase commercial space in the diyAudio.com vendor's bazaar but have had to settle for simple user contributions so far.)
This is a bit mercenary :
We distribute but do not manufacture anything. http://industrialcomponent.com / USBStuff.com / FireWireStuff.com / 3DotAudio.com and more (Online catalogs for USB and FireWire since 1996 ... before USB and FireWire were available from Apple. 😀 )
BUT we do recommend devices from others as well ... like Rolandus.com/edirol/ and Tascam.com, etc. We have many of the M-Audio.com and EchoAudio.com devices in our catalog(s) ... My personal favorite is the AudioFire 4 @ http://echoaudio.com/Products/FireWire/AudioFire4/index.php ... but the truth is that any above make devices for 24 bit / 96K multichannel I/O and all have noise floors greater than 100 db and bandwidths better than 105 db.
EOMA = end of mercenary announcement. 😎
(I would like to purchase commercial space in the diyAudio.com vendor's bazaar but have had to settle for simple user contributions so far.)
FastEddy
Have a look at this thread I started on another forum. It seems that firewire is not the way to go at all according to a few knowledgeable people.
The main reason is that Async is not supported for Firewire by any OS, but is with USB.
http://www.diyhifi.org/forums/viewtopic.php?f=2&t=1650
Have a look at this thread I started on another forum. It seems that firewire is not the way to go at all according to a few knowledgeable people.
The main reason is that Async is not supported for Firewire by any OS, but is with USB.
http://www.diyhifi.org/forums/viewtopic.php?f=2&t=1650
The EMU 1212M and 1616M seem to have a lot going for them.
1616M :-
Six channels analog including 2 mic preamps @ 24/192, lots of sync options, SMPTE/LTC/MTC with daughtercard or sync to S/PDIF, AES/EBU, ADAT, local crystal clock, signal-to-noise (120dB) and THD + noise to die for, I could go on...
Course they're PCI, so you can't plug them into your laptop. but they undercut most if not all of the Firewire 24/192 offerings pricewise.
w
1616M :-
Six channels analog including 2 mic preamps @ 24/192, lots of sync options, SMPTE/LTC/MTC with daughtercard or sync to S/PDIF, AES/EBU, ADAT, local crystal clock, signal-to-noise (120dB) and THD + noise to die for, I could go on...
Course they're PCI, so you can't plug them into your laptop. but they undercut most if not all of the Firewire 24/192 offerings pricewise.
w
" ... Either Firewire or USB have the potential for extremely low jitter if they are implemented asynchronously, as Gordon has done. There are still plenty of pitfalls to achieving low-jitter, but at least this has the best chance of it. ... I suspect that USB will take the lead again in 2009, when more asynchronous interfaces are available, and 24/192 is supported. ..." - SOURCE is audioengr @ DiyHiFi.org in England. [ http://www.diyhifi.org/forums/viewtopic.php?f=2&t=1650 ]
Don't count on this. The USB 1.1 and 2.0 specifications are now "cast in stone" and will not be changing in the foreseeable future. And most DAC chip makers will not be upgrading their chips to accommodate a better "jitter" or latency specification, mostly because USB technology and topography will not easily lend itself to any increases in performance in these areas = probably will never happen.
The USB 2.0 upper limit of 24bit/96k stereo and/or "compressed" Dolby 5.x is it fellers, and the "jitter" and latency specs are as good as it is going to ever get with very modest improvements if any at all.
Best bet of achieving reliable, low jitter, low latency, 24bit / 192K stereo or multichannel audio, either Dolby 5.x or 7.x or THX, for now and the foreseeable future, whether asynchronous interface or the various other transfer protocols, is FireWire.
(As for USB taking any kind of lead in professional recording and playback, there is always FireWire 800 (1394b) and the newer 1.6 and 3.2 gigabit FireWire. FireWire 800 is already more than twice as fast as 1000BaseT Gigabit Ethernet and almost 3 times as fast as any USB available, in spec or out. http://en.wikipedia.org/wiki/Firewire )
Don't count on this. The USB 1.1 and 2.0 specifications are now "cast in stone" and will not be changing in the foreseeable future. And most DAC chip makers will not be upgrading their chips to accommodate a better "jitter" or latency specification, mostly because USB technology and topography will not easily lend itself to any increases in performance in these areas = probably will never happen.
The USB 2.0 upper limit of 24bit/96k stereo and/or "compressed" Dolby 5.x is it fellers, and the "jitter" and latency specs are as good as it is going to ever get with very modest improvements if any at all.
Best bet of achieving reliable, low jitter, low latency, 24bit / 192K stereo or multichannel audio, either Dolby 5.x or 7.x or THX, for now and the foreseeable future, whether asynchronous interface or the various other transfer protocols, is FireWire.
(As for USB taking any kind of lead in professional recording and playback, there is always FireWire 800 (1394b) and the newer 1.6 and 3.2 gigabit FireWire. FireWire 800 is already more than twice as fast as 1000BaseT Gigabit Ethernet and almost 3 times as fast as any USB available, in spec or out. http://en.wikipedia.org/wiki/Firewire )
I think the point is that without an asynchronous protocol, truly low digital deviation (jitter) is not possible and USB supports this and Firewire doesn't (when used with a PC/Mac OS). So, using a bulk protocol, low jitter (say below 100ps) is not easy with either USB or Firewire.
Currently, using other protocols to get the best out of the standards, Firewire probably is better than USB (Benchmark and Empirical may be better), but when more manufacturers work out easy ways to use the current chips (asynchronously) or get their hands on the new chipsets that are being worked on to allow easy programming to work asynchronously with USB, then we should see USB devices that surpass Firewire.
Also, may be USB3 will be the way forward?
I am no expert on this subject, just been trying to gather info, so my assumptions may be completely off.
Currently, using other protocols to get the best out of the standards, Firewire probably is better than USB (Benchmark and Empirical may be better), but when more manufacturers work out easy ways to use the current chips (asynchronously) or get their hands on the new chipsets that are being worked on to allow easy programming to work asynchronously with USB, then we should see USB devices that surpass Firewire.
Also, may be USB3 will be the way forward?
I am no expert on this subject, just been trying to gather info, so my assumptions may be completely off.
" ... I think the point is that without an asynchronous protocol, truly low digital deviation (jitter) is not possible and USB supports this and Firewire doesn't ..."
Actually FireWire does support an asynchronous protocol, just not the one that the software works with. (It also supports several others.)
From http://en.wikipedia.org/wiki/Firewire :
" ... Enhancements (IEEE 1394a-2000)
An amendment IEEE 1394a was released in 2000[17], which both clarified and enhanced the original specification. It added in support for asynchronous streaming, quicker bus reconfiguration, packet concatenation, and a power saving suspend mode. Enhancements (IEEE 1394a-2000) ..."
But we shouldn't get wrapped around some other software driver writer's axle over this. If you are having to configure special software for hand made devices, be my guest ... but for us mortals, the packaged standard drivers should suffice since they are field tested and "known good". 😉
=====
FYI: " ... Aircraft
IEEE 1394b is used in military aircraft, where weight savings are desired. Developed for use as the data bus on the F-22 Raptor, it is also used on the F-35 Lightning II.[24] NASA's Space Shuttle also uses IEEE 1394b to monitor debris (foam, ice) which may hit the vehicle during launch.[24] This standard should not be confused with the unrelated MIL-STD-1394B. ..."
[The real reason? FireWire is faster and more reliable than USB, EtherNet, iSCSI, fiberchannel (fibrechannel), etc. ... and Mil Specs / NASA could not allow the latency and jitter associated withn the other hardware protocols.]
=====
" ... Comparison to USB
Although high-speed USB 2.0 nominally runs at a higher signaling rate (480 Mbit/s) than FireWire 400, typical USB PC-hosts rarely exceed sustained transfers of 280 Mbit/s, with 240 Mbit/s being more typical. ..."
... = bandwidth = 24 bit/96k, unidirectional only.
Actually FireWire does support an asynchronous protocol, just not the one that the software works with. (It also supports several others.)
From http://en.wikipedia.org/wiki/Firewire :
" ... Enhancements (IEEE 1394a-2000)
An amendment IEEE 1394a was released in 2000[17], which both clarified and enhanced the original specification. It added in support for asynchronous streaming, quicker bus reconfiguration, packet concatenation, and a power saving suspend mode. Enhancements (IEEE 1394a-2000) ..."
But we shouldn't get wrapped around some other software driver writer's axle over this. If you are having to configure special software for hand made devices, be my guest ... but for us mortals, the packaged standard drivers should suffice since they are field tested and "known good". 😉
=====
FYI: " ... Aircraft
IEEE 1394b is used in military aircraft, where weight savings are desired. Developed for use as the data bus on the F-22 Raptor, it is also used on the F-35 Lightning II.[24] NASA's Space Shuttle also uses IEEE 1394b to monitor debris (foam, ice) which may hit the vehicle during launch.[24] This standard should not be confused with the unrelated MIL-STD-1394B. ..."
[The real reason? FireWire is faster and more reliable than USB, EtherNet, iSCSI, fiberchannel (fibrechannel), etc. ... and Mil Specs / NASA could not allow the latency and jitter associated withn the other hardware protocols.]
=====
" ... Comparison to USB
Although high-speed USB 2.0 nominally runs at a higher signaling rate (480 Mbit/s) than FireWire 400, typical USB PC-hosts rarely exceed sustained transfers of 280 Mbit/s, with 240 Mbit/s being more typical. ..."
... = bandwidth = 24 bit/96k, unidirectional only.Yeah, sorry, I did know that Firewire does support async, but just that current OS's don't.
I hope that soon there are very low jitter USB or Firewire (I really don't care which) DACs (below 50ps) at affordable prices. If manufacturers can make a standard allowing the DAC to act as the master clock and the sourse the slave, then we will truly have great digital audio.
With regards to latency for those who record etc. As all current devices have latency free monitoring, I don't see this as an issue anyway.
I hope that soon there are very low jitter USB or Firewire (I really don't care which) DACs (below 50ps) at affordable prices. If manufacturers can make a standard allowing the DAC to act as the master clock and the sourse the slave, then we will truly have great digital audio.
With regards to latency for those who record etc. As all current devices have latency free monitoring, I don't see this as an issue anyway.
- Status
- Not open for further replies.