Re: [LAD] Open Source Audio Interface

From: Arnold Krille <arnold@email-addr-hidden>
Date: Thu Sep 11 2014 - 23:18:33 EEST

Just some cents...

On Thu, 11 Sep 2014 12:44:45 -0700 (PDT) Len Ovens <len@email-addr-hidden>
wrote:
> 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,

Arnold

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Received on Fri Sep 12 00:15:06 2014

This archive was generated by hypermail 2.1.8 : Fri Sep 12 2014 - 00:15:06 EEST