Linux: autoseek generates xruns

Help, Support & Bugs
1

Hi

I record quite a lot of vocals with renoise, and normally have autoseek on for all vocal samples. However it seems that autoseek doesn’t go well with low latency settings.

Example: A song with 16 tracks of backing vocals, all with autoseek enabled. If I start playback after one or more samples with autoseek enabled is triggered, I get either an xrun and a click when playback is started. It seems that the more samples with autoseek enabled that are triggered before the point I start playback, the more pronounced the problem is. Also a click + xruns is produced when renoise has to jump to the beginning of looped section of the song.

Here’s a video (no sound, couldn’t figure out how to capture audio from jack) that shows the problem in the test song: autoseek_xruns.ogv

In this particular test song (all playback is started in the same spot, the “outro” where all vocal samples have been triggered) I measured which jack settings would produce xruns with two versions of the song, only difference was that one had all autoseek disabled. I should not that it’s fairly consistent, the measurements was done by starting/stopping playback at the exact same spot 10 times, and all results were 100%, so either 0 xruns in 10 playbacks start/stops or 10 xruns in 10 playback start/stops.

  • with autoseek enabled ------------------------------
    Settings that doesn’t generate xruns:
    1024 frames/period and 2 periods/buffer (46ms latency)

Settings that generates xruns:
512 frames/period and 2 periods/buffer (23ms latency)
512 frames/period and 3 periods/buffer (34ms latency)

  • with autoseek disabled -----------------------------
    Settings that doesn’t generates xruns:
    128 frames/period and 3 periods/buffer (8.7ms latency)
    128 frames/period and 2 periods/buffer (5.8ms latency)

Settings that generates xruns:
64 frames/period and 2 periods/buffer (2.9ms latency)
64 frames/period and 3 periods/buffer (4.3ms latency)

A little bit about my system:

I’m running Ubuntu 12.10 with my own patched kernel on a lenovo x61s, cpu frequency govenor is set to performance (max frequency) when running jack. Renoise is version 2.8.1.

atte@blokhus:~$ uname -r  
3.6.5-rt14  
  
atte@blokhus:~$ jackd --version  
jackdmp 1.9.9  
Copyright 2001-2005 Paul Davis and others.  
Copyright 2004-2012 Grame.  
jackdmp comes with ABSOLUTELY NO WARRANTY  
This is free software, and you are welcome to redistribute it  
under certain conditions; see the file COPYING for details  
jackdmp version 1.9.9 tmpdir /dev/shm protocol 8  
  
atte@blokhus:~$ cat /etc/security/limits.d/audio.conf   
@audio - rtprio 99  
@audio - memlock unlimited

I’d be more than happy to supply any additional information, including xrns of the song with/without autoseek enabled.

2

This was covered earlier in this thread: Linux 64-Bit: Jack Disconnects When Starting Playback In The Middle Of

3

Hmmmm, thanks for pointing to that (old) thread! I posted a reply there…

4

Bump.

I’d like to hear from the devs. What are your thoughts on this? Any chance we could get a solution to this?

5

hallo
do you “perform” live with that projekt? or are using hardware? otherwise I cant see why the low latency is so important

6

With this particular project I’m trying to record more vocals, and I get an xrun every time the recording loop starts over.

And please, don’t suggest that a system (kernel, user space software and renoise) capable of realtime audio in the 3-5ms latency range, should be set back to 46ms of latency because of a single performance flaw in the chain.

7

no it shouldnt. i hope youll get help.
best regs
./h

8

When it regards recording, it is up to the soundcard its capabilities and how well the drivers perform for it.
You state in your signature that you have a firewire card of which i don’t know exactly what its performance is in other software, but in generic firewire cards are known to jitter when connected to a system that doesn’t have a specific chipset (Texas Instruments) which supports firewire audiocards the best.
I heard complaints from the Mac OSX corner and Windows, now it looks like Linux not to be excluded so this may really seem a hardware conflict, but as said, i don’t know the details of your system specs.

9

Not sure what youre trying to say, but the system performs well, when not using auto seek. Ive been running renoise for years on various laptops and a few sound cards, did 6 albums with vocals, never had this performance taxing before. Adding off messages helps, switching auto seek off makes everything work just perfect.

I think my firewire chip is intel, will check when i get home…

10 
atte@blokhus:~$ lspci | grep -i firewire  
05:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
11

Hi atte,
those 7th pads of fodspor came into my mind while I was walking through snow today :)/>

You definitely need a TI chip. If it’s a notebook, I hope it still has an express-card slot.
I’ve had an onboard Ricoh controller in my notebook and the latest jack & ffado sources would not help. Even FFADO states that one should have a TI chip. As soon as I got one, things improved very much.

However, while Firewire can be tricky, I’m also wondering if this Autoseek-behaviour can be any related to it. Can you do a quick test against alsa to sort it out (‘-d alsa’ instead of ‘-d firewire’)? If autoseek still behaves the same or not, then we’ll know more, right?

Oh, and Autostatic’s patched version of ‘recordmydesktop’ is able to work with jack. However, the package depends on Jack1 and you are using jack2. If you should need help here, PM me. I don’t want to distract from your topic.

Best,

gilzad

12

You remember one of my tunes! Wow!

I’m sorry, but the results are exactly the same when running jack over alsa.

Another test I just did: Adding slices in sample editor + inserting notes on line 0 each new patten the long samples (the old school way of handling long samples, except that back in the days we didn’t have slices, so I cut/pasted to individual samples), works just perfect. To my tests this performs the best, exactly the same as auto seek off and triggering the samples once.

Maybe we could make a tool that does that: insert slices in long samples where a new pattern starts and insert notes on each of the patterns 0’th lines…

13

I thought Ricoh shoulnd’t be too bad either (not as good as TI though). The Via chipsets are the ones you should avoid the most.

If it only involves autoseek, i consider it just worth a look for the devs to see if it can be improved somehow.

14

Richoh are known as being really bad! Texas Instruments are by far the most recommended but everybody (as far as I and others I’ve spoken to on forums can tell anyway) has stopped using them for laptops. Event Apple now use Agere and have for a fair few years now. Some reports are the newer Agere are not [i]too[/b] bad but I’ve heard people a lot more knowledgeable than myself say they believe it’s more the problems are in part masked by the fact the other core components of the computer are that much faster that it masks a lot of the problems.

Even using a Firewire adapter (ExpressCard for example) which uses the TI chipset will in no way guarantee perfect performance. The chipsets on modern computer will do the Firewire along with most other interfaces, including the PCIe that you want, are often now all part of the South Bridge. So if this chipset is your problem putting a TI one before it will not always solve your issues.

This is why I’ve given up on the idea of using Firewire at all!

15

Could we agree, that since the problem is exactly the same when running jack over the buildin sound card AND the problem is gone, when turning autoseek off, this is NOT caused by firewire.

Or should I create a problematic xrns for people with a TI firewire card to test?

16

yeah atte has adequately demonstrated that this is not a firewire issue at this point.

not a firewire issue.

17

Ok, I just spend a couple of hours hunting this bug down. Seems it’s not that easy to reproduce, but I took a project that had the problem and stipped it down to just a few instruments and no dsp (links to xrns and video of the problem below)

If I start playback in pattern 10 (named “loop ok”) looping (here meaning “loop current pattern”) is fine, no xruns, no glitch.

If I start playback in pattern 11 (named “loop not ok”) I immediately get an xrun, audio is interrupted for 1/2-1 second, and every time the loop starts over I get an xrun and the same 1/2-1 second interruption of audio.

I recorded the problem (first looping pattern 10, then pattern 11, then pattern 10 again) with AutoStatic’s patched recordmydesktop found here. This meant that I had to switch from jack2 to jack1. In fact this made the problem even worse, behavior is the same as on jack2, except on jack2 the interruption of audio is very short, maybe just a click. The xruns and the way to get them are exactly the same.

After playing the recordmydesktop-video back I realized that the disruption of audio is not in the video (although it was there when I captured it), maybe jack somehow managed to handle the problem gracefully. Therefore I recorded a second video with my phone. It’s blurry, and the sound is poor, but it shows the problem exactly the way I experience it. Notice how the pattern editor freezes when starting the loop of pattern 11 (at 0:36 and 0:43).

Here are links to the files I used:
.xrns (pattern 10 loops ok, pattern 11 doesn’t)
Screen capture (recordmydesktop)
Screen capture (mobil phone)

18

I really meant it, when I wrote, you can PM me for help. It’s really easy to fix the dependencies, so you can use recordmydesktop with jack2.

But back on topic: You say that things got worse, when you switched to jack1. This means that jack is in some way involved in the underruns you get.
In a nutshell: Jack2 (earlier jackdmp, i.e. jack-daemon-multiprocessor) is able to use more processors, so it can process whatever it does quicklier. Now if you get stronger underruns with jack1, it means that for some reason the audio buffer couldn’t be filled in time, so a gap (xrun, underrun, click) occoured.

Jack didn’t really ‘manage’ this. The data has been written down to disk, when it was available. Opposed to playback writing to disk is not so time critical. The missing data (the gap) just haven’t been written to disk, so the audiostream in your videofile is seamless. This makes the problem appear to be even more Jack-specific. But still we can’t say that Renoise is not responsible at all. Because it’s the host who’s feeding Jack with audio data.

Could you do us another favour?

Can you configure Renoise (preferences) to use ALSA directly, without jack at all, and see if you still get underruns? Renoise accesses ALSA exclusively, so make sure nothing else is using your ALSA-soundcard before you attempt to access it with Renoise.

Thanks for the effort.

PS: Jack transport was disabled during your tests, right?

19

Ok, I misunderstood.

Makes sense.

I still get a click, but it’s quite a lot less, no 1/2 second hickup just a small click, and not in all cases where the test song would click. This matches my experiences exactly, from 2003 when I first started using laptops with linux on stage: alsa is more forgiving somehow. However there are things obviously not possible without jack…

Did you download the xrns and try to reproduce my problem? If not, maybe you could do me a favor, and do so.

You mean unticked in the box “Jack Transport Sync”? Yes, it was disabled…

20

With a latency of 10ms (periods=2, buffer=256) I cannot reproduce the issues you mentioned. Not even, if I have my governor set to on-demand (running on 800 MHz at that time).
I tested ‘play pattern’ and ‘play song’ on both patterns, had them looping and no issues.
Currently I’m in a situation where I can’t setup my whole system with the fw-interface. And on my onboard-soundcard I can’t go below 10ms without having random xruns. But you wrote, you’d already get xruns with a latency of 34ms, so…

My Sys: Deb6 (amd64), Kernel 3.2.14-rt. But my CPU is newer, so could it be just a power-issue? Autoseek does need some calculation time that loads the CPU. For instance, if I load a 6-Minute-sample, enable autoseek and trigger a pattern, then Renoise really takes some time until it finally starts playing.