From: FFADO <ffa...@ff...> - 2013-04-18 06:39:05
|
#367: Jack locks up when ffado-mixer attempts to set clock source to SPDIF or ADAT -------------------------+-------------------------------------------------- Reporter: rgreen | Owner: arnonym Type: bug | Status: new Priority: major | Milestone: Indeterminant (awaiting volunteer) Component: ffado-mixer | Version: FFADO 2.1.0 Keywords: | Device_name: Saffire Pro26I/O (BeBob) -------------------------+-------------------------------------------------- ffado version 2.999.0- as distributed by ubuntustudio. I start ffado- mixer, and attempt to switch the clock source from internal to spdif. ffado-mixer returns with a message that it was unable to do that, and then locks up completely. ffado-mixer on my older system (Ubuntustudio 8.04) works fine. I can boot either laptop into windows, and saffire control pro is able to make the clock switch OK in both WinXP and Vista environments. The US8.04 system has the old firewire stack, and the US12.04.2 system has the new firewire stack. I've looked about, and I don't have any distribution disks available for any 'interim' releases that contain both the old and new stack for testing. I've attached a tar archive with three files. A nosy_dump of the failing session, a nosy_dump of a successful session under windows, and the output of ffado-test ListDevices. -- Ticket URL: <http://subversion.ffado.org/ticket/367> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2013-04-18 18:08:51
|
#367: Jack locks up when ffado-mixer attempts to set clock source to SPDIF or ADAT ----------------------------------------+----------------------------------- Reporter: rgreen | Owner: arnonym Type: bug | Status: new Priority: major | Milestone: Indeterminant (awaiting volunteer) Component: ffado-mixer | Version: FFADO 2.1.0 Resolution: | Keywords: Device_name: Saffire Pro26I/O (BeBob) | ----------------------------------------+----------------------------------- Comment (by rgreen): I misspoke. Jack isn't running when I attempt this. It's ffado-mixer that locks up, and jack will refuse to start after I attempt to set the clock source to spdif. -- Ticket URL: <http://subversion.ffado.org/ticket/367#comment:1> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2013-04-22 02:30:58
|
#367: ffado-mixer locks up when it attempts to set clock source to SPDIF or ADAT ----------------------------------------+----------------------------------- Reporter: rgreen | Owner: arnonym Type: bug | Status: new Priority: major | Milestone: Indeterminant (awaiting volunteer) Component: ffado-mixer | Version: FFADO 2.1.0 Resolution: | Keywords: Device_name: Saffire Pro26I/O (BeBob) | ----------------------------------------+----------------------------------- Changes (by jwoithe): * summary: Jack locks up when ffado-mixer attempts to set clock source to SPDIF or ADAT => ffado-mixer locks up when it attempts to set clock source to SPDIF or ADAT Comment: FYI I've changed the ticket summary to reflect your updated information that it's not jack which locks up. Unfortunately, due to a typo in the repo in the leadup to the release of version 2.1.0, ffado version 2.999.0 is in fact older than version 2.1.0. All subversion revisions between ffado 2.0 and 2.1 had this erroneous version number. Is it possible for you to upgrade to ffado version 2.1.0 and re-test. I strongly suspect that this won't make a huge difference, but at least then we know that we're both working from a recent code base. To confirm my understanding of the problem: under Ubuntustudio 8.04 (with the old firewire stack) you can set the Saffire's clock source to SPDIF without any trouble, but exactly the same action under Ubuntustudio 12.04.2 causes the lockup. It's rather odd that the different kernel stacks would give rise to this sort of behaviour. Tracking it down could prove interesting. The most obvious difference between the two nosy captures is that in the "failing" case we see what appears to be an infinite loop involving sequential read requests to offsets 0xfffff0000904 and 0xfffff0000984. In the trace from windows there is only ever one read from these two locations and - perhaps significantly - they are not sequential. Would it be possible to obtain a nosy dump when the Ubuntustudio 8.04 makes this change? Comparing this to the failing case may be easier since it's running a system that's much closer to Ubuntustudio 12.04.2 than is the windows environment. -- Ticket URL: <http://subversion.ffado.org/ticket/367#comment:2> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2013-04-22 04:32:59
|
#367: ffado-mixer locks up when it attempts to set clock source to SPDIF or ADAT ----------------------------------------+----------------------------------- Reporter: rgreen | Owner: arnonym Type: bug | Status: new Priority: major | Milestone: Indeterminant (awaiting volunteer) Component: ffado-mixer | Version: FFADO 2.1.0 Resolution: | Keywords: Device_name: Saffire Pro26I/O (BeBob) | ----------------------------------------+----------------------------------- Comment (by rgreen): Thank you. Yes, its ffado-mixer that locks up. And it also leaves the interface or the firewire bus in some irregular state, as I can't start jack after I've attempted this switch, but jack will start with the internal clock if I do it immediately after a reboot. I haven't found any other workaround. I've tried power cycling the interface, unplugging the firewire cable, killing ffado-mixer and ffado-dbus-server, but it seems nothing short of a reboot will put the bus back into a usable state. I've been unable to get a nosy-dump of the US8.04 system, because that's the only system I have running right now with a PCMCIA slot. I have obtained a PCI-PCMCIA adapter card, but I have yet to build up a system with one of the cast-off machines around here to serve as another nosy- dump host. I should be able to manage that in the next few days... -- Ticket URL: <http://subversion.ffado.org/ticket/367#comment:3> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2013-04-22 16:08:40
|
#367: ffado-mixer locks up when it attempts to set clock source to SPDIF or ADAT ----------------------------------------+----------------------------------- Reporter: rgreen | Owner: arnonym Type: bug | Status: new Priority: major | Milestone: Indeterminant (awaiting volunteer) Component: ffado-mixer | Version: FFADO 2.1.0 Resolution: | Keywords: Device_name: Saffire Pro26I/O (BeBob) | ----------------------------------------+----------------------------------- Comment (by rgreen): I booted the laptop from the UbuntuStudio 13.04 daily build of 4/20 and ran a few tests. That liveCD has ffado 2.1.9999 with a January date. Ffado-mixer still exhibits this bug. Would it be possible to configure subversion so that it reports the svn level in the third position of version instead of the constant 9999? Then it might survive ubuntu's packaging, which seems to strip off the svn level. I did notice that ffado-mixer opened up in the 'too tall' UI, so it was post-2.1 but pre-UI-change. -- Ticket URL: <http://subversion.ffado.org/ticket/367#comment:4> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2013-04-23 01:06:50
|
#367: ffado-mixer locks up when it attempts to set clock source to SPDIF or ADAT ----------------------------------------+----------------------------------- Reporter: rgreen | Owner: arnonym Type: bug | Status: new Priority: major | Milestone: Indeterminant (awaiting volunteer) Component: ffado-mixer | Version: FFADO 2.1.0 Resolution: | Keywords: Device_name: Saffire Pro26I/O (BeBob) | ----------------------------------------+----------------------------------- Comment (by jwoithe): Thanks for confirming the behaviour with the recent ffado snapshot. It would be great if you could do the nosy sniff of the older US8.04 system at some point because the resulting dump may well give us some indication as to what's going wrong here. I'll await further news on this; I understand that it may take some time to set up for doing this. Regarding the version number, I don't think it has anything to do with subversion. Subversion itself is correctly reporting the revision number. Having said that, I've noticed for the last year or more that debian- derived distributions seem to drop the svn revision number from the version number they report, but I've never had the time to look into what was going on (I don't run a debian-based system). Digging a bit further, I notice that if the ffado source is acquired via an export rather than a checkout, then the revision number will be empty. Therefore, if this is how the source is obtained for debian packaging then this is probably the root cause as to why the packages don't include the revision number. This would also explain the lack of a revision number in ffado-diag under these distribution packages. I'm not sure there's much we can do about this issue in this case: if the debian packagers are using exported source trees the revision number is totally unavailable once this process is done. The only way to make revision numbers accessible would be to have a statically defined file which contained the revision number which would need continuous manual updating - which is obviously never going to work in practice. I will keep thinking about this, but if the above is true there may not be anything we can do about the version number issue. -- Ticket URL: <http://subversion.ffado.org/ticket/367#comment:5> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |