Ticket #326 (new bug)

Opened 4 years ago

Last modified 11 months ago

Cannot start jack with Saffire PRO 40, new firewire stack and 96KHz sample rate

Reported by: darkbasic Assigned to:
Priority: waiting for device info Milestone: Indeterminant (need device info)
Component: generic Version: FFADO SVN (trunk)
Keywords: Cc: nils, jwoithe
The device the bug applies to: Focusrite Saffire PRO 40

Description

I use latest ffado and lib1394 snapshots, kernel 2.6.38 and Gentoo amd64 with pro-audio overlay. 44.1 Khz and 48 KHz do work flawlessly (except for the routing bug http://subversion.ffado.org/ticket/325).

Attachments

AutoStatic-ffado_96khz.log (86.6 kB) - added by autostatic on 11/04/12 03:58:19.
Log of Saffire PRO 40 running at 96kHz with JACK 0.121.3 and FFADO 2.1.0
AutoStatic-ffado_diag_lsi.txt (7.8 kB) - added by autostatic on 11/04/12 03:59:18.
Output of ffado-diag on machine with Saffire PRO 40 attached

Change History

03/27/12 07:36:20 changed by jwoithe

I believe some work has been done with the Saffire driver which may address at least some of the issues noted in this ticket. Can you please re-test with new ffado/jack and report back with your findings?

03/27/12 16:05:56 changed by jwoithe

  • milestone set to FFADO 2.x.

Reported on the mailing list by Philippe Carriere:

Well, from my own tests: jack starts at 96kHz with the new firewire stack but playback streaming almost does not work (I mean, some 1/2s with sound - apparently correct - for 10s of silence, mostly random). A point is that everything work at 88.2kHZ (and 44.1 and 48kHz, of course); I did not see an evident mistake in the configuration, at first glance. Further work is clearly required.

It's strange that other rates - even 88.2 kHz - are seemingly ok. At first glance that would suggest some sort of throughput issue. However, the difference between 88.2 and 96 isn't all that much so it's a bit hard to see how a modern machine would work fine with the former but fail with the latter.

To resolve this we clearly need someone who owns a Saffire PRO 40 to pick this up and determine what the problem is. I'll set the milestone to 2.x for now since the timing for this to occur is completely unknown. If it happens in the next month and makes 2.1, well and good. If not, I don't consider it a show-stopper for 2.1.

In the meantime it would be good to hear from other PRO-40 owners to see if these problems affect them too.

06/03/12 05:51:46 changed by jwoithe

  • priority changed from major to waiting for device info.
  • milestone changed from FFADO 2.x to Indeterminant (need device info).

As per comment 2, we need more information about the Pro-40 related to operation at 96 kHz. Without this (and someone with a Pro-40 to look into this issue) it's not possible to make any progress on this ticket report. Given the lack of progress over the past two months I doubt this can be resolved before 2.1. Since we are more or less waiting for device information I'll set the priority and milestone to reflect this. We can therefore pick things up when further information comes to hand.

06/12/12 07:29:56 changed by nils

  • cc set to nils.

Last time I tried 96kHz on my (then still solitary) Saffire Pro40, I experienced the same. I'll try to remember looking into this when I get to my gear next time.

06/13/12 15:58:06 changed by nils

Ok, I doubt that this is a matter of Firewire bandwidth, and here's why:

I tested this by playing music with audacious in all combinations of 88.2/96kHz sample rate and connections routed to a stereo pair of inputs on one interface and alternatively with the output of audacious connected to all 2*20=40 inputs on my two Saffire Pro40s. Regardless of whether I connected to only two inputs on one interface or all 40 on both, I saw this: With 88.2kHz, the music played back flawlessly(*), with 96kHz it played back for 2-3 beats, then went mute for about the same time, then unmuted, then went mute again and so forth. I didn't see anything unexpected in the jackd messages. Is there anything else I should check?

(*): For those who read about my unexplainable glitch problems: I seem to be suffering from a Heisenbug here -- no xruns today and I really have no idea what should be different today than the days before.

06/13/12 16:43:47 changed by jwoithe

  • cc changed from nils to nils, jwoithe.

Nils: thanks for the testing. One thing that's worth bearing in mind here is that the amount of data sent to/from the device does not depend at all on how many inputs/outputs you're actually using. If jackd is running with FFADO then all inputs and outputs active on the device are being sent, even if there's no software running and connected to the jack ports. At least this is how it is with every other interface that I'm aware of; I assume it'll be the same with DICE.

In the context of the tests you outlined above, what this means is that the bandwidth being used on the wire during 2-channel playback is exactly the same as during 40-channel playback.

Despite this, I do agree that it doesn't seem to be a bus bandwidth problem - but for different reasons in light of what I've outlined above. Firstly, the problem at 96 kHz manifests itself when either one or two Pro40s are in use, and the bus wire bandwidth when using one device is half that used when two devices are in use. In addition, it's quite obvious that 88.2 kHz operation across two devices will exceed the bandwidth required for 96 kHz operation on a single device. Since the former works and the latter doesn't, it strongly suggests that we're not talking a bus bandwidth issue here. In other words, there's something about 96 kHz operation on the Pro40 that's causing trouble on at least some systems.

Just to cover all bases, could you attach the output of ffado-diag to this ticket? I don't expect this will show anything, but it's worth checking to make sure.

06/14/12 05:46:40 changed by jwoithe

For those who read about my unexplainable glitch problems: I seem to be suffering from a Heisenbug here -- no xruns today and I really have no idea what should be different today than the days before.

That's certainly strange. Nothing I can think of (things like memory pressure, denormals, differing system loading) is all that plausible given what you described on ffado-devel. It might be worth posting this development to ffado-devel since that's where the discussion is currently happening.

06/14/12 05:50:12 changed by nils

I intend to do that. This disclaimer was merely to not get people confused (at least any more than I am ;-)) because I said one thing a few days before and something different here in this ticket.

11/04/12 03:55:47 changed by autostatic

Ran some tests with my PRO 40 at 96kHz. Got stuttering audio too and I get the idea that has something to do with these messages:

Warning (IsoHandlerManager?.cpp)[1573] putPacket: reconstructed CTR counter discrepancy

I've attached a log and the output of ffado-diag of the machine with the PRO 40 attached.

Regards,

Jeremy

11/04/12 03:58:19 changed by autostatic

  • attachment AutoStatic-ffado_96khz.log added.

Log of Saffire PRO 40 running at 96kHz with JACK 0.121.3 and FFADO 2.1.0

11/04/12 03:59:18 changed by autostatic

  • attachment AutoStatic-ffado_diag_lsi.txt added.

Output of ffado-diag on machine with Saffire PRO 40 attached

11/08/12 10:32:57 changed by leandromarco

Hi. I've just bought a Saffire Pro 40 and here this problem also occurs as described ( I tested with the latest svn revision of ffado).

I saw here that this bug is marked as "waiting for device info". I also saw that new logs have been attached here, but if you need more info regarding this issue I will be glad to help.

I am not a ffado developer (although I know programming), so I need some directions regarding which information is useful to you.

11/09/12 03:50:15 changed by jwoithe

Thanks "leandromarco" for your feedback. It is clear that there is something about the Pro40's operation at 96 kHz which FFADO is currently unable to deal with. The ticket is marked "waiting for device info" because in this case we really need further information about how the device operates at 96 kHz so we can determine why FFADO is unable to do so reliably. For example, it may be that there's a vendor-specific register which needs to be set to a magic value, or perhaps the Pro40 gets upset because we do something in an order which it doesn't like.

In other words, what we need is some low level programming information about the Pro40 at 96 kHz. Ideally this would be in vendor-supplied documentation but I don't know if the information is available in a form that can be released publicly. Beyond that, analysing how other systems control the device at 96 kHz could provide the answers, but this would require some tedious protocol analysis work.

Phil (Philippe on the ffado-devel mailing list) has been doing a lot of work recently with the Saffire driver, but that's been mostly associated with routing and the mixer. He may have something to add, but I think he's at the point where the afore-mentioned information is needed so we can make sense of what's happening.

10/28/13 14:16:15 changed by la-page-web-of-phil

I began to track this bug and has some news, not so bad but not so fair. Indeed, I was able to have playback streaming working correctly at 96kHz, but success is randomly distributed. First note I upgraded recently to the last Focusrite firmware (released around August 2013: MIDI users have to be cautionned that they might experience problems with this update). Then, sometime it works when "starting from zero": I mean, PC and Pro 40 powered down, plugin in the cable, powering on the Pro 40, powering on the PC (after all leds available), then starting ffado-mixer and selecting 96kHz, finally starting jack at 96kHz.

Thus I was able to compare some outputs in working/not working situations: the long outputs from jack do not seem to show very different things. At the opposite, running test-dice-eap while jack running shows that:

(dice_avdevice.cpp)[ 739] showDevice: Extended Status : 0x00000040

when playback works while

(dice_avdevice.cpp)[ 739] showDevice: Extended Status : 0x00000000

otherwise.

(note: I checked that 0x40 is also the value at 88.2kHz - always working - and 0xC0 at 48 and 44.1kHz).

Also, the notification register

(dice_avdevice.cpp)[ 721] showDevice: Notification : 0x00000040

is sometime at 0x20 or 0x10 when playback doesn't work (but not always).

I would like to have the opinion of more experimented developers than me. Also, I must have a further, more precise, look to the code, but I am vaguely wondering if:

  • introduction of a kind of temporization somewhere during the streaming initialization (possibly around IsoHandlerManager?.cpp()) wouldn't be of help. This would be due to the fact that Pro 40, at 96kHz, would be slower to set its internal (firmware/hardware specific).
  • otherwise, might be Pro 40 does not succeed all times to set its internal correctly and this would require to repeat some initialization phase until success. Here, I refer to an unclear "general stability" gain comment at Focusrite web page, about their new firmware version. Possibly, the fact I was able, under some circumstances, to obtain playback streaming at 96kHz with the new firmware is not fortuitous.

Regards,

Phil