Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Jonathan Woithe <jwoithe@ph...> - 2010-12-20 14:01:32
While debugging the causes of a long (4-5 second) delay experienced when
starting RME streaming, one thing lead to another and I started looking at
the mechanism used for telling the kernel which cycle the iso streaming
should commence. In the case of the receive stream this is accomplished
with what is ultimatel a call to ieee1394_iso_recv_start() in libraw1394
which calls into the kernel via an ioctl. One of the arguments to this
function (and the kernel ioctl) is the cycle at which to commence operation.
In normal operation with ffado, this commencement cycle number always seems
to be set to 0. For the RME I don't really need the rx stream to wait for
the zero cycle (I want it to be -1), so I started to look at where this
number comes from. It turns out that it is just the value of
IsoHandler::m_switch_on_cycle at the time when enable() is called in
Now the start switch executed by updateState() is set up with a call to
requestEnable() which takes as a parameter the cycle to start on. The fly
in the ointment is that this parameter is not in fact used - it is
completely ignored. This means that m_switch_on_cycle is never altered from
its initialisation value (0) and thus all handlers - transmit and receive -
are always started at cycle 0.
This explains why the debug info from
StreamProcessor::scheduleStartDryRunning() indicates non-zero cycle counts
for "Start at" and yet the streaming only ever starts when cycle is 0.
With this in mind I've hacked an extension into IsoHandler and
IsoHandlerManager to permit the direct setting of m_switch_on_cycle from the
stream processor itself (see IsoHandler::setIsoStartCycle() and
IsoHandlerManager::setIsoStartCycleForStream()). For RME I then call the
latter with an argument of -1 and thus arrange for receive streaming to
start ASAP as desired. These changes are in r1943.
However, to me it seems odd that IsoHandler::requestEnable() doesn't set
m_switch_on_cycle itself (or use its "cycle" parameter in any way). What do
others think about this?
If it was determined that requestEnable() should set m_switch_on_cycle I
would have to come up with another way of ensuring "-1" was used as the
start cycle for the RME receive processor since
StreamProcessor::scheduleStartDryRunning() has no way of doing this itself
at present. But that's a problem for another day.
I was reluctant to change IsoHandler::requestEnable() without first
discussing it in case other ffado drivers were relying on the existing