How to estimate multi track playback with disk read/write speed

If I run ardour on a raspberry pi 3 with a sad Card with let’s say 40 MB read and 25 write.
How many tracks of audio Can I mix in ardour at 44.1 and or 48khz

And Also when using ardour there is a setting for buffer performance in the options for playback, how does that work, doesn’t ardour read the tracks from my disk which means I need to have a good amount of read speed to keep up?

How does it all work

There’s only one way to find out, which it to try it! There are too many variables (some unknown) to be able to predict, especially on RPi which not so many use for Ardour.
One important factor is the number and types of plugins you are running in your mix - they use large and varying amounts of CPU time.
As for file read speed: 24 bits at 48k is 144KB per second, so in theory that’s 277 tracks at 40MB/s, but you’ll get nothing like that in practice. You should be able to do a good number of tracks, though, as long as processing speed and latency problems don’t limit you first.

To answer a few questions:

Yes Ardour does read and write to disk, and that is the purpose of the buffer settings in the preferences, a larger buffer will take more time to seek to locations, but less likely to have issues reading. That being said with a RPi you are more likely to be CPU bound for mixing, and it will depend much more on your choice of processing rather than the number of tracks, so long as you have a decent SD card (Note that many general SD cards will not spec minimum read speed, just maximum at least till you get to the ‘professional’ level of cards).


My experience was that Ardour was a little too slow for the RPi3 - it will run, but not very well - though I guess a build specifically optimized for the Pi might be viable (I actually compiled ardour on the Pi3 as well - it took almost a day and the ARM chip overheated twice…)
If you don’t mind proprietary alternatives, Tracktion Waveform8 is available for the Pi3 and is very impressive (I had 16 tracks running on a Pi3 with a hifiberry DAC+ audio card together with dynamics and eq plug-ins in each channel and still had some CPU to spare). In my opinion you should use something like the DAC+ audio card in preference to e.g. USB sound adapters in order to get the best audio performance / latency / reliability etc

Yes I do plan on using the hifiberry dac with XLR, how many tracks were you able to run max on the pi on the SD card. Just want to know what to expect. I know some cards are faster then others and have faster read speeds.

You can try an optimized build for ARM: (unzip to /opt, start as /opt/Ardour-5.12.0/bin/ardour5 )
Unless you use some USB-stick with really poor performance, Disk I/O is unlikely to be an issue. For tracking it’s fine, basic mixing (using larger buffersizes) is OKish, but it’s easy to overload the CPU with plugins.

PS. For older RPi systems, Raspian based on debian/oldoldstable (jessie):

Bandwidth for audio is really low. A mono track at 48kHz (4 bytes/sample * 48000 samples/sec) = 188 kBytes / sec. The problem is throughput, especially when writing many SDs have a rather long setup cost. As Seablade mentioned, increasing the disk-buffer in Preferences may help, Ardour will read/write larger chunks in one go from/to disk.

As for soundcard, I would not expect low latency with a default system, but given sufficient effort it can be done (e.g. the MOD is a ARMv7 system and it can run reliably at ~5ms round-trip latency).

Is it optimized for 64 bit arm, do you know if it’s missing any features from the original build

armhf is for 32bit ARM CPUs with hard-float (FPU) and using VFP, NEON SIMD, targeted at ARMv7 CPUs.

It’s a complete full-featured build of Ardour 5.12. What’s missing is bundled 3rd party software (e.g. bundled Harrison XT-plugins, General-midi synth etc which are not available for ARM CPUs at this point in time. Also as opposed to x86 binaries from there’s no installer, yet.

It’s basically a first step to investigate if it’s reasonable and viable to add ARM to the list of binaries provided by Any feedback is welcome.

I think arm is viable to have arm,
Is there’re a 64 bit build with those same Cpu features or would I have to compile it?

Is there’re a 64 bit build with those same Cpu features...
At the present time it's likely that your OS will be 32Bit even if the Pi hardware is 64Bit capable, in which case you will need the 32Bit Ardour build anyway. It's probably best to go for a stable 32Bit OS until you have an idea of how well it might work - for example, I used Ubuntu MATE 16.04 LTS for RPi3 which I would highly recommend - basically it 'just works' the only issues I had were around OpenGL drivers (which I think are still under development) and something to do with wifi, which I believe might have been a conflict with the DAC+ card (wired network was fine). Obviously swapping OS images is trivially easy if you decide to go for something more cutting edge later.

@x42 That is awesome Robin, I will download and try it out. I have 3 Rpi2s and 1 Rpi3. I am pretty sure Rasbian on the Rpi3 is still 32bit as well, Mike. I did not have as good of luck with Ubuntu MATE 16.04 as you did. I found it to be very laggy, but that was on the RPi2. I have not yet tried it on the 3. Honestly my preferred usage for the RPi3 would be to make a dedicated Guitarix platform for live use. When I have the time to put it all together, that is.

@Lexridge: The Pi3 is significantly more powerful - there is also some benefit to setting the CPU governor to ‘performance’.

On a more general note, I hope to have some ARM compatible plug-in builds available again soon too.

That’s good to hear, I believe arm is the future. I also read online that the new Iphone Cpu is fast as a intel i5. Some arm boards already are pretty powerful, just wish the support for it was really good.

There are now ARM / Raspberry Pi 3 compatible builds of the OverTone DSP plug-ins at:

I’ve tested them with Ardour5.12 for ARM (the x42 build mentioned earlier in this thread) and they also work with Tracktion Waveform for RPi, both on Ubuntu MATE 16.04 for RPi 3. For ardour, I would recommend setting a buffer size of 1024 / 2 periods if using the built in ALSA drivers, and turning off ‘summary’ in the editor display, as I found this was buggy and used valuable CPU cycles to not redraw itself properly. (I would also recommend using one of Ardour’s alternative built-in themes like ‘UnaStudia’ - but that’s just personal preference)