Ticket #215 (closed bug: fixed)

Opened 6 years ago

Last modified 3 years ago

[Focusrite Saffire Pro 40] Jack stops and/or crashes after a short time (1'-3')

Reported by: orl Assigned to: ppalmers
Priority: major Milestone: FFADO 2.1
Component: Version: FFADO SVN (trunk)
Keywords: focusrite pro 40 samplerate Cc:
The device the bug applies to: Focusrite Saffire Pro 40

Description

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.

Attachments

ffado_dbus_jack_p128_r1538.log.tar.gz (56.5 kB) - added by orl on 04/17/09 03:00:45.
logs with channel name vector error
ffado-jack_p1024_n4_r1538_adimode.log.tar.gz (41.2 kB) - added by orl on 04/17/09 03:01:16.
logs with mod for correcting channel name vector error
ffado-jack_p1024_n4_r1511_adimode.log.tar.gz (39.1 kB) - added by orl on 04/17/09 03:02:23.
logs with mod for correcting channel name vector error with 1511 version
ffado-diag.txt.gz (1.9 kB) - added by teh_l1nx on 08/12/09 10:02:38.
jackd-out.txt.gz (6.8 kB) - added by teh_l1nx on 08/12/09 10:05:52.

Change History

04/17/09 03:00:45 changed by orl

  • attachment ffado_dbus_jack_p128_r1538.log.tar.gz added.

logs with channel name vector error

04/17/09 03:01:16 changed by orl

  • attachment ffado-jack_p1024_n4_r1538_adimode.log.tar.gz added.

logs with mod for correcting channel name vector error

04/17/09 03:02:23 changed by orl

  • attachment ffado-jack_p1024_n4_r1511_adimode.log.tar.gz added.

logs with mod for correcting channel name vector error with 1511 version

04/17/09 05:11:51 changed by orl

Here's part of the discussion between adi and I, concerning outputs of PRO40:

18:53 < adi> Ah, here's the mismatch. 18:53 < adi> RX0: 18:54 < adi> Nb audio channels : 10 18:54 -!- Irssi: Pasting 12 lines to #ffado. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. 18:54 < adi> Mon 1 18:54 < adi> Mon 2 18:54 < adi> Line 3 18:54 < adi> Line 4 18:54 < adi> Line 5 18:54 < adi> Line 6 18:54 < adi> Line 7 18:54 < adi> Line 8 18:54 < adi> Line 9 18:54 < adi> Line 10 18:54 < adi> SPDIF L 18:54 < adi> SPDIF R 18:54 < adi> These are 12! 18:54 < adi> And then: 18:54 < adi> RX1: 18:54 < adi> Nb audio channels : 10 18:54 -!- Irssi: Pasting 8 lines to #ffado. Press Ctrl-K if you wish to do this or Ctrl-C to cancel. 18:54 < adi> ADAT 1 18:54 < adi> ADAT 2 18:54 < adi> ADAT 3 18:54 < adi> ADAT 4 18:54 < adi> ADAT 5 18:54 < adi> ADAT 6 18:54 < adi> ADAT 7 18:54 < adi> ADAT 8 18:54 < adi> These are eight. 18:55 < adi> So in total, they're right, but it's wrong.

04/19/09 03:49:12 changed by ppalmers

  • owner set to ppalmers.
  • status changed from new to assigned.
  • version changed from FFADO 2.0-rc1 (1.999.40) to FFADO SVN (trunk).

On 1.

It's a bug, I'll commit a fix soon

On 2.

This is not necessarily a problem, but might indicate that your system is not very good at scheduling realtime threads. But again, it's not that much of a problem.

On 3 and 5: I'll have to look in to it.

04/19/09 07:20:38 changed by orl

OK, I just checked the 1539 version, it fixes the point 1.

05/17/09 04:18:34 changed by ppalmers

There are multiple reports about issues with the VIA VT6306, but I have difficulties reproducing the issues. I will try and figure it out.

08/12/09 07:45:00 changed by teh_l1nx

I seem to be getting the same sort of error. Either this or the issue described in Bug #217 since I am using an ExpressCard?.

Jackd is: jackdmp 1.9.3 FFADO is 2.9999.0-1613 And I'm running on 64-bit Ubuntu 9.04 (Tried both generic kernel: 2.6.28-14-generic and rt kernel: 2.6.28-3-rt)

Command to start jack was: jackd -R -d firewire

The relevant device under lspci: 05:00.0 FireWire? (IEEE 1394): Texas Instruments XIO2200(A) IEEE-1394a-2000 Controller (PHY/Link) (rev ff)

08/12/09 10:02:38 changed by teh_l1nx

  • attachment ffado-diag.txt.gz added.

08/12/09 10:05:52 changed by teh_l1nx

  • attachment jackd-out.txt.gz added.

11/21/09 12:11:38 changed by ppalmers

  • milestone changed from FFADO 2.0 to FFADO 2.1.

This is one of the bugs that is too difficult to track and solve to be blocking for 2.0. Tough luck for those affected. Once we're moving to kernel streaming it might be easier to track and find these issues as it should be simpler.

05/11/12 05:27:23 changed by jwoithe

  • status changed from assigned to closed.
  • resolution set to fixed.

This ticket is now quite old and much development has occurred both in the kernel and within FFADO itself since it was reported. According to the comments at least some of the points raised have definitely been fixed, but the status of most of them are still unknown.

To reflect the fact that at least one of the issues has been fixed I'll close this ticket as "fixed". If a re-test with a recent FFADO, kernel and libraw1394 shows that some or all of the remaining issues are still present please re-open this ticket and provide:

  • an updated ffado-diag output for the system
  • a revised status description of the remaining problems
  • anything else you feel would be helpful to determine what the problems might be