"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
news:dn7ush$2bj$1@canopus.cc.umanitoba.ca...

> In article <dn7roc$sur$1@nntp.webmaster.com>,
> David Schwartz <davids@webmaster.com> wrote:

>>"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
>>news:dn4v0s$qak$1@canopus.cc.umanitoba.ca...

>>> In modern NICs on fully-fledged "computers", the device driver would
>>> likely DMA the packet over to the NIC to take care of (a matter of a
>>> small number of operations), but in an embedded system or if the NIC is
>>> too old or too cheap (or is specialized for bit-level controls) then
>>> the device drive might have to emit one byte at a time.

>> I think you'd have a very hard time finding a Linux system that worked
>>that way.

> Linux is commonly used for WiFi Access Points and kin; the interface to
> the radios are often not the same as for typical ethernet NICs.

Actually, it is. The WiFi NIC is frequently a compact version of PCI.
Otherwise, it's usually integrated on the main board, but it's a fully
modern network interface.

>>In any event, when you hear hoofs, you think horses, not zebras.
>>It is totally reasonable to presume the OP meant on typical systems,
>>unless
>>they specify otherwise.

> On "typical systems" there isn't any problem sending 96 KHz audio
> without worrying about system call overhead. The OP is clearly doing
> -something- non-typical.

Re-read the OP's original post and follow up. There's no reason to think
he's actually having an issue with the overhead of system calls. Wanting to
avoid something and it being a problem are not anything close to the same
thing.

DS