Re: [LAD] Open Source Audio Interface

From: Len Ovens <len@email-addr-hidden>
Date: Fri Sep 12 2014 - 06:16:04 EEST

On Thu, 11 Sep 2014, Paul Davis wrote:
>
> On Thu, Sep 11, 2014 at 6:50 PM, Len Ovens <len@email-addr-hidden> wrote:
>
>
> Shouldn't be, The network traffic does not need to be real time,
> but the network does. In other words the way the host computer
> deals with network traffic does not need to be real time. The
> computer puts a packet into a buffer, this part does not need to
> be real time.
>
>
> this is not correct. there's no difference between this operation and
> putting audio into the h/w buffer associated with a PCI audio interface. the
> entire transport chain must be RT.

Ok, first off network traffic does not equal audio traffic. Perhaps I
should say ethernet traffic and IP traffic. The audio is sent as raw
ethernet packets. This call must be realtime. The whole audio chain is
real time. The network or IP traffic is fed to our driver through normal
channels. Our driver looks to the system like an eth* device, but in fact
it is not a device, but a socket that puts a packet into a buffer. That
part does not have to be real time... but once it is in the buffer the
feeding of that data as a raw ethernet packet does have to be real time
because this operation must be completed in time for the next packet of
audio data because, whatever the interval the audio is sent at, the audio
data has to be sent in time with that.

So in the case I was supposing with 4 samples of data per audio packet,
as soon as the 4th sample has been collected by the ADC, An audio packet
is sent with all 4 samples for all channels. Then the time left till next
4th sample is calculated/read and the size of data allowed to fit is sent
(some leeway is left). The ethernet interface should be left open by the
time the next audio frame is ready. The audio driver may have to test the
actual time required from packet send to receive to know how big to allow
the IP data packet to be. The guard band time is supposed to be a certain
length (the MACs plus type plus guard band _should_ be 304 bits long). If
the IP data in the buffer is not completely written by the time the audio
packet has been sent, it waits for the next audio packet to go first. The
network (IP) traffic will be slowed down more than would be expected by
just looking at percentages, but the audio should be able to be sent on
time every time. There is no other traffic but what goes through the audio
driver.

In a home situation where even with wide band internet the max speed is 6
to 15 mbits The network speed from the computer to the gateway does not
need to be a full 100mbit. In a more critical situation, a second NIC
would be better.

Len is not very good at explaining things...

--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Sep 12 08:15:02 2014

This archive was generated by hypermail 2.1.8 : Fri Sep 12 2014 - 08:15:02 EEST