Just some cents... On Thu, 11 Sep 2014 12:44:45 -0700 (PDT) Len Ovens <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
