Ticket #243 (closed bug: fixed)

Opened 11 years ago

Last modified 8 years ago

pro26 adat clock source selection not correct

Reported by: ppalmers Assigned to: ppalmers
Priority: major Milestone: FFADO 2.1
Component: Version: FFADO 2.0-rc1 (1.999.40)
Keywords: Cc:
The device the bug applies to: saffire pro26


I'm running the RC1 version on Ubuntustudio 8.04. Last night I recorded a show using the eight built-in preamps, and one outboard ADAT unit. Unfortunately, I was never able to capture any audio thru the ADAT channels 11-15. Since I was running FOH as well, I could not divert my attention to do any debugging during the show.

This morning, I duplicated the setup back at home, and discovered what

was happening:

I had a single ADAT interface plugged into the 'ADAT 9-16 in' port, and

I was trying to capture audio from channels 11-15, which correspond to ADAT channels 1-5. Doh!

But the confusing part was that I had used ffado-mixer-qt3 to set the

clock sync source to 'ADAT 1', and it sync'd up fine.

This morning, I set up the rig with the ADAT interface plugged into

'ADAT 1-8 in', and I get audio streamed from channels 11-15 just fine, but in order to get the clock source to sync up, I have to select 'ADAT 2' as the clock source.

So it appears that in the RC1 version, the clock source selection is

actually reversed from what it should be. I see a note in the beta7 - RC1 release notes that clock source selection was corrected, but no notes in the RC1 - RC2 release pertaining to this issue, and a search of this list archive didn't turn up a comment, so I thought I'd mention it.

Change History

04/01/12 07:25:46 changed by jwoithe

Are there any Pro26 owners out there who can test FFADO trunk for this problem? Is it an issue which needs correction? From the description it doesn't sound like it's a particularly difficult problem, but the devil may be lurking in the detail.

04/27/12 07:06:29 changed by jwoithe

It seems there are no Saffire Pro26 users watching this ticket or ffado-devel. I'll close this bug as "fixed" in a week or so if no further information is forthcoming in that timeframe.

05/04/12 04:26:43 changed by jwoithe

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

With no further feedback on this issue I'll assume this problem has been fixed and close the ticket. If someone testing a recent subversion snapshot with a Pro 26 observes that the problem persists this ticket can be re-opened.