Ticket #159 (closed enhancement: duplicate)

Opened 12 years ago

Last modified 10 years ago

ease portability: libatomic_ops

Reported by: sobukus Assigned to:
Priority: major Milestone: FFADO 2.1
Component: Version: FFADO 2.0-beta6 (1.999.36)
Keywords: Cc:
The device the bug applies to:


I am working on getting my firewire setup working on Alpha architecture (yes, call it a spleen;-) and actually that's not that hard with ffado, the only stumbling point being the atomic operations in that Atomic.h, once grabbed from jack, apparently.

I removed these in favor of using libatomic_ops, which provides such operations on various platforms. It seems to work fine... though I didn't yet have a successful recording session with ardour2 because of some bug on that end (floating point exception).

But jackd (also patched to use alpha assembler code already included in jack svn, guess I will do a libatomic_ops patch, there, too) runs nicely with my FA-101 and its 10 channels @ 92kHz, 17% CPU load.

Anyhow, would ffado consider inclusion of a patch along this one:


? I think it is a good idea to keep these nasty processor details out of the code if possible...

Info about libatomic_ops:



libffado-atomic_ops.patch (3.1 kB) - added by adi on 10/16/08 14:25:28.
libatomic patch from the git repo

Change History

09/23/08 02:01:43 changed by ppalmers

  • milestone changed from FFADO 2.0 to FFADO 2.1.

10/16/08 14:25:28 changed by adi

  • attachment libffado-atomic_ops.patch added.

libatomic patch from the git repo

10/16/08 14:28:15 changed by adi

Looks good. I've attached the patch from the git repository to this ticket. I guess all we need now is an update to scons to include libatomic_ops (detecting the installed version, inclusion in linker flags, if necessary...)

sobukus: Do you have the required scons changes as well?

10/16/08 23:53:58 changed by holin

The idea is good, but I'm not sure what exactly is libatomic_ops bringing to the table. First, the releases are old and the project unmaintained and, as noted on the main page, it is a part of the bdwgc garbage collector tree now. You'd have to extract maintained code from there. Second, the implementation for many architectures is very incomplete (look at sparc, for example) and untested, and the code is literally sprinkled with FIXMEs. Quantity (of ported archs) doesn't replace quality here. IMHO, atomic operations are something you either have right or don't have at all, and, in that case, revert to using something slower like pthread mutexes.

10/17/08 03:18:01 changed by sobukus

Well, so perhaps libatomic_ops is not the final answer to this. But it is clear that it is total nonsense to recreate these macros/functions all over again for jack, ffado and whatnot. Since jack seems to have working code for alpha inside (sort of, with my builds I was able to record 8 channels with my FA-101, but I had occasional crackling in the sound -- not underruns, as it sounds?), why not at least merge these efforts and make a common header/library with this tricky stuff?

holin: did you look at the current code from http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.1alpha3-080224.tar.gz ? I guess it's not much changed from the "old" libatomic_ops... actually, it looks older, when I look at the diff of atomic_ops.h .

So, I'm back at my basic statement: The idea of libatomic_ops is a necessary one. I don't particulary mind in what form it is realized, but I guess the optimum would be to merge the efforts of jack, ffado and Hans Boehm, possibly convincing him to make libatomic_ops a separate release again, or just forking off useful bits. I don't see much vlaue in competing implementations here. This is basic enough that "the one" correct implementation is enough, isn't it?

Especially since you have these operations right or not at all, we should make sure that if someone has the right one, everyone should use it. For now I have my patch in local use... I won't insist on using it in the release when we find an even better solution;-)

adi: I went the lazy route without scons stuff; there's no linking needed... just included the header, build system unaware.

10/17/08 23:00:03 changed by holin

sobukus: I was looking at their cvs repo.

Yes, indeed, a correct implementation is all that is needed. I'd say, do what jack has done and copy the relevant bits from the linux kernel sources, but NOT for all possible archs, just the ones that are actually used and tested by someone.

I don't think we need to have anything to do with Boehm's garbage collector project, unless somebody wants to contribute code there. FWIW there are many other projects that have local atomic ops implementations, sometimes done from scratch due licencing (or ignorance.) As nice as it is to try to avoid duplicating effort, I think it should be enough for us to have a good implementation in ffado and make sure it eventually propagates to jack/jackmp/ardour (if it uses atomic ops).

In the end, I don't really care what the solution is, as long as I don't have to start filing patches to <some obscure project> upstream and/or distros before I can get ffado going on my 64-bit SMP ppc box or ultrasparc or whatever other-than-x86 arch.

10/12/09 14:31:32 changed by arnonym

Is this still an issue with the latest changes for sparc and ia64?

07/21/10 10:30:07 changed by adi

  • status changed from new to closed.
  • resolution set to duplicate.

We completely forget about this and go for the approach in #280.