Good morning
Is there a comprehensive test routine/s which can determine a (Linux) computer system’s state of health and likely performance for running Ardour?
I have run hparm, memtester and gputest and everything seems good.
I started on Phoronix, but the full test suite download would take over 5 hours on a good wired connection and fill up my hard drive. So, are there any particular Phoronix, or other, test routines that would help determine the health and potential of my system?
Many thanks
The easiest way to test if Ardour will work on your system is to install Ardour and do what it is you want to do in it. I’ve never found synthetic benchmarks to be very useful, except when comparing different hardware setups against each other.
2 Likes
Thankyou for your reply. I’m sure that’s right. In my* case, *I am trying
to find out if there is anything wrong on my system, as I seem to
experience some strange issues when using Ardour. That said, I think it’s
the best DAW in the world
You could give rtcqs a spin: rtcqs/rtcqs: rtcqs is a Python utility to analyze your system and detect possible bottlenecks that could have a negative impact on the performance of your system when working with Linux audio. - rtcqs - Codeberg.org
Bear in mind that rtcqs does not check if you have sufficient system resources to run Ardour properly. It only checks some basic audio related settings.
1 Like
Thanks Jeremy
I will try it. Please can you explain to me what I need to download and setup from codeberg. I’m not all that technically skilled, but I can follow instructions.
Fastest way would be to download the latest binary release at https://codeberg.org/rtcqs/rtcqs/releases/download/v0.5.2/rtcqs_gui_x86_64
Then make that binary executable by right clicking on it and there should be an option there to make it executable. Once it’s executable you can double-click it to open it. It should give you some pointers on your system’s setup with regards to audio settings.
/me should really do an updated binary release 
As a side note for the security inclined (myself included): if you don’t trust the binary you could always verify its checksum ( 83fa7d3ea9d647934e9a6aae1097fc90a3ec134d65e98a7afcf5cb6ff95cf25a) in a terminal:
$ sha256sum ~/path/to/rtcqs_gui_x86_64
Should give:
83fa7d3ea9d647934e9a6aae1097fc90a3ec134d65e98a7afcf5cb6ff95cf25a /full/path/to/rtcqs_gui_x86_64
Thanks Jeremy
I will give it a try now
Hi Jeremy
I have run rtcqs and had 3 messages which may be of interest:
- Kernel with Spectre and Meltdown mitigations found
- Avoid using a mount on /run/user/1000/doc.
- Found USB port ehci_hcd:usb1 with IRQ 18 that shares its IRQ with the following other devices: ehci_hcd:usb1, ehci_hcd:usb2, i801_smbus
This is my usb configuration:
$ lsusb
Bus 002 Device 002: ID 8087:8002 Intel Corp. 8 channel internal hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:800a Intel Corp. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 17aa:1034 VIA Labs, Inc. USB Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 003 Device 002: ID 17aa:1034 VIA Labs, Inc. USB Hub
Bus 003 Device 006: ID 192f:0916 Avago Technologies, Pte. ADNS-2710 Optical Mouse Controller
Bus 003 Device 005: ID 1a2c:2124 China Resource Semico Co., Ltd Keyboard
Bus 003 Device 004: ID 0424:2512 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 0582:0159 Roland Corp. DUO-CAPTURE EX
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The Roland audio interface is alone, on a separate pci usb card
I am using AVL linux 21.3 which has a Liquorix 6.0.0-10.1 and uses threaded irqs.
It has an ext4 filesystem. cpu governor is set to performance
My system has an ssd which gave satisfactory results on a hparm test
Would any of the above conditions have much impact on Ardour’s performance?
Many thanks
Thanks for the screenshot and extra info! You can disregard the mitigations and mount warnings. And your USB card sits alone so that shouldn’t be an issue either. From what I can see you’re good to go from an audio settings perspective!
Maybe you could tell more about the issues with Ardour you’re facing?
The two most common issues are:
- crashes when editing region boundaries or moving regions
- disk too slow messages when adjusting regions on stacked multiple takes (eg for comping) and editing plugins during playback
Ardour 8 seems to be much more stable than 7 was for me and I haven’t had to abandon and redo any projects since 8 came out, which is great.
I still don’t understand why I get the disk too slow message as seen below on a project with one 30 second audio track and no plugins. Maybe its because the track is still rec-armed?
My computer is a 2017 thinkstation with a Xeon E5-1620 processor and 32GB ram.
Thanks for your time
For the disk too slow messages, maybe you could increase disk I/O buffering? See The Ardour Manual - Preferences
As for the crashes when editing boundaries or moving regions, no idea unfortunately 
When recording, I try to keep the buffer size so that the latency is less than 13msec, ie 512 samples at 48kHz. I monitor the performance direct as I dont want to use the computer to playback what I’m recording, and cause extra loading.
My Roland UA22 only has 2 channels and a max rate of 48KHz, which I normally use for sessions.
I had a 48K session with one track and a 2048 sample buffer and that complained when I dragged bits of regions around during playback. Looking at the session, again I can see the track was still rec-armed, so I will try to make a habit of disabling rec-arm as soon as I finish recording and see over time if i get less problems.
Regarding the crashes, @Paul said its a known bug, but no one has yet found a reliable recipe to cause it.
Thanks for your help
If you are monitoring direct, is there any reason you are worrying about setting the buffer size low?
Cheers
Keith
Also the disk buffer sizes are different from the processing buffer size. You can have larger disk buffer sizes, which just reads or writes more data into memory to lessen the load on the disk, at the trade off of larger seek times, or longer times to flush to disk after a recording (And potential lost data if a crash does happen).
Processing buffer sizes on the other hand affect your latency of audio I/O, but as @Majik stated, if you are monitoring direct this is likely not much of an issue so long at latency compensation is properly engaged.
I don’t see it mentioned, are you on a SSD or a spinning disk drive? If the latter are you running off a single drive for OS, Applications, Storage, and Audio?
Seablade
My primary disk is an ssd.
I looked at the partitioning of AVL and was surprised to see that it’s all in one partition (except the efi and swap).
Thanks for this insight.
I guess I will have to go and buy another ssd for Audio.
@GMAq Will you change the partitioning scheme in the next AVL release?
So there are certainly reasons to do more complex partition schemes, but for the record when dealing with SSDs audio performance is not one of them. Even on Mechanical drives it isn’t quite as simple as to say partition schemes will increase performance.
A seperate audio drive can help, but really you shouldn’t be seeing that message with a SSD. That makes me suspect something is causing a disk slowdown on occasion, this can happen with SSDs due to CPU topping out, or due to trying to overwrite old sectors that are no longer used, technically need to be cleared first before being written to, most SSDs should do that automatically but particularly early cheaper disks didn’t causing their performance to tank once all the sectors were written to once.
All that being said, increasing your playback and record disk buffers would definitely be a good way to address that. As also mentioned your processing buffer size for your use case could also most likely be safely increased.
Seablade
1 Like
Thanks this is very useful.
I cant understand why one audio track playing back with no plugins would cause the cpu to suffer and also, using Ardour, I have never seen the cpu temperature go above 35 centigrade, so I don’t think it can be working that hard. It’s all too strange.
This is why I was trying to find out if there’s any whole system tests I could do. But I have ordered a new ssd so I will set that up with AVL and see if the error messages go away.
Another possibility, could it be a problem with the RAID and is there a way to test that?
How.much memory is showing with the command “free -h” in the terminal CLI ? I am thinking the swap file may be being used. I had an issue at one time that linux did not see all of my physical memory, and there waa a system setting that needed to be changed.