FFADO 2.0 Release Candidate 2 (1.999.42) available

FFADO 2.0 Release Candidate 2 (1.999.42) available

The FFADO team is happy to announce the release of the second release candidate for FFADO 2.0.

It has been 6 months since we released FFADO 2.0 Release Candidate 1, and we have to admit that this is quite long. The usage statistics show that about 300 people have been using RC1 in this period, and the good news is that we did not get a lot of bug reports. Most of the reports filed were related to crappy host controller hardware (most notably the Ricoh controllers), which is something we unfortunately cannot fix. In the mean time the remaining bug reports have been fixed, so here we are again.

This release candidate contains a few reliability improvements and bugfixes that should get some field testing before we can release the official 2.0. I would therefore like to ask all users and packagers to upgrade as soon as possible such that we can release sooner rather than later. If we get to about 100 registered users without significant significant bug reports I feel confident that we're good to go. So happy testing!

To indicate that we're quite busy even though we don't put out a lot of announcements let me give you a sneak preview of what is under development for post-2.0 ...

First of all 2.1 will contain support for extra devices:

  • The first device to take full advantage of our DICE platform support will be the Focusrite Saffire PRO40. The platform based audio and MIDI streaming is fully functional. The custom mixer functionality is currently being alpha-tested.
  • The DICE platform support also enables the basic use of the TC Electronic Konnekt 8, 24D and Live. Support for these devices is limited to streaming (no DSP effects). Currently it doesn't look like the DSP is going to be supported any time soon.
  • Support for the Behringer FCA-202 has been added.
  • Support for the Stanton SCS.1 series is added. Support for both the audio I/O as the HSS1394 control surface protocol has been implemented, meaning that these devices are fully functional.

We keep on talking to several device vendors to increase our device support, and we will most likely be announcing some new devices in the near future.

The second major development is the move of the streaming infrastructure to kernel space. Thanks to the Google Summer of Code and the Linux Foundation, we have somebody working on this during the summer. A kernel-space implementation will bring significant improvements with respect to reliability and efficiency. Furthermore it will expose an ALSA interface, meaning that the scope of FireWire audio is extended significantly.

libffado?

This release provides the libffado shared library that provides a unified programming interface to configure and use all supported devices. Currently this library is used by the 'firewire' backend of the jack audio connection kit sound server (http://jackaudio.org). This backend provides audio and midi support, and is available both in jackd and it's multiprocessor variant jackdmp (aka jack2). (note: At the moment there is no direct support for ALSA nor for pulseaudio, but these systems can use jack.)

Access to the device internal configuration (e,g, internal mixer) is exposed using the ffado-dbus-server daemon. This daemon exposes the configurable parameters of all detected devices through DBUS. The ffadomixer application in support/mixer presents a basic GUI to control these parameters (only for officially supported devices).

Features

  • 24-bit audio input/output (unlimited number of channels)
  • support for all sample rates a device supports
  • MIDI input/output (unlimited number of channels)
  • Support for S/PDIF and ADAT/SMUX I/O
  • Support for external sync (e.g. Wordclock)
  • Internal mixer and device control support for all officially supported
    devices (NOTE: no support for internal effects DSP)
  • Support for device aggregation (limited to devices on the same bus that are synced externally)

Usage feedback

This release includes an option where you can identify your device as being used on Linux with FFADO. You will be asked whether you want to submit your device information to ffado.org. The reason this feature is present is to convince the supportive vendors that their cooperation pays off, and to convince the other vendors that Linux users are a market. A secondary advantage is that we can keep track of what versions are used by how many people.

Therefore we would like to ask everyone to perform this registration. No personal data is transmitted (except for an optional email address). The IP address of the submitter is saved to help recovery in case the database is bombed with bogus data. However the address is first processed by one-way MD5 hashing it, such that it is not recoverable and privacy is secured. This usage information is of enormous importance for future device support. The aggregated statistics are available online: http://www.ffado.org/?q=usage.

Changelog

RC1 => RC2

  • Various packaging improvements and cosmetic fixes.
  • Improved the Edirol FA101 mixer
  • While the streaming engine is running, prevent mixer changes that result in aborted streaming
  • Add status bar logging to the mixer window
  • Install a service-file if possible
  • Add command rate control for the Saffire devices to reduce the issues with mixer actions messing up audio.
  • Fix Terratec Phase88 mixer
  • Implement mixer support for the MOTU UltraLite
  • Improve mixer support for the MOTU 896HD
  • Add a minimum for the packetsize parameter for very low channel-count devices
  • Fix handling of MIDI 2x and 3x mode
  • Improve the jitter performance of the timestamping
  • Reduce CPU usage
  • Fix the bug that prevented jackd from exiting freewheeling mode
  • Introduce transmit prebuffering to increase reliability with small period sizes
  • MOTU: Fix bug related to disabled (unused) audio channels
  • Introduce support for driver parameters in the config file
  • Ensure that the order specified in the specification string when aggregating devices is honored.
  • Ensure that libffado.so is properly versioned (SONAME) and installed
  • Add a firmware version check for ECHO Fireworks based devices
  • Add a firmware version check for Terratec Phase88 devices
  • By default the library is compiled with debugging turned off

Beta7 => RC1

  • Various packaging improvements and fixes.
  • Install both the qt3 and the qt4 mixer when the needed tools are available.
  • Add ffado-diag to the installed tools
  • Disable the nickname control for devices that don't support it
  • Various QT4 mixer improvements
  • Increase efficiency while streaming
  • Fix some CTR wraparound bugs
  • Fix bebob fallback discovery
  • Fix AV/C based sync source selection
  • Fix Saffire Pro sync source selection
  • Fix Saffire Pro and Saffire (LE) samplerate selection
  • Fix jack freewheeling bug
  • Add workaround for Edirol FA-101 firmware race condition

Beta6 => Beta7

  • General code cleanup
  • Improve mixers of various devices (especially the MOTU and Edirol mixers)
  • Port mixers to QT4 for better usability (QT3 mixers still work but are deprecated)
  • Implement support for ECHO session blocks
  • Fix Focusrite Saffire Pro clock source selection
  • Implement configuration file mechanism to ease run-time configuration
  • Improve the behavior when confronted with dying iso transmit handlers
  • Reset transmit buffer rate DLL on XRUN.
  • Improve bus reset handling
  • Improve reliability of ISO streaming on various host controllers
  • Fix discovery issues with DM1x00 based devices (especially Edirol devices)
  • Remove the dependency on libavc1394 by implementing our own FCP transaction support
  • Fix float to int conversion dynamic range bug in the AMDTP StreamProcessor

Beta5 => Beta6

  • implement discovery fallback (tries generic support when encountering an unsupported device)
  • fix gcc-4.3 compilation issues
  • take CC and CXX from the environment if defined there
  • implement separate mixer for Phase X24 and Phase 24
  • fix saffire mixer
  • fix cache issues
  • fix clock source segfault
  • fix ffadomixer python 2.4 compatibility
  • use FocusRite vendor-specific clock selection for the Saffire PRO devices

Beta4 => Beta5

  • fix BeBoB flooding issues
  • numerous mixer improvements
  • fix threading issues
  • remove all unused code
  • fix clocksource selection bugs
  • fix 64bit compilation issue
  • improve library behavior in error situations
  • improve shutdown of MOTU interfaces
  • make dbus server handle busresets cleanly

Beta3 => Beta4

  • fix bugs in BeBoB caching code
  • extend Saffire PRO26 mixer
  • various mixer improvements
  • switch back to BeBoB discovery code for FA-101

Beta2 => Beta3

  • fix memory corruption bug in saffire LE mixer code
  • various debugging code improvements
  • create config save directory if not present.
  • change registration window looks.
  • various MOTU mixer improvements
  • workaround MOTU not setting a vendor/model name
  • one window for all mixers, tabbed.
  • fix CTR reconstruction bug
  • Add a generic part for each mixer controlling the nickname and the clocksource.
  • Rework/resort the initialization of mixer-widgets...
  • fix issues in timestamp usage
  • re-enable late transmission
  • switched off all extended debugging features by default

Beta1 => Beta2

  • Correct issues in the README file
  • Remove unneeded ALSA dependency
  • Several mixer improvements
  • Implement usage statistics gathering

Building and Installing

Please refer to the README document in the package. Not doing so means taking a risk ;).

Download

Binary Packages

As Ubuntu has picked up FFADO in its latest release, we no longer provide our own APT repository.

Source Distribution

AttachmentSize
libffado-2.0-rc2.tar.gz756.73 KB

Comment viewing options

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

I am posting here because

I am posting here because there seems to be a bit of interest in firewire, and 64studio is also debian-based

The summary is below

1) FFADO fails to install properly using default prefix /usr/local
error while loading shared libraries: libffado.so: cannot open
shared object file: No such file or directory
fix: cp /usr/local/lib/libffado.so /usr/lib/

2) FFADO fails to install using PREFIX=/usr (scons error)
scons: *** DirNodeInfo instance has no attribute 'csig'

3) tests/test-ffado Discover failure after successful install (using fix
in #1 above)
see ffado_error #3 for full debug output

4) jackd version mismatch after successful compile of jackd with
firewire support.

Regarding 1) that is not a

Regarding 1) that is not a fix! Moving the library after installation is asking for troubles because the install-path is also coded into the library to fetch additional text-files and dependencies. Better use "scons PREFIX=/usr" from the start.

Regarding 4): That version-mismatched tells you that you are using the old binaries installed in /usr with the new library installed to /usr/local and moved to /usr. Better do 1) right at the first place...

Oh, and stop placing spam-links...

ffado for dummies

Hi, I know Linux and most of its programs/applications are meant to be used by individuals savvy enough to build from code. But is there a possibility that this can be developed past the half-baked point....so that us knuckle draggers can enjoy it too?

A sudo apt-get install ..... and it builds, downloads and configures itself would be nice. Does it really take that much more to have everything in a package like that?

Why we don't provide packages fur distribution X.Y by default

Hi,

Lets count the ubuntu-version in usage nowadays: 8.04, maybe 8.10, definitely 9.04 and 9.10. Add to that the different versions of Suse, Redhat/Fedora, Mandriva, Gentoo, Arch and all the other debian-based distros. Lets not forget about debian itself.

Times two for x86 and x86_64 to have the most important architectures.

Now take a look at the time we had in the past year to work on ffado. And then substract the time needed to build and support packages into the various distributions.

Packaging software into the distributions system is a job far better done by the distributors themselves. And they do a terrific job at that!
Please ask your distribution vendor to include the packages you want. Normally they are quite fast at picking ffado into their systems.

It might not be the most user-friendly way, but we prefer to spend our time bug-hunting and coding and sometimes even helping users. I am very thankful that there are others enjoying packaging our software into the distributions.

Speaking for myself, if I start packaging too, my wife will probably throw all he computers out of the window.

(If we really get around to providing nightly packages for our personal favorite distribution and architecture, please take that as an additional bonus, not as granted.)

Ok, thats

Ok, thats understandable.

How is the progress going with the TC Konnekt???

I see there are some pics of TC that seems to be working in Linux...I take it you are at the bug killing phase.

package for hardy?

First of all: Biiig thank you for all your efforts!

I'd like to upgrade to RC2 in my studio, but I'm only using LTS versions of Ubuntu on production systems (and I guess I'm not alone with that).
From Canonical, Hardy is still supported until April 2011 (https://wiki.ubuntu.com/Releases), so are there any plans to still package for Hardy?

If not, I could offer to build a proper .deb package for RC2 to safe others some work.

Alsa interface...

I am very, very interested in the part where you mention moving some of this stuff into kernel space, which in turn will expose an alsa interface...

I have an Edirol FA-101, and have been a regular user of freebob/ffado since mid-2007, and reliability has always been an issue. Previous to this, I used an M-Audio Delta 44, which was utterly flawless (hooked into jackd, ardour etc).

Granted, I think some of these issues are related to whats going on elsewhere in both user and kernel space, and Linus himself mentions performance regressions in the kernel (as a side note, Gtk of late runs like molasses, and my overall experience is slower and less reliable than the alternative - Windows XP, which is sad, and didn't always use to be the case).

Anyway, I am hopefully optimistic that improvements in both the code base and refactoring into the kernel will improve the state of firewire audio on linux immensly, and I would love to test bugs and give feedback, but there doesn't seem to be much information on this. Are you able shed some light??

great!!!

Reediting my comment.. Just realized konnekt support is only for 2.1... I'll try to get the development tree and see what's happening with my konnekt. Thanks a lot for your hard work!

development tree

Hello. Did You get this development tree ? is there any location i can get that ? i have searched this whole webpage and i cannot find this ;)

I am using konnekt 24D and i would love to switch totally to linux , i just cannot manage my konnekt card to work.

Can i ask You for some help please ?

Best reagrds

Maciek

--------------------------------------------
TC Electronic Konnekt 24D user