<br><br><div class="gmail_quote">On Sun, Feb 10, 2013 at 7:38 PM, Len Ovens <span dir="ltr"><<a href="mailto:len@ovenwerks.net" target="_blank">len@ovenwerks.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Sun, February 10, 2013 3:03 pm, Paul Davis wrote:<br>
> On Sun, Feb 10, 2013 at 5:58 PM, Len Ovens <<a href="mailto:len@ovenwerks.net">len@ovenwerks.net</a>> wrote:<br>
><br>
>><br>
>><br>
>> Two linux drivers to consider. The PCIe stuff in the kernel is probably<br>
>> optimized for throughput to make the best use of Video cards, fast ether<br>
>> net, etc. Means larger chunks of data for less overhead. Maybe higher<br>
>> latency too. It shouldn't be as it is faster than PCI which handled<br>
>> things<br>
>> just fine. The extra throughput should actually help for higher channel<br>
>> counts. (from reading though some of the docs on netjack)<br>
>><br>
><br>
> not really. the drivers for RME devices are PCI-species independent. the<br>
> PCI bus doesn't really exist for them, which is why the same driver can<br>
> interact with the (old) cardbus version as if it is directly on the bus.<br>
> drivers see address spaces and registers, not the bus.<br>
<br>
</div>Ok, so what I get from this is that the CPU sees a PCIe device in the same<br>
way it sees a PCI device. Yet I know from reading the specs on both the<br>
PCI to PCIe bridge and the MB chip sets, that there is some firmware<br>
involved at both ends.</blockquote><div><br>that would likely be in the chipset that interacts with the bus. device drivers for particular PCI(.) devices do not interact with this level of hardware (in general).<br> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This may not be something that is run by the CPU<br>
itself (though it could be) but something that could be run by another<br>
processor in the glue logic itself. It may rather be part of the bios. I<br>
don't know. Most of the PCI(e) sound cards have a DSP with some sort of<br>
firmware as well.</blockquote><div><br>RME devices do not. they use Xilinx FPGA chips. the firmware (the actual firmware) is on an eprom that is surface mounted.<br><br>personally, i consider audio interfaces with onboard DSP to be a mostly-bad design. if i wanted DSP, i'd buy some kind of processor for that. i don't want a decade old DSP chip cluttering up my audio interface - my hammerfall cards are now 13 years old and still working perfectly, unaffected by the fact that DSP technology has moved on.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> How much all of this interacts I don't know. What I do<br>
see is a lot of brand new MBs that handle sound badly.<br></blockquote><div><br>i don't know of any MBs that in and of themselves handle sound badly (these days, anyway). the problems come from a different set of levels (a few notes on this (to be expanded): <a href="http://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/">http://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/</a><br>
<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Len Ovens<br>
<a href="http://www.OvenWerks.net" target="_blank">www.OvenWerks.net</a><br>
<br>
</font></span></blockquote></div><br>