Re: [FFADO-devel] MotU Bandwidth allocation

[Jonathan W. <jw...@ph...>]

Hi Francois

> I'm trying to define more acurately the bandwidth allocation for different
> devices.
> In the code, you say the Traveler packet size @192kHz is 1160.
> 
> Correct me if I'm wrong:
> 
> Bloc_size = (nb_of_ports * (sample-rate/8000) * 3 + 10) rouded to upper
> quadlet
> 
> (+10 is from the SPH and the control/MIDI bytes).
> That makes 1164 according they are 16 ports. So I presume Phones and Mix1
> are disabled @192kHz.
> @96kHz, the bloc size is 1308 bytes.
> @48kHz, the bloc size is 804 bytes.
> 
> So the biggest bloc case should be 96kHz?

Phones and Mix1 are disabled at 192 kHz, yes.  However, there are additional
subtleties.  Note that here "event" is the aggregate containing one sample
from every audio channel.

  At 1x rates:
    Each packet contains a CIP header (2 quadlets = 8 bytes) and 8 events
    Channels present = Phones/mix1, 8 analog, 8 ADAT, 2 SPDIF, 2 AES/EBU
     = 22 channels
    Each channel has 3 bytes of data
    The SPH and other headers are a constant 10 bytes *per event*

    Total size of packet = 8 + 8*(22*3 + 10) = 616 bytes

  At 2x rates:
    Each packet contains a CIP header (2 quadlets = 8 bytes) and 16 event
    Channels present = Phones/mix1, 8 analog, 4 ADAT, 2 SPDIF, 2 AES/EBU
     = 18 channels
    Each channel has 3 bytes of data
    The SPH and other headers are a constant 10 bytes *per event*

    Total size of packet = 8 + 16*(18*3 + 10) = 1032 bytes

  At 4x rates:
    Each packet contains a CIP header (2 quadlets = 8 bytes) and 32 event
    Channels present = 8 analog = 8 channels
    Each channel has 3 bytes of data
    The SPH and other headers are a constant 10 bytes *per event*
    Each frame has 16 bytes of pad data at the end

    Total size of packet = 8 + 32*(8*3 + 10 + 2) = 1160 bytes

So the largest packet is indeed 1160 bytes which occurs at 4x rates, as
per the source code.

I should add that via packet sniffing I have verified that the above packet
sizes are in fact correct (with ADAT/SPDIF enabled when possible).

I'm trying to work out why your calculation is out.  I don't quite follow
the formula you've got, but I think the problem is two-fold.  Firstly, the
number of frames in a packet is assumed to be (sample-rate/8000), but this
is only the ideal average.  For the purposes of the bandwidth calculation we
have to go with what's really sent.  The MOTUs send packets consisting of 8
frames at 1x, 16 at 2x and 32 at 4x, and then periodically skip a cycle to
"catch up" to reality.  The ieee1394 standard dictates that the bandwidth
allocation is done assuming that you send your biggest packet in every cycle
- so we must use these multipliers when doing the calcuation.

Secondly, I think there might be confusion as to how many channels are
actually active at the different sample rates.  Your example suggested 16
channels at 192 kHz but there is in fact only 8.

So, a more accurate calculation would be (assuming n_active_channels > 0):

  S = n_active_channels*3 + 10
  S = ( (S+3)/4 )*4
  S = Ne*S + 8

where Ne is the number of events per packet (8 for 1x rate, 16 for 2x rate
and 32 for 4x rate).

Oh yes, S is assumed to be an integer.  The second line accounts for padding
bytes; since the divisor is a multiple of two the division (and subsequent
multiplication) will be optismised to shift operations, so the calculation
isn't as bad as it looks in terms of CPU power.  Walking the port list to
find n_active_channels will take longer.

In fact, instead of reimplementing all this in MotuDevice::prepare(), let's
just take the maximum value of event_size_out and event_size_in (henseforth
M) and plug it into the third line of the above calculation:

  S = Ne*M + 8

m_bandwidth can then be trivially calculated as 25 + S.  Note that 
in general event_size_out and event_size_in will be equal.  I've made
this change in SVN but again it's not compile tested.

Finally, note that all this assumes all MOTU devices use the same data
stream layout.  So far this has been verified only on the Traveler, 828 and
(by association) the UltraLite.  I would not be surprised if the 896 is
different in some way.

> This part is an actual enigma for me, each time I try to see clearer I find
> something different.

:-) It's a nasty little detail.

Regards
  jonathan