Ticket #180 (closed feature: wontfix)

Opened 6 years ago

Last modified 2 years ago

loop back mode for ffado

Reported by: dx9s Assigned to:
Priority: major Milestone: FFADO 2.x
Component: Version: FFADO SVN (2.0 branch)
Keywords: b1484 Cc:
The device the bug applies to:

Description (Last modified by ppalmers)

I've been seeing strange xruns and tracked it down... It comes from something that occurs (and it's not in jackd or kernel as jackd w/ dummy is fine) -- need jackd w/ libffado and a loopback mode to see if it's in the core streaming interface code or in the hardware driver side (fireworks, freebob, motu, etc.)

The problem is xruns (one or two created in a short period) when the free system memory (which is used for disk caching) is completely used up in caching ardour writing to disk... understand the SYSTEM is not out of memory.. it's just the disk cache is releasing old disk cache and replace it with more recent disk I/O activity...

I think the problem can be hunted down easier with a dummy loopback "driver" that simply loops anything out back to in (like dummy in jackd).

The problem does seem to pop up on on of my machine with a single core and only on the other machine with a dual core.. so I suspect it might be something like BKL (Big Kernel Lock) which effect SMP systems. I **COULD** make a single core only kernel and run on this machine (using only one core) and see if all is good THAT way (as-well).

But in any case -- this is weird... I also need to figure out a way to limit disk caching to less than all un-used system memory ... perhaps write a program that allocates memory.

(understand I have gone and tested with BOTH swap memory enabled and disabled)

This is a See ticket #179 as this is what I've found after testing same jackd svn, same ffado svn and same ardour2 ... only difference is kernel / cpu / memory / hardware ... and the machine with XRUNS is superior in my opinion. (more memory, faster, dual core, etc.)

--Doug

Change History

11/28/08 00:27:48 changed by dx9s

oops The problem does seem to pop up on on of my machine with a single core

should read

The problem doesn't seem to pop up on on of my machine with a single core

11/29/08 03:11:04 changed by ppalmers

  • description changed.
  • milestone changed from FFADO 2.0 to FFADO 2.x.

Unfortunately things are not that simple. libffado's streaming is driven by the libraw1394 packet callbacks. Those are driven from kernel space, by the ISO traffic on the wire.

The implementation of a loopback mode is a good idea, but technically not easy at all.

10/12/09 14:34:27 changed by arnonym

  • summary changed from ffado needs a loop back mode to loop back mode for ffado.

(Make the title a bit less dramatic.)

Would it be possible to run one jack in bounce mode and another one connecting to it?

03/28/12 02:20:52 changed by jwoithe

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

As Pieter said, because ffado's timing is driven by the flow of traffic on the bus, writing a loopback mode would be rather tricky. Since we have a very limited number of core developers (all of whom are volunteers with day jobs unrelated to FFADO) and the somewhat limited use such a mode would have for ongoing development, it doesn't seem sensible to dedicate core developer time to a loopback mode. Of course if someone turns up with code which implements such a feature we'll gladly take a look and integrate it if it makes sense.

For now I'll close this as "wontfix".