Raspberry Pi 3 + Ardour

Hi there!!

Recently I get a Raspberry 3 so, as you can imagine, I tried to do “things” with it.

I have installed Ubuntu Mate for Raspberry, and I have installed too Ardour…but I have some problems with “Jack”.

When I use Alsa drivers in, for example Audacity, all works ok and I can use a USB Audio Interface for recording a microphone or instrument…but, when I try to use JACK…problems and problems…

Do you know anything about problems with JACK / Arduour and Raspberry Pi 3?

All tips are welcome!!! :smiley:

Thanks !

Why would you use JACK on an RPi ? Just use Ardour’s own builtin ALSA driver.

I think the problem with this Paul is the one that I am having. If you select ALSA then you cant have a different input and output device as Ardour won’t then start. It gives an error of: Audio device not valid. The only way to connect a mic to a Pi is via USB.

Jack has the same issue. While you can in principle select 2 different devices it’ll fall over unless those devices are sample-sync (wordclock or similar).

With jack, http://jackaudio.org/faq/multiple_devices.html is an option, though.
Also see http://wiki.linuxaudio.org/wiki/raspberrypi

Not sure if it helps anybody but I finally have it working for me with a USB microphone and internal sound card through Jack. I ran Jack using “pasuspender Qjackctl” as per normal to make sure Pulse is suspended. Select my default interface and the same for output in Jack and the USB mic as input. Then in Ardour, I can startup choosing JACK as my audio service. That isn’t the end of the story though. Recording works immediately but in order to hear the recorded parts I have to connect them in the Jack control to my main system playback outputs. Individual tracks in Ardour show as their own readable clients in JACK. Each must be patched to system playback. Not sure if this can be automated but so far I don’t mind. Just glad it is finally working.

I don’t think you are supposed to do that in normal Ardour workflow. It is possible, but you’re probably better off routing the tracks to Ardour’s master bus (you could do that with Qjackctl, but you can do it more easily within Ardour itself), then connecting the master bus to Jack’s main output.

@kolkurtz: all those connections should be made automatically if you just accept the default session settings when creating a new session. There should be no reason to have to make any connections like that at all.

Hi you all,
Have any of you tried to compile ardour 5 on the raspberry pi 3? I’ve tried with no success. I’d like 5 because of the alsa drivers without jack. I tried ardour 4 on the pi but the connection to my behringer xair 18 was very instable. With ardour 5 on an old laptop (debian) it works like a charm. So ardour 5 on the pi 3 might help…
Cheers,

I managed to compile ardour 5 on a raspberry pi.
But it was running a bit strange, even playing a single track was slow…

I am currently building it using the patched gtk and cairo libraries, to see if it gets better.

I will post a proper bug report with simple test cases if I still got problems

So I got ardour 5 running on raspberry pi 2.
It seems to work, but everything is slow.
Even the metronome is 4x too slow.
CPU peaks at 25%

During compilation, I had seen the following messages a lot.
Is it related?

libs/ardour/ardour/cycles.h:221:2: warning: #warning You are compiling libardour on a platform for which ardour/cycles.h needs work [-Wcpp]

update: I have the ‘slowness’ problem only with alsa
With jack, ardour is working fine with a simple project.
Am I allowed to post a bundle here or a recipe to build it on arm?

Sounds like the ALSA backend /thinks/ it’s running at a higher sample rate than the actual rate. Can you start it from the commandline with the environment variable ZITA_ALSA_PCMI_DEBUG=1 set? that should print some info.

Also try ZITA_ALSA_PCMI_DEBUG=768 (that forces 16bit: 256 and stereo-only: 512)

Perhaps someone someday will create a dedicated “ArdourOS” for the Raspberry Pi. That would be very cool anyway. :slight_smile: I have 4 RPis 2/3. I have never tried running Ardour on any of them, but it is very thought provoking for sure! A dedicated OS booting to Ardour and running from a healthy battery for power could be very useful indeed!

Hello

Sorry for the delay, I will try to answer quickly next time.

So here is the complete log file I get.
Nothing really useful about alsa…
Do I have to enable more debug logs somewhere?

bind txt domain [gtk2_ardour5] to /opt/Ardour-5.4.421/share/locale
Ardour5.4.421 (built using 5.4-421-ge7243c0 and GCC version 4.9.2)
ardour: [INFO]: Your system is configured to limit Ardour to only 65,536 open files
ardour: [INFO]: Loading system configuration file /opt/Ardour-5.4.421/etc/system_config
ardour: [INFO]: Loading user configuration file /home/pi/.config/ardour5/config
ardour: [INFO]: No H/W specific optimizations in use
ardour: [INFO]: Loading default ui configuration file /opt/Ardour-5.4.421/etc/default_ui_config
ardour: [INFO]: Loading user ui configuration file /home/pi/.config/ardour5/ui_config
ardour: [INFO]: Loading color file /opt/Ardour-5.4.421/share/themes/dark-ardour.colors
ardour: [INFO]: Loading ui configuration file /opt/Ardour-5.4.421/etc/clearlooks.rc
ardour: [INFO]: Loading ui configuration file /opt/Ardour-5.4.421/etc/clearlooks.rc
Found nothing along /home/pi/.config/ardour5/templates:/opt/Ardour-5.4.421/share/templates
curl failed: No Error
run dialog
protocol Generic MIDI active ? 0
protocol Steinberg CC121 active ? 0
protocol Ableton Push 2 active ? 0
protocol PreSonus FaderPort active ? 0
protocol Mackie active ? 0
protocol Open Sound Control (OSC) active ? 1
lilv_world_add_plugin(): error: Duplicate plugin https://community.ardour.org/node/7596
lilv_world_add_plugin(): error: … found in file:///opt/Ardour-5.4.421/lib/LV2/reasonablesynth.lv2/
lilv_world_add_plugin(): error: … and file:///usr/lib/lv2/reasonablesynth.lv2/
Scanning folders for bundled LV2s: /opt/Ardour-5.4.421/lib/LV2
lilv_world_add_plugin(): error: Duplicate plugin https://community.ardour.org/node/7596
lilv_world_add_plugin(): error: … found in file:///opt/Ardour-5.4.421/lib/LV2/reasonablesynth.lv2/
lilv_world_add_plugin(): error: … and file:///usr/lib/lv2/reasonablesynth.lv2/
KP is ardour.keys
Set cursor set to default
Set buffering params to 262144|131072|10|10
protocol Generic MIDI active ? 0
protocol Steinberg CC121 active ? 0
protocol Ableton Push 2 active ? 0
protocol PreSonus FaderPort active ? 0
protocol Mackie active ? 0
protocol Open Sound Control (OSC) active ? 1
Set buffering params to 262144|131072|10|10
Skip explicit buffer seconds, preset in use
Skip explicit buffer seconds, preset in use
Butler drops pool trash
caught signal - shutting down.

Log files are identical without ZITA_ALSA_PCMI_DEBUG, with ZITA_ALSA_PCMI_DEBUG=1, 256, or 512

with ZITA_ALSA_PCMI_DEBUG=256 and ZITA_ALSA_PCMI_DEBUG=512, the the music seems to play faster than without flags, but still not fast enough.

I tried to play this audio file with other applications…

$ file Audio-4%L.wav
Audio-4%L.wav: RIFF (little-endian) data, WAVE audio, mono 48000 Hz

with audacious, it plays fine.

But with aplay:
$ aplay Audio-4%L.wav
Playing WAVE ‘od/dbus/interchange/dbus/audiofiles/Audio-4%L.wav’ : Float 32 bit Little Endian, Rate 48000 Hz, Mono
aplay: set_params:1233: Sample format non available
Available formats:

  • U8
  • S16_LE

Than I plugged a cheap usb audio interface and select it in ardour alsa config.

With that, everything was playing normally.

So it seems to be something specific to the broadcom audio driver.

Is there anything more I can do ?

OK. So this is an optimized build… are you comfortable with editing the source?
If so, change https://github.com/Ardour/ardour/blob/master/libs/backends/alsa/alsa_audiobackend.cc#L927 to #if 1
That’ll print the settings that ardour’s alsa backend uses at startup. S16_LE is supported by Ardour/ALSA.

Also when running jack: cd /tmp && wget http://jackaudio.org/downloads/adevices.sh && bash ./adevices.sh will show what jackd uses.

it does sound like some format/channel negotiation issue with the broadcom sound-card.

Running a fully fledged DAW on an under-spec’ed system with a cheap soundcard is questionable to begin with, then again this may help to improve Ardour overall.

@x42

While I won’t disagree with the premise about under-spec’d etc. I go back to my memories of running Ardour on an AMD K6 or K7 a long time back:)

It is tough to compare the two, but it wouldn’t surprise me if the RPIv3 is more powerful.

        Seablade

@x42: OK, I’m going to enable the audio debug. I keep you updated.

So here is what I got:
Same log file for ZITA_ALSA_PCMI_DEBUG set to 1, 256, 768
I get this additional info:
playback :
nchan : 2
fsamp : 48000
fsize : 512
nfrag : 2
format : S16_LE
capture : not enabled

Then, I tried again with jack, and I was partly wrong…

In fact, even with jack, I have to set parameters to certain values, or ardour gets slow
1024 frames/period and 3 periods/buffer, at 48000 (64ms latency) -> OK
512 and 6 -> OK
512 and 4 -> OK (42.7s)
512 and 3 -> NOK
1024 and 2 -> NOK (ardour cpu usage at 25%, and top: %Cpu(s): 15.4 us, 2.7 sy, 0.0 ni, 81.3 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st)

The session only consists of one stereo audio track at 48000/16bits

So my initial bug report was wrong: I can get it to work with jack, but not with every configuration.

Here is the content of adevices with a ‘working’ configuration:

========================================
Part I: ALSA
Advanced Linux Sound Architecture Driver Version k4.4.21-v7+.

Card 0 (ALSA):

  • Playback Device 0 (bcm2835 ALSA):

    • Subdevice 0 (hw:ALSA,0,0):
      used by: jackd (PID 3073)
      access: MMAP_INTERLEAVED
      format: S16_LE
      subformat: STD
      channels: 2
      rate: 48000 (48000/1)
      period_size: 1024
      buffer_size: 3072

    • Subdevice 1 (hw:ALSA,0,1):
      closed

    • Subdevice 2 (hw:ALSA,0,2):
      closed

    • Subdevice 3 (hw:ALSA,0,3):
      closed

    • Subdevice 4 (hw:ALSA,0,4):
      closed

    • Subdevice 5 (hw:ALSA,0,5):
      closed

    • Subdevice 6 (hw:ALSA,0,6):
      closed

    • Subdevice 7 (hw:ALSA,0,7):
      closed

  • Playback Device 1 (bcm2835 IEC958/HDMI):

    • Subdevice 0 (hw:ALSA,1,0):
      closed

Card 1 (MIDI):

========================================
Part II: jack processes
2341 pts/2 SLl+ 0:53 qjackctl
3073 ? SLsl 0:00 /usr/bin/jackd -dalsa -dhw:ALSA -r48000 -p1024 -n3 -P

Thanks. So things begin to make sense.

Did you try using Ardour’s ALSA backend with the same settings as jack? Input Device: None ; Buffer Size: 1024 ; Periods: 3. That should work just like jackd -p1024 -n3 -P
The Ardour/ALSA debug out: "… fsize : 512 nfrag : 2 … " is equivalent jack’s -p 512 -n 2 and that’s NOK with jack either.

Ardour’s ALSA backend does only allow 2,3 for the periods. Effectively 512 * 6 is the same as 1024 * 3 (some subtle difference, but in that case generally prefer larger buffer-size -> lower CPU)

I tested the same settings with ALSA backend, and have the same results:
1024 and 3 (64ms latency) -> OK
512 and 6 -> N/A (cannot test with this nb of periods)
512 and 4 -> N/A (cannot test with this nb of periods)
512 and 3 -> NOK
1024 and 2 -> NOK

So for the raspberry pi2, the latency for a simple audio session must be at least 64ms.