AudioFire 8

As of August 2012, the Audiofire 8 will only work with FFADO if firmware 4.8 or earlier is installed in the device. Please refer to ticket #360 for more details and for news about progress in fixing this.

28 Oct 2013: Takashi Sakamoto has pointed out that firmware versions 5.5 and later no longer support 192 kHz sample rate. This is a hardware limitation and is not related to FFADO. It is not currently known why this rate is no longer supported. To continue to use 192 kHz sample rate, stick with firmware version 4.8.

29 Oct 2013: As of r2451/r2452, audio streaming with FFADO may now be functional with AudioFire-8 firmware versions 5.5 and later. This has not been explicitly tested by FFADO. Reports of tests are welcomed. This is thanks to Takashi Sakamoto.

Support Status: 
Full Support
Manufacturer: 
ECHO

Comments

I have this card, what can I do to help the development of the driver for it ?

I want 8 XLR inputs, and I'm considering this one. Seems to be similar to the Audiofire 8, but with preamps.
Does anybody knows if it will also work with ffado?
Thanks.

FFADO doesn't yet know about the Pre 8, but the Echo driver should work if you add the device ID; see http://subversion.ffado.org/wiki/AddingDeviceIds .

I have located the vendorID and deviceID, but there is no /root/trunk/libffado/configuration file to add the IDs to. I did locate a libffado/config file at /usr/share/libffado2/configuration, though.

I added:

{
vendorid = 0x001486;
modelid = 0x000af9;
vendorname = "Echo";
modelname = "AudioFirePre8";
driver = 2;
xmit_max_cycles_early_transmit = 2;
},

to the config in usr/share, but I still can't get it to interact. Any help will be massively appreciated. thx!

The "root/trunk/..." path refers to the source tree. When ffado is installed on the system the relevant file will be somewhere under /usr as you have identified.

Was the behaviour any different after you added the above to the configuration file?

Hey jwoithe,

sadly the behavior is similar.

so I'm using qjackctl. in settings i've selected "firewire" for the driver. the interface choices it gives me with firewire are (default), /dev/dsp, /dev/audio, hw:0 and plug:hw:0, all of which fail to interface with the pre8. The message window reports:

55348015915: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0- built Aug 11 2010 00:12:04
firewire ERR: Error creating FFADO streaming device
cannot load driver module firewire
no message buffer overruns
11:21:06.933 JACK was stopped successfully.
11:21:06.935 Post-shutdown script...
11:21:06.935 killall jackd
jackd: no process found
11:21:07.344 Post-shutdown script terminated with exit status=256.

I took a couple of guesses, and I forgot some colons. lemme try again...

any technology distinguishable from magic is insufficiently advanced

I think we're going to need a bit more information to work out what might be going on. Firstly, try running jack directly on the command line. Use a command like this: jackd -P70 -R -d firewire -p 1024 -n 4

These are conservative settings with moderate latency, but they should prove whether things are workable or not. If this gives the same general error, try adding "-v 6" (without the quotes) to the end of the command. This should greatly increase the amount of information written to the screen. Have a look through this and see if you can spot anything which might hint at the problem. If you have difficulty perhaps email me the output directly (you can find my address in posts to the ffado-devel mailing list).

I notice that the version of ffado in use is fairly old - it was built in August 2010. That may or may not be significant - I don't know the Echo development enough to know if there have been significant bug fixes since then.

I should point out at this point that I don't own any Echo devices and therefore my ability to assist here is limited to general high-level suggestions. Hopefully someone who has one of the Echo devices working will chime in with some thoughts.

Thank you thank you, jwoithe!

I'm running narwhal now, and I'm recording on my AFpre8 thanks to your help! qjackctl doesn't seem to be recognizing, but I can record in Ardour after starting up jackd as you suggested.

Hey everyone who's wondering- the pre8 works.

this is the error I get:

no message buffer overruns
JACK compiled with System V SHM support.
loading driver ..
00100548596: (ffado.cpp)[ 92] ffado_streaming_init: libffado 2.999.0- built Aug 11 2010 00:12:04
firewire ERR: Error creating FFADO streaming device
cannot load driver module firewire
no message buffer overruns

--------------------

the interface options qjackctl gives me with firewire are hw:0, default, /dev/dsp, /dev/audio, and plughw:0. I get the above error which each interface option. using the freebob driver is the same.

I am about to buy the pre 8 instead of the Audiofire8 since I am going to need 4 preamps sometimes instead of 2 and why not 8? But it is a $700 risk and I sure would like to know how you made out with it. I am going to try it with an Asus motherboard M4A78-E with the later Via VT6315N chipset and see what happens; I am prepared to get a pci express Firewire card if the onboard one gives me problems. But I am just one guy in a basement and am not putting a lot of demand on this device. I am a long time Linux and UNIX user and am leaning toward Ubuntu Studio for this instead of the Centos/Redhat I have used for years or the AV Linux which seems to not have many users as US. Appreciate your thoughts...

Thanks

Hello,
I have had some success with ECHO AudioFire 8 and ffado. I have a couple of questions.
I have not updated anything--running only with packages provided at the repository server.

Ubuntu studio with latest updates from Canonical repositories:

ffado-tools 2.0~rc2+svn1569-2ubuntu1
ffado-mixer-qt4 2.0~rc2+svn1569-2ubuntu1
ffado-dbus-server 2.0~rc2+svn1569-2ubuntu1
libffado1 2.0~rc2+svn1569-2ubuntu1

I did a simple test with Microphone plugged into front panel input 1 on the AudioFire 8 and I am able to record and playback using Ardour--very good.

I can see 16 input (capture) and 16 outputs (playback) in Jack (qjackctl) connection control. I was thinking I should see only 10 inputs and 8 outputs to match AudioFire8 hardware. During startup of ffado-dbus-server I get a warning which reads:
00229486320: Warning (fireworks_device.cpp)[ 134] discover: Using generic ECHO Audio FireWorks support for unsupported device "Echo Digital Audio AudioFire8"

1. Does this (generic support) mean that I should try to compile ffado from latest source since I have read that the AudioFire8 is fully supported?

I plugged my midi contoller (Peavy midi keyboard) midi-out into the AudioFire8 midi-in, but did not see an entry show up in Jack connection control ALSA tab for the AudioFire8 midi device.

2. Can you give me an idea as to the midi support available in the ffado with AudioFire8? Should midi be working at this point?

Any advice you can provide would be appreciated.
I will also contact ECHO to let them know that I am making all of my hardware choices on devices that work with Linux. I will mention supporting ffado.

Ubuntu Studio v9.10, ECHO AudioFire 8, AMD Athlon X2 64bit

Thanks,
zman58

I saw the same message and am more stumped than you are...

Bottom line is Jack does not see the device but it works fine on Windoze. I am using the VIA 1394 onboard controller, System Admin Studio Controls-->100% memlock, raw1394 access and enable nice -10. /dev/raw1394 is still owned by "video" and premissions are still 660....chmod to 777 does not seem to help at all. I am thinking that the 1394 controller is the only problem that I have not confronted by switching to a TI chipset. Output of ffado-test ListDevices, and discover is below. Any thoughts are welcome!!!thanks

~ $ ffado-test ListDevices
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 1.999.43
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

=== 1394 PORT 0 ===
Node id GUID VendorId ModelId Vendor - Model
0 0x001e8c0001cacbdd 0x00001E8C 0x00000000 Linux - ohci1394 -
1 0x001486045b65d6e8 0x00001486 0x00000AF9 Echo Digital Audio - AudioFire8
no message buffer overruns
~ $

ffado-mixer runs and eventually prints this:
DEBUG:configparser:DeviceList::addDevice()

DEBUG:configparser:DeviceList::getDeviceById( 0x0001f2, 0x00000000 )

DEBUG:dbus:connecting to: Updated on /org/ffado/Control/DeviceManager (server: org.ffado.Control)

DEBUG:panelmanager:PanelManager::updatePanels()

DEBUG:panelmanager:going to add 001486045b65d6e8

DEBUG:panelmanager:Adding device 0: 001486045b65d6e8

DEBUG:panelmanager: Found (001486045b65d6e8, 1486, AF9) Echo Digital Audio AudioFire8

DEBUG:registration:version/GUID combo already registered

DEBUG:configparser:DeviceList::getDeviceById( 5254, 2809 )

~ $ lspci | grep FireWire

03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. Device 3403

raw 1394 is there now since
Ubuntu studio crontrols enable raw1394 was done yesterday

ffado-test Discover :

-----------------------------------------------

FFADO test and diagnostic utility

Part of the FFADO project -- www.ffado.org

Version: 1.999.43

(C) 2008, Daniel Wagner, Pieter Palmers

This program comes with ABSOLUTELY NO WARRANTY.

-----------------------------------------------

00436551903: Debug (devicemanager.cpp)[ 332] discover: Starting discovery...

00436557834: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436559016: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436560207: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436561373: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436562541: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436616167: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436617338: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436618516: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436619692: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436620862: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC1, addr = 0x0000FFFFF0000400, length = 256

00436669695: Debug (devicemanager.cpp)[ 594] discover: driver found for device 1

00436669780: Warning (fireworks_device.cpp)[ 134] discover: Using generic ECHO Audio FireWorks support for unsupported device 'Echo Digital Audio AudioFire8'

00436671057: Debug (avc_audiosubunit.cpp)[ 55] discover: Discovering AVC::AudioSubunit...

00436671071: Debug (avc_subunit.cpp)[ 108] discoverPlugs: Discovering plugs...

00436671357: Debug (avc_subunit.cpp)[ 228] initPlugFromDescriptor: plug loading from descriptor not implemented

00436671398: Debug (avc_plug.cpp)[ 182] discover: discover: Could not init plug from descriptor (1,1,0,0,0)

00436671951: Debug (avc_subunit.cpp)[ 228] initPlugFromDescriptor: plug loading from descriptor not implemented

00436671964: Debug (avc_plug.cpp)[ 182] discover: discover: Could not init plug from descriptor (1,1,0,1,0)

00436672513: Debug (avc_musicsubunit.cpp)[ 65] discover: Discovering MusicSubunit...

00436672525: Debug (avc_subunit.cpp)[ 108] discoverPlugs: Discovering plugs...

00436680649: Debug (avc_unit.cpp)[ 366] discoverPlugs: Discovering plugs...

00436680885: Debug (avc_unit.cpp)[ 383] discoverPlugs: number of iso input plugs = 1

00436680893: Debug (avc_unit.cpp)[ 385] discoverPlugs: number of iso output plugs = 1

00436680901: Debug (avc_unit.cpp)[ 387] discoverPlugs: number of external input plugs = 3

00436680905: Debug (avc_unit.cpp)[ 389] discoverPlugs: number of external output plugs = 3

00436680914: Debug (avc_unit.cpp)[ 426] discoverPlugsPCR: Discovering PCR plugs, direction 0...

00436681204: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436681217: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,0,0)

00436681468: Debug (avc_unit.cpp)[ 448] discoverPlugsPCR: plug 'PCR Unknown Input' found

00436681480: Debug (avc_unit.cpp)[ 426] discoverPlugsPCR: Discovering PCR plugs, direction 1...

00436681771: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436681789: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,1,0)

00436682039: Debug (avc_unit.cpp)[ 448] discoverPlugsPCR: plug 'PCR Unknown Output' found

00436682053: Debug (avc_unit.cpp)[ 459] discoverPlugsExternal: Discovering External plugs, direction 0...

00436682383: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436682396: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,0,0)

00436682645: Debug (avc_unit.cpp)[ 479] discoverPlugsExternal: plug 'External Unknown Input' found

00436682929: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436682937: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,0,1)

00436683205: Debug (avc_unit.cpp)[ 479] discoverPlugsExternal: plug 'External Unknown Input' found

00436683482: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436683495: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,0,2)

00436683742: Debug (avc_unit.cpp)[ 479] discoverPlugsExternal: plug 'External Unknown Input' found

00436683755: Debug (avc_unit.cpp)[ 459] discoverPlugsExternal: Discovering External plugs, direction 1...

00436684046: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436684062: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,1,0)

00436684324: Debug (avc_unit.cpp)[ 479] discoverPlugsExternal: plug 'External Unknown Output' found

00436684613: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436684627: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,1,1)

00436684883: Debug (avc_unit.cpp)[ 479] discoverPlugsExternal: plug 'External Unknown Output' found

00436685207: Debug (avc_plug.cpp)[ 374] discoverStreamFormat: No matching cluster info found for index 1

00436685225: Debug (avc_plug.cpp)[ 235] discover: Could not discover stream format (1,31,255,1,2)

00436685516: Debug (avc_unit.cpp)[ 479] discoverPlugsExternal: plug 'External Unknown Output' found

00436685537: Debug (avc_unit.cpp)[ 489] discoverPlugConnections: Discovering PCR plug connections...

00436685832: Debug (avc_unit.cpp)[ 500] discoverPlugConnections: Discovering External plug connections...

00436686622: Debug (avc_subunit.cpp)[ 148] discoverConnections: Discovering connections...

00436686909: Debug (avc_subunit.cpp)[ 148] discoverConnections: Discovering connections...

00436688294: Debug (avc_unit.cpp)[ 653] discoverSyncModes: No PCR sync input plug found

00436688301: Debug (avc_unit.cpp)[ 660] discoverSyncModes: No PCR sync output plug found

00436688313: Debug (avc_unit.cpp)[ 667] discoverSyncModes: No PCR iso input plug found

00436688317: Debug (avc_unit.cpp)[ 675] discoverSyncModes: No PCR iso output plug found

00436688665: Debug (avc_unit.cpp)[ 536] propagatePlugInfo: Propagating info to PCR plugs...

00436688671: Debug (avc_unit.cpp)[ 542] propagatePlugInfo: plug: PCR Unknown Input

00436688688: Debug (avc_unit.cpp)[ 542] propagatePlugInfo: plug: PCR Unknown Output

00436688697: Debug (avc_unit.cpp)[ 547] propagatePlugInfo: Propagating info to External plugs...

00436688705: Debug (avc_unit.cpp)[ 553] propagatePlugInfo: plug: External Unknown Input

00436688712: Debug (avc_unit.cpp)[ 553] propagatePlugInfo: plug: External Unknown Input

00436688721: Debug (avc_unit.cpp)[ 553] propagatePlugInfo: plug: External Unknown Input

00436688726: Debug (avc_unit.cpp)[ 553] propagatePlugInfo: plug: External Unknown Output

00436688735: Debug (avc_unit.cpp)[ 553] propagatePlugInfo: plug: External Unknown Output

00436688741: Debug (avc_unit.cpp)[ 553] propagatePlugInfo: plug: External Unknown Output

00436752688: Debug (devicemanager.cpp)[ 631] discover: discovery of node 1 on port 0 done...

00436752698: Debug (devicemanager.cpp)[ 639] discover: Discovery finished...

00436752729: Debug (devicemanager.cpp)[1184] showDeviceInfo: ===== Device Manager =====

00436752737: Debug (Element.cpp)[ 121] show: Element DeviceManager

00436752745: Debug (devicemanager.cpp)[1192] showDeviceInfo: --- IEEE1394 Service 0 ---

Iso handler info:

Dumping IsoHandlerManager Stream handler information...

State: 2

00436752770: Debug (devicemanager.cpp)[1202] showDeviceInfo: --- Device 0 ---

00436752774: Debug (efc_cmd.cpp)[ 171] showEfcCmd: EFC Length: 6

00436752783: Debug (efc_cmd.cpp)[ 172] showEfcCmd: EFC Header:

00436752786: Debug (efc_cmd.cpp)[ 173] showEfcCmd: Version : 0x00000000

00436752793: Debug (efc_cmd.cpp)[ 174] showEfcCmd: Sequence number : 0x00000004

00436752797: Debug (efc_cmd.cpp)[ 175] showEfcCmd: Category : 0x00000000

00436752804: Debug (efc_cmd.cpp)[ 176] showEfcCmd: Command : 0x00000000

00436752806: Debug (efc_cmd.cpp)[ 177] showEfcCmd: Return Value : 0x00000000

00436752812: Debug (efc_cmds_hardware.cpp)[ 127] showEfcCmd: EFC HW CAPS info:

00436752816: Debug (efc_cmds_hardware.cpp)[ 128] showEfcCmd: Flags : 0x00000625

00436752823: Debug (efc_cmds_hardware.cpp)[ 129] showEfcCmd: GUID : 001486045B65D6E8

00436752827: Debug (efc_cmds_hardware.cpp)[ 130] showEfcCmd: HwType : 0x00000AF9

00436752834: Debug (efc_cmds_hardware.cpp)[ 131] showEfcCmd: Version : 5776851272204288

00436752838: Debug (efc_cmds_hardware.cpp)[ 132] showEfcCmd: Vendor : Echo Digital Audio

00436752846: Debug (efc_cmds_hardware.cpp)[ 133] showEfcCmd: Model : AudioFire8

00436752850: Debug (efc_cmds_hardware.cpp)[ 135] showEfcCmd: Supported Clocks : 0x0000001D

00436752857: Debug (efc_cmds_hardware.cpp)[ 136] showEfcCmd: # 1394 Playback : 16

00436752861: Debug (efc_cmds_hardware.cpp)[ 137] showEfcCmd: # 1394 Record : 16

00436752870: Debug (efc_cmds_hardware.cpp)[ 138] showEfcCmd: # Physical out : 16

00436752873: Debug (efc_cmds_hardware.cpp)[ 139] showEfcCmd: # Physical in : 16

00436752880: Debug (efc_cmds_hardware.cpp)[ 142] showEfcCmd: # Output Groups : 2

00436752884: Debug (efc_cmds_hardware.cpp)[ 145] showEfcCmd: Group 0: Type 0x00, count 8

00436752891: Debug (efc_cmds_hardware.cpp)[ 145] showEfcCmd: Group 1: Type 0x03, count 8

00436752895: Debug (efc_cmds_hardware.cpp)[ 147] showEfcCmd: # Input Groups : 2

00436752902: Debug (efc_cmds_hardware.cpp)[ 150] showEfcCmd: Group 0: Type 0x00, count 8

00436752906: Debug (efc_cmds_hardware.cpp)[ 150] showEfcCmd: Group 1: Type 0x03, count 8

00436752913: Debug (efc_cmds_hardware.cpp)[ 152] showEfcCmd: # Midi out : 1

00436752917: Debug (efc_cmds_hardware.cpp)[ 153] showEfcCmd: # Midi in : 1

00436752924: Debug (efc_cmds_hardware.cpp)[ 154] showEfcCmd: Max Sample Rate : 96000

00436752928: Debug (efc_cmds_hardware.cpp)[ 155] showEfcCmd: Min Sample Rate : 32000

00436752935: Debug (efc_cmds_hardware.cpp)[ 156] showEfcCmd: DSP version : 0x00000000

00436752939: Debug (efc_cmds_hardware.cpp)[ 157] showEfcCmd: ARM version : 0x05030000

00436752947: Debug (efc_cmds_hardware.cpp)[ 158] showEfcCmd: # Mix play chann. : 16

00436752950: Debug (efc_cmds_hardware.cpp)[ 159] showEfcCmd: # Mix rec chann. : 16

00436752961: Debug (ffadodevice.cpp)[ 228] showDevice: Attached to port.......: 0 (ohci1394)

00436752969: Debug (ffadodevice.cpp)[ 229] showDevice: Node...................: 1

00436752980: Debug (ffadodevice.cpp)[ 231] showDevice: Vendor name............: Echo Digital Audio

00436752984: Debug (ffadodevice.cpp)[ 233] showDevice: Model name.............: AudioFire8

00436752993: Debug (ffadodevice.cpp)[ 235] showDevice: GUID...................: 001486045b65d6e8

00436753000: Debug (ffadodevice.cpp)[ 240] showDevice: Assigned ID....: dev0

00436753041: Debug (devicemanager.cpp)[1205] showDeviceInfo: Clock sync sources:

00436753352: Debug (efc_cmd.cpp)[ 171] showEfcCmd: EFC Length: 6

00436753364: Debug (efc_cmd.cpp)[ 172] showEfcCmd: EFC Header:

00436753368: Debug (efc_cmd.cpp)[ 173] showEfcCmd: Version : 0x00000000

00436753375: Debug (efc_cmd.cpp)[ 174] showEfcCmd: Sequence number : 0x00000074

00436753379: Debug (efc_cmd.cpp)[ 175] showEfcCmd: Category : 0x00000003

00436753385: Debug (efc_cmd.cpp)[ 176] showEfcCmd: Command : 0x00000001

00436753389: Debug (efc_cmd.cpp)[ 177] showEfcCmd: Return Value : 0x00000000

00436753399: Debug (efc_cmds_hardware_ctrl.cpp)[ 74] showEfcCmd: EFC Get Clock:

00436753403: Debug (efc_cmds_hardware_ctrl.cpp)[ 75] showEfcCmd: Clock : 140733193388032

00436753411: Debug (efc_cmds_hardware_ctrl.cpp)[ 76] showEfcCmd: Samplerate : 140733193484032

00436753415: Debug (efc_cmds_hardware_ctrl.cpp)[ 77] showEfcCmd: Index : 140737488355327

00436756278: Debug (devicemanager.cpp)[1214] showDeviceInfo: Type: Internal , Id: 0, Valid: 1, Active: 1, Locked 1, Slipping: 0, Description: Internal sync

00436756288: Debug (devicemanager.cpp)[1214] showDeviceInfo: Type: WordClock , Id: 2, Valid: 0, Active: 0, Locked 1, Slipping: 0, Description: Word Clock

00436756302: Debug (devicemanager.cpp)[1214] showDeviceInfo: Type: SPDIF , Id: 3, Valid: 0, Active: 0, Locked 1, Slipping: 0, Description: SPDIF

00436756308: Debug (devicemanager.cpp)[1214] showDeviceInfo: Type: ADAT , Id: 4, Valid: 0, Active: 0, Locked 1, Slipping: 0, Description: ADAT 1

no message buffer overruns

Not sure if this will help you, but everything I am running is running from user mode (not sudo or root). I added a udev rule for kernel to always place /dev/raw1394 node in the audio group.


zadmin@zlat1:/etc/udev/rules.d$ ls
70-persistent-cd.rules 70-persistent-net.rules raw1394-audio-group.rules README
zadmin@zlat1:/etc/udev/rules.d$

I created the above file raw1394-audio-group.rules
This is the contents of that file:

# Created by kwz on 2010-03-19 to place raw1394 dev node in the audio group.
# This was done for ffado use of firewire for audio interface.
#
# ffado-dbus-server needs to run under a user who is in the the audio group.
# This rule should allow io to/from the raw1394 firewire dev node.
# /dev/raw1394
#
KERNEL=="raw1394", GROUP="audio"

Note the group permissions for the raw1394 node:

zadmin@zlat1:~$ ls -l /dev/raw1394
crw-rw---- 1 root audio 171, 0 2010-03-22 22:23 /dev/raw1394
zadmin@zlat1:~$

The added udev rule (raw1394-audio-group.rules) makes sure that the Kernel always places raw1394 device node in the audio group. My user "zadmin" is a member of the audio group so has read and write access to that node.

zman58
(Ubuntu Studio v9.10, ECHO AudioFire 8, AMD Athlon X2 64bit)

I didn't completely open up raw1394 on my system. I am using a udev rule which places the raw1394 device node (/dev/raw1394) in the audio group. My user account is in the audio group. Any users in the audio group have access to /dev/raw1394. I tried to post my udev rule last night, but for some reason the server thought it was spam. I will try again this evening to post the rule file that I am using.
zman58
(Ubuntu Studio v9.10, ECHO AudioFire 8, AMD Athlon X2 64bit)

I'd guess FFADO doesn't yet know about the new revision of the AF8.
Please see Adding Device IDs.
(Echo's vendor ID is 0x001486; the known AF8 device ID is 0x000af8.)

Forgive a newb for being dense, but how can you tell from his post that the rev level of his AF8 has changed?.....I guess after my long post that took a bit of time for the moderator to clear, the response was to my own response and that my AF8 identifies itself as an AF9. I will follow the instructions provided and try to get the device added without goofing up the Ubunto Studio version. Thank you for the guidance.

Thanks for the info. I now can report some progress. I have not compiled anything and still working with Ubuntu Studio 9.10 with latest updates from Canonical repository. FFADO revisions have not changed.

!!The ffado-mixer program is now working properly and I can actually see the mixer controls for the hardware I have. :)

This is what I had to do:

Surprise. look at the model id below:

zadmin@zlat1:~$ ffado-test ListDevices
[...]
=== 1394 PORT 0 ===
Node id GUID VendorId ModelId Vendor - Model
0 0x001486025b636d30 0x00001486 0x00000AF9 Echo Digital Audio - AudioFire8
1 0x394fc00037060241 0x00394FC0 0x00000000 Linux - ohci1394 -

I focused on your suggestion about the ID and discovered that the AudioFire 8 that I have reports a newer ModelID. It reports 0x000af9. I used this new device and placed it in the config file for FFADO located at /usr/share/libffado1/configuration

First I made a backup copy:
sudo cp configuration configuration_original_2010-03-22

Then I edited in a new section for my latest AudioFire8 as follows. This needs to be done using sudo or as root. I used vim editor but gedit would have been just fine as well.
(note that i placed the new entry using 0xAF9 first and the second entry is the same one originally in the configuration file which was 0xAF8)

{
vendorid = 0x1486;
modelid = 0xAF9;
vendorname = "Echo";
modelname = "AudioFire8";
driver = 2;
mixer = "AudioFireMixer";
xmit_max_cycles_early_transmit = 2;
},
{
vendorid = 0x1486;
modelid = 0xAF8;
vendorname = "Echo";
modelname = "AudioFire8";
driver = 2;
mixer = "AudioFireMixer";
xmit_max_cycles_early_transmit = 2;
},

After I started ffado-dbus-server things were looking better. I did not get the generic device warning. I'm not sure what the exact differences are between the AF8 and AF9 models but I did notice on the product box that it states "Now with ADAT". Hoping that what I need with existing ffado support will work properly. I'll still need to spend some test time with it, but it looks promising so far.

I just started qjackctl and can see 16 inputs and 16 outputs on the audio tab. This confused me earlier, but now I see on the box for the AudioFire 8 that it states:
"16 in 16 out firewire audio recording with preamps"

I am still not seeing any representation of the MIDI port in qjackctl ALSA connections interface. If anyone can provide any clue about why this is missing I would greatly appreciate it as I would like to be able to connect my MIDI keyboard to the AudioFire 8.

Summary: So far so good for audio but still need to get the MIDI port working under jack.

zman58
(Ubuntu Studio v9.10, ECHO AudioFire 8, AMD Athlon X2 64bit)

Oh man Zman! Thanks for making it all make more sense. I gave up last night trying to figure out what file to vi (tells you how old I am). I never understood why you had to recompile for a l'il old device file change. When I get done with my day php/mysql job I will try this out. Curious, which firewire device are you using? I am using the onboard Via on the Asus M4A78-E 64bit. I heard that a lone guy like me might work perfectly on the Via chipset and that only those pushing hard might have trouble with it and need the TI. Thanks again

I followed your lead and edited the file to include the corrections and it worked great. Thank you. But I did not see the 16 and 16 on the audio tab. But what I did see was an error message like this:

00271343715: Debug (ieee1394service.cpp)[ 521] readNoLock: raw1394_read failed: node 0xFFC0, addr = 0x0000FFFFF0000400, length = 256

Having also made your changes to set raw1384 behaviour at runtime in udev, the access look OK 660 and root/audio were owner/group so I thought I could read it, being a member of the audio group. But something cant read it and is giving me the above nasty message.

And something curious also when the device cannot talk to the pc I would expect that mics in could be monitored with the headphone still...but that seems not to be the case Any ideas where to look would be really appreciated...

Echo audiofire 8 (9)on Ubunto Studio 9-10 on an Asus quadcore 4g & twin 1t HD and onboard firewire ATI but also have a LaCei 400 pci card with TI chipset that I havent got working get

Cladisch,
I have been running my audio setup on a Dell latitude E6400. It has an onboard Richoh chipset for 1394

zadmin@zlat1:~$ lspci
[...]
03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
03:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
03:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11)

zman58
(Ubuntu Studio v9.10, ECHO AudioFire 8)

I am going to spend some time this evening trying to find out what's going on with midi input-output support on the audiofire. MIDI interface for the audiofire 8 does not seem to be working on my system. The midi interface (input or output) does not enumerate in qjackctl interface at all. Perhaps if I peruse through the code I can find some hints about it.

zman58
(Ubuntu Studio v9.10, ECHO AudioFire 8, AMD Athlon X2 64bit)

My experience with MIDI has been very positive - Using a Audiofire Pre8 and running "a2j" I get full MIDI support - tested with a Keyboard and QSynth and Hydrogen. The "a2j" software routes between the older ALSA based MIDI and Jacks internal version.

Euan.

(Ubuntu 9.10, ECHO Audiofire Pre8, AMD 6 Core 64 Bit)

Hey Euan, I'm running Ubuntu as well, but haven't any success with the pre8. How'd you do it?

I can't get the svn ffado packages installed. i can't find the dbus.mainloop.qt and python module 'qt' packages to satisfy ffado. where do you get these?

I believe this is a supported device? You shouldn't need to compile the driver from source. Use Ubuntu 11.04.

All you need to do is goto "System Settings" then "Users and Groups" then "Advanced Settings" then the "User Privileges" Tab and check the "Use Audio Devices" tab. I check all the tabs.

Next goto the new "Ubuntu Software Center" and search "ffado" and install the FFADO-Mixer. You may also want to install Ardour and any other apps you need. To install everything you'll ever need for audio recording goto the "Synaptec Package Manager" and search for "Ubuntu-Studio" and install all the audio related packages.

Three Steps
1.Enabled "Use Audio Devices"
2.Install "FFADO-Mixer"
3.Reboot or logout then back in.

Be patient and wait for the board to boot up. It can take a minute for some hardware.

Hope this helps.
Jazzman

Hi,

Been trying to get an Echo Audiofire Pre8 working at the higher sample rates - 88.2K and 96K. ffado-mixer, jackd and ffado-test will not set these frequencies.

Strange thing, if I run windows and echo console, set the samplerate to 96000, and power down the device and restart in Linux again I can then only access higher
frequencies - 88.2K and 96K and I get an error for the lower ones. Possibly there is a 2X multiplier setting that needs to be set/reset? Jackd also fails to start with the higher frequencies, but that is probably a secondary issue.

I would appreciate any help on what direction to go in or how I can help with this. I'd really love to have full functionality - it's a great piece of kit and the Linux software stack is getting very good.

BTW: I am using the latest SVN snapshots of FFADO on Ubuntu 9.10 (2.6.32.24 kernel)

Thanks.

I just did a fresh install of Arch, installed the latest ffado svn from the aur, and ffado mixer wont recognize my device. jackd will connect and record, but I need the ffado mixer to work for the playback not to be garbage. I set up realtime and have given fw1 temporary access each time I try to use the the device via a:

# chmod 666 /dev/fw1

the firmware version (according to the xp console program) is 5.3, its what it shipped with.

would love to get the device fully working in arch, i know it works in avlinux, but it doesn't have the recent svn version for the newer firmware, and thus has a problem at the higher sample rates (>48000).

alright, trying to recognize the audiofire pre8 from echo. after adding my device id and vendor id to my libffado/configurtion, still no luck with "jackd -P70 -R -d firewire -p 1024 -n 4 -v 6". My bash fills up with:

no message buffer overruns
jackd 0.116.1
Copyright 2001-2005 Paul Davis 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.
cannot lock down memory for jackd (Cannot allocate memory)
loading driver ..
Enhanced3DNow! detected
SSE2 detected
JACK: unable to mlock() port buffers: Cannot allocate memory
JACK: unable to mlock() port buffers: Cannot allocate memory
02023905158: (ffado.cpp)[ 92] ffado_streaming_init: libffado 1.999.43 built Sep 17 2009 20:06:09
02023905347: Debug (Element.cpp)[ 129] setVerboseLevel: Setting verbose level to 6...
02023905361: Debug (StreamProcessorManager.cpp)[1536] setVerboseLevel: Setting verbose level to 6...
02023905383: Debug (devicemanager.cpp)[1179] setVerboseLevel: Setting verbose level to 6...
02023905392: Debug (ffado.cpp)[ 119] ffado_streaming_init: Starting with realtime scheduling, base priority 70
02023905417: Debug (DeviceStringParser.cpp)[ 284] isValidString: isvalid? hw:0
02023905435: Debug (devicemanager.cpp)[ 207] addSpecString: Adding spec string hw:0
02023905454: Debug (DeviceStringParser.cpp)[ 253] parseString: parse: hw:0
02023905463: Debug (DeviceStringParser.cpp)[ 258] parseString: left: hw:0
02023905482: Debug (DeviceStringParser.cpp)[ 56] parse: parse: hw:0
02023905504: Debug (ffado.cpp)[ 148] ffado_streaming_init: setting slave mode to 0
02023905548: Debug (ffado.cpp)[ 154] ffado_streaming_init: setting snoop mode to 0
02023905921: Debug (Configuration.cpp)[ 63] openFile: Could not open file: ~/.ffado/configuration
02023910924: Fatal (devicemanager.cpp)[ 165] initialize: No firewire adapters (ports) found.
02023910950: Fatal (ffado.cpp)[ 160] ffado_streaming_init: Could not initialize device manager
02023910982: Debug (Configuration.cpp)[ 138] save: Not saving temporary config file: temporary
firewire ERR: Error creating FFADO streaming device
cannot load driver module firewire
02023910993: Debug (Configuration.cpp)[ 135] save: Not saving readonly config file: /usr/share/libffado1//configuration
no message buffer overruns

interesting, no?

Hi, I'd like to know if there are some known issues using this interface on a JMicron Firewire port (I have one on my hp pavillon dv6-2193el laptop computer, on wich I hade some problems with a Focusrite SaffirePro26 too who should have been full supported on ffado)

thank you all!

I can't directly comment since I have no experience with JMicron's chipsets. If you don't get a response here you may wish to post to the ffado-users or ffado-devel mailing lists. There are people on those (particularly the latter) who may have personal experience.

Generally speaking we try to keep notes about various chipsets on http://subversion.ffado.org/wiki/HostControllers but looking on there I don't see anything specifically about JMicron chipsets. I have a vague memory of reading about problems with JMicron devices but I can't recall where that was or in what context it was in.

The other thing to not is that with some manufacturers we have found some of their chipsets to be good and others to be bad (eg: VIA, as noted on the above wiki page). In order for others to comment on your particular chip we'll need to know what it is. The required information can be found by running "lspci -v" in a terminal. Find the section relating to the firewire card and use that to determine what exactly it is. Post that information here or into a message on ffado-devel and we'll see what we can come up with.

thank you for the answer, here it is the result of the "lspci -v" command, the firewire voice:

04:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller (prog-if 10)
Subsystem: Hewlett-Packard Company Device 3659
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at d8100000 (32-bit, non-prefetchable) [size=2K]
Memory at d8100d00 (32-bit, non-prefetchable) [size=128]
Memory at d8100c80 (32-bit, non-prefetchable) [size=128]
Memory at d8100c00 (32-bit, non-prefetchable) [size=128]
Capabilities:
Kernel driver in use: ohci1394
Kernel modules: firewire-ohci, ohci1394

I'll wait for an answer here, but if you think it's better I'll send a message on the ffado-devel

Thanks for this information. As I said, I cannot make any direct comments since I have no experience with either JMicron nor Echo devices. I would suggest that if no one chimes in here in the next day or so that you post to ffado-devel and see what follows from that.

In the meantime, could you provide a description of the problems that you're seeing? You mentioned that you were having problems but I don't think any details were included.

if you post to ffado-devel, please include the above information about your card. You may also like to post the entire output of ffado-diag since that can sometimes help pick up potential sources of problems. Obviously also include a description of the issues that you're seeing.

Thank you, I think I'm gonna post on the ffado-devel (I don't get precisley how to do it: I have to send an email to ffado-devel@lists.sourceforge.net, right?

by the way I haven't got any problem, since I don't have the echo device: I just wonder if it would work because I had a Focusrite SaffirePro 26 that is reported as full support here, that worked on my desktop pc, but didn't on my laptop (on my desktop I have a Texas Instrument firewire chipset with the 6-pole plug, while on the laptop I have the 4-pole plug with this JMicron Chipset).

the ffado-diag command shows up this:

emiliano@ubuntu791:~$ ffado-diag

FFADO diagnostic utility 0.1
============================
(C) 2008 Pieter Palmers

=== CHECK ===
Base system...
kernel version............ 2.6.32-26-preempt
FIXME: implement test for RT kernel
RT patched............... False
old 1394 stack present.... True
old 1394 stack loaded..... True
old 1394 stack active..... True
new 1394 stack present.... True
new 1394 stack loaded..... False
new 1394 stack active..... False
/dev/raw1394 node present. True
/dev/raw1394 permissions.. True
Prerequisites (dynamic at run-time)...
gcc................ gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
g++................ g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
PyQt............... sh: pyuic: not found
jackd.............. jackd version 0.120.1 tmpdir /dev/shm protocol 24
path............. /usr/bin/jackd
flags............ -L/usr/lib64 -ljack -lpthread -lrt
libraw1394......... 2.0.4
flags............ -lraw1394
libavc1394......... Package libavc1394 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavc1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavc1394' found
flags............ Package libavc1394 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavc1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavc1394' found
libiec61883........ 1.2.0
flags............ -liec61883 -lraw1394
libxml++-2.6....... 2.30.0
flags............ -pthread -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgthread-2.0 -lrt -lglib-2.0
dbus-1............. 1.2.16
flags............ -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -L/lib -ldbus-1 -lpthread -lrt
Prerequisites (static at compile-time)...
gcc................ gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
g++................ g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
PyQt............... sh: pyuic: not found
jackd.............. jackd version 0.118.0 tmpdir /dev/shm protocol 24
path............. /usr/bin/jackd
flags............ Package jack was not found in the pkg-config search path.
libraw1394......... 2.0.4
flags............ -lraw1394
libavc1394......... Package libavc1394 was not found in the pkg-config search path.
flags............ Package libavc1394 was not found in the pkg-config search path.
libiec61883........ 1.2.0
flags............ -liec61883 -lraw1394
libxml++-2.6....... 2.30.0
flags............ -pthread -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgthread-2.0 -lrt -lglib-2.0
dbus-1............. 1.2.16
flags............ -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -L/lib -ldbus-1 -lpthread -lrt
Hardware...
Host controllers:
04:00.0 FireWire (IEEE 1394) [0c00]: JMicron Technology Corp. IEEE 1394 Host Controller [197b:2380] (prog-if 10)
Subsystem: Hewlett-Packard Company Device [103c:3659]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: ohci1394
Kernel modules: firewire-ohci, ohci1394

CPU info:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3192.31
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.83
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.83
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.83
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 4
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.83
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 5
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.83
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 6
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.84
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz
stepping : 5
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips : 3191.84
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Configuration...
IRQ information
Hardware Interrupts:
--------------------
IRQ 0: PID: None, count: [141, 141, 141, 141, 141, 141, 141, 141], Sched None (priority None), drivers: ['timer']
IRQ 1: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['i8042']
IRQ 4: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['enecir']
IRQ 8: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['rtc0']
IRQ 9: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['acpi']
IRQ 12: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['i8042']
IRQ 16: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['ehci_hcd:usb1', 'ohci1394', 'jmb38x_ms:slot0', 'eth1', 'mmc0', 'HDA Intel', 'nvidia']
IRQ 21: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['ehci_hcd:usb2']
IRQ 22: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['HDA Intel']
IRQ 24: PID: None, count: [11854, 11854, 11854, 11854, 11854, 11854, 11854, 11854], Sched None (priority None), drivers: ['hpet2']
IRQ 25: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['hpet3']
IRQ 26: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['hpet4']
IRQ 27: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['hpet5']
IRQ 28: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['hpet6']
IRQ 34: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['ahci']
IRQ 35: PID: None, count: [0, 0, 0, 0, 0, 0, 0, 0], Sched None (priority None), drivers: ['eth0']

Software Interrupts:
--------------------

=== REPORT ===
FireWire kernel drivers:
[PASS] Kernel modules present and correctly loaded.
[PASS] /dev/raw1394 node present and accessible.

About the mailing lists: you are correct that to post to the list you send an email to that address. However, before doing so you will need to subscribe to the applicable list. You can do this by accessing the webpage at http://sourceforge.net/mail/?group_id=192582 and using the "subscribe" link for the desired list. Once you're subscribed you will be able to post to the list. The above page also includes links to unsubscribe. When you do subscribe you'll receive an email with usage instructions.

Thank you for clarifying the nature of your enquiry. Given that there's been little feedback here on the forum I agree with your idea that the posting to ffado-devel is probably the best bet at the moment. It's interesting that the Saffire pro26 didn't work with your laptop and it may point to there being a chipset issue but I really don't have the personal experience to call this. Hopefully by posting your query will be seen by others who do and they will be able to offer suggestions. Note that because you don't have the pro26 it may not be possible to get to the bottom of the problem since to do that would probably require further testing. At the very least it would help if you could describe the sort of trouble you were having.

Besides the JMicron chipset, your ffado-diag output didn't contain anything which stuck me as being particularly worrying with the exception of the IRQ list. This indicates that the firewire interface (ohci1394) is sharing an interrupt with a whole bunch of stuff: a USB host controller, a card reader, a network card, the onboard sound chip and the nvidia video driver. That's a pretty busy interrupt line and it may be at least part of the reason for your problems. If problems seemed to be associated with the movement of a USB mouse it would be interesting to try without that mouse attached. The proprietary closed-source nvidia video card has also given ffado grief in the past even when it didn't share the same IRQ as the firewire port. Because it's closed-source there's very little we can do about it except suggest a retest without this in use. I have helped a number of people whose xruns and stability issues went away when they disabled the nvidia driver.

Based on the info you have now provided, there may be more than one cause of your troubles. It seems that the heavy sharing of IRQ 16 on the laptop may well be a contributing factor. However, you can't do a lot about that because the IRQs are generally hard-wired. The use of the closed-source nvidia video driver kernel module is another possible problem since this has been problematic for other users. Finally, the JMicron card itself may not be helping things. The first two can only really be explored by yourself since it involves testing on your laptop. In the meantime, posting to ffado-devel about the JMicron chipset is worthwhile to get the views of others on this chip. You may like to include a reference to this thread of discussion too.

thank you!! I've written to the ffado-devel!

by the way, I've understood more or less the IRQ 16 matter, but I didn't get perfectly how to solve it: I can make a try with no usb peripherals plugged, but I'm not sure on how to disable the nvidia drivers...then I've seen there are a lot of other voice on that line...maybe my problems come from this? I'd like to try and see if it's better!

Solving the IRQ issue - assuming that it is an issue - is very much dependent on your particular laptop and the Linux distribution you are running. As you mentioned, it's easy enough to try things without USB devices plugged in, but some of the others aren't quite so easy to deal with. If you can find a way to temporarily disable the nvidia drivers on your system it would be worth doing this as a test. In the past we've had a number of people who reported problems with ffado which disappeared when the closed-source nvidia driver was removed from the system, so it's quite likely that this is at least a part of your problem too.

As to how you do this disabling, it depends on your distribution. In the first instance it might be worth googling something like "disable nvidia Ubuntu" (replacing "Ubuntu" with the name of your distribution) and see what you come up with.

You were right, I'm on Ubuntu, Ubuntu Studio 10.04...
do I have to go to System->Administration->Hardware Drivers and disable the nVidia drivers?
I'll try to do it, but unfortunatly now I had "just" the MOTU 828 mkII which I think has some problems just due to the not full support of the ffado drivers (I know, I shouldn't have taken a motu on linux)

I don't personally use Ubuntu so I don't really know how one might go about disabling the nvidia driver. Sorry. Google may help here.

FYI I wrote and maintain the MOTU driver in ffado. I initially wrote it for the Traveler (which I have) but over the years I have been able to extend it to many other MOTU devices thanks to information provided by owners of those interfaces. The 828Mk2 works well with ffado by all accounts - numerous people have reported it to be stable and very usable. If it gives you trouble then (depending on exactly what it is that's going wrong) it probably indicates some kind of system-level setup problem.

Did you want to try to identify the causes of the problems you're seeing with the 828mk2?

Is there any chance you can borrow a firewire card based on some other chipset to try things out on? If the symptoms change at least it might tell us something.

Were you the person who posted to ffado-devel about the jmicron chipset? I didn't read the replies all that closely but my recollection is that there was at least one suggestion that the chipset may be problematic.

Yes, I was the one who posted about the jmicron, and I got some replies, and I've understood that the real problem is the chipset. I have tried to use an express card with a Texas Intrsument chipset, but it didn't work at all (the lspci found it, but when I plug the device to the port it couldn't be recognized and it didn't work)
maybe I should try with another card and see if now it works, by the way I have posted my problems with my MOTU on the relative page here on the site. and, by the way, I had problems with it even on my desktop pc.
I wonder if I've something wrong in my system, but I really don't know what!
by the way thank you for all the support!

If the device wasn't recognised when the TI-based express card was used then that's a little odd. If after plugging in the MOTU and turning it on, it would be good if you could run dmesg and see if the MOTU device was detected at the kernel level. With the old stack you'll see some messages starting with "ieee1394" talking about a Node being added among other things. I think the new stack does something similar but the messages probably start with "firewire" in that case.

This of course assumes you still have access to the expresscard. Anyway, if dmesg does not report the registration of the MOTU on the bus then that indicates a bus-level problem.

Regarding your previous posts on the device-specific page, I think I vaguely recall these. I'll have to go back and check, but my memory is that at the time we were starting to suspect that the MOTU itself may have had a fault. Or maybe this was another user.

Unfortunatly I don't have the card anymore so I cannot do this test. By the way the problems with the motu 828 mkII are on the notebook and the desktop pc with no differences (and on this one I have a Texas Instrument chipset on wich the 828 works perfectly on Windows, so no chipset problems)
By the way I don't think this is the right place to talk about my problems with my MOTU, don't you think so too? :)
thank you for all your support, I've understood, if I'd like to try the Echo Audiofire8, that first of all I should make another try with another firewire expresscard.
(anyway, I think I'll wait for the full support of the RME stuffs, I just love them)

In relation to not having the card anymore, I understand.

Regarding the MOTU difficulties, I agree it's out of place in this particular section of the website. If you wish to pursue the MOTU issues, perhaps email me directly and we can pick it up from there (I'm jwoithe on the ffado-devel list, which should be enough for your to find my address). Something fishy would appear to be going on with this since others have had success with the 828mk2. I will note in passing that just because the card works under one OS doesn't mean it should work under another. There may be, for all we know, a bug on the chip which is silently worked around in other OSes. Having said that, TI chipsets are usually rock solid so I agree that it's unlikely to be chipset related, at least not on the TI-equipped machine.

Your comment about trying with another firewire card is probably the best option at this point, assuming you've ruled out the other obvious things such as bad cables and bad sockets.

Finally, there is progress being made on the RMEs now. Check out the recent announcement on the main page, and keep an eye on ffado-devel for updates.

Is this device supported? Since AudioFire 8 is, and this seems to be the same device only with 8 mic preamps I was wondering... I tried to add the device but couldn't so I figured I'd ask the question on the support page of the closest device.

Thank you!

Gabe.

Is there some ffado equivalent to the "digital mode" feature mentioned in the audiofire manual?
See http://echoaudio.com/Downloads/Manuals/AudioFire%20Windows%20Manual%20v2... page 33

Perhaps related, I can't get the thing to work at clock rates faster than 48KHz, even if I tell it to sync to spdif and supply 88K2.

$ /usr/bin/ffado-test -v 3 -n 1 SetSamplerate 88200
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 2.0.0
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

03366412163: Warning (fireworks_device.cpp)[ 134] discover: Using generic ECHO Audio FireWorks support for unsupported device 'Echo Digital Audio AudioFire8'
03366922861: Warning (avc_plug.cpp)[ 885] setSampleRate: output plug signal format command not accepted
03366923074: Error (avc_plug.cpp)[ 996] setSampleRate: setSampleRatePlug: PCR Unknown Input plug 0 does not support sample rate 88200
03366923080: Error (avc_avdevice.cpp)[ 250] setSamplingFrequency: setSampleRate: Setting sample rate failed
Could not set samplerate
no message buffer overruns

Thought you'd like to see the error:

$ /usr/bin/ffado-test -v 3 -n 1 SetSamplerate 88200
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 2.0.0
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

03366412163: Warning (fireworks_device.cpp)[ 134] discover: Using generic ECHO Audio FireWorks support for unsupported device 'Echo Digital Audio AudioFire8'
03366922861: Warning (avc_plug.cpp)[ 885] setSampleRate: output plug signal format command not accepted
03366923074: Error (avc_plug.cpp)[ 996] setSampleRate: setSampleRatePlug: PCR Unknown Input plug 0 does not support sample rate 88200
03366923080: Error (avc_avdevice.cpp)[ 250] setSamplingFrequency: setSampleRate: Setting sample rate failed
Could not set samplerate
no message buffer overruns

Just built ffado from svn and the problem is fixed.

All sample rates work

Ffado version seems to be called "2.999.0-2008" (retrieved 22nd Nov 2011)
If you need to do this then see http://subversion.ffado.org/wiki/InstallingFfadoFromSource
This Ffado works OK with the Jack version in Ubuntu 10.04

- the mixer now has pads on it but no digital mode selector.

The windows driver for the 8a includes a digital mode control with 3 options:
spdif coax or spdif optical or adat optical
There is no such feature on the the ffado mixer for this device.
Could I do anything to help?

Echo have added one to the ID.

$ ffado-test ListDevices
...
=== 1394 PORT 0 ===
Node id GUID VendorId ModelId Vendor - Model
0 0x001e8c0000a9f033 0x00001E8C 0x00000000 Linux - ohci1394 -
1 0x001486085b68e02a 0x00001486 0x00000AF9 Echo Digital Audio - AudioFire8

Thanks for the information.

This revised ID is already in our main development trunk - the respective model name is AudioFire8a. It was added in r1817 in April 2010. However, this change did not make it into our last release (2.0.1), so if this is the version of ffado you have on your system that probably explains why you needed to add it.

On a windows computer I installed the echo driver version 5.7 and connected the audiofire
On first connection the driver flashed the memory of the AudioFire - now it reports its name as 8a:

$ ffado-test ListDevices
...
=== 1394 PORT 0 ===
Node id GUID VendorId ModelId Vendor - Model
0 0x001e8c0000a9f033 0x00001E8C 0x00000000 Linux - ohci1394 -
1 0x001486085b68e02a 0x00001486 0x00000AF9 Echo Digital Audio - AudioFire8a

It would seem that after the firmware update everything is behaving normally. I do know that certain devices need their recent firmware revisions to work correctly with ffado. Perhaps the AudioFire8 is one of them (that's what seems to be the case from what I understand from your observations). Given that your version of ffado obviously knows about the "AudioFire8a" id it's about the only reason I can think of that it failed to do so previously (unless you've also upgraded ffado in the meantime).

Anyway, whatever changes have been made it now appears that ffado is at least correctly identifying your AudioFire8 - a good thing.