Longest Firewire cable being successfully used with if/FW-DM?

wm_b

Veteran
Joined
Jan 24, 2013
Messages
129
Karma
22
Gear owned
DM3200, DM4800 and DM24
I realize this is subject to many variables but I'm curious what kind of experiences people have. Also, is there a brand of cable that's particularly good? Planning some remodeling and I'd like to conceal some cabling which always eats up length.

Cheers and happy weekend!
 
Last edited:
If wikipedia still is an authority, 4.5meters @ 400Mbits/s are OK. I find this a bit odd - in my last setup I had 7 meters, and no problems. Now - in another location - I use 2.5 meters. I don't know, if there's an absolute limit (you can always go for repeaters).

In my experience the brand has not such an impact as one may expect - either they work or they don't; mostly they do ;-) Over the years for different scenarios I might have used about 50 different cables in different locations with different length, and maybe never used the same brand twice. At the moment I can't remember any drop out I ever had.
 
Keep in mind that cables of any kind that carry and use clocking data should always be as short as possible. Don't put all your faith in some lame ass WIKI page. Not all Firewire devices are designed or created equal or are spec compliant as to what Firewire cable length you can get away with.

I forget what cable length the DM/IFFW card came with, but that would be length that you likely should only be using as that is what Tascam tested the DM mixer with and would only be officially supporting with their software and drivers. unless that have stated over wise.

Of course you can do whatever you want.
 
One thing about being a test pilot on a computer is that generally no one gets hurt. I hear what you're saying about staying within specifications but these specs are made to insure consistent performance across many, many systems. Right now I'm using a 5 meter cable for a couple years and it works flawlessly. I have a machine room and the computer is far enough from the mixer that I need something longer than 2 meters - I tried a 5 meter cable and it worked. If 10 meters can work I might have some options that 5 won't allow. I'm seeking some anecdotal experience and understand that not all computers or cables are equal performers.

I'm not totally sure how the relationship between the if/fw-dm mkII and the firewire adapter on the computer works but my console is clocked from an apogee converter that's connected via a 1 meter cable. Everything with that is rock steady. I use it everyday without issue.
 
I can tell you that I am using a unibrain cable that is at least 10 meters for an audio device that does 24 channels and I am having no problems (I think it is 50'). If I get a chance I can try it with the DM4800. I plan to move the computer out of the control room next build so it will be nice to know for sure that it works.
 
I'll also point out that a long Firewire cable that works for one uses in a specific setup may not work for another user under different conditions.

And while using such a long cable "may work" I would only trust such a thing if I were to scope out the signals to look for degrading and/or sloppy clock edges that can contribute to increase in clock Jitter that can happen from using long cables. The ability for a user to hear the artifacts of jitter increase from cable length difference would depend on many factors.
 
I think my first post on this thread expresses my awareness of subjective outcomes.

You bring up an interesting topic; jitter. In almost 20 years of digital recording I've never known what jitter is or sounds like. I've heard incorrectly clocked systems that have snappy pops and clicks. I've heard stuttering audio when an over taxed system is trying to play back a project. What is jitter and where can I hear some to know what it sounds like.

Furthermore, is the data relationship between the host PC subject to the same linear priority of the audio streams in the converter/mixer relationship. Since there's a buffer doesn't that mean the data is read, prepared and then sent as opposed to being literally accessed in real time like a stylus in the groove of a LP. if the supply of data is adequate then doesn't that mean the system should play it back correctly according to the system clock? Where does the jitter enter the equation?
 
Last edited:
There are plenty of places on the web to research and understand what jitter is so I'll refrain from rehashing that here.

Most basically, if you send/receive a digital clock from one digital audio source to another, you have the potential of inducing jitter. When the clock signal degrades such as it often does over a long cable run, one of the artifacts can be jitter.

Onc example of jitter would be using a high quality external clock as the master clock for some old 1st generation A2D converters where the sound quality was noted as being better when using an external clock. Better because of less jitter among a few other things.

Note that using an external clock does not always make any converter sound better because it is not just about using a great high quality external master clock. The device clocking to it also has to be able to accurately re-sync to that clock and do it more accurately than using it's internal clock to be of any real value and that rarely happens in decent pro audio gear. In most modern pro audio gear these days, the internal clock quality is more accurate than it's re-sync circuit (usually a PLL) is capable of when used with an external clock. There are of course exceptions.
 
As I understand the job of the FW cable, it isn't carrying a digital audio format, it's carrying data as specified by the 1394 specification. If there isn't a clock source locked with the computer over firewire that is directly from the digital audio clocking system can a long data cable with sufficient bandwidth cause jitter in a digital audio system? There might be a point where the bandwidth of the firewire cable is exceeded and all sorts of things might start going wrong but if the data stream is within the range of the required bandwidth how could it be a cause for jitter?
 
  • Like
Reactions: Rockum
Well, we don't really know what is in the data stream of the Firewire cable for the IFFW card in the DM mixer. I make an assumption that it has and uses audio clock data. If I were to scope out the signals I could find out. If I were inclined to use a longer Firewire cable I could test and measure both and come to valid conclusions, but I'll just stick with the shorter cable for as long as I'm still using the IFFW card as I'm moving on to 4 UA Apollo Thunderbolt setup anyway.

I'm more involved in past 5-years in other protocols such as Thunderbolt, USB 3.1, AVB, VoIP and few others that are not currently main stream but I do remember scoping signals on a 1m and 4.5m Firewire cables years ago for some audio product development testing and noting clock degradation and a difference in the PHY_DELAY nodes between the cables that points to Jitter due to cable length. Longer cables than 4.5m would be expected to measure even worse In researching the issue at the time I came across a few AES papers that went into plenty of detail about it that you could likely look up. One paper I remember was from Daniel Weiss of Weiss Engineering who not only talked about cable length jitter but of cable properties and such who I trust as someone who knows more than a thing or two about clocks, jitter and high end pro audio design.
 
What is jitter.........[?]

Listen to a MUSIC MP3 done at 64kbs. You'll hear plent...ttt.....tt....yy...yyy....eee....:)

CaptDan

Ah, the sound of Sirius/XM radio, I get it.
 
Hah!

Well - not ALL of their stations. A few are pretty hi-rez - though there's got to be some 'compression' happening; you don't stuff a zillion stations of bandwidth into a satellite bound data stream without some, eh? :rolleyes:

I'm thinking more about the 'classic' venues - such as the [thankfully] deceased 'MP3-Con.'
But to be fair, when that vintage of online audio was going on, a majority of victims - er - 'listeners' - were participating via dial-up modems, a virtual circus of jitter, jerk and pop. :)

I suppose a modern corollary would be the 'plebian-quality' of 'Ewe-Toob' material. Those are replete with 'RealAudio(tm)' old-school style jitter. But I'd better shut up; some software tyro might be reading and get the idea to develop a plug in model to replicate it deliberately. :)

CaptDan
 
Hah!

Well - not ALL of their stations. A few are pretty hi-rez - though there's got to be some 'compression' happening; you don't stuff a zillion stations of bandwidth into a satellite bound data stream without some, eh? :rolleyes:

CaptDan

To stray off topic for a moment about Sirius/XM - their streaming service has far superior sound to their "from outer space" service. My SO listens to the mainstream country station (which I think would expect to be higher quality) on the radio in her car and it sounds really bad. I listen to the android app and everything is much better, still compressed but a snare drum and high hat sound like different instruments. It's strange to me that they don't promote themselves on that part of the service.
 
It's strange to me that they don't promote themselves on that part of the service.

Threaten to cancel your subscription(s) immediately and watch how their promotion machine leaps into service. :)

CaptDan
 

New threads

Members online

No members online now.