Firewire bandwidth issues

[jabulani jonny]

This is just a curious question thrown to all those that may know...Currently I'm using an external firewire 7200 rpm 8mb cache HD for all of my audio and the internal 7200 rpm drive for my recording application. I am connecting the HD to the Firewire port on the computer and the HD using a PCMCIA FW adapter with three ports. If I plug both the HD and my M-Audio 1814 into the PCMCIA card I get clicks and pops. Using the different ports I don't really get any and everything's fine. I understand that the PCMCIA slot only gets a certain bandwidth and the two devices would share that.

Now my question is this. If I get another HD for samples, should I daisy chain those HD's or just plug it into another port on the PCMCIA card and will it handle it? I mean I see people using mulltiple HDs through Firewire and I'm curious as to how they're connecting everything. Thx!

Jonathan

 

[iratecaller666]

Bandwidth

PCMCIA cards have about the same bandwidth as old PCI slots.

Since I use a PCMCIA firewire card for capturing video at 720*480 @ 32 bpp uncompressed, this translates to about 250mbps (250 mega bits)

A single PCMCIA based firewire port can be used for several hard drives.

HOWEVER, a multi-chanel firewire audio interface should have it's own firewire port / bus, since accesses to hard drives connected on the same bus will interrupt the data flow from the audio interface.

It's not suprising that you get clicks.

The firewire bus bandwidth is much more than 2 hard drives.

Feel free to daisy chain both drives on the same port.

The reason you're getting pops and clicks is simply that the data flow from your audio interface must be interrupted when your system writes to your firewire hard drive.

The audio interface and hd being on the same bus, still requires them to be accessed independantly.

You'll need a dedicated firewire bus for your audio interface.


Tristan

 

[jabulani jonny]

Thanks Tristan, that's what I'm doing now and it works fine. I was just curious about adding another drive. I figured the data transfer would be fine for HD uses, but wasn't sure. Thx!

 

[dgatwood]

HOWEVER, a multi-chanel firewire audio interface should have it's own firewire port / bus, since accesses to hard drives connected on the same bus will interrupt the data flow from the audio interface.

It's not suprising that you get clicks.

Actually, it's very surprising. FireWire is almost completely immune to that sort of issue unless either Windows has a seriously broken FireWire inplementation or you have some really weird hardware bugs.

FireWire audio is sent using a very robust isochronous mode. In that mode, bandwidth is basically guaranteed, hardware bugs notwithstanding. Once you have an isoch reservation, the only way you should be able to get pops and clicks is if that isoch reservation gets cancelled, which would cause a chunk of audio data to get delayed.

Assuming Windows obeys the FireWire spec correctly, the only way an isoch reservation can be cancelled in FireWire (hardware failures notwithstanding) is if the bus topology changes and two free-running busses get merged into one (i.e. two computers with FireWire interfaces that both are running at over 200Mbps) get connected together by a FireWire cable on the same buses, thus forming a single, shared FireWire bus with >400Mbps total isoch reservations.... Obviously, that isn't happening here.

I suppose it could also be caused by a bad FireWire cable or other electrical noise causing data loss and retransmission. I think it could also be caused by the FireWire hard drive causing a bus reset, but if that's the case, you should pull the hard drive out of the case and toss the case in a dumpster, since it is likely to have major performance problems....

Bottom line is that such problems make me strongly suspect that some piece of hardware doesn't do isoch correctly, though I couldn't begin to guess whether it's a bug in the M-Audio firmware or the FW card's firmware/hardware. Are you using the latest firmware for that interface?

BTW, in all likelihood, there are probably only two firewire busses on the card shared among the three ports.

 

[jabulani jonny]

Hmmm....dgatwood. I kind of follow you, but not about the case issue. I'll have to check the firmware for the PC card. It is a TI chipset so I'm good there. The external drive is a Seagate 160 gb 7200 rpm 8mb cache FW drive in just a basic external case with power supply. I do mobile recording on a laptop so this is what I use, I couldn't afford a Glyph drive at the time.

 

[iratecaller666]

hrm.

dgatwood, good comment man. I never cease to learn. Not being sarcastic either.

You're probably best suited to answer my question then. Just trying to get a better understanding.

I understand guaranteed bandwidth and isoch reservation (i think, lol) , but transfers to and from a hard drive do take a finite amount of time. Bandwidth is guaranteed to the device, but is instantaneous, (virtually) zero latency access guaranteed?

What I'm asking is, is the data buffer sent to/from hard drives small enough that it wouldn't significantly impact the audio subsystem? And, the transaction overhead, how much time does it take for Windows to talk to a hard drive though the firewire bus, given that device is really an IDE drive?

That transaction time, if any, would be roughly how long the bus could 'lock' into one device without servicing any others. The average bandwidth is still guaranteed of course, but each device must be serviced independantly right?

If this is a matter of a few hundread microseconds, then it definately shouldn't be a problem, given that the audio host would buffer at least a couple of 'audio buffers' to prevent clicks from hapenning.