LinuxMusicians

i2productions wrote:@capoeira
Do you use pure arch and build your system up from there, or do you start with crunchbang, or bridge or something?

falkTX wrote:jack doesn't use the chrt definition of priorities, but kernel-level scheduling.

falkTX wrote:this is why the niceness level on /etc/security/limits.d/audio.conf doesn't do much, it's not how jack works. this is also why jack requires special permissions for rt access - it's kernel related. if this wasn't the case you could just chrt jackd/jackdbus.

as a final note, high-disk usage can cause xruns too. This is because most apps need to read files from disk and can't cache enough data on time.
For example, ardour will not load a 2Gb wav file directly to RAM, but instead pre-read into a cache as needed. That pre-read can fail if the user is copying huge files to the disk.

This usually leads to xruns, although I suspect an app like ardour is prepared for this and has some kind of fallback mechanism that stops playback or outputs silence.
Anyway, the idea is there.

falkTX wrote:

raboof wrote:I'm not so sure about this: I/O (including reading from disk) should always be done in a non-rt thread, and indeed put in some kind of (ring)buffer. When I/O is too slow, indeed the application will get buffer underruns - which may cause audible glitches. However, this should never cause xruns, as the processing thread is not allowed to wait (block) until the buffer fills up, right?

That's the theory, but without checking the code of every single app and plugin we can't be sure.
I've seen some random plugins doing nasty things... I use locks in my Carla host processing code, and most likely any other decent app. The trick is to limit the locked time as low as possible (just to safely change a variable, for example).

This is also related to how linux starts new processes/executables. From what I understand it momentarily locks the entire system (so that everything is in sync), but is such small amount is not noticeable (if not this, is something very similar).
Anyway, I know the kernel can freeze for a few ms when for example starting wine for the first time. Since jack running RT depends on the kernel, xruns happen here. This can also happen when starting big apps/plugins, although not very common.

I _think_ that when copying large files the I/O of the disk plus CPU needed for the operation can leave the system 100% busy, so xruns happen.

falkTX wrote:

raboof wrote:Meh, I'm not so sure. The specs of course flat-out forbid this. I *guess* it's possible call some of these 'safely', but it's hard to get right - you'd have to make sure all threads that may contend for the same lock also have a realtime priority, for example.

Personally I'd say an app that uses those calls in the process() is basically broken, and there's no amount of distribution tuning you can do to fix a broken app...

I have to disagree. It's very very hard to code a multi-thread application without the use of locks and "mutexes"?.

I've seen code considered to be rt-safe to use such locks. Of course one needs to be careful when using them (and I am! I've been reviewing and rewriting my code several times...!).

Well, consider that the system is 100% full. The kernel wants to lower the prio of the hogging process, but because it's using 100% resources it just cant do anything (ie, a dead-lock). 100% usage seems impratical and/or impossible to me though... beh

Capoeira wrote:doesn't make sense loading an os to ram would lead to less xruns

it depends on system services loaded in the background

I can run EASILY hydrogen and jack with 16 frames/period and 2 periods/buffer on my Arch install qith 0 x-runs, and nothing is loaded to ram. I'm sure I could lower but I haven't tested it.

ps -ef | grep jackd

/usr/bin/jackd -T -ndefault -r -dfirewire -r44100 -p512 -n2

jeffh wrote:

Capoeira wrote:doesn't make sense loading an os to ram would lead to less xruns

it depends on system services loaded in the background

I can run EASILY hydrogen and jack with 16 frames/period and 2 periods/buffer on my Arch install qith 0 x-runs, and nothing is loaded to ram. I'm sure I could lower but I haven't tested it.

I think you've discovered the same bug in QJackCtl that I have... For some reason, when it can't start jackd with your current settings, it runs jackd with your last settings that did work. I've been able to "start" QJackCtl at 192khz (which my Saffire Pro14 does not support), 16 Frames/Period and 2 Periods/Buffer, but when you open a terminal and type:

Code: Select all

ps -ef | grep jackd

I can see that it completely ignored it and used my last good settings, like:

Code: Select all

/usr/bin/jackd -T -ndefault -r -dfirewire -r44100 -p512 -n2

I'm going to come right out and say that there's no way you're possibly running that 0.1ms of latency or whatever that comes out to, the Linux audio stack just isn't capable of that... For that matter, Windows isn't really either, but there's a whole bunch of users who have been convinced that they can "feel" a difference at those sub 1ms latencies, which must mean that their advanced brains can process over 1000 events a second. They also get upset whenever you try to tell them that measuring actual real-world, roundtrip latency with one of those instruments will always show that latency is about 10ms + the latency settings of your soundcard

[studio@localhost ~]$ ps -ef | grep jackd
studio   14325 14304 34 23:57 ?        00:00:16 /usr/bin/jackd -S -P70 -p512 -dfirewire -dKonnekt -r44100 -p8 -n2 -I104 -O104
studio   14367 11760  0 23:58 pts/0    00:00:00 grep jackd

jeffh wrote:I rest my case... Notice is says -p512 then -p8 ? Surely it's going with the first value...

Capoeira wrote:

Code: Select all

 224.867 frames      5.099 ms total roundtrip latency
        extra loopback latency: 208 frames
        use 104 for the backend arguments -I and -O