[LAD] Open Source Audio Interface

Len Ovens len at ovenwerks.net
Fri Sep 12 03:16:04 UTC 2014

On Thu, 11 Sep 2014, Paul Davis wrote:
> On Thu, Sep 11, 2014 at 6:50 PM, Len Ovens <len at ovenwerks.net> 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 

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

More information about the Linux-audio-dev mailing list