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