«

"ShriRam" <(E-Mail Removed)> wrote:
>
>Hi,
> I am trying to send audio from one machine to another at 96KHZ
>
> I want to eliminate the system call delays.
>
> I want my code to run in the kernel module.

There is a very common misconception that kernel-mode code somehow runs
substantially faster than user-mode code. It ain't so.

In your specific case, network delays will be vastly greater than any
system call overhead.

Don't waste your time optimizing where it will not help.
--
- Tim Roberts, (E-Mail Removed)
Providenza & Boekelheide, Inc.

In article <(E-Mail Removed)>,
Tim Roberts <(E-Mail Removed)> wrote:
>"ShriRam" <(E-Mail Removed)> wrote:

>> I am trying to send audio from one machine to another at 96KHZ

>> I want to eliminate the system call delays.

>> I want my code to run in the kernel module.

>There is a very common misconception that kernel-mode code somehow runs
>substantially faster than user-mode code. It ain't so.

>In your specific case, network delays will be vastly greater than any
>system call overhead.

Quite.

96 KHz times (say) 16 bits per sample, is 19200 bytes per second.
A 2.4 GHz computer would have 125000 cycles per byte to prepare
the next byte. A 33 MHz computer (say a PDA or embedded system)
would have 1718 cycles per byte. How many cycles does a system call
take -- 40??
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

"Walter Roberson" <(E-Mail Removed)> wrote in message
news:dn3ivj$sko$(E-Mail Removed)...

> Quite.
>
> 96 KHz times (say) 16 bits per sample, is 19200 bytes per second.
> A 2.4 GHz computer would have 125000 cycles per byte to prepare
> the next byte. A 33 MHz computer (say a PDA or embedded system)
> would have 1718 cycles per byte. How many cycles does a system call
> take -- 40??

And there is no way you could use one system call per byte anyway. At a
minimum, you'd use one system call to send each packet.

DS

Walter Roberson wrote:
>
> How many cycles does a system call take -- 40??

That depends on a lot of factors. I did some
meassurements on gettimeofday and found it
took about 350 cycles on an AMD K6/2 CPU.
But with some other kernel version or another
CPU, you may get different numbers.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

In article <dn4qhb$prt$(E-Mail Removed)>,
David Schwartz <(E-Mail Removed)> wrote:

>"Walter Roberson" <(E-Mail Removed)> wrote in message
>news:dn3ivj$sko$(E-Mail Removed)...

>> Quite.

>> 96 KHz times (say) 16 bits per sample, is 19200 bytes per second.
>> A 2.4 GHz computer would have 125000 cycles per byte to prepare
>> the next byte. A 33 MHz computer (say a PDA or embedded system)
>> would have 1718 cycles per byte. How many cycles does a system call
>> take -- 40??

> And there is no way you could use one system call per byte anyway. At a
>minimum, you'd use one system call to send each packet.

I considered saying that in my posting, but then I realized that one
would then start getting into semantics about what a "system call" is.

A user-level process would, as you indicate, place one system call per
packet, which would -usually- result in the packet being copied into
device drive memory space. But then how does the device driver psuh the
individual bytes of the packet onto the wire?

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.

If the device driver does not have direct address to I/O space, then
the device driver might have to ask the kernel to emit the byte; that
I/O operation could potentially be classed as a "system call". Imagine
for example a 3 ring structure, the kernel at ring 0, the drivers at
ring 1, the user processes at ring 2, but that the drivers are
using I/O operations that require kernel intervention... such
as if the device drivers are virtual drivers that have to go through
a Hardware Adaptation Layer (HaL).
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

"Walter Roberson" <(E-Mail Removed)> wrote in message
news:dn4v0s$qak$(E-Mail Removed)...

> 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. 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.

DS

In article <dn7roc$sur$(E-Mail Removed)>,
David Schwartz <(E-Mail Removed)> wrote:

>"Walter Roberson" <(E-Mail Removed)> wrote in message
>news:dn4v0s$qak$(E-Mail Removed)...

>> 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.

>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.
--
All is vanity. -- Ecclesiastes

Walter Roberson wrote:

> On "typical systems" there isn't any problem sending 96 KHz audio

I don't think there are many people, who can hear 96 KHz audio. ;-)

"Walter Roberson" <(E-Mail Removed)> wrote in message
news:dn7ush$2bj$(E-Mail Removed)...

> In article <dn7roc$sur$(E-Mail Removed)>,
> David Schwartz <(E-Mail Removed)> wrote:

>>"Walter Roberson" <(E-Mail Removed)> wrote in message
>>news:dn4v0s$qak$(E-Mail Removed)...

>>> 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

Hi,

Will 48KHZ work - 48 K Samples/Second with 2 channels and each
sample of 4 bytes each.

That makes up to (48 * 2 * 4) bytes/milliseconds.

I dont know if typical rtp works with 48 KHZ and gives excellent
result.

Does anyone know any light wt rtp which gives excellent results.

I am exp. a loss of 5 to 10 %.

The packets are arrived and are in the recieve fifo. but my
Application is not able to detect if
playtime has reached.

my process gets scheduled and the next time i get back - the playtime
has expired (i checked the packets is in the wait queue).

I even tried waiting for in a while loop - checking continuously for
playtime. but process gets scheduled.

any ideas when i am going wrong ?.

Regards,
SRiram