OK, so this is an issue with the RPi2 soundcard and/or its driver and there’s nothing we can do about it on the Ardour or JACK side of things. Is that correct?
Also it’s a non-issue if you use an external “proper” soundcard, right?
Yes this is correct.
I had no idea that the internal sound card could be so… useless…
With a cheap USB sound card (Hercule Muse Pocket), I was able to obtain a correct playback at 48000, with a buffer of 128 and 2 periods (2.7ms latency!)
Sorry for the waste of time.
I don’t think discovering and telling the rest of us that you can get Ardour running with 2.7ms latency on a RPi is a waste of time at all!
indeed, that’s good news. You might want to file a bug report for the RPi. Then again it depends on the audio-chipset/codec hardware. It may well be that it’s a hardware limitation of some kind, or it may be a driver/DMA issue for small buffer sizes.
BTW, https://packages.debian.org/sid/ardour does provide Ardour 5.5 builds for: alpha, amd64, arm64, armel, armhf (<< RPi), hppa, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x and sparc64.
I’m wondering if anyone has a MIPS machine that can run Ardour 
I do not really know where to report such a bug… And I will need a simpler use case…
Do you think it is a problem with the clock or the soundcard’s sample rate?
In that case, how comes that a mp3 may be played flawlessly with another player, for instance?
Do you know what could be different in the way ardour uses the soundcard or the clock?
I will try the debian 5.5 packages and file a bug anyway if I can reproduce the problem…
About MIPS machine… could be fun to try !
Anyway, I got some patches to the build system, that allow to create a bundle even on ARM. Would you be interested in upstreaming them?
I hazard a guess that mp3 player will use a large (if not huge) buffersize.
You could check with cd /tmp && wget http://jackaudio.org/downloads/adevices.sh && bash ./adevices.sh which will list all soundcard, and their currently used settings.
Anyway, it looks like this a known issue and it sounds like a won’t-fix: https://github.com/raspberrypi/linux/issues/1252 – the smallest the RPi allows for the “internal” soundcard is 1024 * 2 (or 512 * 4 or 256 * 8…). That issue-report suggests that it’s an arbitrary limit in the driver and you can work around it by editing bcm2835-pcm.c and recompiling the kernel.
What changes are needed to create a bundle on ARM?
Curious: how long does it take to compile natively? Why not cross-compile?
Okay I see so this is an arbitrary limit in the kernel… OK, maybe I will try to patch it. Thanks for your pointer.
To create the bundle on ARM, these files have to be patched a bit to handle ARM architecture:
build
package
stage2.run.in
For instance, in build, I had to add a case:
armv7l)
echo “Architecture is arm”
ARCH=‘arm’
WARCH=‘arm’
HARCH=‘linux32’
ARCH_BITS=‘32-bit’
MULTIARCH=‘arm-linux-gnu’
;;
*)
…
My patches are not that clean, beacuse I think they still embed 32-bit x86 VSTs into the bundle.
But I can work on it if there is a use for somebody.
Am I the first one trying Ardour on ARM? (even if debian try to compile it for ARM too)
I an surprised that Ardour compiles and runs cleanly ‘by chance’ on little endian architecture.
It is tested regularly on such architectures, right?
It takes a long time to be compiled natively, but I used distcc with emulated arm machines (running on qemu and docker), to speed it up 
And still, i takes more than one day
It is certainely not the fastest method, but it’s fun, and I don’t like cross compilers.
I mean, if your build system is not ready for cross compilation, it can be a nightmare.
So I prefer to go slowly, but native.
OK, so it’s only the bundling part that needs tweaking. not the build-system itself. I’m not sure if that’s useful, unless you also include the complete build-stack (gtk etc) from scratch, it’s more useful to just roll a .deb. Do you include all build-deps (https://nightly.ardour.org/list.php#build_deps) or rely on Raspian for those?
I’m sorry but you’re not the first one for ARM, but probably the first one for the RPi.
I did compile it for ARMv5 (armel) back in 2008/9ish and later for v7 (armhf), mostly academic and to get a 2nd compiler opinion. JACK patches for ARM (packed data structures) came to be around are around the same time. in both cases I cross-compiled it though and killed a native compile after ~4hours still below 50% done. Also Debian has been providing ARM binaries for a long time.
PS. waf is entirely fine with x-compile, just set up the usual standard environment variables CC, CXX, CFLAGS etc. The official windows binaries are also x-compiled with mingw on GNU/Linux. see tools/x-win/compile.sh for an example.
OK, so it’s only the bundling part that needs tweaking. not the build-system itself. I’m not sure if that’s useful, unless you also include the complete build-stack (gtk etc) from scratch, it’s more useful to just roll a .deb.
Do you include all build-deps (https://nightly.ardour.org/list.php#build_deps) or rely on Raspian for those?
No, I relied on Raspbian.
But I did compile all the build-deps from scratch successfully on x86, using docker.
If I find out that the Raspberry Pi is a viable platform for ardour, I might adapt my dockerfile for ARM.
I’m sorry but you’re not the first one for ARM, but probably the first one for the RPi.
I did compile it for ARMv5 (armel) back in 2008/9ish and later for v7 (armhf), mostly academic and to get a 2nd compiler opinion. JACK patches for ARM (packed data structures) came to be around are around the same time. in both cases I cross-compiled it though and killed a native compile after ~4hours still below 50% done.
Also Debian has been providing ARM binaries for a long time.
Yes, I see that debian is compiling Ardour 5 for ARM as well
About cross compilation, you are right, maybe I should use it instead of ‘emulated native compilation’
I know that waf is fine, but I do not know if it is the case for every build-dep…
do you?