From: Jonathan W. <jw...@ph...> - 2007-06-14 23:40:59
|
Hi Pieter > >> *) we have to make sure that we don't end up in a deadlock when we have > >> devices that don't start to transmit before they receive something. > > > > FYI this is not an issue with the MOTU devices - they send as soon as the > > device receives an "enable streaming" command. > > > >> The ideal system probably would be to have all the streams running until > >> they are ready & synced and then start operation. This part is a bit of > >> a mess though. > > > > So this might mean extending the meaning of "running" to indicate "running > > and synced". If this were the case then the existing stream processor > > infrastructure possibly wouldn't need much changing (although I haven't > > looked into it in detail lately, so this view is subject to change without > > notice :) ). > I was trying to solve the issues, so it doesn't really surprise me that > the infrastructure is almost there ;). > > If I remember correctly the biggest problem is the following: > Suppose you have to generate timestamps for the transmitted stream. The > sync source is a received stream, and defines the 'master' timestamps > for the other streams. At startup the problem is that you can't transmit > valid packets before you have this master timestamp, so the receive > stream should already have 'locked'. > > The transfer of the sync timestamp info is normally done at a period > boundary, but some devices don't like it if they don't receive data for > a certain time, so they stop. This means that we don't succeed in the > startup. Right. Obviously to this point I only have direct detailed experience with the MOTU products and for them the lack of data doesn't cause them to stop; they just sit around patiently and wait for it (with a few caveats). I can quite understand how this may be an issue for other devices however. Regards jonathan |