Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#46236 - [ardour] 4.2-1 out of memory when trying to add a "tape" audio track

Attached to Project: Arch Linux
Opened by Razvan Cojocaru (rc) - Wednesday, 09 September 2015, 14:06 GMT
Last edited by Ray Rashif (schivmeister) - Sunday, 15 October 2017, 12:30 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Ray Rashif (schivmeister)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


When trying to add a new audio track to a project, Ardour just runs out of memory and ends up being killed by the OOM killer.

I'm using Ardour 4.2-1, on a Dell Latitude E5440 laptop with 8GB of RAM and an external USB3 SSD. I've tried both the regular kernel and linux-rt. I've also made sure that pulseaudio is not running or respawning. I've straced the binary but it doesn't tell me much, just that the last call before the application gets killed is a mmap() request for a huge chunk of memory. GDB doesn't help, since the application doesn't crash but is being killed by the OS. I've also tried both jack and jack2.

# uname -a
Linux dell 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux

Steps to reproduce:

1. Start up Ardour and create a new project.
2. Go to menu, Track -> Add track or bus...
3. Use the default settings, except for "Record mode:", where you need to change it to "Tape".
4. Click Add.

For the moment I've switched to Cubase, which so far seems immune to these kinds of issues. Nothing like a well-timed crash to ruin a take. Especially when it freezes your whole system with it for a couple of minutes.

I don't know if this only happens on my system, hopefully not. I can't test it on another computer right now, but will be able to at some point next week if requested.
This task depends upon

Closed by  Ray Rashif (schivmeister)
Sunday, 15 October 2017, 12:30 GMT
Reason for closing:  Upstream
Additional comments about closing:  Please re-open if necessary.
Comment by Razvan Cojocaru (rc) - Wednesday, 09 September 2015, 17:19 GMT
Well, here's how my talk with the Ardour devs went in #ardour on Freenode:

<red_> hello, I'm running Ardour 4.2 with Arch Linux and any time I try to add an audio track in "tape" mode, Ardour just starts eating up memory as soon as I hit the Add button, and it ends up being killed by the OOM killer
<red_> I've straced it, the last syscall printed out is a mmap() request for an ungodly ammount of memory
<red_> I've tried it with the distro Ardour package, with a binary downloaded from the Ardour page, and I've cloned the Git repo and built it, with the same results
<red_> I've also booted AV Linux which has an older version of Ardour (3.something) and that one worked
<rgareus> red_: tape tracks are currently broken.
<red_> I see
<rgareus> red_: they are "infinitly long" which is not a proplem per se (audio regions are limited), were it not for audio-tempo maps...
<rgareus> .. musical-tempo maps
<red_> right, thank you for the explanation
<red_> wouldn't it be OK to just disable that option from the GUI though?
<red_> why just leave it in to crash the application?
<rgareus> red_: as a reminder for us to fix it :)
<rgareus> red_: it can currently work under some circumstances. you can convert a track to a tape track.
<rgareus> then it works... until session reload, I think.
Comment by Ray Rashif (schivmeister) - Wednesday, 09 September 2015, 21:03 GMT
  • Field changed: Category (Packages: Extra → Upstream Bugs)
A truly unfortunate case -- all that troubleshooting to find out upstream has kept a dangerous reminder to themselves!

Anyway, on a more serious note, there is also no memory lock for rt privileges by default (our config, as well as the config recommended by some). [1] But this does not look like an audio region issue at all, although you could see if locking it down helps.

Keeping this open for reference.

Comment by Razvan Cojocaru (rc) - Wednesday, 09 September 2015, 21:46 GMT
It doesn't help. It's not a locking issue.