Re: [FFADO-devel] [FFADO] #78: Port FFADO to the new firewire stack

[FFADO <ffa...@ff...>]

#78: Port FFADO to the new firewire stack
---------------------+------------------------------------------------------
Reporter:  ppalmers  |         Owner:           
    Type:  task      |        Status:  new      
Priority:  major     |     Milestone:  FFADO 3.0
 Version:            |    Resolution:           
Keywords:            |   Device_name:           
---------------------+------------------------------------------------------
Changes (by ppalmers):

 * cc: lin...@li... (added)

Comment:

 Replying to [comment:3 adi]:
 > First tests of Juju on 2.6.27.1 with libraw1394-2.0.0 and ffado r1359:
 >
 > Ieee1394Service::initialize complains about lacking
 raw1394_read_cycle_timer support. This isn't really true, it's a matter of
 initialization. For the old stack, the raw1394handle contains a file
 descriptor which gets initialized to fopen(/dev/raw1394) from
 raw1394_new_handle_on_port(). Later, ioctl(handle->fd,
 RAW1394_IOC_GET_CYCLE_TIMER, &) is called.
 >
 > For the new stack, things are pretty much the same, except that
 handle->fd is now handle->iso.fd and initialized by
 raw1394_iso_xmit_init(). In other words, the raw1394_read_cycle_timer()
 calls can only succeed after ISO initialization.
 >
 > With the current code, strace shows:
 >
 > {{{
 > ioctl(4294967295, 0x8010230c, 0x7fffdeb43bc0) = -1 EBADF (Bad file
 descriptor)
 > clock_gettime(CLOCK_MONOTONIC, {8301, 175520540}) = 0
 > futex(0x7f6dd6b21078, FUTEX_WAKE_PRIVATE,
 1083011clock_gettime(CLOCK_MONOTONIC, {8301, 175808565}) = 0
 > futex(0x7f6dd6b21078, FUTEX_WAKE_PRIVATE, 108301175808: ESC[31mWarning
 (ieee1394service.cpp)[ 252] initialize:  This system doesn't support the
 raw1394_read_cycle_timer call.
 > }}}
 >
 > Obviously, the fd is invalid (initialized to -1).
 >

 This means that the juju implementation is not backward compatible to the
 old one. There is no reason to tie the cycle timer read to an ISO
 descriptor since it's not related to an ISO stream. It's a global function
 of the card, not the stream.

 The current implementation in FFADO also reflects this, and I don't really
 want to change this.

 >
 > Second: the ISO streaming does not start. IsoHandler::prepare expects
 E_Initialized, but the state is 3, which seems to be E_Running. See the
 attached log for details, if interested.
 >
 The juju version doesn't seem to be iterating the handlers. The packet
 callback handlers are not called.

 >
 > Since the new libraw1394-2.0.0 is backward compatible with the old
 stack, distributions will include it. I'm somewhat involved in the Debian
 Juju migration, talking to both, the libraw1394 maintainer and to the Juju
 kernel guys. We've fixed a libraw1394-2.0.0 segfault, I'll also attach the
 patch until it gets included upstream.

 Obviously the new implementation is not backward compatible to the old one
 yet. If that would be true, FFADO would just work. Therefore I think
 libraw should be fixed instead of us implementing quirks. I hope the
 linux1394 maintainers think the same. Currently I don't have the time to
 look into it myself.

 >
 > However, moving to the new stack should IMHO be accompanied by switching
 to the new API. There's no need to hurry, since Juju won't be fully
 featured before Linux 2.6.29. On the other hand, there's no use in
 developing for the old stack for years. One could expect 2.6.29 within six
 months. It might be worthwhile to keep and maintain the 2.0 release branch
 while changing the trunk to Juju.

 Something like that is the idea, but priority is on releasing 2.0 at the
 moment. After all, if libraw is 100% backwards compatible it doesn't
 matter what stack the user runs. The main issue with switching to juju is
 that it will take quite some time before it has propagated to the majority
 of users.

 >
 > I feel, ffado-3.0 is way too late for this. It should be targeted as the
 follow-up release to the 2.0.

 There is no reason to put juju support in the 2.0 series, since the old
 style should keep working, even on juju systems. As far as I can assess
 it, the changes required to make efficient use of the juju native API will
 be fairly extensive. The main issue is that the current implementation is
 built around the per-packet callback paradigm, where the new style would
 be based around a per audio-buffer callback. One of the challenges with
 that is that the number of packets that constitute one audio buffer is
 variable. The scheduling of hardware interrupts will have to be done
 taking that into account, which is not really accounted for with the
 current implementation.

 Once we start doing such extensive changes, we will have a hard time
 maintaining compatibility with old-style systems. And since not all
 current distro releases are already including juju, there will be old-
 style systems for years to come. I don't want to ask people to upgrade
 their distro to upgrade their FFADO.

 BTW: Thanks for looking into this.

 Pieter

-- 
Ticket URL: <http://subversion.ffado.org/ticket/78#comment:4>
FFADO <http://subversion.ffado.org/index.fcgi>
Free Firewire Audio Drivers