[alsa-devel] [FFADO-devel] [PATCH 08/19] firewire-motu: add MOTU specific protocol layer

[Jonathan Woithe]

On Sun, Jan 29, 2017 at 12:54:06PM +0900, Takashi Sakamoto wrote:
> This commit adds data block processing layer specific for the MOTU
> protocol. The remarkable point is the way to generate SPH header. Time
> stamps for each data blocks are generated by below calculation:
> 
>  * Using pre-computed table for the number of ticks per event
>   *  44,1kHz: (557 + 123/441)
>   *  48.0kHz: (512 +   0/441)
>   *  88.2kHz: (278 + 282/441)
>   *  96.0kHz: (256 +   0/441)
>   * 176.4kHz: (139 + 141/441)
>   * 192.0kHz: (128 +   0/441)
>  * Accumulate the ticks and set the value to SPH for every events.
>  * This way makes sense only for blocking transmission because this mode
>    transfers fixed number or none of events.
> 
> This calculation assumes that each data block has a PCM frame which is
> sampled according to event timing clock. Current packet streaming layer
> has the same assumption.
> 
> Although this sequence works fine for MOTU FireWire series at sampling
> transmission frequency based on 48.0kHz, it is not enough at the frequency
> based on 44.1kHz. The units generate choppy noise every a few seconds.

Using a fixed number of ticks per event is not guaranteed to work at any
sample rate for MOTU interfaces.  At 48 kHz (and multiples thereof) one
obviously has even divisibility but the fractional accumulation allows for
the irregular 44.1 kHz rates.  For any sample rate, use of fixed tick
intervals will only be stable for devices whose audio clock generator
happens to be very close to its nameplate frequency relative to the firewire
iso cycle timer.  This is because MOTU decouple the audio clock from the
tick frequency.  You could certainly get devices where the clocks are very
well matched but it's really pot luck.  Ultimately all devices will
eventually experience discontinuites due to the unlocked clocks.

The only apparent way to maintain synchronisation with the playback packets
over hours is to make use of the timestamp fields returned by incoming audio
packets from the interface (other operating systems unsurprisingly appear to
take this approach).  The difference between successive timestamps (or the
received timestamps with an offset added) can be used to synthesise the
outgoing timestamps.  Because the SPH timestamps in the incoming packets are
guaranteed to synchronised with the audio clock an outgoing stream whose SPH
timestamp is synthesised with the differences will likewise maintain sync
indefinitely.  I wrote a proof-of-concept test illustrating this method of
SPH timestamp generation for MOTU interfaces back in 2006; stable operation
(no audio discontinuities) across all sample rates was observed for periods
exceeding 24 hours.

One can observe the unlocked nature of the SPH timestamps even at 48 kHz (I
have personally seen it with 828, 828mk2, Traveler, 896HD devices).  As
shown in the pre-computed table, for locked clocks one would expect 512
ticks per event at 48 kHz.  While 512 is certainly the dominant difference,
one does not have to wait long before seeing a difference of 511 or 513
(depending on whether the audio clock runs fast or slow relative to the iso
cycle timer).

Regards
  jonathan