Fighting with my new Mobo ~and the winner is . .

[tramp]

Well, Linux wins.

But indeed, I'm a long time Linux user, nevertheless it takes me a real long time, to solve my issues.
I've got a used Mobo:

• Intel model: DG965MQ v: AAD37419-302
  Bios: Intel v: MQ96510J.86A.1250.2006.1005.1532 date: 10/05/2006

with CPU:

• Quad core Intel Core2 Quad Q6600 (-MCP-) cache: 4096 KB
  flags: (lm nx sse sse2 sse3 ssse3 vmx) bmips: 19199
  clock speeds: min/max: 1596/2394 MHz
  1: 2394 MHz 2: 2394 MHz
  3: 2394 MHz 4: 2394 MHz

setting up :

• Desktop: Cinnamon 2.2.16 (Gtk 3.14.5) dm: lightdm
  Distro: siduction 14.1.0 Indian Summer - cinnamon - (201411230307)

and tweak anything for Audio-performance. I do what I know and then, I do anything from
http://wiki.linuxaudio.org/wiki/system_configuration
but, I still get X-runs, unrelated to the dsp-load, or any audio work. They are not regularly provide, appears here and there, that drives me to the nuts.
Note that my previous Mobo had a Single core Intel Pentium 4 CPU, and only makes a Xrun when I start up Qsynth (the usual one )
This Cinnamon Desktop is new to me, as I used LXDE before, I notice Cinnamon comes with pulse-audio, which I've avoided up to now, however, putting

Code: Select all

pasuspender --

in the serverpath of Qjackctl, pause pulse during jack is running, but surprisingly, that didn't help. I verify that pulse didn't run. So what? I build the latest rt-kernel 3.14.25-rt2 and getting a nice impression when it runs , but, never had that in the last 10 years, a freeze, I try again make some music, freeze. Umpf.
So I search the net for solutions, and my last resort was Hyper-treading. I build a new Kernel, disable support for Hyper-treading, and voila. Now, my new system runs smooth and stable.

I've made this story short for you, and I'm a glad linuxer again, but in fact, it takes me 2 hole day's, just to set-up my machine to work properly, now I can start to tweak the desktop, re-organize my data, and start work again on my code.

regards
hermann

[glowrak guy]

Congrats on the victory. Defeat is not a linux user option. I recently got the new guitarix running on a distro that only had a .11 era version.
It took a lot of alien conversions from debian sid dependency lists, and libavahi-gobject installed without errors,
but wasn't listed in file managers, and guitarix terminal output also said it was missing. Then I installed all the avahi related
things in my distro repository, (shotgun administration mode ) and guitarix began working! And very well worth the effort!
(Sorry for the off-topic)
Cheers

[tramp]

Congrats on the victory. Defeat is not a linux user option.

I recently got the new guitarix running on a distro that only had a .11 era version.
It took a lot of alien conversions from debian sid dependency lists, and libavahi-gobject installed without errors,
but wasn't listed in file managers, and guitarix terminal output also said it was missing. Then I installed all the avahi related
things in my distro repository, (shotgun administration mode ) and guitarix began working! And very well worth the effort!
(Sorry for the off-topic)
Cheers

Avahi isn't a hard-dependency for guitarix, if you build it from source, you can use the configure flag

Code: Select all

--no-avahi

to deselect it.
You only need Avahi, if you would run the guitarix engine and GUI as separate programs or an separate PC's, or would use the WEB-interface to control guitarix from your phone (or whatever). The same is true for bluez. Other than that, we almost try to take care, that our dependency’s could be solved even from old-stable. A couple of work-around's therefore have been included in the source, but truly, I haven’t check if it works on old-stable, for quite some time.

[glowrak guy]

I have a Mustang usb guitar amp, ($50 used, warranty expired etc) all chips, no tubes,
and I'm thinking about removing the speaker, and putting a computer motherboard inside,
and a mounting an lcd monitor on the back. For taking on beach trips, holiday visits etc
And potentially, for daily use desk space. The headphone jack, when in use, shorts out the speaker circuit,
so load shouldn't be an issue.

Shielding the solid-state amp mobo from the computer mobo and monitor,
are the main concerns. Do you have any thoughts as to the success potential?
The amp has sat two feet from my open-case computer for years, wihout issue.
And a very clean tone is available to send to ampsims.
Cheers

[tramp]

Sure, that will work. Check out our wiki here, http://sourceforge.net/p/guitarix/wiki/ ... _-ARM_SoC/
how to set up guitarix-embeded. The wiki is a bit outdated, sure, but for setup the system it is good enough. The control chain have been slightly improved, so, you could control the system not only from the GPIO, but as well from your Phone or Tablet (Web-interface), or as well from your PC with the remote GUI.

[glowrak guy]

Nice wiki link. Lots of good reding ahead!

[asbak]

Many thanks for the interesting information Tramp, I think it is quite important and should be included in an updated Linux Audio Guide.

I tried all the usual things but never managed to get rid of random Xruns on a Xeon server with Debian Jessie + RME 9652 PCI Audiocard system even though the same hardware seems to run fine with Windoze 7.
(I know about the non-native PCI bus issue on modern motherboards but I don't seem to have performance issues with multiple Xruns. I only get random Xruns)

Some possible conclusions: (For some of us, not the ones who are unaffected because of their particular hardware / software configurations)


- a RT kernel seems to still be relevant for audio production? (Not for all systems and audio interfaces of course but nothing I've tried has eliminated xruns from my RME PCI card)
- Desktop choice may also be important, I seemed to get less xruns with XFCE than Cinnamon
- DBUS / systemd may be another problem area, perhaps this could be replaced with sysvinit like here: http://sohcahtoa.org.uk/osd.html
(I haven't tried it yet and it will stop some Linux Audio applications which rely on systemd from working of course)
- Video drivers choice may also have an effect, I seemed to get less xruns with the proprietary nVidia drivers than with the Nouveau driver (cannot be sure though).

Just out of interest, what sources of information did you use for building the RT Kernel? At some point I'll give it a go on Jessie. There is some good info out there but if you know of anything relatively simple / easy to follow I'd love to know.

[tramp]

Hi asbak

Well, it seems that my problem wasn't really related to Hyper-treading, or Rt-patch, but to the kernel module
i2c_i801 -> i801_smbus.

With newer Kernels, it tend to use IRQ, which unfortunately get shared with my soundcard.
Kernels before 3.5 haven't this feature, so the 3.4.105-rt kernel works well.
Later ones gives me the trouble.
Now, I've found out that the i2c_i801 module have a option to don't use interrupts, I've set this in /etc/modprobe.d/modesetting.conf

Code: Select all

options i2c_i801 disable_features=0x10

and now the i801_smbus didn't use a IRQ anymore, my soundcard have it's own IRQ, and no Xruns anymore, even with a standard generic kernel from siduction.

Just out of interest, what sources of information did you use for building the RT Kernel? At some point I'll give it a go on Jessie. There is some good info out there but if you know of anything relatively simple / easy to follow I'd love to know.

You can just follow the Guide on http://wiki.linuxaudio.org/wiki/system_ ... the_kernel
I usually use the plain vanilla kernel from kernel.org with rt-patch

EDIT://
No, the only Kernel which runs absolutely smooth here is 3.4.104-rt128 x86_64
disable IRQ for i801_smbus on 3.17.5 (for example) helps, but performance is a lot better with 3.4.104-rt
I will try now the latest 3.14 kernel with rt-patch and disabled IRQ for i801_smbus

[asbak]

Interesting advice thank you tramp. I installed nVidia drivers which only work with kernel 3.16, I guess I will have to get rid of those and try again with the suggestions you made.

[asbak]

So I tried some older rt kernels downloaded from Debian but either they won't work properly with Jessie (in some cases system won't boot) or in the case of the later versions which do work, it keeps crashing.
I patched a 3.14 kernel to rt on a Xeon64 bit computer, set CONFIG_PREEMPT, set CONFIG_HZ=1000 and disabled CONFIG_SCHED_SMT and then compiled and installed the kernel headers and image.

The computer ran for about 5 mins and during testing of audio apps (Kontakt running on Wine) it hung.

Installing a 3.14 RT kernel image from Debian didn't seem to work either, computer freezes.

By the way, I also made the "mistake" of installing nVidia drivers which complicates kernel testing so it's better to go back to Nouveau but it is a bit tricky to uninstall it properly and get Nouveau working again. This is what I ended up doing as root user.

Code: Select all

apt-get remove --purge nvidia-*
mv /etc/X11/xorg.conf /etc/X11/xorg.conf.oldnvidia
echo 'nouveau' | tee -a /etc/modules
apt-get install xserver-xorg-video-nouveau
dpkg-reconfigure xserver-xorg

Reboot and hope for the best

- UPDATE -
Compiled a 3.18 Kernel with PREEMPT, 1000HZ and installed in Jessie
Tested with Kontakt in Wine and OBXD in Carla, system still Xruns with a RME 9652
Seems to work OK so far, no Xruns, with a UMC404

The UMC404 has magically stopped working in Linux in the past and only connecting it to a Windows computer has seemed to reset it. Anyway, the conclusion I can draw so far is that getting PCI cards to work well with Linux audio seems to be challenging and that USB cards seem to work better. Perhaps certain PCI-Express models would also work but until somebody's tested them who knows.

For people who want to compile kernels in Debian and wonder how, here's a very rough guide


Install QT4 if not already installed

Code: Select all

apt-get install libqt4-dev

Install the following

Code: Select all

apt-get install kernel-package fakeroot build-essential

Download Kernel Sources from Kernel.org

Code: Select all

https://www.kernel.org/pub/linux/kernel/v3.x/

Untar Kernel Source (It's up to you to decide what version you want to use)

Code: Select all

tar xJvf linux-3.14.29.tar.xz
cd linux*

If patching RT Kernel

Code: Select all

xzcat ../patch-3.14.29-rt26.patch.xz | patch -p1

Copy the config of your current kernel to the folder you untarred the linux kernel sources. The config version depends on the kernel version you currently have installed, below is just an example

Code: Select all

cp /boot/config-3.16  .config

Code: Select all

make oldconfig

(Select preempt model you require. Next you can accept all the other default settings when prompted by holding down the enter key until it's run through the config file.

Code: Select all

make xconfig

Ensure the settings below are set and save the .config when done.


Processor Type and Features,
- [Optional] can select Xeon at Processor Family (or use usual 64Bit x86 CPU)
- [Optional] SMT Hyperthreading, disable (it may help with crashing if compiling RT Kernel??)
- Preemption Model, set to low-latency (if you're not using a RT kernel)
- Timer Freq set to 1000HZ
- [Optional] Disable APM

You should see these values when you check the .config file

CONFIG_PREEMPT=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_APM=n (Optional)


To compile the kernel

Code: Select all

make-kpkg clean
CONCURRENCY_LEVEL=`nproc` LOCALVERSION= fakeroot make-kpkg --initrd --revision 0 kernel_image kernel_headers

Install the kernel

Code: Select all

cd ..
dpkg -i linux-headers-xxxx.deb
dpkg -i linux-image-xxxxx.deb

NOTES
run update-grub2 (to update bootloader, not really necessary when installing kernel with dpkg -i)


Listing kernel components

Code: Select all

dpkg --get-selections | grep linux- 

Uninstalling old kernels. Be careful you don't uninstall the standard kernel by accident.

Code: Select all

apt-get remove --purge linux-image-xxxx
apt-get remove --purge linux-headers-xxxx

[tramp]

After more tests, it turns out that the Xruns I receive are related to 3D acceleration. Some responses on LAU indicate, that it should happen as well with the NVIDIA driver, so not related to nouveau.
I get no Xruns with newer kernels, when I use LXDE instead of Cinnamon. True, with the tweaks I mention above.
On exception is indeed the 3.14 kernel, which hangs here as well.
Which Desktop do you use?

[asbak]

I originally used XFCE + nVidia driver (seemed to get the least Xruns) and am currently using XFCE + Nouveau driver. I suspect (not sure) that Cinnamon causes more Xruns.
I also suspect (not 100% sure) that the Nouveau driver causes loads of Xruns when using a Webbrowser (Iceweasel) and that the nVidia driver causes less Xruns, at least when using a browser.

I haven't used Linux for Audio in recent months so I don't have good recent test data since I compiled new kernels to experiment with only last night.

Jessie + 3.14 RT and other RT kernels I tried either hung after < 5 mins or simply didn't work or even boot. It's possible that one could get 3.14 RT to work with more tweaks, perhaps disable APM before compiling, perhaps disable Hyperthreading in BIOS etc. My original goal was to get a PCI RME 9652 to work without Xrunning but so far no joy. (I guess it's supposed to work with AV Linux and perhaps on a different mobo to what I have... who knows).

The brief testing I did with a home compiled PREEMPT 1000HZ 3.18 Kernel and a UMC404 USB interface + your modprobe tweak for I2C has been positive. I didn't get Xruns with OBXD in Carla or with Kontakt running in WIne.
I haven't tested extensively so don't know for sure how well this will keep work. Of course I still should also test Guitarix

In the past Jackd2 tended to start killing the CPU and Xrun like mad after a couple of hours of uptime but I haven't tried using it recently for extended periods so don't know if it still causes the CPU to runaway.

[asbak]

My RME 9652 PCI xruns may have been caused by an unexpected source namely the MIDI ports on the RME. Perhaps something's buggy in the Linux drivers or perhaps there's another reason, I don't know.

Since using a USB MIDI interface instead of the MIDI ports on the 9652 it seems to be working quite well for audio and playing softsynths with low'ish latency (128) under Linux using a 3.18 PREEMPT 1000Mhz kernel.
A 3.18 RT Kernel appears to work similarly OK to the 3.18 PREEMPT. There didn't seem to be much difference between the two in terms of playing softsynths with low latency.

This is on an Asus P9D-X motherboard (C222 Chipset) with (I think?) an Asmedia PCI-e to PCI bridge controller.

All now running on Jessie + 3.18PREEMPT 1000Mhz + nVIdia Videodrivers + Cinnamon Desktop + jackd2, jackdbus disabled and so far, so good.

One thing which not everybody may be aware of when compiling kernels is that during bootup with the new kernel it usually hung for me because the display wasn't working properly with the previously installed nVidia drivers.
So to get around this I first uninstalled nVidia driver, reinstalled Nouveau, rebooted, compiled kernels (3.18 PREEMPT 1000Mhz and 3.18 RT 1000 Mhz in my case), tested that these worked. Then I reinstalled nVidia drivers and it now works with all kernels.