Ticket #101 (closed task: wontfix)

Opened 12 years ago

Last modified 8 years ago

fix iec61883 bandwidth allocation

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

Description

from config.h.in:

// The current version of libiec61883 doesn't seem to calculate
// the bandwidth correctly. Defining this to non-zero skips
// bandwidth allocation when doing CMP connections.
#define IEEE1394SERVICE_SKIP_IEC61883_BANDWIDTH_ALLOCATION 1

This should be investigated and fixed

Change History

03/29/12 06:45:28 changed by jwoithe

Do we know anything more about what libiec61883 was doing wrong here? Does the current version of libiec61883 (which I believe is 1.2.0) still do the wrong thing? The code for iec61883_cmp_calc_bandwidth() in libiec61883 1.2.0 appears sane at first glance, but I'm no expert with CMP.

03/29/12 07:28:20 changed by cladisch

libiec61883

  • always tries to use some oPCR, but for broadcast connections, then uses some completely different oPCR, or even an iPCR;
  • assumes that somebody has already set the PCR's overhead_id field to the correct value (of course, nobody ever does); and
  • does not support any speeds faster than S400.

Computing the bandwidth overhead is not easy. This paper goes into great detail, but ignores the fact that we do not know the actual cable lengths. The kernel driver tries to derive the bandwidth overhead from the gap count, but this is currently not possible in user space.

03/29/12 15:27:40 changed by jwoithe

Thanks Clemens for the details of what the problem is. Clearly it's not an easy problem to solve and it doesn't appear that it's going to be fixed in libiec61883 any time soon. So where does that leave us in terms of resolving this issue? Should we just ignore the problem and run with the line that libiec61883 doesn't do this properly - that's what is done now and as far as I know it's had no practical impact on users, even if it is technically incorrect. Should we code this functionality ourselves within FFADO, assuming we can determine what exactly needs to be done? Or (in a similar vein) should we work out what needs to be done and push the fix into libiec61883?

The problem with the last two options is that they clearly require a fair amount of background reading before we can know what should be done. Plus of course the gap count isn't presently available to userspace anyway.

In terms of the first suggestion, when the streaming drivers are ultimately ported to the kernel anything we do in relation to this problem is likely to become irrelevant anyway. Therefore is there any in spending a lot of time addressing this now, even though the move to kernelspace is probably still a fair way off?

What do you suggest is the prudent approach here?

03/29/12 23:48:15 changed by cladisch

Not doing bandwidth allocation just means that the incomprehensible error message that is output before jack dies has a different wording.

All the other protocols do allocate bandwidth, but AFAICS all of them assume S400 and use a fixed estimate of the overhead.

03/30/12 00:08:38 changed by stefanr

From quite a while back I remember someone discussing to drop libiec61883 dependency from ffado entirely. I don't remember who and when.

Another aspect: If you add bandwidth allocation, there is an at least theoretical possibility of conflicts with device firmwares that wrongly allocate bandwidth too. Such firmware behavior was said to be occasionally present in some AV/C consumer/entertainment video devices.

03/30/12 03:21:20 changed by jwoithe

From comment 4:

All the other protocols do allocate bandwidth, but AFAICS all of them assume S400 and use a fixed estimate of the overhead.

I can confirm that at least for the MOTU and RME drivers the above summary is correct. Then again, the devices themselves require S400 or else there's insufficient bandwidth in some modes, so the fixed S400 assumption turns out to be reasonable in the circumstances.

So given all that, if we're going to do bandwidth allocation for this protocol as well we'll have to code it ourselves, but it's clearly a complex problem and may not be worth spending time on.

As I see it, we have the following options:

  • leave things as they are and effectively close the bug (maybe set the milestone to FFADO 3 so it may be reviewed at some indeterminate time in the future)
  • code up some sort of a crude estimation of bandwidth based on the assumptions made in the MOTU and RME code and use that (we'd need some way to get the channel counts out of CMP)

I'm leaning towards the former since there seems little to be gained practically by implementing bandwidth allocation, and we've lived with the current situation for over 4 years.

04/27/12 08:00:34 changed by jwoithe

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

It seems that no one has strong opinions one way or the other in regard to this, so I'll close this ticket as "wontfix" for the moment. If a practical need for this arises at some point in the future we can always revisit it.