Hi Stefan,
On Apr 10 2016 01:34, Stefan Richter wrote:
On Mar 07 Takashi Sakamoto wrote:
On Mar 7 2016 22:43, Stefan Richter wrote:
On Mar 07 Takashi Sakamoto wrote:
- Dice II units
- TC Electronic ImpactTwin
- TC Electronic Konnekt24D
- TC Electronic Konnekt8
- Dice Jr. units
- TC Electronic DesktopKonnect6
- Dice Mini units
- Focusrite Saffire Pro 26
FWIW, Saffire PRO 24 and 40 are based on Dice Junior according to FFADO's device database. If desired I could open up my 24 and 40 to check.
If you don't mind it, please. (Because once opening your unit, usually, you cannot get repair service from sellers.)
And I wrote wrong for Dice Jr./Mini units. Correctly:
- Dice Jr. units
- TC Electronic DesktopKonnect6
- Focusrite Saffire Pro 26
- I have no units with Dice Mini (Oh...).
Anyway, all of my units with Dice Jr. works fine. So we can judge that Pro 40 has its own quirk which we don't know.
Written on the Dice chip in my Saffire PRO 24, purchased in 2010:
TCD2210 K34FAAB C0906
So that's a DICE Mini.
And the Saffire PRO 40, purchased in early 2015:
TCD2220 K8GVUF A1246
i.e. DICE JR.
Thanks for your confirmation. The database of FFADO project includes the wrongs for some models, therefore it's better for us to get such evidences.
Recently I got PreSonus FireStudio Mobile from used-market. It has TCD2210 (Dice Mini). I've started to read packet dumps for Dice ASICs except for TCD3070-CH, on Windows/Linux (ALSA).
Well, would you please get packet dumps with your models? Especially with SaffirePro 40 because current ALSA firewire stack cannot make it generate correct sounds, as long as you tested. I need the dumps under conditions below:
- From the beginning of starting packet streaming. - During seven seconds after the beginning, at least. - Including the contents of asynchronous packets for cycle start packet. - Including the contents of isochronous packets for all of used channels. At least: - The length of payload. - The number of channel - The node IDs for ishcchronous source and destination - Two quadlets of CIP header. - A condition that your unit is driven by Windows driver. - At both of 44.1/48.0kHz
For example, this is a sample got by my protocol analyzer (not nosy, I have no cards with PCILynx).
rel. time (uSec),type,source ID,dest. ID,offset,label,retry code,response code,priority,data length,quadlet data,tag,channel,sync.,speed,acknowledge,data 0.000,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371B034,,,,100,, 2.614,Streaming,,,,,,,,8,,1,0,0,400,,0x020F0028,0x9001FFFF,0x570A5DF9 122.375,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371C034,,,,100,, 2.614,Streaming,,,,,,,,488,,1,0,0,400,,0x020F0028,0x9001DAB9, (CIP data) 122.386,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371D034,,,,100,, 2.614,Streaming,,,,,,,,488,,1,0,0,400,,0x020F0030,0x9001F423, (CIP data) 122.386,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371E034,,,,100,, 2.614,Streaming,,,,,,,,8,,1,0,0,400,,0x020F0038,0x9001FFFF,0xD4D853F5 122.386,CycleStart,0xFFC2,0xFFFF,0xFFFFF0000200,0,retry_1,,15,,0xE371F034,,,,100,, 2.614,Streaming,,,,,,,,488,,1,0,0,400,,0x020F0038,0x9001098E, (CIP data) ...
When I run my parser written by Python3, I got enough information: ['0xE371B034', '0x020F0028', '0x9001FFFF', 2795258932, 0, 0] ['0xE371C034', '0x020F0028', '0x9001DAB9', 2795262004, 2795267769, 5765] ['0xE371D034', '0x020F0030', '0x9001F423', 2795265076, 2795272227, 7151, 4458] ['0xE371E034', '0x020F0038', '0x9001FFFF', 2795268148, 0, 0] ['0xE371F034', '0x020F0038', '0x9001098E', 2795271220, 2795276686, 5466, 4459] ...
Legend: - CycleStart - CIP header 0 - CIP header 1 - CycleStart(tick) - presentation timestamp(tick) - subtraction between CycleStart and presentation timestamp (tick) - subtraction between previous/current presentation timestamp(tick)
Currently, I can find some differences between Dice ASICs: - The ASIC for Dice II transfers/receives packets with less transfer-delay than the value defined in IEC 61883-6. But packets for the other ASICs are compliant to it.
I don't investigate the sequence of the length of CIP data yet.
Regards
Takashi Sakamoto