Reverse Engineered

MOTU is hostile towards Linux

Support Status: 
Reported to work


Hi there,

today I managed to get my Motu 828 mkII working with the following setup:
- Debian Etch
- kernel
- libraw1394 1.3.0 from svn
- jack from svn
- libffado from svn

At first scons was unable to find my libraw1394 as I had a previously compiled version
also under /usr/local. In /usr/local/lib/pkgconfig/libraw1394.pc, the version was missing
and some header files had not been copied to /usr/local/include/libraw1394 by "make install".

Second, the compilation of jack was not working as expected, automake reported some
errors. So I copied some alsa-midi/* files to drivers/alsa and drivers/freebob
and changes minor things in the appropriate Makefile.am's so that everything went fine.

After everything was ready to start, I fired a jackd -R -d firewire -r 48000 in a terminal
since my qjackctl version didn't know anything about a firefire backend driver.
The debug version of libffado produces a lot of messages so I sent it via 2&> to
a log file so that I could focus on the sound thing.

I started then qjackctl to see the channels in the connection dialog.
Though in the logs the channels had names like Analog7 and Analog8 - the names one is used
to from the WDM drivers, all channels are named from capture_1 to capture_14 and playback_1
to playback_14.

My first little task was to play a pcm file through the device's main output. I used ardour2
for it, which I compiled some weeks ago. In ardour, the channel names switch again. Each pair
of stereo channels appear as Out 1+2, Out 3+4 and so an. Unfortunately Out 1+2 refer to the
headphones, Out 11+12 to the Main Outs and Out 13+14 to the SPDIF digital out. I imported an
existing stereo file to a track and woom! A beautiful sound came out of my speakers. Very cool.

The next task was to record something on top. Ardour showed 23ms of latency so I decided to leave
it alone, optimizing latency is yet worth another test session.
I plugged a mic into my RNP+RNC preamp setup and connected its output to Analog1.
This time I created a mono audio track, and from the availabe inputs (in 1 to in 14), the in 1
was the right one. I recorded some words and checked on hiss or hum. This track was really clean!

The first little issue was: Turning volume of Main Outs or Headphone up and down on the device,
the display stays with the Message "Clock Source: Internal", so the faders cannot be seen anymore.
And the green LED showing signal acitivity on Channel 1 is always blinking as if there is some
noise floor (which I could not prove to be there).

And the second one, more annoying: After doing some work on it, some strange noise on a very high
pitch appeared. It sounded like the synchronization has gone away or even worse.
As I repeated my tests, it's usually OK for a minute or two. After that, there is here and there some
crackle, the previously mentioned noise or some LEDs show short peaks of signal activity.

So, to sum it up, I am very happy that the Motu is supported and that it intially works fine, but
the covered issues make it still unusable for everyday audio work. With some bug fixes until 2.0,
I think the device can be marked as supported by ffado, though. Kudos to the coders!


Dear all,
I found this post only today but I see it was posted in 2007!!
Is there someone helping me to make my motu MK II working with Ubuntu Studio latest relase.
I believe since 2007 there is a simpler way to solve this problem.
Is there someone could help me?

As far as I know the 828Mk2 works fine with the current FFADO codebase. Try 2.0-rc2 or later (avoid 2.0-rc1 for use with MOTUs since a last minute infrastructure change broke the MOTU driver in that release). Alternatively, wait for the 2.0 release which is happening "soon".

For installation help, first check out the install-type documents in the "User documentation" section of http://subversion.ffado.org/. If you still have questions please post to the ffado-users mailing list.

My experience has been reasonable:

unable to output to headphone jack (lack of knowledge I suspect)
works fine on higher sample rates (96, 88) and crashes on lower rates (44, 48)

Which is probably what is to be expected with an almost supported device. :)

Which 828 was this: the original, the 828 Mark 2 or the 828 Mark 3?

I can't imagine why the headphone output isn't working - this hasn't been reported by others using the 828 Mark 2. In fact, the 828 Mark 2 has been pretty well working for quite some time now, so I'm surprised to hear that there are problems with yours (assuming of course that you have the 828 Mark 2. I would be interested in pursing this further if you like since until now I was not aware of any issues with the 828 Mark 2.

If on the other hand you're using an 828 or an 828 Mark 3 I would still be interested in working through the issues. The ultimate goal is to have all these interfaces operational, but since I can't afford to buy them all myself I rely on others testing the interfaces I don't have.

It may prove easier to work this out via email - feel free to contact me via the ffado-devel mailing list if you like.

Hi, first of all, sorry for my bad english, then
I have successfully installed ffado drivers on my Ubuntu 10.04 on a Core2Quad Intel, 2 Gb ram desktop pc, to use Motu 828 mkII interface. It works fine, I haven't had any problems.
Then, i bought a HP pavillion dv6-2193el notebook to make travelling recording, and I decided to install on it Ubuntu Studio 10.04.
Then, I've installed the ffado drivers, jack, etc, then I started the ffado-dbus-server, I plugged the 828mkII interface and I switched it on and...this is what's happened:

00315288695: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00315288732: Warning (IsoHandlerManager.cpp)[ 516] handleBusReset: could no handle busreset on xmit
00315288738: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00315288744: Warning (IsoHandlerManager.cpp)[ 519] handleBusReset: could no handle busreset on recv
00316272148: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00316272170: Warning (IsoHandlerManager.cpp)[ 516] handleBusReset: could no handle busreset on xmit
00316272175: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00316272182: Warning (IsoHandlerManager.cpp)[ 519] handleBusReset: could no handle busreset on recv
00322789212: Error (configrom.cpp)[ 148] initialize: Could not parse config rom of node 0 on port 0
00322790543: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00322790563: Warning (IsoHandlerManager.cpp)[ 516] handleBusReset: could no handle busreset on xmit
00322790581: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00322790586: Warning (IsoHandlerManager.cpp)[ 519] handleBusReset: could no handle busreset on recv
00326750090: Error (configrom.cpp)[ 148] initialize: Could not parse config rom of node 0 on port 0
00328122401: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00328122430: Warning (IsoHandlerManager.cpp)[ 516] handleBusReset: could no handle busreset on xmit
00328122435: Error (IsoHandlerManager.cpp)[ 101] handleBusReset: shadow map update request not honored
00328122441: Warning (IsoHandlerManager.cpp)[ 519] handleBusReset: could no handle busreset on recv

by the way the ffado mixer works and I can open jack, but it crashes after few seconds, and after reporting a lot of xruns
what does it mean? how can I try to resolve this problem?

First up, it's great to hear that you've had the 828mk2 working on your desktop.

As to the problems on the HP laptop, the messages posted above seem to point to a low level bus problem. They are emitted from the FFADO layer below the actual driver. Obviously they have something to do with bus resets and the general feeling is that something isn't working correctly after or during the bus reset. In particular, the "Could not parse config rom of node 0 on port 0" means that a rather fundamental component of the bus isn't working for at least one device on the bus.

I'm not sure what precisely to suggest at this point. You might like to join the ffado-devel mailing list and post your problem there - that way all the developers will see it and perhaps it will ring bells for one of them. I didn't have a lot to do with the lower level ffado code so its likely that those who did may have a useful insight.

Some other things to check: what firewire chipset is in the HP? This should be detailed in the output of the "lspci" command.

Did you happen to have jackd/ffado running when you plugged the device in? This is not generally recommended. If you did do this, perhaps try activating the device first and then starting jackd - things may work a bit better then. It's actually quite hard for a running ffado/jackd to deal cleanly with bus resets and reconfigurations while it's running due to the tight timing requirements of the audio streams and it may be that on that particular laptop either the hardware or ffado software aren't quite up to it.

FYI ffado-mixer operates independently of the audio streaming system provided by jackd/ffado. It's entirely possible to run either without the other active, and for one to work and not the other.

Ty for the answer,
by the way, I don't know why, before I was trying to do something to make the whole sistem works, I tried to start ffado server then jack and...it started!!
I have had some weeks of good working jack/ffado, then today I got again some problems.
First of all, I've seen that the low level bus problems come out even on my desktop pc, they come out when I start the ffado server before plug and turn on the device (as you suggested) so they are not relevant when I do things in the correct way, and don't seem to cause crashes on jack.

The problem is - again - on my notebook: as I told, today it stops working as it should without any reason. I plugged the cable, turned on the device then started the ffado server. Then I started jack and it crashes after two or three seconds (the first time it requested the real time mode).
On the Ubuntu Studio I have the 2.6.32-25 preempt kernel, so I installed the 2.6.31-11 realtime kernel, and it works.
I think it's a problem of real time, but why the preempt kernel - installed natively on Ubuntu Studio - worked good untile yesterday, and today I had to use the realtime one?

EDIT: with the realtime kernel i keep to have problems...with the Ardour projects I have experienced some crashes of jack but most of all very annoying noise like whistle or something like that.
by the way here it is my lspci, I found the line about the ieee1394 chipset, it tells:
04:00.0 FireWire (IEEE1394): JMicron Technology Corp. IEEE1394 Host Controller

I'm having difficulty understanding exactly what you've tried and what has happened, so for now I'll just offer a few thoughts which may or may not be relevant.

First up, you should have the audio interface plugged in and turned on before you attempt to start jackd.

Could you post the jackd command line you're using? Depending on your computer and its capabilities it is possible that you're asking jack to do something which it cannot manage on your conputer. I tend to recommend that people start conservatively and then experiment with lower latency settings once that's working. For example, to start with I would suggest you run jack like this:

jackd -P70 -R -d firewire -p 1024 -n 4

This is what I tend to use all the time when latency isn't an issue.

You mentioned that jackd crashed when it requested real time mode. This would tend to suggest that the applicable permissions have not been set up on your machine. Certainly without realtime scheduling (which is what this is all about) jackd/ffado won't run reliably. Have you had a read through the relevant sections of the installation guides on the ffado wiki yet?

I should note here that one does not need a "realtime kernel" in order to have access to the realtime scheduler. Somewhat confusingly most stock kernels these days include the realtime scheduler and therefore work pretty well with ffado. Importantly, if there is a permission issue preventing the use of the realtime scheduler then this will apply equally well to realtime and non-realtime kernels. This may be the reason you continue to have troubles when using a realtime kernel (if indeed you are - I can't quite tell), although a realtime kernel will, for other reasons, make things less likely to give trouble even in this circumstance.

The whistles are, unfortunately, unavoidable with MOTU hardware. If jackd/ffado crashes under certain circumstances the MOTU interface emits these rather nasty and unpleasant sounds and there's very little we can do about it. It's a hardware thing and therefore beyond the ability of software like ffado to deal with.

I can't explain why things worked fine until recently and have now stopped. Have you upgraded any parts of your installation recently?

- "I'm having difficulty understanding exactly what you've tried and what has happened, so for now I'll just offer a few thoughts which may or may not be relevant."
Sorry, this is probably for my bad english, i cant' explain very well this kind of problems!

-"First up, you should have the audio interface plugged in and turned on before you attempt to start jackd."
Yes I already knew this, and there are no particular differences between high or nearzero latency, so I think it doesn't depend on it.

About the kernels:
on UbuntuStudio 10.04 you get natively the preempt kernel, which follows the numeration and updating of the generic kernel, while the realtime kernel instead follows another kind of numeration (I mean, now I can have the 2.6.31-11-rt or the 2.6.32-26-generic or the 2.6.32-26-preempt)
Quite everythings whas good on the preempt kernel until I update to the 2.6.32-25-preempt: maybe this update could have something wrong, by the way I installed the 2.6.31-11-rt kernel and everything works fine. So I don't know where is the problem! How can I make sure to have the right permission to have access to the realtime scheduler? by the way I'll try to re-install the 2.6.32-24-preempt to see if the problem is the 32-25 or the preempt kernel.

About the whistle: they have something to do with the alsa driver, I didn't get the problem very well but I managed to stop it (I blacklisted the internal soundcard, but some softwares like jackrack or hydrogen don't work fine without any alsa card so I moved it away from blacklist but I didn't enabled on jack setup panel the "Enable ALSA sequencer support" option)

Thanks for the updated information. To clarify, the "preempt" kernels should be sufficient for running ffado these days. In the past the "rt" (realtime) kernels were required but that is in general no longer the case (mostly because many of the more critical features of the rt kernels have made their way into the standard kernel). This does depend a bit on the computer though - perhaps some slower machines (for example, less than 1 GHz) may still require the rt kernels.

Based on what you've said it does seem that something has changed in the 2.6.32-25-preempt kernel to upset things on your system, especially since you successfully used earlier preempt kernels. Your idea to try 2.6.32-24-preempt is a good one - it will be interesting to see what the results are. Out of interest, what is the latest kernel version you have access to in UbuntuStudio 10.04?

Regarding the permissions for realtime scheduling, I suspect this is already done for you in UbuntuStudio. For most distributions it's set by lines in /etc/security/limits.conf (or some other similar name). Lines similar to "@audio - rtprio 99" and "@audio - memlock unlimited" should already be present; if they are then you're good to go.

I can't comment further on the whistle issue because I can't really understand how ALSA could have anything to do with it. In any case, do I take it that the problem is now solved, or at the very least worked around?

the limits.conf was set as you say most time ago :D
the latest kernel version I have access in UbuntuStudio 10.04 is the same in the "normale" Ubuntu 10.04, so the 2.6.32-26.
by the way I've re-installed the 2.6.32-24-preempt, and everything works fine.
So I tried to isntall the 2.6.32-25-preempt (the one I had problem with) and everything (well, something) works fine.
Then, I installed the 2.6.32-26-preempt, and it goes fine on it too.
So I don't know where's the problems!!
I removed the 2.6.31-11-rt and the 2.6.32-24-preempt, so now I'm with the 25 and 26 preempt kernel, and the little things I have tested works fine (I haven't had a single xrun even workin at 128 frames/period for half an hour)
the whistle...a remembering of the past: I think the problems is something like the plugin hosts and other pro audio softwares load alsa driver modules even if jack is set on the firewire driver; maybe this could depend on the fact that the firewire interface aren't seen like audio interface while they need someone to start.
This is an idea, but I'm not sure (I'm not sure to have wrote it in the right way in english, too)

So now quite everything seems to work fine...I hope for a long long time!
ty all!

Thanks for the update. I guess we'll just have to keep an eye on it and see if it remains stable over a longer period of time. I'm glad to see that it's holding together at the moment.

I must say that it's impressive that it's seemingly working with 128 frames/period. If you do encounter issues in the future the first thing to do would be to increase this somewhat (to, for example, 512) and see if that improves things. But while it's working you might as well leave everything as it is.

Bad news...
I got a registration session several days ago, first I got a 10-mic drum session, then a 2 channel keybord, then guitar, then voice.
During the sessions I experienced problems and some xruns, even at higher latencies (putting the frames from 64 to 512 doesn't change anything)
Every hours, hours and a half, I got xrun or simply jack crashed, the MOTU whistled and I got to close Ardour, stop Jack, restart it, then open Ardour. Sometimes it happens that the system froze, too, and I had to wait or simply manually turn it off.
This happened on my desktop pc too, during the editing and mixing session, and even when I start an Ardour project with a lot of tracks, it says "Jack disconnected Ardour cause it's too slow etc etc", then I have to restart jack and hope to have Ardour work good for another hour.
I even tryied to change the 1394 chip with a Texas Instrument one, but things don't change...
The last thing I have to do now is to try the MOTU on Windows...if it works properly there, then I have to sell it and buy something like the Saffire Pro 26 ore the Terratec Mic2/Mic8
as usual, sorry for my bad english and thank you for all

UPDATE (31-01-2011) I've tried the MOTU on a Windows7/Cubase system (on the same desktop pc) and it works good, no whistle, no stop, no problems, no crash. Misteriously, on my notebook, on Windows7, the soundcard cannot be supported and it doesn't work at all, while with UbuntuStudio it works (with the xruns, jack crashes, etc)
Now I've bought a Saffire Pro 26 and I'm waiting to receive it, as soon as I got it I'll update again this post (I'm sorry for the MOTU, but I really hope the saffire will work 100% good and I could sell the 828 back)

I hope the Saffire works out for you.

It is hard to work out precisely what the problem might have been with the MOTU in your case. The fact that it worked on one machine and not on another suggests that there might have been something about the "bad" machine which was causing the problem. There are many possibilities: shared interrupts (especially if firewire shares an interrupt with USB), binary video drives (Nvidia ones in particular), something in userspace which happens to cause sufficient problems in the kernel to upset things, and so on. If your ardour session was very large with many CPU-intensive effects (or perhaps one buggy effect which took too long to run) it might well be that you were running out of CPU cycles. In fact, problems with ffado in general (and MOTU in particular) would not normally result in jackd complaining about ardour taking too long - if that complaint is made then it usually means there's some issue with the ardour session. Perhaps there's something in Ubuntu that's causing issues on your hardware.

The "whistling" from the MOTU is the usual behaviour when something goes wrong with the streaming (eg: you get xruns).

Unfortunately I suspect that at least some of the problems you've seen are the result of something on the system upsetting things, as outlined above. If this is the case then changing to another audio device may not dramatically improve things because the underlying problem was not the MOTU device or the driver. What I do know is that there are quite a few reports of people successfully using the 828mk2 with ffado (along with other MOTU models of the same generation), which is why I suspect there was something amiss which was unrelated to the MOTU, its driver or even ffado itself. I myself have run 16-channel recording sessions with my Traveler (which is very similar to the 828mk2) for hours on end without any issues at all.

Anyway, best of luck with the Saffire - it's a nice interface, and I hope it works better on your particular combination of hardware and software. I'm sorry we weren't able to identify the true source of your difficulties.


I think the problem is related to the JMicron chip. I had problems with this chip in windows. After 10 seconds, my Saffire LE card stopped working even after disabling almost all other devices (network, cdrom, webcam, etc..). Same thing as in Ubuntu Studio 10.04 (xruns and bus problems after 10 seconds).

JMicron released a new driver for windows in august/september 2010 and with this driver I finally got it to work in Windows. Now I'm trying to get it to work in Ubuntu. I've tried with both the old and new stack, but the problem persists. I haven't tried by disabling the other devices in linux yet (or changing the irq).

Well I have to say that now my chip seems to work good...maybe the problems was that in new kernels this chip is not supported, I don't know...
by the way I guess, if the chip were the problem, how could I change it...

I've changed the chip on my desktop pc, that was VIA, with a TI chip, the crashes are still there...
I'm trying to do the same on the netbook, but I think the results will be the same, so I don't think the matter is only in the chip

Hi everyone,
i can't manage to get working my MOTU.
Here is my setup:
- Ubuntu 13.04 (kernel 3.8.0-29-generic)
- firewire new stack
- ffado 2.1.0
- jackd2

This is what jackd says when i try to start it using 'jackd -R -d firewire':

jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 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
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
libffado 2.1.9999- built Feb 1 2013 04:49:43
firewire ERR: FFADO: Error creating virtual device
Cannot attach audio driver
JackServer::Open failed with -1
no message buffer overruns
Failed to open server

And this is what i get when start 'ffado-diag':

FFADO diagnostic utility 2.1.9999-
(C) 2008 Pieter Palmers
2009-2010 Arnold Krille

=== CHECK ===
Base system...
kernel version............ 3.8.0-29-generic
Preempt (low latency)... False
RT patched.............. False
old 1394 stack present.... False
old 1394 stack loaded..... False
old 1394 stack active..... False
new 1394 stack present.... True
new 1394 stack loaded..... True
new 1394 stack active..... True
/dev/raw1394 node present. False
/dev/fw* permissions:
crw------- 1 root root 251, 0 авг. 22 22:28 /dev/fw0
User IDs:
uid=1000(ziflex) gid=1000(ziflex) groups=1000(ziflex),4(adm),24(cdrom),27(sudo),29(audio),30(dip),46(plugdev),108(lpadmin),124(sambashare)
Prerequisites (dynamic at run-time)...
gcc ............... gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
g++ ............... g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
PyQt4 (by pyuic4) . Python User Interface Compiler 4.10 for Qt version 4.8.4
jackd ............. no message buffer overruns
path ............ /usr/bin/jackd
flags ........... -ljack
libraw1394 ........ 2.0.9
flags ........... -lraw1394
libavc1394 ........ 0.5.4
flags ........... -lavc1394 -lrom1394 -lraw1394
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.34.2
flags ........... -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0
dbus-1 ............ 1.6.8
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -ldbus-1
Prerequisites (static at compile-time)...
gcc ............... gcc (Ubuntu/Linaro 4.7.2-20ubuntu1) 4.7.2
g++ ............... g++ (Ubuntu/Linaro 4.7.2-20ubuntu1) 4.7.2
PyQt4 (by pyuic4) . Python User Interface Compiler 4.9.6 for Qt version 4.8.3
jackd ............. sh: 1: jackd: not found
path ............
flags ........... Package jack was not found in the pkg-config search path.
libraw1394 ........ 2.0.9
flags ........... -lraw1394
libavc1394 ........ Package libavc1394 was not found in the pkg-config search path.
flags ........... Package libavc1394 was not found in the pkg-config search path.
libiec61883 ....... 1.2.0
flags ........... -liec61883 -lraw1394
libxml++-2.6 ...... 2.34.2
flags ........... -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0
dbus-1 ............ 1.6.8
flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -ldbus-1
uname -a...
Linux zmachine 3.8.0-29-generic #42-Ubuntu SMP Tue Aug 13 19:40:39 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Host controllers:
03:00.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403] (rev 01) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. VT6315 Series Firewire Controller [1106:3403]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: firewire_ohci

CPU info:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 23
Stepping: 10
CPU MHz: 1600.000
BogoMIPS: 5866.46
L1d cache: 32K
L1i cache: 32K
L2 cache: 3072K
NUMA node0 CPU(s): 0,1
IRQ information
Hardware Interrupts:
IRQ 0: PID: None, count: [46, 0], Sched None (priority None), drivers: ['timer']
IRQ 1: PID: None, count: [3, 1], Sched None (priority None), drivers: ['i8042']
IRQ 7: PID: None, count: [0, 0], Sched None (priority None), drivers: ['parport0']
IRQ 8: PID: None, count: [1, 0], Sched None (priority None), drivers: ['rtc0']
IRQ 9: PID: None, count: [0, 0], Sched None (priority None), drivers: ['acpi']
IRQ 12: PID: None, count: [5, 2], Sched None (priority None), drivers: ['i8042']
IRQ 16: PID: None, count: [53730, 52891], Sched None (priority None), drivers: ['uhci_hcd:usb3', 'pata_jmicron', 'nvidia']
IRQ 17: PID: None, count: [201, 209], Sched None (priority None), drivers: ['snd_hda_intel']
IRQ 18: PID: None, count: [5030, 5101], Sched None (priority None), drivers: ['ehci_hcd:usb1', 'uhci_hcd:usb5', 'uhci_hcd:usb8']
IRQ 19: PID: None, count: [416510, 418086], Sched None (priority None), drivers: ['uhci_hcd:usb7', 'firewire_ohci']
IRQ 21: PID: None, count: [162299, 157813], Sched None (priority None), drivers: ['uhci_hcd:usb4']
IRQ 23: PID: None, count: [1777, 1210], Sched None (priority None), drivers: ['ehci_hcd:usb2', 'uhci_hcd:usb6']
IRQ 45: PID: None, count: [90813, 50671], Sched None (priority None), drivers: ['ahci']
IRQ 46: PID: None, count: [748596, 126], Sched None (priority None), drivers: ['eth0']

Software Interrupts:

=== REPORT ===
FireWire kernel drivers:

The new FireWire kernel stack is loaded.
If running a kernel earlier than 2.6.37 and problems are experienced, either
try with the old Firewire kernel stack or upgrade to a newer kernel
(preferrably 2.6.37 or later).

Please help :)

I have a few comments and thoughts.

The first thing I note is that your system is running a generic kernel - one which is neither configured for low latency operation (PREEMPT) or has received the so-called realtime patch. For most people the latter is not necessary, but a PREEMPT kernel generally is. The Ubuntu repository has a low latency / preempt kernel available. Please install this on your system and test again. This is probably the most important thing to try. Let us know if you need more information about this.

If problems persist, please post the jackd command line you are using or a summary of the jackd options you have set in qjackctl (depending on how you start jackd). To reduce the stress on your system while getting things working initially, I suggest you specify a buffer size of 512 and the number of buffers as 3 (on the command line this would amount to "-p 512 -n 3"). Also, jackd is running at a rather low priority - 10 according to your log. It would be worth trying a number of the order of 70 if things continue to fail.

I note that your system uses the proprietary nvidia video driver. This has been known to cause performance trouble for latency-sensitive applications like FFADO. For now I'll simply note this; if we cannot get things working through other means this might be something to revisit later. Also, your firewire interface shares an interrupt with a USB host controller, which can sometimes cause problems. Again, we'll just note this for now.

To summarise these suggestions, here is the jackd command line I tend to suggest that people use initially:

jackd -P70 -R -dfirewire -p512 -n3

This produces moderate latency, but that can be optimised later if it's critical in your application. The most important thing at this stage is to get something working.

Thanks for so fast replying!
Unfortunately, I'm not very experienced in Linux. Could you explain what should I do to.. change kernel? Is it possible without re-installing the system? I've installed the packages from Ubuntu Studio (I thought to migrate from vanilla Ubuntu to Ubuntu Studio), this link (https://help.ubuntu.com/community/Ubuntu%20Studio%20Upgrade%20from%20Ubuntu) says that there is a 'real-time kernel for low latency' (but kernel version wasn't changed). So, I guess I should solve the problem with kernel firstly. But I need help with it.
Thanks advance!

P.s. Also, I'm still considering the possibility for migration to Ubuntu Studio. They say that it doesn't have such problems with compatibility.

To answer your question: yes, it is possible to do this without reinstalling the system. A suitable kernel should be available from amongst the standard packages available from Ubuntu or Ubuntu Studio. The "real-time kernel for low latency" that you found mentioned at the link you gave is exactly the package you need. If you install this in the usual way and then reboot you should find yourself running a kernel which includes the string PREEMPT when you run "uname -a" in a terminal window (this is what proves you have the right kernel running).

It is fine that it's the same kernel version as the one you have. The difference is in the options that are activated within it.

I don't have any personal experience with Ubuntu myself so my ability to offer specific instructions is limited. Can you work out a way to install this package using the package manager? If not I'll try to find someone on our mailing lists who might be able to help. Please let me know.

Finally, based on what I've read it is also my understanding that Ubuntu and Ubuntu Studio are more or less compatible.