markc 23:15, 27 October 2007 (EDT): Couldn't the --with-default-tmpdir=/tmp/jack hint be --with-default-tmpdir=/dev/shm because /dev/shm already exists on every AL system (therefor saves adding a line to /etc/fstab) ?
I had to disable the intel_pstate driver with the boot parameter "intel_pstate=disable" in order to get JACK to run properly with pstate enabled kernels. This will probably need to be added to the wiki, but I'm going to wait and make sure that other people are experiencing the same issue before I make the edit. Mynis (talk) 23:55, 21 June 2013 (UTC)mynis
This and that
unfortunately I don't have the time to check everything from
However, taking a brief look, I noticed a few things.
"Latencies of 5ms down to even as low as 1ms can be achieved with good hardware and proper configuration."
This is true for just using an effect processor or lightweight audio/MIDI productions, but the latency likely increases rapidly on many computers when doing more advanced audio/MIDI productions.
linux-lts from official repositories is 4.9.18, so is there the need for the threadirqs warning?
Did somebody compare alsa-midi-latency-test with and without
echo 2048 > /sys/class/rtc/rtc0/max_user_freq echo 2048 > /proc/sys/dev/hpet/max-user-freq
IMO we could assume that nowadays only hpet (hrtimer) is used by MIDI software, so if the above should make sense, then just for hpet.
I also think that "Timer Frequency is set to 1000Hz (CONFIG_HZ_1000=y; if you do not do MIDI you can ignore this)" is obsolet.
Is there any evidence that editing
vm.swappiness = 10 fs.inotify.max_user_watches = 524288
$ setpci -v -d *:* latency_timer=b0 $ setpci -v -s $SOUND_CARD_PCI_ID latency_timer=ff # eg. SOUND_CARD_PCI_ID=03:00.0 (see below)
is a good idea?
I just noticed that for my old mobo unbinding USB ports sharing an IRQ might be useful, while for my new mobo this seems to be irrelevant.
"For onboard and USB devices, try Periods/Buffer = 3." Why? IMO the sane value is "2". The article is named "Professional audio" so we could assume at least pro-sumer USB audio interfaces and no onboard sound at all.
"If after getting jack setup you will find that Flash has no audio.
In order to get flash to work with jack you will need to install the libflashsupport-jackAUR package."
What the ...? It's not an issue to mention onboard devices by a short sentence, but this is just clutter.
When is flash needed for pro-audio usage? I suspect it's the same as for using pulseaudio in combination with jack, for all those radio productions that require flash and skype? IMO this doesn't belong to a Wiki about pro-audio. Let's focus on important things.
"If you want to use any MIDI hardware you need to ensure the ALSA MIDI driver is loaded. You can set the MIDI driver to load at boot by creating the file /etc/modules-load.d/alsamidi.conf containing:"
There's no need to do this!
Perhaps the audio hardware should move to another Wiki page. If we add more hardware to this list, this could become very long.
Shouldn't we refer more to jackd instead of jackdbus? For good reasons the Wiki mentions lightweight desktop environments and at the same time we introduce dbus?
This page is disastrous
The JACK and PulseAudio pages are bad, but this is a whole different level. This is so bad that it actively hampers the progress of someone who's trying to achieve the setups described. The entire page needs a rewrite. Actioninja (talk) 05:48, 28 May 2017 (UTC)
Want to contribute some findings
Hello, I've used this page for quite some time and have written a guide myself (which I am currently rewriting). I was told to hop on here and contribute. Please excuse me if I'm not doing this right, it's been a while since I mediawiki'd. I'll just start off with a few things I've found.
Firstly, I'm not entirely convinced noatime is necessary on audio systems with HDDs. I'm able to achieve 2ms latency without noatime and performance is not gained with my testing. I'm aware noatime is a better setting for SSDs, but I'm not sure this is the place for that setting.
Second, and this one was big for me, assigning a higher priority to my PCI soundcard was detrimental to audio performance. Most people are using an audio interface, and in this case they should instead disable the PCI audio module completely. I had an issue where even without modifying priority, my PCI audio was stealing IRQ priority from my audio interface. Blacklisting the module alone was enough to eliminate xruns completely. If anyone is aware of a less heavy-handed solution, that would be great, but this definitely needs a mention -- the difference is night and day!