Ticket #363 (new bug)

Opened 8 years ago

Last modified 8 years ago

RME Fireface 800 random latency

Reported by: juanramon Assigned to: jwoithe
Priority: major Milestone: FFADO 3.0
Component: devices/rme Version: FFADO SVN (trunk)
Keywords: latency frames Cc:
The device the bug applies to:

Description

I've noticed a strange issue. I was messuring the latency with jdelay and every time I restarted jack I red different amount of frames. ( 2933, 1457, 382 , etc) I changed the frames per period and even preriods per buffer but every time the result was erratic. I'm using jackdbus and juju stack.

This strange behaboir doesn't happen with my TC Electronic Konnekt 48 neigther with Focusrite PRO 40 so I thought it could be a problem with RME driver or maybe the hardware FPGA.

Change History

09/18/12 16:28:33 changed by jwoithe

  • owner changed from jwhoite to jwoithe.
  • milestone set to FFADO 3.0.

With the current FFADO streaming architecture there may not be a lot we can do about this. The problem is that the RME streaming system works in a rather different way to most other firewire devices, and it was an interesting exercise to get it to operate within the framework of FFADO (which was designed with a more conventional setup in mind). Some parts of the FFADO streaming system are utilised in unusual ways within the RME driver and I can quite understand that this may give rise to the behaviour you have seen.

When time allows (over the next week or so) I will run some tests myself to see if I can pin this down in more detail, but that may still not provide a way forward given the framework the driver has to work within. We'll see; if not possible to eliminate, there may be an opportunity to minimise the effect. Off the top of my head I strongly suspect it's due to a combination of the startup procedure we have to use and what we have to do to ensure the first start after powering the device on doesn't produce a short burst of high amplitude digital noise from the outputs.

For what it's worth I expect that when I move the RME streaming driver into the kernel (ETA completely unknown at this stage, but in my mind this will probably correspond to a FFADO 3) things will work better in this regard because there will be no need to work with a higher level streaming infrastructure. Of course this doesn't help in the present, but it shows that there is a longer-term solution possible.

09/21/12 08:15:20 changed by juanramon

Thanks for explanation and I apologize for mistakes.

10/31/12 07:36:27 changed by jwoithe

I've finally had some time to look into this. Not unsurprisingly, I can reproduce the original report in so far as jack_delay reports varying round-trip latencies for different jackd sessions. It's early days, but from my brief tests tonight it seems that the variation is not due to the mechanism I initially thought. That in itself is an interesting thing.

It definitely has something to do with the way the fireface is being driven because testing with another interface (MOTU Traveler) I don't see the latency variation. I shall continue to ponder this as to whether something can be done in the short term to at least minimise the effect (whatever it turns out to be).

11/03/12 04:10:20 changed by jwoithe

I've spent some time working through various scenarios. At this point it does not appear to be caused by what I initially thought, so I'm going to have to take a closer look at what's going on. For the record, this issue is almost certainly caused by something in FFADO's RME driver. The RME device itself (including the FPGA) would not be causing these erratic round-trip latencies (otherwise it would be seen under other systems, and it's not).

11/03/12 12:43:02 changed by juanramon

I was thinking the issue might be the driver, but like I cannot try it with other OS I've suggested the possiblity of of hardware problem. So now I'm happy because (likely) only the code is implicated in this issue.

11/09/12 03:40:04 changed by jwoithe

A brief update: I'm still trying to determine where this randomised latency is coming from. I've tested most of the obvious suspects but the behaviour remains unchanged. It seems that there is some strange interaction between the methods used by FFADO to drive the device and the way the device responds to those. Getting a handle on the details though is proving to be an interesting challenge. More information will follow as it comes to hand.

11/27/12 04:02:40 changed by jwoithe

Another update: I've been trying various experiments and hacks over the past few weeks to try to identify where this variable round-trip latency behaviour is coming from. Suffice to say I have not found it yet. I still suspect it's got something to do with the interaction between the interface and the synthetic timestamps we need to generate to keep FFADO's core happy, but identifying the precise mechanism at work is proving elusive.

I have a few more ideas in mind which I intend to pursue over the next week or so.