Jackd crashes within minutes when using it with a Focusrite SAFFIRE PRO 40 FIRMWARE VERSION 914 (uptodate).
After an afternoon of attempts with adi, few things appeared:
1. there is a channel name vector mismatch when using RX0 with 10 channels and RX1 with 10.
00112311367: ESC[31mWarning (dice_avdevice.cpp)[ 813] prepare: The audio channel name vector is incorrect, using default names
The warning disappears with the following hack in src/dice/dice_avdevice.cpp:
if (i == 0) {
nb_audio = 12;
} else {
nb_audio = 8;
}
Though, the routing works in a very weird way: one cannot hear anything when linking an audio source to any analog channel, but if monitor know is raised up, one can hear audio source plugged on any analog channel via headphone busses (7-8 and 9-10).
Probably, the problem is not fully solved on this point.
2. There is a certain amount of late wakeups.
3. Instantanous estimated samplerate differs from nominal:
04105452738: ESC[31mWarning (StreamProcessor?.cpp)[ 743] getPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 23964.895173, diff: 24035.104827 ( 0.500731)]
and, as one may see, it looks like estimated is half the nominal (or almost).
Though, just before in the logs, one may read:
Framerate : Nominal: 48000, Sync: 47998.832731, Buffer 47998.752626
and then, it totally goes crazy with jitter!
04105860685: Warning (StreamProcessor?.cpp)[ 743] getPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 50789.976750, diff: -2789.976750 ( -0.058125)]
04105860715: Debug (StreamProcessor?.cpp)[ 754] getPacket: cy 1248, rather large TSP difference TS=01576708940 => TS=01576712811 (3871, nom 4096)
04105860820: Warning (StreamProcessor?.cpp)[ 743] getPacket: Instantanous samplerate more than 1% off nominal. [Nom fs: 48000.000000, Instantanous fs: 50789.976750, diff: -2789.976750 ( -0.058125)]
4. Linux kernel and drivers don't seem to be involved, as we've tested that with 2 kernels (2.6.26.8-rt16 and 2.6.29.1-rt7)
5. Focusrite firmware has been updated, but it didn't change anything, even if the firmware update spoke about MAJOR FIRMWARE REVISION.
6. The FW controller is onboard controller VIA:
03:03.0 FireWire? (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev c0)
But it doesn't seem to be a problem, as Focusrite recommends it, and adi could test his own io14 on such a chip with success.
7. A very weird thing happens with error_ticks calculous and comparison to 1*CYCLE_PER_SECOND:
04106847249: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545671780, max: +/- 1239901223783424 (try: 10) 1600647067
04106847420: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545667577, max: +/- 1239901223783424 (try: 9) 1600651270
04106847560: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545664136, max: +/- 1239901223783424 (try: 8) 1600654711
04106847704: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545660572, max: +/- 1239901223783424 (try: 7) 1600658275
04106847853: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545656910, max: +/- 1239901223783424 (try: 6) 1600661937
04106847995: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545653419, max: +/- 1239901223783424 (try: 5) 1600665428
04106848154: Debug (CycleTimerHelper?.cpp)[ 393] Execute: (0x834160) have to retry CTR read, diff unrealistic: diff: 1545649511, max: +/- 1239901223783424 (try: 4) 1600669336
04106848311: Debug (CycleTimerHelper?.cpp)[ 475] Execute: Rather late wakeup: 1072 usecs
diff is much less than max, and though it's considered as bigger.
