From: FFADO <ffa...@ff...> - 2008-11-28 08:19:24
|
#180: ffado needs a loop back mode --------------------------------------+------------------------------------- Reporter: dx9s | Owner: Type: feature | Status: new Priority: major | Milestone: FFADO 2.0 Version: FFADO SVN (2.0 branch) | Keywords: b1484 Device_name: | --------------------------------------+------------------------------------- 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 -- Ticket URL: <http://subversion.ffado.org/ticket/180> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2008-11-28 08:27:54
|
#180: ffado needs a loop back mode -----------------------------------+---------------------------------------- Reporter: dx9s | Owner: Type: feature | Status: new Priority: major | Milestone: FFADO 2.0 Version: FFADO SVN (2.0 branch) | Resolution: Keywords: b1484 | Device_name: -----------------------------------+---------------------------------------- Comment (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 -- Ticket URL: <http://subversion.ffado.org/ticket/180#comment:1> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2008-11-29 11:11:09
|
#180: ffado needs a loop back mode -----------------------------------+---------------------------------------- Reporter: dx9s | Owner: Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Version: FFADO SVN (2.0 branch) | Resolution: Keywords: b1484 | Device_name: -----------------------------------+---------------------------------------- Changes (by ppalmers): * milestone: FFADO 2.0 => FFADO 2.x Old description: > 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 New description: 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 Comment: 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. -- Ticket URL: <http://subversion.ffado.org/ticket/180#comment:2> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2009-10-12 21:34:38
|
#180: loop back mode for ffado -----------------------------------+---------------------------------------- Reporter: dx9s | Owner: Type: feature | Status: new Priority: major | Milestone: FFADO 2.x Version: FFADO SVN (2.0 branch) | Resolution: Keywords: b1484 | Device_name: -----------------------------------+---------------------------------------- Changes (by arnonym): * summary: ffado needs a loop back mode => loop back mode for ffado Comment: (Make the title a bit less dramatic.) Would it be possible to run one jack in bounce mode and another one connecting to it? -- Ticket URL: <http://subversion.ffado.org/ticket/180#comment:3> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |
From: FFADO <ffa...@ff...> - 2012-03-28 09:21:06
|
#180: loop back mode for ffado -----------------------+---------------------------------------------------- Reporter: dx9s | Owner: Type: feature | Status: closed Priority: major | Milestone: FFADO 2.x Component: | Version: FFADO SVN (2.0 branch) Resolution: wontfix | Keywords: b1484 Device_name: | -----------------------+---------------------------------------------------- Changes (by jwoithe): * status: new => closed * resolution: => wontfix Comment: 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". -- Ticket URL: <http://subversion.ffado.org/ticket/180#comment:4> FFADO <http://subversion.ffado.org/index.fcgi> Free Firewire Audio Drivers |