From: Euan de K. <eu...@de...> - 2010-11-04 14:44:44
|
On Thu, 2010-11-04 at 15:34 +0100, Clemens Ladisch wrote: > Euan de Kock wrote: > > getSytInterval() will return 16 at 96K (and 8 at 48K) - so I assume we > > are already accounting for the dual mode (or just double size) nature of > > 96K traffic within the 13 channels anyway. > > The SYT_INTERVAL just says how many audio frames can be sent in one > FireWire frame; it's independent of the channel count. > Yes, it is independent of the channel count, but it is dependent on the sampling rate. The ADAT protocol's switch from 8 to 4 to handle 96K is not a factor at the firewire level as we still have sufficient bandwidth - its purely an ADAT limitation. > > So, in conclusion - everything is consistent with a 13 channel ISO > > packet, except for the CIP->DBS value in the received data - this is > > reported as 17! > > This would be a firmware bug. > > > If I force the packet->dbs to be 13 but only when the length is 840 I > > can get a fully functional jackd session running at both 48K and 96K. I > > can even record from within Ardour! > > > > One caveat to all the above: The data I am getting at 96K is suspect - > > when I mic up one (or more) analog channels and I spike the volume on a > > mic (ONE! TWO! TESTING! TAP! TAP! etc) I see corresponding signals > > across all 8 channels I am recording - and the signal is dreadful. SO I > > don't think we are decoding the ISO packets correctly at 96K (Yet...). > > It looks like the packet data is being interleaved across all the > > channels. > > Does FFADO still think that it should get 17 channels? If yes, try > creating a fake packet with 17 channels by rearranging the received > packet's samples. This is a good approach - even at the 13 channel level I can use this method to resolve the interleaving problem - thanks for the suggestion. > > > Regards, > Clemens |