10:28 p.m.
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(a)redhat.com
11:06 a.m.
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-audi...
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(a)redhat.com
_______________________________________________
Fedora-music-list mailing list
Fedora-music-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-music-list
1:26 p.m.
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 :).
--
Jarod Wilson
jwilson(a)redhat.com
2:37 a.m.
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 :).
2:21 p.m.
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.
--
Jarod Wilson
jwilson(a)redhat.com
5:54 a.m.
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
5756
days inactive
5758
days old
5 comments
3 participants
participants (3)
-
Christoph Doerbeck -
Fernando Lopez-Lezcano -
Jarod Wilson