Ticket #55 (closed task: fixed)

Opened 13 years ago

Last modified 8 years ago

survive bus resets when streaming

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

Description

Make FFADO at least survive bus resets, possibly generating an xrun.

Change History

03/27/12 07:44:51 changed by jwoithe

Over the years some progress has been made towards this goal (see for example r2074). It is however a tricky problem to solve and there are almost certainly situations remaining where we can't recover without a complete restart. Given that things are better now than in 2008 should we close this ticket? Or are there ideas floating around which justify keeping it open?

(follow-up: ↓ 3 ) 03/29/12 08:02:39 changed by wagi

My guts feeling is that the necessary complexity you would have to add to overcome this problem is just not worth. The streaming part is already complex enough.

Of course, it is very annoying if your live recordings are interrupted because of a bus reset. The question to answer is, does this happen often, rarely, never?

From my past experience, if you have a crappy cable or connector you will have a lot of bus resets. In those situation you will never get it working nicely.

(in reply to: ↑ 2 ) 03/29/12 15:40:13 changed by jwoithe

Replying to wagi:

My guts feeling is that the necessary complexity you would have to add to overcome this problem is just not worth.

I'm certainly tending toward this conclusion too. These days it's not as bad as it has been in the past; as far as I can tell ffado can, in certain situations, recover from an xrun. So it's really just the bus reset thing that we're missing.

To survive bus resets one has to make allowances for the device's streaming subsystem to be completely reset from scratch (some devices at least will require this). The current structure of FFADO provides no convenient way to do this. One would probably have to device a bus reset handler for each device and charge it with the responsibility of resetting the streaming system. Then there would be a global bus reset handler which coordinated the whole thing. While it's not rocket science, there's certainly a fair amount of work involved.

Of course, it is very annoying if your live recordings are interrupted because of a bus reset. The question to answer is, does this happen often, rarely, never?

In my experience, if the system is stable you simply don't get bus resets in the course of normal operation.

From my past experience, if you have a crappy cable or connector you will have a lot of bus resets. In those situation you will never get it working nicely.

Agreed - and we certainly shouldn't spend a lot of time trying to paper over problems caused by flaky hardware. If the hardware is all good, bus resets simply shouldn't occur during normal operation. If one does something to change the bus topology then sure, a bus reset will be triggered then, but one could argue that you shouldn't be doing that sort of thing when making a critical live recording anyway.

Out of interest, does anyone know how other systems deal with bus resets which occur while streaming is active?

So on balance my vote is to close this ticket at this stage.

03/30/12 00:00:16 changed by cladisch

does anyone know how other systems deal with bus resets which occur while streaming is active?

The IEC61883 protocol has been designed to be pretty much unaffected by bus resets: all devices just continue streaming, but to detect devices that have gone away, all connections must be confirmed within one second after the bus reset. (This implies that conforming implementations must not establish new connections in this interval; libiec61883 is not conforming.)

DICE devices stop streaming on a bus reset, but retain all settings, so the driver can just report an xrun and let the application restart.

All this works just fine in my kernel drivers.

03/30/12 03:28:40 changed by jwoithe

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

From comment 4:

The IEC61883 protocol has been designed to be pretty much unaffected by bus resets: all devices just continue streaming ... DICE devices stop streaming on a bus reset, but retain all settings ...

MOTUs and RMEs tend to do the same as DICE I think, although to restart streaming one has to ensure the device's streaming subsystem is re-primed.

All this works just fine in my kernel drivers.

Given that this is the case (even if it is for only a limited number of devices at present) and that eventually we'll move all the streaming into the kernel using your kernel driver as a template, I think this ticket can be closed. I'll label it "fixed" because some aspects of it have been addressed in the 4 years since it was opened, but with the understanding that there are still cases where things could be improved notwithstanding the points made earlier in this discussion.

If someone in the meantime submits a patch to address this issue we can certainly re-open this ticket if it's an appropriate place to discuss that work.