Ticket #57 (closed bug: fixed)

Opened 16 years ago

Last modified 16 years ago

saffirepro not starting in jack

Reported by: porl Assigned to: ppalmers
Priority: major Milestone: FFADO 2.0
Component: Version:
Keywords: Cc:
The device the bug applies to:

Description

running latest svn builds of jack and ffado, i recieve an error:

firewire ERR: Error creating FFADO streaming device

jackd hangs there for a few minutes, then segfaults.

i have attached both the jackd output, as well as the output files to:

./test-ffado -v6 Discover > ffado-test-stdout 2> ffado-test-stderr

(ffado was built with DEBUG=yes)

porl

Attachments

jackd-out (0.7 kB) - added by porl on 12/23/07 21:14:12.
jackd output (before segfault)
ffado-test-stdout (9.9 kB) - added by porl on 12/23/07 21:14:47.
test-ffado stdout
ffado-test-stderr (93.7 kB) - added by porl on 12/23/07 21:15:06.
test-ffado stderr
ffadoerr (370.8 kB) - added by porl on 01/15/08 21:14:33.
ffadoout (10.0 kB) - added by porl on 01/15/08 21:14:48.

Change History

12/23/07 21:14:12 changed by porl

  • attachment jackd-out added.

jackd output (before segfault)

12/23/07 21:14:47 changed by porl

  • attachment ffado-test-stdout added.

test-ffado stdout

12/23/07 21:15:06 changed by porl

  • attachment ffado-test-stderr added.

test-ffado stderr

01/03/08 04:39:34 changed by porl

just updated both ffado and jack to today's svn (2008.01.03) and still exactly the same problem.

any ideas?

porl

01/10/08 13:37:27 changed by ppalmers

  • status changed from new to assigned.
  • owner set to ppalmers.

please update jackd to SVN rev 1079 and ffado to SVN rev 833. Can you check whether it works any better? If not, please post a log with the following jackd options: jackd -d firewire -v6

(or await the next jack/ffado release)

01/10/08 21:39:24 changed by porl

i updated to them and jack finally started. all the input/output ports were listed, so it seems good. the only problem was that ardour (which is basically what i use jack for) doesn't want to play at all. as soon as i press the play button, it stops again. this also happens using qjackctl to try pressing play on the jack transport. note that i didn't have ardour synced up to the jack transport, so i don't think it is a transport issue, rather something stopping the audio streams from working. with the jackd -d firewire -v6 command, there is way too much to post here (although if you really need it let me know and i'll try to capture the output) but once the initial setting up gets out of the way, the jackd console constantly outputs the following in a seemingly infinite loop (part of the reason the log is so long):

Error (StreamProcessor?.cpp)[1185] scheduleStartDryRunning: Cannot switch to ePS_DryRunning from ePS_WaitingForStream

2131174946: Error (StreamProcessorManager?.cpp)[ 229] startDryRunning: Could not put SP 0x8093d30 into the dry-running state 2131174950: Debug (StreamProcessorManager?.cpp)[ 518] start: Could not put SP's in dry-running state (try -1216789615) 2131174954: Debug (StreamProcessorManager?.cpp)[ 222] startDryRunning: Putting StreamProcessor? streams into dry-running state... 2131174958: Debug (StreamProcessorManager?.cpp)[ 223] startDryRunning: Schedule start dry-running... 2131174965: Debug (StreamProcessor?.cpp)[1163] scheduleStartDryRunning: for Transmit SP (0x8093d30) 2131174972: Debug (StreamProcessor?.cpp)[1169] scheduleStartDryRunning: Now : 02772218457 (112s 6414c 2649t) 2131174976: Debug (StreamProcessor?.cpp)[1174] scheduleStartDryRunning: Start at : 02772832688 (112s 6614c 2480t) 2131174981: Error (StreamProcessor?.cpp)[1185] scheduleStartDryRunning: Cannot switch to ePS_DryRunning from ePS_WaitingForStream 2131174985: Error (StreamProcessorManager?.cpp)[ 229] startDryRunning: Could not put SP 0x8093d30 into the dry-running state

thanks porl

01/11/08 01:43:33 changed by ppalmers

I have seen that too with certain firewire controllers. For one reason or another the OHCI controller stops sending packets. I've verified this (at kernel level) to be an issue with the host controller hardware itself (in my case). With the built-in O2Micro in my laptop exhibits this behavior, while the NEC based cardbus controller doesn't. It's also only with the saffire that I have this issue, not with any other device.

Can you try with another host controller?

01/12/08 21:35:56 changed by porl

unfortunately i don't currently have access to any other controllers. hopefully soon i'll be able to try out one however. i wonder why it would only affect the saffire though?

porl

01/13/08 02:57:11 changed by ppalmers

I also wonder why only the saffire is affected. The only thing I can think of is the fact that it needs significantly more bandwidth than any of the other devices I have.

Pieter

01/15/08 21:13:56 changed by porl

i just tried the latest svn updates of both ffado and jack. unfortunately the old behaviour seems to have returned (i am still using the old controller though, as i haven't been able to access any others yet). i am attaching the stdout and stderr logs (ffadoerr and ffadoout).

porl

01/15/08 21:14:33 changed by porl

  • attachment ffadoerr added.

01/15/08 21:14:48 changed by porl

  • attachment ffadoout added.

01/20/08 06:12:34 changed by ppalmers

I've tracked down this issue to a problem in the kernel layer. Once the packets exceed a certain size, the transmit context of certain controllers seems to die. I can reproduce it, and I'm trying to figure out where it's located.

03/11/08 02:56:00 changed by ppalmers

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

I have tested two different saffire pro's with two machines and several host controllers. If the host controller is good, the device works.