From: Jonathan Woithe <jwoithe@ph...> - 2007-09-19 07:08:34
I've been giving some thought as to why ffado doesn't work at low period
sizes. First though I need to establish what I mean by "low". At a period
size of 1024 ffado seems quite stable on my system. I have also been able
to reliably start and run ffado at period sizes of 512 and 256 bytes. At
128 bytes things may be a bit shaky when other things start using JACK. At
a period size of 64 ffado (via jackd) does not manage to start and gets
itself into a continuous look of xrun handling. Note that this is with a
MOTU interface; behaviour with other interfaces might be different.
Although I still need to confirm this I suspect there are two different
problems. The first could be due to the time-lag between the enabling of
the rx and tx streams. Due to (kernel) buffering effects the tx stream
generally enables before the rx stream. As period size drops, the length of
time the tx stream can run before it needs its buffers refreshed also falls.
Eventually (which for me seems to be with a period size of 64 bytes) the
amount of data pre-queued in the tx buffer is not enough to last until the
rx stream is enabled. An instant xrun is the result. All this happens
because (as far as I can tell) jackd never gets a chance to top up the
buffers until after the streams have been enabled - libffado essentially
sits and waits for all streams to be enabled before jackd gets a chance to
do anything else.
I don't think this is the only issue though. I altered
StreamProcessorManager so it didn't wait for streams to flag themselves as
enabled - it just set them to enable and immediately returned. While this
appeared to prevent xruns occuring while "waiting for streams to enable",
an xrun still occurred soon after (often when doing the debug dump). This
makes me wonder whether there's something else within the ffado/jackd system
which is preventing jackd from keeping the buffers full when the buffers are
small. I know that the tx stream is called in bursts to fill its buffer;
I'm wondering whether the burst is preventing the rx buffer from getting a
All these tests have been run with RT scheduling, so it's not because that's
not in use.
I don't have any solutions at the moment and still don't really understand
what's going on. I'm posting this so others can see what I have seen on my
system in the hope that between us all we can work out what's going on and
Am Mittwoch, 19. September 2007 schrieb Jonathan Woithe:
> I've been giving some thought as to why ffado doesn't work at low period
> sizes. First though I need to establish what I mean by "low". At a peri=
> size of 1024 ffado seems quite stable on my system. I have also been able
> to reliably start and run ffado at period sizes of 512 and 256 bytes. At
> 128 bytes things may be a bit shaky when other things start using JACK. =
> a period size of 64 ffado (via jackd) does not manage to start and gets
> itself into a continuous look of xrun handling. Note that this is with a
> MOTU interface; behaviour with other interfaces might be different.
Its the same on bebob (using presonus firepod here). 256 bytes and more is=
okay and runs reliably (for hours) but anything below produces xruns. I=20
didn't test 64 but on 128 I get enough xruns that I am not able to play pia=
Hi, I am a .signature virus. Please copy me into your ~/.signature and send=
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your=20
administrator to do so...