firewire stack

[hiro]

For me the new firewire stack is unusable. While trying to upgrade my old jack-ffado to tc 3.x I ran into lots of problems. I'm not sure which bugs I'm actually seeing, but it has been written, that the fixes for libraw1394 won't work on anything under 2.6.36 anyway.

So I propose making available firewire-legacy module extensions for tc 3.x.

[hiro]

I had updated my old jack-ffado system last month, but I still have everything on hold because of all the bugs.

[curaga]

The old one is removed upstream as of 2.6.37:

https://ieee1394.wiki.kernel.org/index.php/Release_Notes

[hiro]

Yes, and I also read that people should try to switch at 2.6.33, but it's just *not* possible if you want to use libraw1394. Unless of course someone backports these necessary fixes.

[hiro]

Here's what I've tried to refer to:

libraw1394 2.0.6

1 November 2010

This release brings again several fixes for using libraw1394 on top of the firewire-core kernel driver (as opposed to raw1394 which is going to be removed in kernel 2.6.37). Notably, request reception a.k.a. address range mapping was fixed to report proper sender node IDs and extended tcodes to the application.

Note, this and some of the other updates require linux-headers 2.6.36 or later to be present when libraw1394 is being built. Otherwise, the fixes will not be built into the library, and libraw1394 will behave mostly like v2.0.5 did. (Likewise, kernel 2.6.36 is required at runtime for some of these updates to be in effect. You can run brand new libraw1394 on older kernels and vice versa, but you would miss those fixes and features.)

https://ieee1394.wiki.kernel.org/index.php/Release_Notes_-_Libraries#libraw1394

[hiro]

I'm still not sure whether it's the new kernel module's, libraw1394's or the ffado project's fault, but this transition is definitely buggy or incomplete and ffado acknowledges it. Thus a lot of other audio-centric distros with older kernels use the old stack like I proposed and the few guys with a working setup using the new stack are generally considered only very lucky.

Would it be too much work to create a firewire-legacy module extension or are we soon getting a new kernel anyway?

Alternatively I would also like to support all the jack/ffado stuff together with a 2.6.37-realtime kernel, but I don't want to create anything too far away from the core, so that other potential users may still use tinycore module extensions.
Would it be possible to integrate other kernels like it has been done with amd64?

[curaga]

Would it be too much work to create a firewire-legacy module extension or are we soon getting a new kernel anyway?

I'm sure other firewire audio users would appreciate if you posted it, after all you can test whether it works well for your use-case. It's a fairly simple extension, just enable the desired modules, "make modules", "make INSTALL_MOD_PATH=/tmp/ex modules_install".

Would it be possible to integrate other kernels like it has been done with amd64?

I /think/ that's been discussed before, but can't remember if there was a consensus or not. I'll see if I can search that up. At least the base would handle that fine.

[hiro]

Cool, I didn't really read along when the amd64 port was added, so I'd appreciate any pointers.

I only wanted to avoid multiple work, but I will soon recompile my firewire module for official tinycore (my personal kernel and thus module extensions currently have realtime patches applied), so that at least the occasional mpd firewire user will be able to use this even though latency might get high occasionally.

[curaga]

Ah, here:
http://forum.tinycorelinux.net/index.php?topic=4558.0

That was in the 2.x days, planning 3.x. Nowadays we have kernel-independent dep files, so a custom one should work well.

The situation hasn't come up yet though, so we'd need to discuss that.