Peter C wrote:Hi cc,
You are quite right, thank you.
1. You had mentioned this before, but I didn't know what to google for and could find no further info.
2. "isochronous firewire" is indeed the one. I found a lot of stuff, most of it rather old, and crucially nothing that:
2.1 Described how abritration works to provide isochronous operation when multiple devices are using the firewire bus
2.2 Specified whether the drivers have to be written to support isochronous operation, (I can't believe the hardware handles it all) and if so whether this feature is actually available on Windows platforms
2.3 Told me how to go about writing a driver for (say) a soundcard so that it used the isochronous firewire feature.
I guess the lack of detailed info is probably because this is a rather specialised subject. I believe the isochronous stuff in firewire works just fine - it was a big driver behind developing the standard. Yamaha's mLan (which is a layer on top of firewire) uses isochronous channels.
I don't know whether there is support in Windows though that would let you write a soundcard driver - probably not (yamaha's mLan driver probably hooks in at a lower level). Judging from what google gives back it looks like OSX has better support, so maybe Vista will too.
The reason that I brought it up is that PCIe's QoS support isn't an advantage over firewire. Both of them will need software support to work which probably puts it at the mercy of MS.
3. But assuming all that works just fine, it's useless unless/until the firewire port on the PC is a PCIe device. PCI has no QoS capability.
Not true - if the firewire is built into the southbridge, or if it is on a dedicated PCI bus then there won't be a problem.
Having said all that though, remember Windows can not give any guarantees about anything (for that you need a Real Time OS). So, even if PCIe or firewire can guarantee that the data is there on time, it still possible that the CPU will be off doing something else and miss it!