So tonight, I finally spent some time hacking on ffado and a spec file for it... Got it building, and even at least basically working... (ffadomixer sees my device, that's as far as I got, ship it!). I've submitted it for Fedora package review:
https://bugzilla.redhat.com/show_bug.cgi?id=456353
Reviewers would be greatly appreciated... Even more so if you actually know how to use this stuff (I have no clue myself :).
Hi Jarod,
We need to figure out how to package an older version of jack for fedora with ffado support enabled. From a previous conversation I've had:
"I've put up a modified version of jack 0.106.0 (aka 'the last know good') that includes the most recent firewire backend at: http://subversion.ffado.org/attachment/wiki/DevelopmentReleases/jack-audio-c...
I think it's a good idea to use that for packaging. Anything post 0.106.0 has too many issues, and there is no real need for more testing of these problems. We've fixed some of them, but there are still some well-described test cases that fail consistently. I can personally confirm that the current SVN is not workable. "
-cd
On Tue, 2008-07-22 at 23:28 -0400, Jarod Wilson wrote:
So tonight, I finally spent some time hacking on ffado and a spec file for it... Got it building, and even at least basically working... (ffadomixer sees my device, that's as far as I got, ship it!). I've submitted it for Fedora package review:
https://bugzilla.redhat.com/show_bug.cgi?id=456353
Reviewers would be greatly appreciated... Even more so if you actually know how to use this stuff (I have no clue myself :).
-- Jarod Wilson jwilson@redhat.com
Fedora-music-list mailing list Fedora-music-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-music-list
On Wednesday 23 July 2008 12:06:58 pm Christoph Doerbeck wrote:
Hi Jarod,
We need to figure out how to package an older version of jack for fedora with ffado support enabled. From a previous conversation I've had:
"I've put up a modified version of jack 0.106.0 (aka 'the last know good') that includes the most recent firewire backend at: http://subversion.ffado.org/attachment/wiki/DevelopmentReleases/jack-audio- connection-kit-0.106.99.tar.gz?format=raw
I think it's a good idea to use that for packaging. Anything post 0.106.0 has too many issues, and there is no real need for more testing of these problems. We've fixed some of them, but there are still some well-described test cases that fail consistently. I can personally confirm that the current SVN is not workable. "
Crud. This is gonna be messy, if it can be done at all. Given that Fedora is at 0.109.2 already, we'd have a hard time talking the maintainer into using that build, so we'd be looking at a compat package or an ffado-jackd package or something along those lines. :\
For grins, I started poking at a local build of it (simply as jack) here. At the moment, its falling down like so:
[...] gcc -shared .libs/alsa_driver.o .libs/generic_hw.o .libs/memops.o .libs/hammerfall.o .libs/hdsp.o .libs/ice1712.o .libs/usx2y.o -Wl,--whole-archive ../alsa-midi/.libs/libalsamidi.a -Wl,--no-whole-archive -lasound -lm -lpthread -ldl -m64 -mtune=generic -m64 -mtune=generic -Wl,-soname -Wl,jack_alsa.so -o .libs/jack_alsa.so /usr/bin/ld: ../alsa-midi/.libs/libalsamidi.a(alsa_seqmidi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../alsa-midi/.libs/libalsamidi.a(alsa_seqmidi.o): could not read symbols: Bad value
Might be some requirements on an older ALSA as well, I dunno...
On Tue, 2008-07-22 at 23:28 -0400, Jarod Wilson wrote:
So tonight, I finally spent some time hacking on ffado and a spec file for it... Got it building, and even at least basically working... (ffadomixer sees my device, that's as far as I got, ship it!). I've submitted it for Fedora package review:
https://bugzilla.redhat.com/show_bug.cgi?id=456353
Reviewers would be greatly appreciated... Even more so if you actually know how to use this stuff (I have no clue myself :).
On Wed, 2008-07-23 at 14:26 -0400, Jarod Wilson wrote:
On Wednesday 23 July 2008 12:06:58 pm Christoph Doerbeck wrote:
Hi Jarod,
We need to figure out how to package an older version of jack for fedora with ffado support enabled. From a previous conversation I've had:
"I've put up a modified version of jack 0.106.0 (aka 'the last know good') that includes the most recent firewire backend at: http://subversion.ffado.org/attachment/wiki/DevelopmentReleases/jack-audio- connection-kit-0.106.99.tar.gz?format=raw
I think it's a good idea to use that for packaging. Anything post 0.106.0 has too many issues, and there is no real need for more testing of these problems. We've fixed some of them, but there are still some well-described test cases that fail consistently. I can personally confirm that the current SVN is not workable. "
Crud. This is gonna be messy, if it can be done at all. Given that Fedora is at 0.109.2 already, we'd have a hard time talking the maintainer into using that build,
Well, it is not a stable system. Would not that be reason enough? (doing it is simple, we just need an epoch of "1"... :-) I don't see how the packager would be able to say that it works fine.
One problem is that some software needs post 0.107.0 to even compile! So downgrading is a real problem. Dammed if you do, dammed if you don't.
I have been using current svn and it is much better than 0.109.x, but some people have been having problems (thus the post).
Actually, the only "stable" jack right now is jackmp, a newer implementation of the same API, written in C++. That one is good. If your Jack graph has parallelism, jackmp will execute what it can in different threads so that load will be spread amongst cores in a multi cpu system - something which does not happen in the normal jack. I have had experimental packages for Planet CCRMA for a while (that I have not yet released). Some (not properly written) software was having problems with it, but I think a patch was posted recently for one (the last?) of them, amSynth. So maybe it would be possible to release that for Planet CCRMA.
so we'd be looking at a compat package or an ffado-jackd package or something along those lines. :\
The problem is not unique to faado. Any use of jack is affected.
-- Fernando
For grins, I started poking at a local build of it (simply as jack) here. At the moment, its falling down like so:
[...] gcc -shared .libs/alsa_driver.o .libs/generic_hw.o .libs/memops.o .libs/hammerfall.o .libs/hdsp.o .libs/ice1712.o .libs/usx2y.o -Wl,--whole-archive ../alsa-midi/.libs/libalsamidi.a -Wl,--no-whole-archive -lasound -lm -lpthread -ldl -m64 -mtune=generic -m64 -mtune=generic -Wl,-soname -Wl,jack_alsa.so -o .libs/jack_alsa.so /usr/bin/ld: ../alsa-midi/.libs/libalsamidi.a(alsa_seqmidi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ../alsa-midi/.libs/libalsamidi.a(alsa_seqmidi.o): could not read symbols: Bad value
Might be some requirements on an older ALSA as well, I dunno...
On Tue, 2008-07-22 at 23:28 -0400, Jarod Wilson wrote:
So tonight, I finally spent some time hacking on ffado and a spec file for it... Got it building, and even at least basically working... (ffadomixer sees my device, that's as far as I got, ship it!). I've submitted it for Fedora package review:
https://bugzilla.redhat.com/show_bug.cgi?id=456353
Reviewers would be greatly appreciated... Even more so if you actually know how to use this stuff (I have no clue myself :).
On Thursday 24 July 2008 03:37:03 am Fernando Lopez-Lezcano wrote:
On Wed, 2008-07-23 at 14:26 -0400, Jarod Wilson wrote:
On Wednesday 23 July 2008 12:06:58 pm Christoph Doerbeck wrote:
Hi Jarod,
We need to figure out how to package an older version of jack for fedora with ffado support enabled. From a previous conversation I've had:
"I've put up a modified version of jack 0.106.0 (aka 'the last know good') that includes the most recent firewire backend at: http://subversion.ffado.org/attachment/wiki/DevelopmentReleases/jack-au dio- connection-kit-0.106.99.tar.gz?format=raw
I think it's a good idea to use that for packaging. Anything post 0.106.0 has too many issues, and there is no real need for more testing of these problems. We've fixed some of them, but there are still some well-described test cases that fail consistently. I can personally confirm that the current SVN is not workable. "
Crud. This is gonna be messy, if it can be done at all. Given that Fedora is at 0.109.2 already, we'd have a hard time talking the maintainer into using that build,
Well, it is not a stable system. Would not that be reason enough? (doing it is simple, we just need an epoch of "1"... :-) I don't see how the packager would be able to say that it works fine.
Unfortunately, I know approximately jack about jack, so I dunno what's busted or not where. I know packaging-wise, its not hard to roll back, its the convincing the maintainer to do so part that could take some doing, esp. given...
One problem is that some software needs post 0.107.0 to even compile! So downgrading is a real problem. Dammed if you do, dammed if you don't.
...that 0.106.99 doesn't build locally for me, and as you said, other software requires post-0.107.0. :\
I have been using current svn and it is much better than 0.109.x, but some people have been having problems (thus the post).
I've got a reasonably recent local svn build of 0.112.0, svn r2721 installed here to poke at for now.
Actually, the only "stable" jack right now is jackmp, a newer implementation of the same API, written in C++. That one is good. If your Jack graph has parallelism, jackmp will execute what it can in different threads so that load will be spread amongst cores in a multi cpu system - something which does not happen in the normal jack. I have had experimental packages for Planet CCRMA for a while (that I have not yet released). Some (not properly written) software was having problems with it, but I think a patch was posted recently for one (the last?) of them, amSynth. So maybe it would be possible to release that for Planet CCRMA.
Can jackmp be installed in parallel with jack, or would you just package it as jackmp w/Obsoletes: jack? (i.e., could this potentially get into the fedora tree, or would it need to reside outside of it)
so we'd be looking at a compat package or an ffado-jackd package or something along those lines. :\
The problem is not unique to faado. Any use of jack is affected.
Gotcha. Didn't know it was that widespread. I'm quite the novice in the whole audio area, really only getting involved to try to get things more functional with the new firewire driver and library stack.
On Thu, 2008-07-24 at 15:21 -0400, Jarod Wilson wrote:
On Thursday 24 July 2008 03:37:03 am Fernando Lopez-Lezcano wrote:
Actually, the only "stable" jack right now is jackmp, a newer implementation of the same API, written in C++. That one is good. If your Jack graph has parallelism, jackmp will execute what it can in different threads so that load will be spread amongst cores in a multi cpu system - something which does not happen in the normal jack. I have had experimental packages for Planet CCRMA for a while (that I have not yet released). Some (not properly written) software was having problems with it, but I think a patch was posted recently for one (the last?) of them, amSynth. So maybe it would be possible to release that for Planet CCRMA.
Can jackmp be installed in parallel with jack, or would you just package it as jackmp w/Obsoletes: jack? (i.e., could this potentially get into the fedora tree, or would it need to reside outside of it)
It could potentially get into Fedora. The problem is when. Most probably it will be in Planet CCRMA long before it moves to Fedora.
Jackmp is actually going to be jack 2.0 when the time comes.
There was an experiment with wrapper scripts (which for some time I begged the jack and jackmp developers to write) that enabled both to live side by side, that is, the jack package could include both jackd and jackdmp. Depending on which server you started the clients would magically find their way to the right set of shared libraries.
Regretfully it was a failed experiment and it is no longer supported (although I experimentally packaged it for a while). Some programs had weird interactions with the magic needed to get this going and it was rightly thought that it was better to spend developer man-hours in the actual jack[mp] code.
Current jackmp svn versioning is 1.9x as a predecessor to jack 2, so just packaging jackmp as jack-audio-connection-kit would be the right thing to do. The problem is that you can't really go back once that hits the repositories.
I have spec files that do just that, they build either normal jack or jackmp depending on a %define.
so we'd be looking at a compat package or an ffado-jackd package or something along those lines. :\
The problem is not unique to faado. Any use of jack is affected.
Gotcha. Didn't know it was that widespread. I'm quite the novice in the whole audio area, really only getting involved to try to get things more functional with the new firewire driver and library stack.
Yes, sorry, it is sometimes a bit more complicated than we would want it to be :-)
Thanks for the effort and help!! -- Fernando