[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-audio-dev
Subject:    Re: [LAD] Open Source Audio Interface
From:       Arnold Krille <arnold () arnoldarts ! de>
Date:       2014-09-11 20:18:33
Message-ID: 20140911221833.06d7faf0 () xingu ! arnoldarts ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Just some cents...

On Thu, 11 Sep 2014 12:44:45 -0700 (PDT) Len Ovens <len@ovenwerks.net>
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" (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]