From: Clemens L. <cl...@la...> - 2010-12-10 12:48:29
|
Jonathan Woithe wrote: > Pieter Palmers wrote: > > It took my quite some time to grok it, but I agree. The fact that you > > re-use the syt for a packet exactly 16*N cycles away is what makes > > everything work out. Using a 16*N cycle is just an optimization; in the general case (in the pseudo code I posted), the offset between receive and transmit timestamps (queue_length) could be just as well nonzero. > I can't quite see how you come up with the tx timestamp here. Are you just > taking the last rx timestamp and adding a constant to it? Yes (although "last" is misleading if there are multiple received packets begin buffered; it's the last packet seen so far). > I don't think so though because Clemens said "I still say that proper > timestamping is possible without having to track any previous > timestamps", and taking the previously received timestamp amounts to > tracking it (at least in my books). I was referring to Pieter's code which tracked the timestamp of the previous queued Tx packet. To be more precise: when receiving a packet, it is possible to queue the corresponding Tx packet without any timing-related state, using only the time of the frame in which the packet was received and the received packet's contents (which includes its SYT timestamp). > Aside from that, I assume the idea here is that the packet would be > timestamped and then the streaming engine would work out when it was time to > send it based on the timestamp - right? No, queueing on OHCI controllers works differently: the driver submits a list of packets in advance, and the controller sends out a packet in each frame, one after the next. (It's possible to queue a 'skip' descriptor for no packet in a frame.) So, when queueing a packet, the frame in which the packet will be sent is fixed; the driver can only choose the contents of the packet. > A slight complication with the MOTU protocol is that it isn't technically > the packet which is timestamped - each *frame* has its own timestamp. The > "copy and add an offset" thing should still work though, and for a packet > timewstamp you just choose either the first or last frame to be the packet's > time. In AV/C, the timestamp is associated with one sample (which isn't neccesarily the first sample in packet when using non-blocking mode). > I'm also not sure how important the SYT is in this whole theory, and whether > the entire system as described hinges on SYT. The problem is that MOTU > doesn't set or use the SYT field (at least not in a conventional way). A field that isn't there and that we do not need to set isn't a problem. :-) > It uses its own timestamp fields which are more or less in cycle timer format. The SYT is the lowest 16 bits of the cycle timer. > RME is a touch trickier in that the packets themselves contain no timestamp > at all and like MOTU SYT isn't used in an AV/C sense either (instead, > timestamps are implied). One has to keep track of the number of samples > sent to ensure the average rate seen by the device equals the audio clock. This is exactly the same as with certain USB devices. > The way I currently do this is to use the incoming stream to estimate the > audio clock rate relative to the cycle timer and then base the decision to > send a packet on this synthesised audio clock. Timestamping and determining how many audio frames to put into a packet are two independent tasks. By copying the input stream, i.e., queueing a packet when a packet is received, the rate of both streams is identical. Regards, Clemens |