[LAD] Open Source Audio Interface

Arnold Krille arnold at arnoldarts.de
Thu Sep 11 20:18:33 UTC 2014

Just some cents...

On Thu, 11 Sep 2014 12:44:45 -0700 (PDT) Len Ovens <len at ovenwerks.net>
> Unlike MADI, empty channels would not be filled with null data, but
> rather just not sent. In MADI, 64 channels are always sent even for a
> payload of 1. In this case we should send multiples of two. There is
> no reason that the channel count should not change from frame to
> frame, but of course the receiving sw would have to have time
> (non-real time) to reset itself and audio sw that doesn't know how to
> deal with more channels all the sudden might need restarting too :)
> In Jack's case, if the first two were set up as the sound card, the
> rest could be added as jack clients. On the AI end they would all be
> jack clients anyway and jack would see the whole complement of codecs
> all the time. I feel it is worth while having jack in the AI because
> this would allow routing. There would be no having the outputs be
> channels 9 and 10 because that happens to be how s/pdif appears
> because those could look to the host like 1 and 2.

Varying channel count per packet/frame means a varying number
of malloc/free per packet -> bad for realtime. Its probably better to
stay with one channel-count once the stream is set up.

Thinking about it some more, I think one of the reasons why several
vendors use dedicated network-devices with dedicated drivers is to
reduce the need for malloc/free in the kernel/driver as much as
possible and just use fixed buffers once the channel-count (and
word-size) are known.

Have fun,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20140911/04e84a14/attachment.pgp>

More information about the Linux-audio-dev mailing list