RME driver progress

  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.
  • warning: Creating default object from empty value in /home/ffado/ffado.org/modules/spam/spam.module on line 488.

After far too many delays (both technical and logistical,for which I apologise), practical progress has finally been made on the FFADO RME driver.

In short, the driver is now ready for wider testing, although there are some important limitations and cautions to keep in mind before proceeding. Read more for the details.

  • If a non-zero verbose level is selected using the "-v" option, a 0 dBFS 1 kHz sine wave will be output on the left phones channel. This is to facilitate debugging of audio timing. If you have headphones or monitors connected to the phones output, please do not activate verbose debug mode without taking appropriate precautions.
  • The level produced from the phones (aka monitor) output is very high from this device and the front panel "ph" level control does not affect the level being sent by the computer. Use headphones with extreme caution to prevent inadvertent hearing damage, especially during initial testing and/or if no software volume control is in operation.
  • You will need the latest subversion snapshot of FFADO.
  • Ffado-mixer support is still rather limited and contains only a small number of controls (now the streaming system seems to be working I expect to expand this soon). In particular there is no user access to the onboard mixer controls: however, ffado sets these to a 1-1 mapping which should do for testing.
  • Meaningful testing is probably limited to the Fireface400 for the moment since that is the interface I have been testing with. I will test with with a FF800 in due course - most likely after I've got a more complete ffado-mixer working for the ff400. In the meantime, it is almost certain that the driver will not run with a FF800 yet.
  • I've been testing exclusively with jack1 and the old kernel firewire stack. In theory jack2 should work just as well, but I have seen reports over the last couple of weeks which suggests that there may be a problem with ffado in the latest jack2. YMMV. Similarly the new kernel stack should work but I have not personally tried this yet.

To provide feedback on your experiences please subscribe to ffado-devel and post your findings there initially. If extended discussion is required we can take things off-list if appropriate.

My testing to date has been mostly with 48k and 44.1k rates. I have fired 96k and 192k up and had them work for short periods of time so hopefully that's a good sign. Finally, for initial tests it is probably wise to stick with fairly large latencies: I've been using "-p 1024" and "-n 4" options when starting ffado via jackd.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

problems with qutecsound

Hi JW,
whena I launch "play" with an exampole file of qutecsound nothimg happens.
In the message window of qtljack appears:
"Tue Jul 31 01:23:19 2012: New client 'csound-tmpTTwZ58' with PID 5893
Tue Jul 31 01:23:19 2012: Client 'csound-tmpTTwZ58' with PID 5893 is out"
And nothing more happens

????????????????

Re: problems with qutecsound

I must admit that I'm completely unfamiliar with qutecsound or csound itself. Since other jack-enabled applications are able to playback my guess is that there's something that qutecsound or csound is not doing. For example, there may be a need to manually connect csound jack ports to the playback ports of the RME provided by jack/ffado. If this hasn't been done the csound output isn't being sent to the RME and therefore no output will be heard. Another option is that csound is not using jack by default and needs to be told to do so.

Having a look at http://www.csounds.com/manual/html/UsingRealTime.html, it seems that something like this might be going on. Scroll down to the section "Using jack" (near the bottom of the page, about five sixths the way down). Here it says that the default action is not to connect csound output ports to anything so this will need to be done manually or via something which automatically handles such things (a jack session manager, or perhaps qjackctl if configured to do so). It also shows that there's a need to explicitly request that csound use jack (the default is to use something else - portaudio I think, but I haven't read the document closely so I might have mis-interpreted it).

Presonus Studiolive 1642 Working

Got Presonus StudioLive 1642 working!

Thank you, for your excellent work!

- Koivukoski1

Re: Presonus Studiolive 1642 Working

Thanks for the report.

Fairly obviously this isn't related to RME progress. However, until now we haven't had a device entry for the Presonus Studiolive 1642. I've now created one at http://www.ffado.org/?q=node/2488. If you have the time, it would help other users in future if you could post details of what you had to do onto this new device page. Even if everything worked "out the box" (so to speak), saying this will help other users to know that things can be made to work. Noting the FFADO version would also be worthwhile.

where is the driver for rme fireface 400?

Help?
Where can I find the driver for RME Fireface 400?

I am also wondering about

I am also wondering about this, pardon for this is not my forte. But any help would be appreciated. Thanks

Re: I am also wondering about (FF400)

The driver for the Fireface 400 (and Fireface 800) is included in FFADO version 2.1.0. Things required by a majority of users are supported: all device controls should be usable via ffado-mixer and audio streaming works. Things still to be done which are relevant to the FF400 and FF800 are MIDI I/O and the storage of device configuration to NV RAM (the latter is being worked on now). In addition, the TCO option for the FF800 is still to be done.

Fireface 800 Status

How far off are we yet for basic testing? Do you need help coding for this device? Took a look at dev and tracker just to see what is up. Thanks for the huge effort you have put into this project!

Dominic

Re: Fireface 800 Status

Unfortunately, due to a number of real-life issues unrelated to ffado I have not had the time I expected to have for ffado over the past 6 months. I've been able to assist in the debugging of a few important higher-level ffado issues, but larger-scale things have not been possible.

The status of the code with the ff800 is that it is yet to be tested with that device. The driver as written should be capable of driving the ff800, but as with anything like this there are always a few issues to sort out during debugging. People are certainly free to try their ff800 with the existing driver to see what happens. While the same driver is starting to work acceptably with the ff400, the ff800 does differ from the fff400 in several important ways at the hardware level (which you can notice due to the presence of various ff800 optional branches in the code, for example). This is why it really has to be debugged. There should not be much in the way of code which needs to be written from scratch at present.

At the start of this year my initial plan (after getting audio streaming working with the ff400) was to get some sort of rudimentary support for the ff400 mixer happening. Again, there's little in the way of coding needed for this - it's more "handle cranking" sort of work. Then I was going to start on bringing the driver up for the ff800. Clearly that isn't how the year has turned out - and I'm as disappointed as anyone else with this.

Having said all that, I really do want to start making some more progress on this soon, and I'm hopeful that circumstances are going to let this happen over the next few months. My tentative plan is probably along the lines of what I outlined above, but I may at least do some initial debugging on the audio side of the ff800 sooner, if for no other reason than to prove that things are coming together.

As you may have read elsewhere on the ffado site, the ff400 entered the "basic testing" phase earlier this year.

So to directly answer your question, I can't give any ETAs on the "basic testing" of the ff800. Until I've brought the interface up there's probably not a lot of scope for external help since I can't pass the device documentation on (even then, most of the code is already in place, notwithstanding bugs which need to be discovered and fixed). This bottleneck is one of the reasons I may bring the "basic testing" of the ff800 forward, so others at least can start doing something with the interface and provide feedback, suggestions and so on.

Thanks for checking back regarding the status of the ff800, and I an very sorry that I haven't been able to provide anything in the way of positive news. I am however very much aware that many are waiting for the ff800 to come up under ffado, and I want to reward your patience as soon as I possibly can.

Thanks for the update mate

Thanks for the update mate on this driver.i was looking for some news on FFADO RME driver from last few weeks and here i have.where can i get the latest subversion snapshot of FFADO from?

  • Should you wish to bet online then this pokies online gives you most of the perfect casino site games that you have been searching for.

Re: Thanks for the update mate (RME driver)

Thanks for your interest in ffado. Download and compilation instructions can be found at http://subversion.ffado.org/wiki/InstallingFfadoFromSource. You will want "trunk".

Let us know if any clarifications are required, either through a post here or in one of the mailing lists (ffado-users or ffado-devel).

ff800 testing

I have fired up the ff800 and did some initial testing. Here is what I am using:

dominic@dominicLT:~$ jackd -d firewire -d hw:0
jackd 0.121.2
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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

JACK compiled with System V SHM support.
loading driver ..
libffado 2.999.0- built Oct 14 2011 17:40:28
139162918746: Error (bebob_avdevice.cpp)[ 96] probe: Number of channels command failed
139163726223: Error (avc_avdevice.cpp)[ 89] probe: Subunit info command failed
firewire ERR: Error creating FFADO streaming device
cannot load driver module firewire
no message buffer overruns

I am using ffado revision 1999. Could not compile jack from source because I keep getting an error that libtool does not recognize libjackserver.la as an acceptable archive. So I went looking for packages precompiled and that is what you see above.

Is that a new enough trunk revision?

Also tried ffado-bridgeco-downloader this is the output:

BridgeCo BeBoB platform firmware downloader
Part of the FFADO project -- www.ffado.org
Version: 2.999.0-
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

Node id GUID Vendor - Model
0 0x000a35002e22c7bf '' - ''
139627361780: Error (configrom.cpp)[ 150] initialize: Could not parse config rom of node 1 on port 0
no message buffer overruns

I do not know if this is a bridgeco device so this might be unhelpful. Let me know next steps and I can continue to test.

Let me know,

Dominic

Re: ff800 testing

Here's a brief update for those following along at home. Having reached a point where the ff400 mostly works, I have now fired up the ff800 with ffado. Somewhat surprisingly, most of the controls in ffado-mixer worked straight away. A few minor tweaks and the addition of functionality behind the ff800-specific controls and ffado-mixer was "go" for the ff800. Not unexpectedly, audio streaming did not work straight away due to the inevitable bugs. I was able to address them fairly quickly, with the result that I can now send audio to the ff800 and capture audio from the ff800 using ffado. To replicate this with a ff800 you'll need svn r2062 or later.

dkudos: based on the earlier posts there's still an unresolved issue on your system which is preventing ffado from accessing the firewire device. This prevents device discovery from working and therefore it's not possible for ffado to do anything with the device (it can't even get to the point of determining what sort of device it is). Obviously this problem needs to be rectified before the rme driver will get a chance to run.

Re: ff800 testing

Hi Dominic

For some reason your original post on 7 Nov 2011 got flagged as spam which is why I have only just seen it. I have now unflagged it. :-)

First up, to clarify something you asked, the RME fireface devices do not incorporate Bridgeco components and thus don't use the Bebob driver or respond to any AVC commands. Instead they have implemented their own firewire interface which is why a custom driver is required. There is no way an RME device will work with the standard AVC driver used by Bebob interfaces (or with the bridgeco firmware downloader either for that matter).

For the purposes of initial testing, rev 1999 should be sufficent. As noted elsewhere though, the ff800 code in the FFADO driver has had no testing by me yet so the chances of it working are fairly small. FYI I am trying to finish off an initial mixer implementation for the ff400 before plugging the ff800 in and moving onto that.

The reference to the bebob driver in your output could well have been due to ffado's device probing. During startup ffado will probe for the device type, which usually involves an attempt to access the device with a device-specific command. The RME interfaces - not being bebob - will not respond to any bebob probe commands, and this probably explains the bebob and AVC errors you saw. At least in principle there's probably nothing to worry about here.

Having said that, it's curious that at some later stage there was no obvious attempt to use the RME driver. There is probably a good reason for this: by default, compilation of the RME driver is disabled at present (mostly because it's not yet ready for general use). Therefore the overall failure in your case is possibly due to the lack of an RME driver in your ffado build. To rectify this, add

ENABLE_RME=yes

to your scons command. Install the result and try testing again. To see if this might be your issue, run "scons --help" and look for the "ENABLE_RME" report in the output. The currently active setting will be described on the line beginning with "actual:".

Although it's probably unrelated, having never investigated the "-d hw:0" firewire driver option I have no idea what this is meant to do or why you might have had a need to include it on your jackd command line. Can you provide some additional information about this - in particular, why you needed to specify it. At least theoretically all you should have needed to do is something like

jackd -d firewire

and at least have it use the correct driver.

During these initial tests, it is probably a good idea to enable at least some level of debug output so we can better track what's going on in your case. This is done using the "-v" option after the "-d firewire" jackd parameter. For example:

jackd -d firewire -v 6

If things still don't appear to be doing what you expect after confirming that the RME driver is enabled on your ffado build, the next step would be to run jackd as described above (ie: with "-v 6") and post the output here or on ffado-devel so I can have a look and see what might be happening.

Regards

jonathan

ff800 testing

I have posted two previous posts only use the first one. But in short the ff800 is recognized by ffado.

Succsess!

I will continue to test.

More ff800 testing

Here is what I get from initial testing:

Jack 0.121.3

ACK compiled with System V SHM support.
loading driver ..
Cannot create thread 1 Operation not permitted
ERROR: messagebuffer not initialized: 00755937676: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0-2009 built Dec 4 2011 17:22:40
ERROR: messagebuffer not initialized: 00755937781: Debug (Element.cpp)[ 129] setVerboseLevel: Setting verbose level to 6...
ERROR: messagebuffer not initialized: 00755937791: Debug (StreamProcessorManager.cpp)[1570] setVerboseLevel: Setting verbose level to 6...
ERROR: messagebuffer not initialized: 00755937803: Debug (devicemanager.cpp)[1247] setVerboseLevel: Setting verbose level to 6...
ERROR: messagebuffer not initialized: 00755937811: Warning (ffado.cpp)[ 121] ffado_streaming_init: Realtime scheduling is not enabled. This will cause significant reliability issues.
ERROR: messagebuffer not initialized: 00755937826: Debug (DeviceStringParser.cpp)[ 284] isValidString: isvalid? hw:0
ERROR: messagebuffer not initialized: 00755937842: Debug (devicemanager.cpp)[ 233] addSpecString: Adding spec string hw:0
ERROR: messagebuffer not initialized: 00755937850: Debug (DeviceStringParser.cpp)[ 253] parseString: parse: hw:0
ERROR: messagebuffer not initialized: 00755937856: Debug (DeviceStringParser.cpp)[ 258] parseString: left: hw:0
ERROR: messagebuffer not initialized: 00755937864: Debug (DeviceStringParser.cpp)[ 56] parse: parse: hw:0
ERROR: messagebuffer not initialized: 00755937882: Debug (ffado.cpp)[ 148] ffado_streaming_init: setting slave mode to 0
ERROR: messagebuffer not initialized: 00755937896: Debug (ffado.cpp)[ 154] ffado_streaming_init: setting snoop mode to 0
ERROR: messagebuffer not initialized: 00755938014: Debug (Configuration.cpp)[ 63] openFile: Could not open file: ~/.ffado/configuration
ERROR: messagebuffer not initialized: 00755956147: Fatal (devicemanager.cpp)[ 191] initialize: No firewire adapters (ports) found.
ERROR: messagebuffer not initialized: 00755956179: Fatal (ffado.cpp)[ 160] ffado_streaming_init: Could not initialize device manager
ERROR: messagebuffer not initialized: 00755956194: Debug (Configuration.cpp)[ 138] save: Not saving temporary config file: temporary
ERROR: messagebuffer not initialized: 00755956205: Debug (Configuration.cpp)[ 135] save: Not saving readonly config file: /usr/share/libffado/configuration
firewire ERR: Error creating FFADO streaming device
cannot load driver module firewire

What do you think?

dk

Re: More ff800 testing

The output presented confirms that you are running a recent version of FFADO (which is good) and that debug information is enabled (that's also good).

However, this latest test isn't getting far enough into the initialisation phase to determine what type of interface you have. The line

Fatal (devicemanager.cpp)[ 191] initialize: No firewire adapters (ports) found.

means that FFADO could not read from any firewire adapters in your machine. Being unable to access the firewire card itself there's no way for it to communicate with any devices which might be plugged into the card - be they a ff800 or anything else.

Undoubtedly you have a firewire card in your system, so the problem is probably associated with the permissions of the /dev/fw0 device file. Having permissions on this which prevent your user from reading and writing to this is the usual cause of this kind of failure. What's marginally puzzling is that your previous output - while seemingly not a full debug build - did seem to be getting as far as reading from the interface. That means that it used to be able to read from /dev/fw0. Why it would not be able to now is a bit of a mystery.

You can confirm whether it's a permission issue by doing

ls -l /dev/fw*

This will note the permissions along with the owner/group. The command

id

will tell you what groups your user is a member of. If the group of /dev/fw0 is not one of those you are a member of or its permissions do not permit group read/write access then this is most likely your problem. There are numerous approaches to fixing this but they depend on what exactly the problem is. If you need help in working though this perhaps post the output of the two commands above (the "ls" and "id" commands) and we'll take it from there.

fireface400

Hooray it works!!
(Basically) Having compiled and installed the latest ffado snapshot from source, I've been trying out my fireface 400 in PD using 8 ins and outs, audio at 44100k and a 15ms delay setting. Jack is set to 512 frames/period, 3 period/buffers, giving me an overall latency of 34.8ms
Seems to work well, although sometimes the sound goes all metallic. Restarting the PD program seems to sort it out though.
If I have more problems I'll post again.
Thanks so much for all the work you have put in on this, lots of frustrated RME customers can now consider shifting to Linux. Looking forward to implementation of the mixer controls! Nick

where is the driver for rme fireface 400?

Please, can you tell me how you did to install rme FF400?
Help!

Re: where is the driver for rme fireface 400?

The instructions for doing so vary according to the Linux distribution you are running. It would be helpful if you could post some basic information about your system so that relevant suggestions can be provided. A good starting point is the name and version of the distribution you're using.

Speaking generically the steps involve the following. Some of these points are expanded on our website at http://subversion.ffado.org/wiki/InstallingFfadoFromSource.

  • At this point you need to obtain the current svn snapshot of FFADO. The last release (2.0.1) is not sufficiently recent.
  • Some distributions package a sufficiently recent FFADO snapshot in their unstable or development repositories. If that's the case you should be able to simply upgrade to this using your usual package manager functionality. Otherwise you'll have to get the source code out of svn and compile it.
  • Once FFADO has been installed you may have to recompile JACK as well. It depends on your distribution and what options they have used when compiling the JACK package.

Further details can be provided once we understand the nature of your system.

I'm afraid I have to give up

Dear jwoithe, I'm afraid I have to give up!
I'm so angry that ff 400 works fine only with MAC, but this is the tragic truth!
I've been trying a lot of attempts, as recompiling the file limits.conf by adding

# grant real-time privileges to members of group "audio"
@audio - rtprio 99
@audio - memlock unlimited
@audio - nice -10

every attempt I tried by terminal to open jackd I had the following answer

jackdmp 1.9.8
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2011 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
JACK server starting in realtime mode with priority 10
libffado 2.999.0- built Feb 17 2012 15:52:28
04490089257: Error (bebob_avdevice.cpp)[ 96] probe: Number of channels command failed
04498122208: Error (avc_avdevice.cpp)[ 89] probe: Subunit info command failed
firewire ERR: FFADO: Error creating virtual device
Cannot attach audio driver
JackServer::Open() failed with -1
Failed to open server

Unfortunately I'm more a musician then a programmer.
For all the other stuff (also using all the audio software with ALSA driver with the internal audio device of the pc) Ubuntu is very user friendly, but not for this terrible issue!!!
I'm afraid I will have to give up.
Thanks a lot
Luca Margoni

Re: I'm afraid I have to give up

Luca: I'm sorry to read that you couldn't get things working. Hopefully once we make the upcoming 2.1 release and this gets into the distributions it will be easier for people without programming backgrounds to access. While it would be nice to make these things move quicker, there's a limit to what we can do as a small group of volunteers.

As a closing comment in relation to the messages from jackdmp that you posted, something doesn't add up. The FF400 is not a BeBoB device and ffado will not attempt to use the bebob driver for it - and yet in your case we're getting errors from the bebob driver. Having written that, perhaps it's a probing thing. My only other suspicion is that maybe the RME driver wasn't enabled when you compiled ffado back on 17 Feb 2012 (this is done by adding "ENABLE_RME=yes" to the "scons" command line). I'll add that as of a few weeks ago the RME driver is enabled by default.

In any case, thanks for giving it a go. Hopefully in future we'll improve the setup of these devices so they do just work for most people out of the box.

scons-ff 400

Dear jwoithe,
could you write me precisely what I have to do to write "ENABLE_RME=yes"?
Should I write it in the terminal line?
What is the exact line I have to compile?
Thanks a lot

Re: scons-ff 400

I will assume that you have downloaded the latest subversion snapshot, and that the toplevel libffado directory is the current directory in your shell. There is information about downloading the subversion snapshot at http://subversion.ffado.org/wiki/DownloadFfadoSource, in the section "Downloading from SVN", subsection "trunk". Let me know if you need more details on these steps.

If you have revision 2152 or later from svn you don't need to do anything special to enable RME support: it will be done for you by default. In this case, typing

scons

into the terminal should be all that's needed to compile FFADO. If for some reason you're compiling an earlier revision, you would enable RME support using this in your terminal to compile FFADO:

scons ENABLE_RME=yes

Note too that scons remembers the options you use, so it's only necessary to include the "ENABLE_RME=yes" when you compile the source tree for the first time.

Once compilation has completed you then need to install it on the system: "scons install" is the applicable command in this case.

I should note that if you are compiling FFADO to replace a version of FFADO supplied by your distribution you will most likely want to include "PREFIX=/usr" on your scons line, like this:

scons ENABLE_RME=yes PREFIX=/usr

This will effectively cause the new version of FFADO to be installed over the top of the old one provided by your distribution. There's some comments about this on our wiki at http://subversion.ffado.org/wiki/AvoidingParallelInstallations. If your distribution provided a version of FFADO there should be no need to recompile jack; jack will just use whatever FFADO it finds on the system when it's run.

The above is a brief description of the processes concerned. Please let me know if you need additional details about any of these steps.

scons

Dear Jonathan,
if I write

scons

the answer is

scons: *** No SConstruct file found.
File "/usr/lib/scons/SCons/Script/Main.py", line 904, in _main

and this happen even if I write

scons ENABLE_RME=YES

Last question:
when you tipe "PREFIX=/usr" do you mean that must be written exactly as you do or that, for example, I should type my user name?
Thanks a lot

scons-ff 400 II

Dear Jwoithe,
if I write:
"scons ENABLE_RME=yes"

the answer is

"scons: *** No SConstruct file found.
File "/usr/lib/scons/SCons/Script/Main.py", line 904, in _main"

While if I write

"scons ENABLE_RME=yes PREFIX=/usr"

the tragic answer is

"scons: *** No SConstruct file found.
File "/usr/lib/scons/SCons/Script/Main.py", line 904, in _main

The only answer I have is when I write

scons -h

and it is

"usage: scons [OPTION] [TARGET] ...

SCons Options:
-b, -d, -e, -m, -S, -t, -w, --environment-overrides, --no-keep-going,
--no-print-directory, --print-directory, --stop, --touch
Ignored for compatibility.
-c, --clean, --remove Remove specified targets and dependencies.
-C DIR, --directory=DIR Change to DIR before doing anything.
--cache-debug=FILE Print CacheDir debug info to FILE.
--cache-disable, --no-cache
Do not retrieve built targets from CacheDir.
--cache-force, --cache-populate
Copy already-built targets into the CacheDir.
--cache-show Print build actions for files from CacheDir.
--config=MODE Controls Configure subsystem: auto, force,
cache.
-D Search up directory tree for SConstruct,
build all Default() targets.
--debug=TYPE Print various types of debugging information:
count, duplicate, explain, findlibs, includes,
memoizer, memory, objects, pdb, prepare,
presub, stacktrace, time, dtree, tree, stree,
nomemoizer.
--diskcheck=TYPE Enable specific on-disk checks.
--duplicate=DUPLICATE Set the preferred duplication methods. Must be
one of hard-soft-copy, soft-hard-copy,
hard-copy, soft-copy, copy
-f FILE, --file=FILE, --makefile=FILE, --sconstruct=FILE
Read FILE as the top-level SConstruct file.
-h, --help Print defined help message, or this one.
-H, --help-options Print this message and exit.
-i, --ignore-errors Ignore errors from build actions.
-I DIR, --include-dir=DIR Search DIR for imported Python modules.
--implicit-cache Cache implicit dependencies
--implicit-deps-changed Ignore cached implicit dependencies.
--implicit-deps-unchanged Ignore changes in implicit dependencies.
--interact, --interactive Run in interactive mode.
-j N, --jobs=N Allow N jobs at once.
-k, --keep-going Keep going when a target can't be made.
--max-drift=N Set maximum system clock drift to N seconds.
--md5-chunksize=N Set chunk-size for MD5 signature computation to
N kilobytes.
-n, --no-exec, --just-print, --dry-run, --recon
Don't build; just print commands.
--no-site-dir Don't search or use the usual site_scons dir.
--profile=FILE Profile SCons and put results in FILE.
-q, --question Don't build; exit status says if up to date.
-Q Suppress "Reading/Building" progress messages.
--random Build dependencies in random order.
-s, --silent, --quiet Don't print commands.
--site-dir=DIR Use DIR instead of the usual site_scons dir.
--stack-size=N Set the stack size of the threads used to run
jobs to N kilobytes.
--taskmastertrace=FILE Trace Node evaluation to FILE.
--tree=OPTIONS Print a dependency tree in various formats: all,
derived, prune, status.
-u, --up, --search-up Search up directory tree for SConstruct,
build targets at or below current directory.
-U Search up directory tree for SConstruct,
build Default() targets from local SConscript.
-v, --version Print the SCons version number and exit.
--warn=WARNING-SPEC, --warning=WARNING-SPEC
Enable or disable warnings.
-Y REPOSITORY, --repository=REPOSITORY, --srcdir=REPOSITORY
Search REPOSITORY for source and target files."

Re: scons-ff 400 II

Apologies for the delayed response. For some reason this last reply of yours got tagged as spam.

scons: *** No SConstruct file found.

Hmm. That would indicate that you're running scons from somewhere other than the top-level directory of the FFADO source tree. After checking out the source code with svn you'll have a newly created directory called libffado - that contains the checked out source for FFADO. You would need to do "cd libffado" prior to running scons.

If this doesn't make sense, perhaps briefly outline to me the steps you did before attempting to run scons and I'll try to determine what might have gone wrong.

libffado dir

Dear Jonathan

this is the result of the new instructions you gave me.

strumento@strumento-X51L:~/libffado-2.0.0$ scons
scons: Reading SConscript files ...

scons: warning: The Options class is deprecated; use the Variables class instead.
File "/home/strumento/libffado-2.0.0/SConstruct", line 38, in

scons: warning: The BoolOption() function is deprecated; use the BoolVariable() function instead.
File "/home/strumento/libffado-2.0.0/SConstruct", line 43, in

scons: warning: The PathOption() function is deprecated; use the PathVariable() function instead.
File "/home/strumento/libffado-2.0.0/SConstruct", line 45, in

scons: warning: The EnumOption() function is deprecated; use the EnumVariable() function instead.
File "/home/strumento/libffado-2.0.0/SConstruct", line 65, in
Checking for a working C-compiler yes
Checking for a working C++-compiler yes
Checking for pkg-config (at least version 0.0.0)... yes
Checking for C header file expat.h... no
Checking for XML_ExpatVersion() in C library expat... no
Checking for libraw1394 (1.3.0 or higher)... yes
Checking for dbus-1 (1.0 or higher)... no
Checking for libxml++-2.6 (2.13.0 or higher)... no
Checking for libiec61883 (1.1.0 or higher)... no

(At least) One of the dependencies is missing. I can't go on without it, please
install the needed packages for each of the lines saying "no".
(Remember to also install the *-devel packages!)

And remember to remove the cache with "rm -Rf .sconsign.dblite cache" so the
results above get rechecked.

IT'S BECOMING A NIGHTMARE!

Thank you for your patience

Re: libffado dir

Hi Luca

Thanks for posting the scons output. It shows a number of things.

Firstly, and most importantly, it seems that you're compiling libffado version 2.0.0 (based on the name of the directory). If true, this is a very old version of FFADO - so old in fact that it doesn't include the RME driver at all. To gain access to the RME driver you will need to obtain the latest development version of FFADO. This is done using a program called subversion (svn), which fetches the latest source code from the project repository. This is described on http://subversion.ffado.org/wiki/DownloadFfadoSource, under the "Downloading from SVN" section. Please let me know if you require more information.

Assuming this issue can be resolved, the next point to note is that you'll want to include "PREFIX=/usr" in your scons command. Effectively this will cause FFADO to be installed over the top of your existing FFADO. In theory this prevents you having two incompatible versions of FFADO installed on the same system.

All the "Checking for ... no" lines are indicating that the so-called "devel" packages of the respective libraries are not installed on your system. Libraries usually have two packages associated with them: one which delivers the library itself (allowing you to run programs which use the library) and the "development" package (often abbreviated to "devel". The "devel" package contains additional files required if you wish to compile programs which use the libraries. So (to take one example), to compile FFADO you need both the libraw1394 package and the libraw1394-devel package to be installed on your system.

I am curious to know the name and version number of the distribution you're using.

Finally, it's probably worth noting that we're hoping to do a version 2.1 release in the next couple of months. When that's done, the latest code will be available from the standard package repositories of major distributions. This will mean that there will be no need for prospective users to compile the latest code to gain access to the new features added since FFADO 2.0.x (assuming that a sufficiently distribution is being run). There's no firm time on this, but I'm hoping we can clear the last few bugs reasonably quickly.

Re: News02

I think you're getting very close to having this work. Thanks for all the information you've posted.

From your first email in this latest block:

after I created the directory and launched "scons PREFIX=/usr" appeared to me a huge series of lines like this:
g++ -o src/libstreaming/amdtp/AmdtpPort.os -c -Wall -g -m32 -fPIC -DDEBUG -DENABLE_BEBOB ...

These lines are describing the commands being run to compile the various modules which make up FFADO. In essence they prove that you're compiling FFADO.

Next up, it's good to see that ffado-mixer is doing something. I don't think it's the latest version because I see lines like the following during your compilation step:

I couldn't find all the prerequisites ('pyuic4' and the python-modules 'dbus'
and 'PyQt4', the packages could be named like dbus-python and PyQt) to build
the mixer.
Therefor the qt4 mixer will not get installed.

What I think is happening is that ffado-mixer from the previously installed ffado is not getting overwritten by this new version because the new version can't be built. Therefore "ffado-mixer" is available even though the new FFADO was unable to compile it. The way to fix this is to install the packages required by ffado-mixer. Since one version of ffado-mixer evidently works it would seem that the runtime packages are installed: what's probably missing are the "development" packages. The easiest way to proceed here is to check your distribution's package repository for package names like dbus-python-dev and PyQt-dev. Once these are installed I expect ffado-mixer to be built. Obviously this is of marginal concern at present since the ffado-mixer you have on your system - coupled with the latest version of ffado underneath - appears to work, at least to a point.

As I think I've mentioned earlier, the *-dev packages contain additional files needed to support compilation of programs which use the respective packages; the plain non-dev packages themselves are adequate if all you want to do is run programs. The development packages may be named *-dev or *-devel or some other variation, depending on the convention adopted by your distribution.

Now onto the issue with jack. During scons's startup we see this:

Checking for jack >= 0.0.0... (cached) no
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) no

No jack installed: assuming a FFADO setbuffersize-compatible version will be
used.

Now clearly you have jack installed on your system, so the problem again is most likely due to the lack of a jack-dev package having been installed. So if you obtain and install a jack-dev package I expect the underlying problem to go away: scons will then correctly detect the version of jack on your system and build itself to suit. As it stands now, scons is assuming a newer version of jack will be installed, and this is why you get "firewire ERR: Incompatible libffado version! (libffado 2.999.0-2175)" when you try to run jack.

There is another alternative which might be easier though. If you add "ENABLE_SETBUFFERSIZE_API_VER=false" to your scons command, FFADO will be built to be compatible with the version of jack which is on your system (don't forget to run "scons install" to install the newly compiled version after compilation finishes). I think this is the best thing to do at present, unless finding and installing the jack-dev package is trivial. I certainly don't think that attempting an upgrade of jackd is worthwhile at this stage - let's try to keep things as simple as possible. :-)

Going on

Dear Jonathan, in my repository (I think you mean Synaptic, right?) there aren't jack-dev anymore than those I have already installed.
The only thing I see is that if I install jackd1- firewire he installs it and at the same time he unistalls jackd2-firewire and vice-versa.
Other issues:
I launched "ENABLE_SETBUFFERSIZE_API_VER=false" and then "scons install", but he always says me, as usual:

"Checking for jack >= 0.0.0... (cached) no
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) no"
and says me also;
"
scons: `install' is up to date."
Another issue:
if I write
"svn update"
the answer is:
"WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-FNdlRL/pkcs11: File o directory non esistente [means not existing]
Alla revisione 2175."
So it seems to me that it doesn't allow me to update libffado.
Last issue is the message tha now appears when I launch qjackctl with the options "firewire" and "jack".
"16:06:42.909 Patchbay disattivato.
16:06:42.910 Resetta le statistiche.
16:06:42.921 Connessioni di ALSA cambiate.
16:06:42.940 D-BUS: Servizio disponibile (org.jackaudio.service aka jackdbus).
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server socket
jack server is not running or cannot be started
16:06:42.954 Cambiamento nel grafico delle connessioni di ALSA.
16:06:45.008 D-BUS: il server JACK non può essere avviato. Mi dispiace
Wed Jul 4 16:06:44 2012: Starting jack server...
Wed Jul 4 16:06:44 2012: JACK server starting in realtime mode with priority 10
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server socket
jack server is not running or cannot be started
Wed Jul 4 16:06:44 2012: ERROR: firewire ERR: Incompatible libffado version! (libffado 2.999.0-2175)
Wed Jul 4 16:06:44 2012: ERROR: Cannot initialize driver
Wed Jul 4 16:06:44 2012: ERROR: JackServer::Open() failed with -1
Wed Jul 4 16:06:45 2012: ERROR: Failed to open server
Wed Jul 4 16:06:46 2012: Saving settings to "/home/strumento/.config/jack/conf.xml" ...
16:06:50.510 Non sono riuscito ad avviare JACK come client. - Operazione fallita. - Impossibile connettersi al server JACK. Controlla la finestra dei messaggi per maggiori informazioni.
Cannot connect to server socket err = File o directory non esistente
Cannot connect to server socket
jack server is not running or cannot be started".
What I've got to do?

Re: Going on

I launched "ENABLE_SETBUFFERSIZE_API_VER=false" and then "scons install", but he always says me, as usual:
Checking for jack >= 0.0.0... (cached) no
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) no
and says me also;
scons: `install' is up to date.

Hmm, that's odd. After doing the "Checking for jack ..." bits, does it make any comment the setbufsize support at all? Did you run

scons ENABLE_SETBUFFERSIZE_API_VER=false

I ask because your comment suggests that you might have tried just

ENABLE_SETBUFFERSIZE_API_VER=false

This would not give any errors because it happens to be valid shell syntax, but because it wasn't being used as an scons option it would not have caused a recompilation of ffado. That would in turn be consistent with the "install is up to date" message you got when you then tried to install.

You also wrote:

if I write "svn update" the answer is:
"WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-FNdlRL/pkcs11: File o directory non esistente [means not existing]
Alla revisione 2175."
So it seems to me that it doesn't allow me to update libffado.

It's only a warning, so I suspect that it is still working. At the present moment r2175 is the latest version so an "svn update" would not do any updating. Once I've made that scons jack checking change I mentioned in an earlier comment the revision will go to 2176, so at that point you should see some action. If you try "svn update" once r2175 is not the current revision and it doesn't work let me know and I'll try to work out what's going on. However, I suspect that it will be fine.

Going on

Hi Jwoithe,
yes, i added scons, I show you the complete result, so you can see the things you wrote me about the setbuffer size.
This is what I did:
"scons ENABLE_SETBUFFERSIZE_API_VER=false
scons: Reading SConscript files ...
Checking for a working C-compiler (cached) yes
Checking for a working C++-compiler (cached) yes
Checking for pkg-config (at least version 0.0.0)... (cached) yes
Checking for jack >= 0.0.0... (cached) no
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) no
Will not report SetBufferSize API version at runtime
Checking for libraw1394 (1.3.0 or higher)... (cached) yes
Checking for libconfig++ (0 or higher)... (cached) yes
Checking for libxml++-2.6 (2.13.0 or higher)... (cached) yes
Checking for libiec61883 (1.1.0 or higher)... (cached) yes
Checking for lrint(3.2) in C library m... (cached) yes
Checking for lrintf(3.2) in C library m... (cached) yes
Checking whether 'which pyuic4' executes (cached) no
Checking whether 'xdg-desktop-menu --help' executes (cached) yes

I couldn't find all the prerequisites ('pyuic4' and the python-modules 'dbus'
and 'PyQt4', the packages could be named like dbus-python and PyQt) to build the
mixer.
Therefor the qt4 mixer will not get installed.

Checking for dbus-1 (1.0 or higher)... (cached) yes
Checking for dbus-c++-1 (0 or higher)... (cached) yes
Checking for alsa (0 or higher)... (cached) no
Checking whether 'which dbusxx-xml2cpp' executes (cached) yes
Checking for variable session_bus_services_dir in package dbus-1... (cached) yes
Trying to find the system triple: (cached) i686-pc-linux-gnu
Doing a DEBUG build
Detected DIST_TARGET = i686
Doing a 32-bit build
Insufficient rights to install the system-wide dbus service file.
Please run the "scons install" command with higher authority.
scons: done reading SConscript files.
scons: Building targets ...
scons: `src' is up to date.
scons: `support' is up to date.
scons: `tests' is up to date.
scons: done building targets."

Is it useful for you?
Thanks!

News02

It seems to me that things are going better.
Infact for the first time when I launched ffado-mixer he recognized my FF and allowed me, for example, to give phantom power to the microphones!
The problem is that this is completely unuseful for me, bacause if I launch any musical program it's impossible yet to use jack and to hear any music with my ff.

Besides if I try to launch qjackctl, even as root, the message is akways
"loading driver ..
20:53:44.193 JACK è stato avviato con PID=2826.
firewire ERR: Incompatible libffado version! (libffado 2.999.0-2175)
cannot load driver module firewire
no message buffer overruns
20:53:44.236 JACK è stato fermato con successo.
20:53:46.348 Non sono riuscito ad avviare JACK come client. - Operazione fallita. - Impossibile connettersi al server JACK. Controlla la finestra dei messaggi per maggiori informazioni.
(process:2818): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
20:53:46.472 JACK sta partendo...
20:53:46.472 /usr/bin/jackd -dfirewire -r44100 -p1024 -n3
jackd 0.121.2
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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
20:53:46.497 JACK è stato avviato con PID=2837.
no message buffer overruns
JACK compiled with System V SHM support.
loading driver ..
firewire ERR: Incompatible libffado version! (libffado 2.999.0-2175)
cannot load driver module firewire
no message buffer overruns
20:53:46.592 JACK è stato fermato con successo."

What do you think about this?
Thank you and best regards

jack

Another thing:
If I launch jack this is what happens:
"jack
This is jack 3.1.1 (C)2004 Arne Zellentin
*warning* You have no standard location set, putting files into the current
directory. Please consider setting base_dir in ~/.jack3rc."

What the hell does it means?
Thanks!!!!!

Re: jack

Somewhat confusingly, "jack" is something completely different to jackd as supplied as part of the "Jack Audio Connection Kit" (JACK). In fact until you posted this I had no idea there was a piece of Linux software called "jack".

To start the low latency streaming audio system, the appropriate program is "jackd" (note the "d" on the end).

When scons reports that it's checking for various versions of "jack", it's really talking about the JACK package which provides (among other things) the jackd server. I suspect it's this mixture of names which might have confused you, and now you've raised it I can see how this could easily occur. I shall change the scons messages to talk about jackd instead so as to avoid as much as possible this sort of confusion for others.

The practical upshot here is that you don't have to worry about the program called "jack"; it's not relevant to firewire audio at all.

Apologize!!

Please, apologize for my terrible mistakes!

I launched Jackd and this is what happened:
"jackd -d firewire -v 6

jackd 0.121.2
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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
JACK compiled with System V SHM support.
loading driver ..
firewire ERR: Incompatible libffado version! (libffado 2.999.0-2175)
cannot load driver module firewire
no message buffer overruns"

What about this?
Thanks

Re: jack

I wrote:
I shall change the scons messages to talk about jackd instead so as to avoid as much as possible this sort of confusion for others.

I've had a look at this and it's not as straight-forward as I had hoped. "jack" is actually the formal name of the package which contains jackd, and the phrases like "jack >= 1.9.9" are in fact what's passed to pkg-config in order to do the tests. Consequently it's not trivial get scons to say something different.

In svn revision 2176 I have altered the wording of the summary printed after checking the JACK version. Hopefully this will make the situation a little clearer.

For reference, the "jack" program which was identified is apparently a CD ripping program. It is totally separate to the Jack Audio Connection Kit (JACK) which provides the jackd server which is of relevance to FFADO.

svn revision 2178

Hi Jw,
I launched svn update and there was an update to r2178!

Unfortunately the problems are always the same!
Infact if I write scons ENABLE_RME=YES, the answer is always the same:
"strumento@strumento-X51L:~/Documenti/ffado/ffado-svn$ scons ENABLE_RME=YES
scons: Reading SConscript files ...
Checking for a working C-compiler (cached) yes
Checking for a working C++-compiler (cached) yes
Checking for pkg-config (at least version 0.0.0)... (cached) yes
Checking for jack >= 0.0.0... (cached) no
Checking for jack < 1.9.0... (cached) no
Checking for jack >= 1.9.9... (cached) no
Will not report SetBufferSize API version at runtime
Checking for libraw1394 (1.3.0 or higher)... (cached) yes
Checking for libconfig++ (0 or higher)... (cached) yes
Checking for libxml++-2.6 (2.13.0 or higher)... (cached) yes
Checking for libiec61883 (1.1.0 or higher)... (cached) yes
Checking for lrint(3.2) in C library m... (cached) yes
Checking for lrintf(3.2) in C library m... (cached) yes
Checking whether 'which pyuic4' executes (cached) no
Checking whether 'xdg-desktop-menu --help' executes (cached) yes

I couldn't find all the prerequisites ('pyuic4' and the python-modules 'dbus'
and 'PyQt4', the packages could be named like dbus-python and PyQt) to build the
mixer.
Therefor the qt4 mixer will not get installed.

Checking for dbus-1 (1.0 or higher)... (cached) yes
Checking for dbus-c++-1 (0 or higher)... (cached) yes
Checking for alsa (0 or higher)... (cached) no
Checking whether 'which dbusxx-xml2cpp' executes (cached) yes
Checking for variable session_bus_services_dir in package dbus-1... (cached) yes
Trying to find the system triple: (cached) i686-pc-linux-gnu
Doing a DEBUG build
Detected DIST_TARGET = i686
Doing a 32-bit build
Insufficient rights to install the system-wide dbus service file.
Please run the "scons install" command with higher authority.
scons: done reading SConscript files.
scons: Building targets ...
scons: `src' is up to date.
scons: `support' is up to date.
scons: `tests' is up to date.
scons: done building targets"

I really don't know what to do...

Re: svn revision 2178

Thanks for your latest reports. I'll respond in detail later today - I've only got a few minutes online right now between other commitments.

Regarding the svn update, as I suspected this seems to be working well so we can ignore the warning that you reported a few days ago. This is good. :-)

Thank you for posting the scons output. It's pleasing to see "Will not report SetBufferSize API version at runtime" reported; at least in theory this should mean that the resulting FFADO will be compatible with the jackd you have on your system. I'd like to check the settings that scons is using to make sure that everything is as I think it is. Could you please run "scons --help" and post the output? You can omit everything above the paragraph which starts with "Note that this is a development version"; all I need in this instance is the list of options and their current settings. The first one reported should be "DEBUG:".

There is also a possibility that I've messed up the API version logic and the "false" setting isn't having the desired effect (that would be a bug in FFADO). I'll double-check this later today and let you know what I find.

Re: svn revision 2178

Thanks for the "scons --help" output. At first glance everything there appears to be as I would expect it to be. Your replacement FFADO is being installed under /usr/, so the chances of you having two versions of FFADO on the system are fairly remote. However, to be sure could you please run "ls -l /usr/local/lib/libffado*" and if any files are listed please post the output?

We can also check to confirm that the API option has had the desired effect. In the top-level FFADO source directory is a file called version.h. About 3 lines from the bottom should be a line which includes "FFADO_API_VERSION"; please post the contents of that line. It should be set to "8" if things have worked as they should have.

hope you don't shoot me

Another news, after installing 2179r I launched QJackCtl, always with the option "Firewire" and using as server address "/usr/bin/jackd" it doesn't work as usually and gives me the message:
"00:18:29.509 Patchbay disattivato.
00:18:29.535 Resetta le statistiche.
00:18:29.552 Connessioni di ALSA cambiate.
00:18:29.557 D-BUS: Servizio non disponibile (org.jackaudio.service aka jackdbus).
00:18:29.568 JACK sta partendo...
00:18:29.569 /usr/bin/jackd -dfirewire -r44100 -p1024 -n3
00:18:29.575 Cambiamento nel grafico delle connessioni di ALSA.
jackd 0.121.4
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd 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
JACK compiled with System V SHM support.
loading driver ..
firewire ERR: Incompatible libffado version! (libffado 2.999.0-2179)
cannot load driver module firewire
no message buffer overruns
00:18:29.715 JACK è stato avviato con PID=28559.
00:18:29.727 JACK è stato fermato con successo.
00:18:31.780 Non sono riuscito ad avviare JACK come client. - Operazione fallita. - Impossibile connettersi al server JACK. Controlla la finestra dei messaggi per maggiori informazioni.
(process:28551): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

Re: hope you don't shoot me

Thanks for the latest round of testing. I'll try to collect all my feedback into this single post.

Clearly the fundamental issue is, as you said, the continued appearance of the "Incompatible libffado version!" message. You've obviously recompiled and installed successfully since we made the ENABLE_SETBUFFERSIZE_API_VER because your output is now reporting the latest svn revision (2179 at this time). I have checked the logic associated with this setting and it is correct, and the contents of version.h which you posted are similarly what I would expect (API version is 8). And yet jackd is still seeing an API version of 9 and reporting that incompatible error. It's quite puzzling. I'm now wondering whether for some reason the FFADO build system has managed to get confused somehow and hasn't recompiled FFADO correctly after the API version change. So here's what I suggest we do (all this is from the top-level FFADO source directory).

  1. scons -c
    This command cleans all compiled objects from the source tree.

  2. scons
    Here we recompile FFADO from scratch. However, all the previously configured scons options will be remembered so there is no need to re-specify them.

  3. scons install
    Obviously this command needs to be done as the root user or via sudo (whichever applies to your distribution).

Essentially this completely rebuilds FFADO. Since version.h is correct this should create a ffado which your jackd is happy with. However, I've been spectacularly wrong before. :-)

On the subject of ffado-dbus-server, it should not be necessary to run this as root on most systems. On my development system for example I only ever run it as my user and don't have issues. Even so, running this as root should not cause it to crash out like it did for you. I can't immediately see a reason why it might have crashed like this; I'll keep pondering this while we continue to work towards a fix for the JACK problem.

You reported that you saw "Warning (cycletimer.h)[ 120] wrapAtMinTicks: insufficient wrapping: -2202703981859345120" at various times when starting ffado-dbus-server. This is a known problem I've been trying to address for a while (it's also seen when jackd starts). As it turns out I had time to work on it extensively last night and subversion r2179 should have a fix for it. Since your run of ffado-dbus-server was with r2178 I'd say the appearance of this warning was expected in the circumstances. I should also note that despite the warning ffado-dbus-server will run correctly; that is, this warning does not cause ffado-dbus-server to fail.

You wrote:
if I launch "ls -l /usr/local/lib/libffado*" it tells me that the directory doesn't exist

This is good: it means we're not inadvertently installing under /usr/local/.

You reported that /usr/lib/ contains some libffado* files; this also is good, as these appear to be the libffado that you have compiled.

Interestingly enough though, it seems that your system also has a /usr/lib/libffado2/ directory, in which is found an older version of FFADO. This is possibly the FFADO that was supplied by your distribution. I'm wondering whether its presence is causing trouble. Probably the easiest way to deal with this is to temporarily rename this directory so the contents can't be found. So try something like

cd /usr/lib
mv libffado2 old-libffado2

That last command will need to be done as root. However, please do this after the other things suggested at the top of this post, and only if those other steps don't improve things.

At this point I should confess one thing: As I'm not an expert of UBUNTU I didn't know how precisely install a program by myself (if not possible with the repository)

You're doing great.


Then every time I've been launching anything from terminal was always opening the terminal inside the directory ffado-svn that the installation created inside the directory ffado created by me inside Documents. ... Maybe I've made some mistakes? Is this to cause all the problems I have? What I've gotta do? In what directory should have been better to launch all the steps for installing ffado from svn?

I don't think any of this is the cause of the difficulty we've encountered. FFADO is being correctly installed into the system directories and is being used at least some of the time (we can tell this from the version number it reports when you run things). JACK and FFADO don't care what directory you're in when you launch the programs so this isn't an issue either. Instead I think there's just something subtle going on with the compilation or something, and that once it's found things will work.

We'll get there, I'm sure. I'm also sure that when we finally discover the reason for all these difficulties it will be very obvious. Hindsight is always a wonderful thing.

Important news

Hi Jw,
the ff is workin'!
Thanks a lot, really!
For example Audacious works perfectly, with a clear sound.
The only thing is that I can adjust the volume inside the program, but not in the ffado-mixer.
This happens always, also with other programs, why?

Thanks
I'd like to re-order all the thing we did to allow to everyone to obtain the same result I did, but I don't know if I will be able to.

Going on:
Using Musescore:
It start perfectly but after 10 about seconds of playback (using the example file "Reunion" begins to glitch, pop, scratch, etc.
At the same time the message window of QJackCtl says:
"Tue Jul 10 12:25:30 2012: New client 'Mscore1' with PID 2151
Tue Jul 10 12:25:30 2012: Connecting 'Mscore1:left' to 'firewire_pcm:000a350193f0da7c_pbk_phones-L_out'
Tue Jul 10 12:25:30 2012: Connecting 'Mscore1:right' to 'firewire_pcm:000a350193f0da7c_pbk_phones-R_out'
12:25:32.432 XRUN callback (1).
Tue Jul 10 12:25:32 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:25:32 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:00.885 XRUN callback (2).
Tue Jul 10 12:26:00 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:00 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:02.046 XRUN callback (2 omitidos).
Tue Jul 10 12:26:01 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:01 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:01 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:01 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:02 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:02 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:02 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:02 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:02 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:02 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:04.052 XRUN callback (8 omitidos).
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:04.742 Grafico delle connessioni di JACK modificato.
12:26:04.886 Connessioni di JACK cambiate.
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: Disconnecting 'Mscore1:left' from 'firewire_pcm:000a350193f0da7c_pbk_phones-L_out'
Tue Jul 10 12:26:04 2012: Disconnecting 'Mscore1:right' from 'firewire_pcm:000a350193f0da7c_pbk_phones-R_out'
Tue Jul 10 12:26:04 2012: Client 'Mscore1' with PID 2151 is out
12:26:06.093 XRUN callback (3 omitidos)."

About the other programs:
Audacity allows me to record but I'm not able in any way to hear any sound.
I select edit/preferences/devices and the box "SYstem" (I'm translating from italian) and there are just two options "Jack audio connection Kit" (I select the this) and "ALSA". There is another box, under playback, with two options "firewire_pcm" (I select that) and "PulseAudioJackSource". the same two option there are also for the box under record, and I select "firewire_pcm" also there".
The difference is that I can record with no problem but I can hear nothing!
Thanks

Re: Important news

This is excellent news. I'm glad that we managed to sort out the jackd/ffado versioning issue. For the record I would be interested to know which of the suggested steps resulted in a working jackd. Anyway, onto the remaining issues.

The biggest single issue I can see is typified by the following comment:

The only thing is that I can adjust the volume inside the program, but not in the ffado-mixer.
This happens always, also with other programs, why?

There could be a couple of reasons. When a program wants a volume control there are two ways it can go: it can either attempt to control the hardware directly or it can implement a software volume control. In the latter case, the program simply multiplies the outgoing samples by some number to increase or decrease their value. A multiplying factor greater than 1 makes things louder while a factor less than 1 makes things softer. If the volume control in a program is affecting the output level from the Fireface then it must be implementing a software volume control because no program attempts to directly control the volumes on a FFADO device.

Having said that, ffado-mixer should obviously be able to affect the output levels because it controls the hardware mixer in the interface. The fact that you're not able to affect the output level with ffado-mixer suggests there's some form of problem which we need to sort out.

First up, when talking about playback volume there are two controls which are relevant. The first is in the "playback" matrix mixer.
In this matrix, the columns represent the playback channels from the computer and the rows are the physical outputs from the device. For example, if you wanted to control the volume when sending computer channel 2 to the device's "Analog 4" output you would need to change the control in column 2, row 4.

The second relevant control is the overall volume of the output you're dealing with. These are found in the "output" tab of ffado-mixer.

There is a potential complication in your case which we may have to deal with if everything else seems right. When you compiled FFADO your system reported that it was unable to locate some of the development packages needed to compile the GUI elements of ffado-mixer. This means that any ffado-mixer GUI you have on your system now will be that from your original distribution's FFADO installation. Depending on the age of that version, things may or may not work. If you double-check the matrix mixer information I've given above and things still don't seem to be working, we may well be dealing with a problem caused by the older ffado-mixer GUI.

I also recall that previously you've had issues when ffado-dbus-server was run. ffado-dbus-server is a program which communicates mixer settings to the device. Basically the arrangement is that ffado-mixer talks to ffado-dbus-server via dbus, and ffado-dbus-server handles communication with the actual device (the splitting of the device communication from the GUI means it's easy to write alternative GUI mixers if people wish to do so). Anyway, to make it easier to determine the nature of any remaining issues, it's probably best to manually run ffado-dbus-server in a terminal first. It should spit a whole lot of stuff to the screen and then seemingly go to sleep. If that happens, then start ffado-mixer and see what happens. If the mixer starts try using the "playback" matrix mixer while playing audio from audacious and see if you can get audio out of the Fireface.

If it looks like you need to obtain a newer version of the ffado-mixer GUI, the relevant development packages will be named something like this: dbus-python / dubs-python-devel, PyQt / PyQt-devel. Try installing these through your package manager and then run "scons" again. Look carefully below the initial "checking for" messages and see if you see any messages along the lines of:

I couldn't find all the prerequisites ('pyuic4' and the python-modules 'dbus'
and 'PyQt4', the packages could be named like dbus-python and PyQt) to build
the mixer.

If this message no longer occurs after installing the additional packages it means that ffado-mixer will now be built. After "scons" completes, do "scons install" again and then re-test ffado-mixer. If you're still seeing it perhaps post the top section of the scons output again and we'll try to work out what other *-devel packages are not installed.

Regarding playback, I have one caution for you. At present, when jackd/ffado is started for the first time after turning the Fireface on, a high volume digital noise is emitted from some outputs for about half a second during startup. This does not happen on all systems and I am presently trying to determine the cause. As a result, if you have expensive high-powered monitor speakers attached to the Fireface and turned up high I recommend you only turn them on after jackd/ffado is running to prevent damage. Likewise, if you have headphones connected I wouldn't put them on until a few seconds after you start jackd/ffado.

Finally, regarding musescore, the symptoms are consistent with either an overloaded CPU (it's no longer able to keep up with the requirement of keeping the Fireface supplied with audio data in time to play it out) or a scheduling problem. During your earlier tests the jackd output indicated that it was running with realtime scheduling enabled, which is good. Another possibility is the kernel configuration: if you're using a generic kernel instead of a preempt kernel you can also have scheduling issues even if the relevant software is using realtime scheduling. If you can post the output of "uname -a" we can confirm which kernel you're using and whether this is a possibility. Also, please let me know what CPU is in your system - that way we can rule out CPU load as an option.

I don't know why musescore would be affected like this while the likes of audacious are not. It may have something to do with the internal structure of the respective programs though.

CPU

Hi JW,
my system requirements, as you asked me, are:
CPU: Intel® Pentium® Dual CPU T3200 @2.00 GHz 2.00 GHz
RAM: 3,00 GB
32 bit

About Musescore I think that, as it works with MIDI, probably gives a stress to all the system, as the MIDI files, when executed by the computer need a lot of resources more than the nrmalo audion files like wav, mp3, ecc.
I will try to sort out the problem when I will be back home, because I'm spending the holydays without the Fireface with me.
Thanks again

Re: CPU

Thanks for confirming your CPU. That should be more than fine, assuming the use of a PREEMPT kernel. If a PREEMPT kernel is not used then the added stress of the MIDI files could well be enough to cause trouble where a pure audio application still manages to work, as you have suggested. This would be especially true if you were using soft-synths with the MIDI data.

Enjoy your holidays; we can resume the discussion and investigations upon your return.

Kernel

Hi Jwoithe,
I sorted out every issue about audio, using properly the playback matrix of ffado mixer as you told me some days ago.
The problem with MIDI remains, unfortunately.
I followed the instructions you gave me and this is what came out.
"strumento@strumento-X51L:~$ uname -a
Linux strumento-X51L 3.2.0-23-lowlatency-pae #31-Ubuntu SMP PREEMPT Wed Apr 11 04:07:36 UTC 2012 i686 i686 i386 GNU/Linux".
I'm not able to undertand! Does it means something for you?
Is it a PREEMPT kernel or is it something else?
Thanks

Re: Kernel

Hi Luca

Thanks for your latest update. From what you've written I assume that audio issues are now resolved but that musescore is still creating problems. This is good because it means we're making real progress. I had a quick scan through the ticket history and couldn't locate the post where you described the musescore issue; unfortunately I've forgotten the details. Could you please re-post a brief rundown on what is still going wrong with musescore and/or MIDI? Apologies for this.

On the subject of the kernel, from the output you've supplied it appears that you are running a PREEMPT kernel. A PREEMPT kernel is sometimes referred to as a "low latency" kernel, and in your "uname -a" output we get to see both terms. This is good: we can rule the kernel out as a possibility.

Musescore

Musescore:
it start perfectly but after 10 about seconds of playback (using the example file "Reunion") begins to glitch, pop, scratch, etc.
At the same time the message window of QJackCtl says:
"Tue Jul 10 12:25:30 2012: New client 'Mscore1' with PID 2151
Tue Jul 10 12:25:30 2012: Connecting 'Mscore1:left' to 'firewire_pcm:000a350193f0da7c_pbk_phones-L_out'
Tue Jul 10 12:25:30 2012: Connecting 'Mscore1:right' to 'firewire_pcm:000a350193f0da7c_pbk_phones-R_out'
12:25:32.432 XRUN callback (1).
Tue Jul 10 12:25:32 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:25:32 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:00.885 XRUN callback (2).
Tue Jul 10 12:26:00 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:00 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:02.046 XRUN callback (2 omitidos).
Tue Jul 10 12:26:01 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:01 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:01 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:01 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:02 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:02 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:02 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:02 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:02 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:02 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:04.052 XRUN callback (8 omitidos).
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:03 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:03 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
12:26:04.742 Grafico delle connessioni di JACK modificato.
12:26:04.886 Connessioni di JACK cambiate.
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: ERROR: JackEngine::XRun: client = Mscore1 was not run: state = 2
Tue Jul 10 12:26:04 2012: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Tue Jul 10 12:26:04 2012: Disconnecting 'Mscore1:left' from 'firewire_pcm:000a350193f0da7c_pbk_phones-L_out'
Tue Jul 10 12:26:04 2012: Disconnecting 'Mscore1:right' from 'firewire_pcm:000a350193f0da7c_pbk_phones-R_out'
Tue Jul 10 12:26:04 2012: Client 'Mscore1' with PID 2151 is out
12:26:06.093 XRUN callback (3 omitidos)."
Thanks again.