Kernel 2.6.32 (2 December 2009) and libraw1394 v2.0.5 (26 December 2009)
contain the fixes that are required for FFADO. Debugged and implemented
by Jay Fenlason.
I believe I had vanilla FFADO v2.0.0 running with these, but Debian's
FFADO maintainer packages FFADO trunk which contains a small fix
After looking into things more I basically have the exact issue
mentioned in this FFADO upstream report that I assume is also the issues
Dan Dennedy was refering to.
http://subversion.ffado.org/ticket/78
For FFADO 2.0 the focus is not on porting to the new firewire stack, but
rather relying on
I updated the libraw1394 package to 2.0.1, see LP: #311804 (I blame
Launchpad for the triplicate post in that bug). Using the libffado2
packages from the ubuntustudio-dev PPA I can start the ffado-dbus-server
and connect the ffado-mixer to my device successfully. I can rebuild the
0.116.1 Jack
Does anyone have an overview of which key apps need testing with this
new stack so they can be ready when the new stack becomes the default? I
only know of dvgrab/kino and similar video apps...
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You
There is a Jack driver to test as well that I believe is already
packaged.
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Yeah, unfortunately, the Jack driver FFADO is known to not be working
with new firewire. I was working on some minor fixes in libraw1394 with
the FFADO project earlier in the month, but we got stuck on one last
issue just before the holidays. I will ping them.
--
Enable new Firewire stack in
This bug was fixed in the package linux - 2.6.28-4.5
---
linux (2.6.28-4.5) jaunty; urgency=low
[ Andy Whitcroft ]
* clean up module dependancy information on package removal/purge
- LP: #300773
[ Tim Gardner ]
* Update iscsitarget to 0.4.17
* Build in ext{234}
*
Whhoo!
...erm, what I meant to say was: Thanks to all involved for fixing this one!
Christian ;-)
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Changed in: linux (Ubuntu)
Assignee: (unassigned) = Andy Whitcroft (apw)
Status: Triaged = In Progress
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Having read the linked wiki pages, this new stack is still rather raw.
It does appear we could enable both and blacklist the new. This would
be helpful for porters etc. Will propose this to the kernel team.
--
Enable new Firewire stack in default kernel config
** Tags added: kconfig
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Yes, there would be some benefits to provide the new drivers as an opt-in
alternative, i.e. enabled in the build configuration but blacklisted to prevent
automatic loading:
- Asynchronous performance of 1394a buses (a.k.a. FireWire 400) is indeed
considerably higher in the new firewire
+1 from another sbp2 user here (and as the person that filed the
original report)
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
I would also support having the option of testing the new stack. It
would be a blessing if firewire worked out of the box in Ubuntu in the
future.
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a
Please reconsider your decision and enable the new stack as a module,
but *use the old one as a default*, as recommended upstream.
Despite possibly existing bugs in the new implementation and/or
libraw1394, Firewire can also be used to attach storage devices, no
libraw1394 involved here. When
We are not planning on enabling both stacks for Intrepid. We are
following upstream recommendation for which stack should be enabled.
** Changed in: linux (Ubuntu Intrepid)
Assignee: (unassigned) = Andy Whitcroft (apw)
Status: New = Invalid
--
Enable new Firewire stack in default
** Changed in: linux (Ubuntu Intrepid)
Assignee: Andy Whitcroft (apw) = (unassigned)
Status: Invalid = Won't Fix
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs,
According to http://ieee1394.wiki.kernel.org/index.php/Juju_Migration as
of kernel 2.6.26 it is possible to build both stacks as modules provided
one is properly blacklisted. Version 2 of libraw1394 would also be
required to actually use the new stack.
This config would allow those inclined to
With regard to libraw1394 v2:
https://blueprints.launchpad.net/ubuntu/+spec/libraw1394-2.0-transition
--
Enable new Firewire stack in default kernel config
https://bugs.launchpad.net/bugs/276463
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hi Duncan,
I assume you are referring to the CONFIG_FIREWIRE kernel config option.
I'm pasting the Kconfig excerpt for the kernel team to reference when
considering to enable this option:
comment Enable only one of the two stacks, unless you know what you are doing
depends on EXPERIMENTAL
There are still some very visible regressions of the new vs. the old
stack, see ieee1394.wiki.kernel.org. Alas, upstream work on these
issues slowed down again during the last few months due to lack of
developer manhours.
--
Enable new Firewire stack in default kernel config
21 matches
Mail list logo
