On Sat, Jan 16, 2010 at 05:20:03PM +0100, Jonas Smedegaard wrote:
Hi!
>> If need be, file a ticket at subversion.ffado.org
> I guess it makes sense to first try isolate which part of the Debian
> packaging system cause problem before passing it upstream:
That's a good idea. Thanks for your comprehensive tests.
> Results using *jack* 0.118+svn3796-1, *ffado* 2.0~rc2+svn1569-2 and
> *freebob* 1.0.11-1 (i.e. latest Debian Sid except jackd and least
> possible dependencies rolled back to latest Debian Squeeze):
>
> OK: firewire-ohci + jackd -d firewire -p 512 -n3 -r 44100 -v5
> OK: dv1394 + raw1394 + jackd -d firewire -p 512 -n3 -r 44100 -v5
> OK: dv1394 + raw1394 + jackd -d freebob -p 512 -n3 -r 44100
So to sum this up: ffado-2.0~rc2+svn1569-2 gives good results. Freebob
doesn't matter here, and I'd for now say that jackd version doesn't
matter, but we'll soon find out...
> Above makes me assume that hardware (MacBook) is ok.
I would say so, yes.
> Results using *jack* 0.118+svn3796-2, *ffado* 2.0.0-1 and no *freebob*
>
> OK: dv1394 + raw1394 + jackd -d firewire -p 512 -n3 -r 44100 -v5
> FAIL: firewire-ohci + jackd -d firewire -p 512 -n3 -r 44100 -v5
That's interesting. It would indicate that ffado itself is "fine", and
it's somehow a question between ffado and the new stack in this
particular version.
There has been a small update to FFADO to make it run on Juju stacks,
however, your tests with the rc2+svn1569 indicate that it has been
(somehow) working before.
I checked
http://subversion.ffado.org/ticket/240
and it looks like the FFADO-on-Juju fixes never got applied to the 2.0.0
release branch.
Any chance you can rebuild libffado from source and apply a patch,
first?
I'm thinking of:
# apt-get source libffado
# apt-get build-dep libffado
$ cd libffado-*
$ patch -p1 < /path/to/ffado-2.0.0.patch
$ debuild
$ sudo debi
I've attached ffado-2.0.0.patch to this mail. I guess this could make
ffado work on Juju. If so, I'll take care that this patch gets applied
upstream and that we get another release, perhaps ffado-2.0.1.
> So, it seems to be that problem is in either jack compilation/linkage or
> in FFADO source.
I bet it's FFADO source, but we'll find out:
> How to proceed from here? More tests I can perform?
You can test ffado-2.0rc2+svn1569-2 (the testing version) on new jackd.
Simply install libffado1 and overwrite/symlink to libffado2 in /usr/lib.
This way, both, old and new jackd versions can be tricked to pick up
either libffado1 or libffado2. (these libs are API/ABI compatible at the
moment, so this dirty hack can work.)
This makes sure jackd or linkage isn't the culprit.
> Should I post above to upstream FFADO or Jackd developers (and if so,
> how?)?
Let's first try the attached patch. It has nothing to do with the jackd
developers, since jackd code hasn't changed, only ffado.
I've already pinged ffado upstream on this bug report, and I'm somewhat
ffado upstream myself, so I'll take care of everything.
Cheerio
--
mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver
diff --git a/src/libieee1394/IsoHandler.cpp b/src/libieee1394/IsoHandler.cpp
index d33f9e6..b43e420 100644
--- a/src/libieee1394/IsoHandler.cpp
+++ b/src/libieee1394/IsoHandler.cpp
@@ -84,7 +84,6 @@ IsoHandler::IsoHandler(IsoHandlerManager& manager, enum EHandlerType t)
, m_Client( 0 )
, m_speed( RAW1394_ISO_SPEED_400 )
, m_prebuffers( 0 )
- , m_dont_exit_iterate_loop( true )
, m_State( eHS_Stopped )
, m_NextState( eHS_Stopped )
, m_switch_on_cycle(0)
@@ -424,22 +423,8 @@ enum raw1394_iso_disposition IsoHandler::putPacket(
#endif
// iterate the client if required
- if(m_Client) {
- enum raw1394_iso_disposition retval = m_Client->putPacket(data, length, channel, tag, sy, pkt_ctr, dropped_cycles);
- if (retval == RAW1394_ISO_OK) {
- if (m_dont_exit_iterate_loop) {
- return RAW1394_ISO_OK;
- } else {
- m_dont_exit_iterate_loop = true;
- debugOutput(DEBUG_LEVEL_VERBOSE,
- "(%p) loop exit requested\n",
- this);
- return RAW1394_ISO_DEFER;
- }
- } else {
- return retval;
- }
- }
+ if(m_Client)
+ return m_Client->putPacket(data, length, channel, tag, sy, pkt_ctr, dropped_cycles);
return RAW1394_ISO_OK;
}
@@ -574,19 +559,7 @@ IsoHandler::getPacket(unsigned char *data, unsigned int *length,
this, getTypeString(), *length, m_max_packet_size);
}
#endif
- if (retval == RAW1394_ISO_OK) {
- if (m_dont_exit_iterate_loop) {
- return RAW1394_ISO_OK;
- } else {
- m_dont_exit_iterate_loop = true;
- debugOutput(DEBUG_LEVEL_VERBOSE,
- "(%p) loop exit requested\n",
- this);
- return RAW1394_ISO_DEFER;
- }
- } else {
return retval;
- }
}
*tag = 0;
diff --git a/src/libieee1394/IsoHandler.h b/src/libieee1394/IsoHandler.h
index 16e0fb9..01ec49a 100644
--- a/src/libieee1394/IsoHandler.h
+++ b/src/libieee1394/IsoHandler.h
@@ -142,21 +142,6 @@ public:
bool canIterateClient(); // FIXME: implement with functor
- /**
- * @brief request that the handler exits the packet processing loop ASAP
- *
- * The raw1394 lib doesn't provide a means to stop the packet iteration loop
- * except when the iterate callback returns a DEFER value. Calling this function
- * will make the callback return DEFER ASAP.
- */
- void requestIterateLoopExit() {m_dont_exit_iterate_loop = false;};
- /**
- * @brief allow the handler to stay in the packet processing loop
- *
- * This resets the state set by requestIterateLoopExit()
- */
- void allowIterateLoop() {m_dont_exit_iterate_loop = true;};
-
/**
* @brief get last cycle number seen by handler
@@ -202,7 +187,6 @@ private:
enum raw1394_iso_speed m_speed;
unsigned int m_prebuffers;
- bool m_dont_exit_iterate_loop;
// the state machine
enum EHandlerStates {
diff --git a/src/libieee1394/IsoHandlerManager.cpp b/src/libieee1394/IsoHandlerManager.cpp
index 9a7f784..66c145b 100644
--- a/src/libieee1394/IsoHandlerManager.cpp
+++ b/src/libieee1394/IsoHandlerManager.cpp
@@ -258,9 +258,6 @@ IsoTask::Execute()
if (h->canIterateClient()) {
events = POLLIN | POLLPRI;
no_one_to_poll = false;
- // if we are going to poll() it, let's ensure
- // it can run until someone wants it to exit
- h->allowIterateLoop();
}
m_poll_fds_shadow[i].events = events;
}
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
