Re: [PATCH 08/19] firewire-motu: add MOTU specific protocol layer

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

On Jan 29 2017 22:16, Jonathan Woithe wrote:
> 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.

You have a wrong idea to mix up sampling clock, sampling transfer 
frequency in packet streaming layer and time stamps of SPH in data block 
processing layer. In MOTU FireWire series, sampling clock and the other 
clocks seem to be independent. Unless, the system could not get correct 
sequence of PCM frames in tx packets.

> 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.

This is denied by a fact that I can get different sequence of SPH in 
transmitted packets from the unit when this module puts different 
sequence of SPH to packets to the unit with code modification of this 
module.

In short, the sequence of SPH in tx packets from the unit is dependent 
of the sequence of SPH in rx packets to the unit. Furthermore, this is 
always consistent regardless of selected signals for source of sampling 
clock.

Drivers don't necessarily need to pick up the sequence of SPH from tx 
packets for rx packets.

> 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).

Here, you have the misunderstanding, too.

If you have different stories, please show reasoning from enough facts, 
at first. Not from your opinion or memories.


Regards

Takashi Sakamoto