You are here

Martin's PCIe Article

Page 4 of 4

Re: Martin's PCIe Article

PostPosted: Wed Nov 23, 2005 3:18 pm
by Peter C
Hi Martin,

That's what we are looking for, no question.

Thats what the manufacturers will be claiming, I'm sure, because that's what QoS means.

Will the cards appear? Will they work as advertized. Will the world suddenly become a cleaner, brighter happier place.

I understand your ;) (skepticism?) but I travel in hope; and I do beleive thet the issues with PCIe itself were sorted out with the first generation of graphics cards. The volume and the motivation was there...



Peter

Re: Martin's PCIe Article

PostPosted: Wed Nov 23, 2005 6:06 pm
by Wurlitzer
Whats "QoS"?

Re: Martin's PCIe Article

PostPosted: Wed Nov 23, 2005 7:40 pm
by Peter C
Quality of Service.


It means that the hardware is able to offer guaranteed response times/latency, which is what is required for realtime applications like streaming audio or video.


Peter

Re: Martin's PCIe Article

PostPosted: Wed Nov 23, 2005 8:18 pm
by *INACTIVE USER*
I have seen sata raid controllers on pci-e and I'm sorry I didn't get one then.

Re: Martin's PCIe Article

PostPosted: Thu Nov 24, 2005 1:23 pm
by spjessop
Peter C wrote:Will the cards appear? Will they work as advertized. Will the world suddenly become a cleaner, brighter happier place.

The might appear, but based on observations of this industry it's going to take a lot of effort to get them to work.

I wish is was going to be easy though!

Re: Martin's PCIe Article

PostPosted: Thu Nov 24, 2005 4:17 pm
by Martin Walker
Well I'm becoming convinced enough about PCI Express soundcards to be strongly considering upgrading to a PCI Express equipped motherboard so I'll be able to review them when they're released :crazy:


Martin

Re: Martin's PCIe Article

PostPosted: Thu Nov 24, 2005 4:47 pm
by cc.
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!

Re: Martin's PCIe Article

PostPosted: Thu Nov 24, 2005 9:03 pm
by Jim Y
Thing with pci soundcards is the DMA business. Rather than being at the mercy of the driver acting on an interupt (which is where most troubleshooting is focused), it would appear each samples transport depends on a single DMA "cycle".

I gather this after having tracked down a .pdf datasheet for the Envy24HT pci controller. It says (as I read it) that all channels are handled in a DMA transfer of 32x 32bit words. The number of words can be reduced if fewer than the maximum channels are employed, but I doubt this is done with the M-audio driver for example, as it caters for all sizes of interfaces. 32bits per channel are always used, whatever the audio format.

www.alsa-project.org/alsa/ftp/manuals/icensemble/Envy24HT091DS.pdf

If the driver has no control over the detailed behaviour of the DMA controller and the samples are sent as individual DMA transfers, there is no opportunity for error detection.
The driver can only assume the buffer contains all of the samples.

For me, this goes some way to explain why there is no 100% correlation between gapping problems and driver buffer size or IRQ assignment. The DMA system is relied upon to do the bulk of the fetching and carrying all by itself.

Re: Martin's PCIe Article

PostPosted: Fri Nov 25, 2005 12:56 am
by Peter C
cc. wrote:
Peter C wrote:
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.


But I don't beleive it is. The Firewire is a PCI device (i.e. attached to the PCI bus) on every PCI mobo I have used. I suspect it's still attached to the PCI bus on PCIe mobos, thoiugh that will have to change.


Peter