Ticket #360 (reopened bug)

Opened 2 years ago

Last modified 4 months ago

Make echo audiofire 8 and audiofire 12 work with recent firmwares

Reported by: picander Assigned to:
Priority: waiting for volunteer Milestone: Indeterminant (awaiting volunteer)
Component: devices/fireworks Version: FFADO SVN (trunk)
Keywords: fireworks, ubuntu, studio, audiofire Cc:
The device the bug applies to: Echo Audiofire 12

Description

We echo af8 / af12 owners are forced to install old firmware in order to make the devices work. Downgrading firmware solves (it worked out with an af8 and an af12), but i would like not to touch firmware anymore since my device returned after 5 month of repair because of a simple firmware issue.

This is how my Audiofire12 with latest firewire reacts:

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

=== 1394 PORT 0 ===
  Node id  GUID                  VendorId     ModelId   Vendor - Model
   0       0x001486a29d93a638  0x00001486  0x0000AF12   Echo Digital Audio - AudioFire12
   1       0x00027a080001f54d  0x0000027A  0x00000000   Linux Firewire - 

minibox libffado # ffado-test Discover
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 2.999.0-esportato
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

1478538377137: Warning (efc_avc_cmd.cpp)[  90] deserialize: Deserialization failed
1478538377249: Error (fireworks_device.cpp)[ 216] doEfcOverAVC: EfcOverAVCCmd command failed                                                                    
1478538377275: Error (fireworks_device.cpp)[ 737] readFlash: Flash read failed for block 0x00008000 (64 quadlets)                                               
1478538377293: Error (fireworks_session_block.cpp)[ 129] loadFromDevice: Flash read failed                                                                      
1478538377315: Error (fireworks_device.cpp)[ 426] loadSession: Could not load session block                                                                     
1478538377331: Warning (fireworks_device.cpp)[ 366] buildMixer: Could not load session                                                                          
1478538377572: Warning (efc_avc_cmd.cpp)[  90] deserialize: Deserialization failed                                                                              
1478538377616: Error (fireworks_device.cpp)[ 216] doEfcOverAVC: EfcOverAVCCmd command failed                                                                    
1478538377643: Error (fireworks_device.cpp)[ 623] getClock: Could not get clock info                                                                            
Errore di segmentazione (segfault)
minibox libffado # ffado-diag 


FFADO diagnostic utility 2.999.0-esportato
============================
(C) 2008 Pieter Palmers
    2009-2010 Arnold Krille


=== CHECK ===
 Base system...
  kernel version............ 3.1.10
  old 1394 stack present.... False
  old 1394 stack loaded..... False
  old 1394 stack active..... False
  new 1394 stack present.... True
  new 1394 stack loaded..... True
  new 1394 stack active..... True
  /dev/raw1394 node present. False
 Prerequisites (dynamic at run-time)...
   gcc ............... gcc (Gentoo 4.5.3-r2 p1.0, pie-0.4.7) 4.5.3
   g++ ............... g++ (Gentoo 4.5.3-r2 p1.0, pie-0.4.7) 4.5.3
   PyQt4 (by pyuic4) . Python User Interface Compiler 4.8.1 for Qt version 4.6.3
   jackd ............. jackd version 0.121.3 tmpdir /dev/shm protocol 24
     path ............ /usr/bin/jackd
     flags ...........  -ljack -lpthread -lrt  
   libraw1394 ........ 2.0.8
     flags ...........  -lraw1394  
   libavc1394 ........ 0.5.3
     flags ...........  -lavc1394 -lrom1394 -lraw1394  
   libiec61883 ....... 1.1.0
     flags ...........  -liec61883 -lraw1394  
   libxml++-2.6 ...... 2.22.0
     flags ........... -pthread -I/usr/include/libxml++-2.6 -I/usr/lib64/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/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.24
     flags ........... -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include  -ldbus-1 -lpthread -lrt  
 Prerequisites (static at compile-time)...
   gcc ............... gcc (Gentoo 4.4.5 p1.0, pie-0.4.5) 4.4.5
   g++ ............... g++ (Gentoo 4.4.5 p1.0, pie-0.4.5) 4.4.5
   PyQt4 (by pyuic4) . Python User Interface Compiler 4.8.1 for Qt version 4.6.3
   jackd ............. jackd version 0.121.3 tmpdir /dev/shm protocol 24
     path ............ /usr/bin/jackd
     flags ...........  -ljack -lpthread -lrt  
   libraw1394 ........ 2.0.7
     flags ...........  -lraw1394  
   libavc1394 ........ 0.5.3
     flags ...........  -lavc1394 -lrom1394 -lraw1394  
   libiec61883 ....... 1.1.0
     flags ...........  -liec61883 -lraw1394  
   libxml++-2.6 ...... 2.22.0
     flags ........... -pthread -I/usr/include/libxml++-2.6 -I/usr/lib64/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/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.24
     flags ........... -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include  -ldbus-1 -lpthread -lrt  
 Hardware...
   Host controllers:
01:06.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] (prog-if 10 [OHCI])
        Subsystem: IOI Technology Corp Device [1546:8031]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (500ns min, 1000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at fcfff800 (32-bit, non-prefetchable) [size=2K]
        Region 1: Memory at fcff8000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
        Kernel driver in use: firewire_ohci
        Kernel modules: firewire-ohci

   CPU info:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    2
CPU socket(s):         1
NUMA node(s):          1
Vendor ID:             AuthenticAMD
CPU family:            15
Model:                 107
Stepping:              2
CPU MHz:               2600.085
BogoMIPS:              5199.67
Virtualization:        AMD-V
L1d cache:             64K
L1i cache:             64K
L2 cache:              512K
NUMA node0 CPU(s):     0,1
 Configuration...
  IRQ information
Hardware Interrupts:
--------------------
 IRQ    0: PID:  None, count:         [144, 144], Sched None (priority None), drivers: ['timer']
 IRQ    1: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['i8042']
 IRQ    4: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['']
 IRQ    7: PID:  None, count:             [1, 1], Sched None (priority None), drivers: ['']
 IRQ    8: PID:  None, count:             [1, 1], Sched None (priority None), drivers: ['rtc0']
 IRQ    9: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['acpi']
 IRQ   12: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['i8042']
 IRQ   14: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['pata_amd']
 IRQ   15: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['pata_amd']
 IRQ   16: PID:  None, count:     [12063, 12063], Sched None (priority None), drivers: ['snd_hda_intel']
 IRQ   17: PID:  None, count:     [58465, 58465], Sched None (priority None), drivers: ['firewire_ohci']
 IRQ   19: PID:  None, count:     [44155, 44155], Sched None (priority None), drivers: ['nvidia']
 IRQ   20: PID:  None, count:             [0, 0], Sched None (priority None), drivers: ['ehci_hcd:usb2']
 IRQ   21: PID:  None, count:     [10330, 10330], Sched None (priority None), drivers: ['ehci_hcd:usb1', 'snd_hda_intel']
 IRQ   22: PID:  None, count:             [3, 3], Sched None (priority None), drivers: ['ohci_hcd:usb4']
 IRQ   23: PID:  None, count:     [67930, 67930], Sched None (priority None), drivers: ['ohci_hcd:usb3']
 IRQ   40: PID:  None, count:     [11966, 11966], Sched None (priority None), drivers: ['ahci']
 IRQ   41: PID:  None, count:   [121152, 121152], Sched None (priority None), drivers: ['eth0']

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


=== REPORT ===
FireWire kernel drivers:

The new FireWire kernel stack is loaded. 
This is still kind of experimental. If you encounter problems, please also check
with the old stack.


Attachments

debug.txt (21.0 kB) - added by picander on 08/07/12 14:37:56.
recent Discover gives more debug info
debug.2.txt (50.1 kB) - added by ruxxes on 06/19/14 08:02:55.
FFADO error log (from SVN on Ubuntu Studio 14.04 amd64)
Screenshot.jpg (120.7 kB) - added by ruxxes on 06/19/14 08:03:50.
Error screenshot: "Could not select 48000 as sample rate"

Change History

08/07/12 14:37:56 changed by picander

  • attachment debug.txt added.

recent Discover gives more debug info

08/07/12 15:08:51 changed by picander

trying to recompile with libraw1394-2.1.0 didn't help

08/07/12 16:36:43 changed by jwoithe

  • priority changed from blocker to waiting for device info.
  • milestone set to Indeterminant (need device info).

Thanks for your detailed report picander, and I understand the inconvenience this firmware issue causes.

I should note that compared to version 2.0.7 or 2.0.8 I would not expect libraw1394 2.1.0 to make a difference, so your observations in this respect are as expected.

Unfortunately, to make progress towards fixing this issue we will need someone who:

  • Has one of the affected devices
  • Has documentation about the new firmware and how it differs from the old
  • Possesses the programming knowledge to modify FFADO to work with the new firmware

I do not have an AF device (and I'm not in the position to personally purchase one just for this exercise) nor am I in possession of programming documentation for these devices. I'm also pretty rusty on the whole AVC thing given that none of the devices I have and support make use of it. As much as I'd like to assist, all this makes it pretty much impossible for me to do so at this stage. To my knowledge the only person on the FFADO team who would be in a position to address this firmware issue is Pieter(1), and other commitments mean that he has no time for FFADO work at present. That said, he may have ideas as to why the newer firmware trips FFADO up like this. Taken at face value by someone without any clue about the AVC protocol (ie: me), it looks like there's a bunch of AVC features which the newer firmware makes use of but are unimplemented in FFADO.

Regrettably, this means that until someone steps forward to do this work I can't see that the situation can be addressed. Since there's no realistic chance that this will be rectified in the near future I will not consider this a release blocker; 2.1 has been delayed for far too long already and it makes no sense to block it with something for which there's no definite timeline. To fix the problem we effectively require additional information about the device and its firmware. I have set the priority and milestone to reflect this for the moment.

Having written all that (and despite the rather dire indications in the debug log provided), the problem may be relatively straight-forward to fix to someone familiar with the way these devices work. In any case, patches to address this problem would be more than welcome.

For the purposes of documenting the present situation it would be good to know which firmware versions work with FFADO and which ones fail.

(1) If there is another developer with an AF device I apologise stand corrected. I'm not presently aware of any others though.

08/07/12 23:54:17 changed by picander

4.8 is the last working one to my knowledge. I put the "blocks" priority just because it blocks me to use the device (not a second of sound) :) Maybe it's time to update the supported card database and change the Echo Audiofire's as partially supported?

08/08/12 00:09:12 changed by jwoithe

Replying to picander:

4.8 is the last working one to my knowledge

Great - thanks for this information.

I put the "blocks" priority just because it blocks me to use the device

Right, I understand. FYI in the context of the priorities, "blocker" means that a release cannot happen until the issue is resolved.

Maybe it's time to update the supported card database and change the Echo Audiofire's as partially supported?

Yes, you have a point there and it's something that was at the back of my mind as I was writing my reply earlier today. I'd like to hold off making such a change for a short time though to give others a chance to respond to the issue that you've raised. Historically Echo have been good to the FFADO project, so it would be good to know exactly how the current situation has come about before making rash decisions. I strongly suspect that the problem is that FFADO doesn't implement parts of the AVC model which the recent AudioFire? firmwares make use of, but it would be good to have this confirmed (or shot down in flames) by someone who is familiar with these things.

Let's see what comes out over the next few days.

08/08/12 02:49:51 changed by cladisch

This was talked about back in April on FFADO-user ("Audiofire 8 - getting it to work").

With the new firmware, several commands do not return data in their response packets.

It's possible that this might be fixed by behaving like the Windows driver, i.e., not using FCP.

08/08/12 06:22:49 changed by picander

This is the thread: http://sourceforge.net/mailarchive/message.php?msg_id=29172992

Maybe we could ask Pieter how were he in contact with Echo Audio just to try to ask them what happened with >=5 firmwares? Does he still write in dev mailing list, or answer to direct emails?

(follow-up: ↓ 8 ) 08/08/12 16:35:31 changed by jwoithe

In reply to Clemens:

This was talked about back in April on FFADO-user

Ah yes, so it was. I'm glad that someone has a better memory for these details than I apparently do. Thanks picander for providing a link to the relevant thread for easy reference. Putting all this together, it's safe to say that this issue will only be resolved when someone sits down with one of the affected devices, works out why FFADO is failing (possibly in consultation with Echo) and fixes the prooblem.

Pieter does, as far as I know, still intermittantly lurk on the dev mailing list and as such will most likely see this series of comments (they are CCed to the ffado-dev list). If he has anything to add I expect he'll say something in due course.

(in reply to: ↑ 7 ) 08/09/12 01:22:39 changed by ppalmers

Replying to jwoithe:

In reply to Clemens:

This was talked about back in April on FFADO-user

Pieter does, as far as I know, still intermittantly lurk on the dev mailing list and as such will most likely see this series of comments (they are CCed to the ffado-dev list). If he has anything to add I expect he'll say something in due course.

It has been quite a while since I've looked at the mailing list, sorry for that. Life is interfering quite hard these days.

The only way to update the firmware for echo devices is to install a new driver. The driver will keep the firmware on the device in sync with what it expects. As a result the guys at ECHO don't really care about backwards compatibility (understandable from their point of view). We had the same issue with one of the previous firmware versions.

Unfortunately I don't have the time to dig deep in to this at the moment. If someone else does have the time to look in to this, I can bring them in touch with my contact at ECHO. In the mean time you'll have to stick with the working firmware version.

(follow-up: ↓ 10 ) 08/09/12 10:13:10 changed by picander

is it possible to update the firmware from a linux machine or is the uploader broken?

(in reply to: ↑ 9 ) 08/10/12 00:00:57 changed by ppalmers

Replying to picander:

is it possible to update the firmware from a linux machine or is the uploader broken?

It used to work, but that might have changed. I don't know.

08/27/12 12:56:43 changed by picander

Unfortunately it doesn't. Should I file a new bug? The error code is:

(snip)
01190422039:  (fireworks-downloader.cpp)[ 350] main:  loading file...
01190456537:  (fireworks-downloader.cpp)[ 361] main:  checking file...
01190456602:  (fireworks-downloader.cpp)[ 373] main:   seems to be valid firmware for this device...
01190456625:  (fireworks-downloader.cpp)[ 379] main:  lock flash...
01190456958:  (fireworks-downloader.cpp)[ 381] main:   Could not lock flash

(follow-up: ↓ 17 ) 08/27/12 13:35:59 changed by picander

by the way, someone at Echo answered me he can help us with this bug, we only need someone of us who knows ffado enough to debug the problem. Who jumps in? So "Waiting for device info" is not completely correct since we only need someone to ask for it ;)

08/27/12 16:59:17 changed by jwoithe

In reply to Picander in comment 11:

Unfortunately it doesn't. Should I file a new bug?

Ultimately it might be something to do. However, it's possibly best to wait until it's possible to confirm that the failure of the firmware updater doesn't have the same root cause as the other problems being observed with the device. I think it's unlikely that the two are linked, but until proven otherwise it's always a possibility.

Replying to Picander in comment 12:

someone at Echo answered me he can help us with this bug, we only need someone of us who knows ffado enough to debug the problem. Who jumps in?

This is good news. As to who jumps in, the obvious choice would ordinarily be Pieter: he wrote the driver and was in contact with echo originally. However, as he has previously stated he doesn't currently have the time to spend on FFADO. So someone else is going to have to step up. They will need to have either an audiofire 8 or 12 themselves because debugging things like this without the device is pretty much impossible. The difficulty is that they either need an understanding of the driver or be in a position to study it to gain this understanding. While myself or any of the other developers have skills to do the latter, to my knowledge none of us have an Audiofire device. We are therefore relying on someone else to volunteer to take this on (or for one of the developers to have an Audiofire 8 or 12 donated to them to facilitate this work).

Waiting for device info" is not completely correct since we only need someone to ask for it

To a point, yes. It is however the closest category we have (and we don't want too many fine-grained categories or else it becomes too hard to work out where things are at). Technically it is still correct: while the information required is evidently readily available, we are still waiting for it and will be until someone with the prerequisites comes along and asks for it. I take your point though: the situation with these devices is not quite the same as the others in this category; in all other cases the information is not forthcoming, while for these Echo devices the information will be made available when we have someone to use it. I'll have a think about whether I can do anything to make this more obvious.

The true situation is probably "waiting for someone with an affected device who can look into these issues and contact Echo to obtain the information they will require to fix the bug". It's a bit long-winded though. :-)

08/28/12 00:22:47 changed by ppalmers

I will try and find some time in the next month. No promises though.

(follow-up: ↓ 16 ) 10/26/12 11:57:49 changed by ajaaskel

1) I have both Audiofire 12 and 8. I could manage with AF12 alone, would AF8 help you as a test box ?

2) There are two generations of Audiofire with different AD/DA chips and FireWire? interface/DSP board looks a bit different. I guess those are looking driver-wise same but I have no exact data on that. Both of my AF units are older revision with Cirrus Logic AD/DA (CS4272 codecs). DSP is TMS320C6713, FireWire? chip TSB43CB43A, Flash chip is JS28F160 (checked from AF12).

(in reply to: ↑ 15 ) 10/30/12 04:22:48 changed by jwoithe

Replying to ajaaskel:

1) I have both Audiofire 12 and 8. I could manage with AF12 alone, would AF8 help you as a test box ?

I myself don't have any audiofire devices to test, so if I was to start hacking on the driver I would need at least one. One impediment is that I'm in Australia, and freight from anywhere in the world is surprisingly expensive. In the first instance it would probably work out quicker if someone already familiar with the AF devices and their driver could take a look. Pieter may yet find time to do this at some point. I'm also unsure as to which devices Pieter has access to.

In the long run, having a developer with access to an AF8 would help; it's just a case of determining the most appropriate person. I guess it's a case of "stay tuned" for the moment.

2) There are two generations of Audiofire with different AD/DA chips and FireWire? interface/DSP board looks a bit different. I guess those are looking driver-wise same but I have no exact data on that.

No, me neither. It may be that the newer firmware was brought out to support the new hardware revision (possibly including the necessary details to ensure backwards compatibility with the older version). We may never know.

Both of my AF units are older revision with Cirrus Logic AD/DA (CS4272 codecs). DSP is TMS320C6713, FireWire? chip TSB43CB43A, Flash chip is JS28F160 (checked from AF12).

As with most other interfaces, the key details for most of these chips is in the device's firmware. In the AF case, this would at least partly reside in the TMS code, but there could be other chips in there which take "firmware" (an FPGA for example). Since the code running on these chips is proprietary, the device data sheets won't include what we need to know. Even so, it's good to have knowledge of the hardware used; it could come in handy.

(in reply to: ↑ 12 ) 02/23/13 21:39:03 changed by jwoithe

Replying to picander:

by the way, someone at Echo answered me he can help us with this bug, we only need someone of us who knows ffado enough to debug the problem.

Admittedly this comment is now over 6 months old, but it may be possible to progress this issue now. It turns out that a mate of mine has recently purchased an AudioFire?12 and it would be possible for me to borrow it for an extended period of time to work through this issue with the newer firmware. In the first instance I need to get in contact with the relevant people at Echo to work out what needs to be done at the FFADO end and then set things in place to make this happen.

To move this forward, if "picander" could contact me off-list via email we can work out the relevant details. Pieter: do you have anything to add in the way of comments or useful contacts at Echo?

07/14/13 12:35:55 changed by ruxxes

Hey there!

The main page still states the full support for Echo AF, but it looks like we got a show-stopper here with our latest firmware update...

Any progress on this?

Your help is greatly appreciated!

07/15/13 05:42:41 changed by jwoithe

It's on my list of things to do. It's not one of my primary devices though (I don't have an AF myself), which does cause it to drop below some others that I'm working on. I do now have information about an Echo contact though, and there's a suspicion about what might be causing the trouble thanks to some posts on various mailing lists over the past few months. It's just a matter of getting some time to sort though the issue and at present I'm not sure when this might be. If someone with an AF had the time and skills to look into this issue and provide a fix I would happily pass on what I know.

Irrespective of this, I should probably try to make time to summarise things in this ticket regardless so at least the present knowledge is properly documented.

09/11/13 16:32:34 changed by jwoithe

In the interests of further defining the problem, Takashi Sakamoto reported on the ffado-devel mailing list that when loaded into an AudioFire?-4, firmware 5.8 does not suffer from this problem. Furthermore, an earlier report on the mailing list suggests that the AudioFire? Pre8 is also fine with firmware 5.8. In other words, it seems that this issue is specific to the AudioFire?-8 and the AudioFire?-12; other AudioFire? devices do not appear to be affected at this time and seem to work fine with firmware 5.8.

09/11/13 16:37:57 changed by jwoithe

Further to comment:20, the tests with firmware 5.8 on the AudioFire?-4 done by Takashi were done on Ubuntu 13.04 with FFADO svn revision 2240.

02/27/14 15:28:36 changed by jwoithe

As of commit r2452 by Takashi Sakamoto, the problem which affected AF12 (and possibly AF8) devices has a workaround. I believe that this makes it possible to use the AF12 and AF8 with FFADO when the devices have previously problematic firmware version 5.8. It would be great if others could confirm this which would allow this ticket to be closed.

04/16/14 09:51:51 changed by ajaaskel

I have test environment consisting of Ubuntu Studio beta2 14.04 64 bit and Audiofire 12. I could test upgrading AF12 firmware and running svn r2452-> ffado. However, my background knowledge about ffado+svn is limited. Thus I hope someone could provide me with a link to 64 bit binary for testing which could simply be used to replace the old file(s).

05/05/14 22:04:55 changed by jwoithe

ajaaskel: Unfortunately I don't have access to a 64-bit box at present so I am unable to provide a 64-bit binary for you to test.

Takashi Sakamoto has committed some further improvements to his workaround in r2452 (see r2509 to r2515 inclusive). According to his post to ffado-devel announcing these changes Takashi believes that the current trunk (soon to be FFADO 2.2) will handle these devices when programmed with the newer firmware. It would be good if this could be tested so the ticket can be closed but we won't hold FFADO 2.2 up for this. When 2.2 is released it will make testing easier since it will be picked up by the distributions.

06/01/14 17:27:14 changed by jwoithe

  • status changed from new to closed.
  • resolution set to fixed.

According to Andrew Hately (http://www.ffado.org/?q=node/71#comment-12757) on the Audiofire 12 device page, the revised code does now work with an Audiofire 12 loaded with the latest device firmware (5.8.1). This code is in FFADO version 2.2.0 and all later versions. On the basis of this report I will close this ticket as "fixed". Please re-open if further problems are observed which are related to device firmware version.

06/19/14 08:02:55 changed by ruxxes

  • attachment debug.2.txt added.

FFADO error log (from SVN on Ubuntu Studio 14.04 amd64)

06/19/14 08:03:50 changed by ruxxes

  • attachment Screenshot.jpg added.

Error screenshot: "Could not select 48000 as sample rate"

06/19/14 08:05:41 changed by ruxxes

  • status changed from closed to reopened.
  • device_name set to Echo Audiofire 12.
  • priority changed from waiting for device info to waiting for volunteer.
  • milestone changed from Indeterminant (need device info) to Indeterminant (awaiting volunteer).
  • keywords set to fireworks, ubuntu, studio, audiofire.
  • resolution deleted.

We have compiled the last FFADO version from SVN on Ubuntu Studio 14.04 amd64.

The ffado-mixer loads but does not work correctly when trying to change parameters: "Could not select 48000 as samplerate." (see the Screenshot.jpg attached)

The ffado-test Discover shows the following errors:

01812631088: Warning (efc_avc_cmd.cpp)[  90] deserialize: Deserialization failed
01812631179: Error (fireworks_device.cpp)[ 207] doEfcOverAVC: EfcOverAVCCmd command failed
01812631650: Error (fireworks_device.cpp)[ 834] readFlash: Flash read failed for block 0x00008000 (64 quadlets)
01812631657: Error (fireworks_session_block.cpp)[ 129] loadFromDevice: Flash read failed
01812631668: Error (fireworks_device.cpp)[ 429] loadSession: Could not load session block
01812631672: Warning (fireworks_device.cpp)[ 369] buildMixer: Could not load session
01812635055: Warning (efc_avc_cmd.cpp)[  90] deserialize: Deserialization failed
01812635109: Error (fireworks_device.cpp)[ 207] doEfcOverAVC: EfcOverAVCCmd command failed
01812638084: Warning (efc_avc_cmd.cpp)[  90] deserialize: Deserialization failed
01812638149: Error (fireworks_device.cpp)[ 207] doEfcOverAVC: EfcOverAVCCmd command failed
01812638228: Error (fireworks_device.cpp)[ 523] isClockValid: Could not update polled values

The full log is attached (see debug.2.txt).

06/19/14 16:50:38 changed by jwoithe

Thanks for testing with your AF12 and the report, ruxxes. Could you please tell us the version number of the firmware you have loaded into your AF12?

You mention the mixer failing to change the sample rate. Is sample rate the only parameter which doesn't work, or are all settings pretty much unusable?

Can you use jackd to start audio streaming? Note that this operates completely independently of ffado-mixer.

This is interesting given that Andrew Hately (see comment:25) reports his AF12 to work fine with what is stated to be the latest firmware. The apparent contradiction between his interface and yours is unexpected.

One thing which is worth double-checking is that there aren't any old FFADO files (such as libffado.so*) sitting on your system somewhere. These may be picked up by some components and not others, or new binaries (reporting the new version) may be linking against an older libffado; all this leads to confusing results. In particular, a distribution will install libffado.so* in /usr/lib/ while by default a source install will go in /usr/local/lib/. If you have libffado.so* in more than one area, there are two ways to deal with it. For a quick initial test you could try using "rm" to remove the older files. Alternatively, run "scons -c install" as root in your ffado source tree (to remove the svn install), then run "scons PREFIX=/usr" to configure FFADO to install over the top of the distribution-provided files in /usr/lib/, and finally "scons install" (as root) to do the new installation. An "ldconfig" as root wouldn't go astray at this point.

BTW, I'm not sure "waiting for volunteer" is completely correct here for "priority" and "milestone". If we have someone who is familiar with the AF protocol who can determine what has gone wrong here and can post a description of what needs to be done to fix it, then these settings can remain - in this case we literally will be waiting for someone with an AF12 device to implement a fix for a well defined problem. At this stage Takashi is probably the only developer who might fall into this category, but he is very busy with the in-kernel streaming work for the AF series.

On the other hand, all we know at the moment is that some commands which FFADO thinks should work are rejected by the device for unknown reasons. To determine those reasons we need more information about the device, and further work on this issue cannot progress until we have it. In this case, "waiting for device info" is a far more appropriate status.

I will wait a few days to gauge feedback and see if Takashi responds. If further analysis does not appear in that time I'll be resetting the priority and milestone to "waiting for device info" to accurately indicate what is required in order to make further progress with this ticket.

In the meantime ruxxes, feel free to post further information if you happen to come across it.

06/19/14 17:45:21 changed by mocchi

...
00583400310:  (ffado-dbus-server.cpp)[ 329] main: DBUS service running
00583400338:  (ffado-dbus-server.cpp)[ 330] main: press ctrl-c to stop it & exit
00583400344: Debug (ffado-dbus-server.cpp)[ 333] main: dispatching...
...
00585287879: Debug (ffado-dbus-server.cpp)[ 335] main:  dispatcher exited...
00585287899: Debug (ffado-dbus-server.cpp)[ 337] main:  activity handled...
00585289183:  (ffado-dbus-server.cpp)[ 353] main: server stopped
00585422128: Debug (ffado-dbus-server.cpp)[ 202] exitfunction: Debug output flushed...
no message buffer overruns

These lines shows ffado-dbus-server correctly runs. This means libffado can drive FFADO applications for AudioFire?12 with the latest firmware.

So I hope testers to run jackd with the other sampling rate such like 96,000.

I note that AudioFire?12 with firmware version 5.0 or later losts its support for higher sampling rate such as 192000. This is completely due to firmware specification, not relevant to FFADO.

06/19/14 18:06:17 changed by jwoithe

Takashi: ffado-dbus-server seems to start ok for ruxxes. The problem seems to occur when they used the ffado-mixer to instruct ffado-dbus-server to make changes to the device. In their case they tried to change the sample rate to 48k and it failed. Could you perhaps run ffado-mixer and test whether you can in fact configure the sample rate on your system?

ruxxes did not mention what their original sample rate was. Their problem does not appear also does not appear to be related to the firmware limit which prevents 4x rates from being used because the change was to 48k, which certainly should have worked.

06/19/14 18:37:22 changed by mocchi

Jonathan:

Could you perhaps run ffado-mixer and test whether you can in fact configure the sample rate on your system?

Yes. If not so, I would have never committed yet.

Their problem does not appear also does not appear to be related to the firmware limit

Exactly. My intension is that the users surely realize the limitation with latest firmware. I don't want to hear 'Why my AudioFire?12 with the latest firmware doesn't work at 192kHz?'.

Anyway, I hope testers to try jackd with the other sampling rate. If it doesn't work well, the cause is in Fireworks stack inner libffado. Else, the cause is in front-end or handlers for d-bus interface.

06/19/14 19:00:00 changed by jwoithe

Takashi: thanks for the confirmation. BTW, do you think we ought to add a warning message to the code if 192k is requested for a device whose firmware doesn't support it? This could make it clear that the newer echo firmware removed support for 192k and would avoid those sorts of questions.

Regarding the possible cause of ruxxes's issue, what does the "doEfcOverAVC: EfcOverAVCCmd command failed" message tell us? I've had a quick look at the code and when setting the sample rate at least it seems that if this message is displayed it means the attempt is being abandoned. I can't recall precisely the details of the issue you worked around but it might have been slightly different: whereas this is a complete failure of the EfcOverAVCCmd() function, the problem you addressed might have been the return of invalid values by this function. I'll have to check the history again.

The fact that you don't see these doEfcOverAVC() errors on your system seems to confirm what was said in comment:25: that the latest AF12 firmware works with recent FFADO versions. However, ruxxes clearly has a problem on his system with doEfcOverAVC() failing. Since he is presumedly running the same FFADO code as you the fundamental issue can't be the fireworks stack in FFADO. Similarly, the error is in doEfcOverAVC(), so it's not clear to me how the front-end of ffado-mixer or the dbus interface could have anything to do with this. About the only thing left is the firmware in ruxxes's AF12; hopefully this will be confirmed in the next day or so and we can press on from there.

For what it's worth I expect jackd use will fail for ruxxes as well: the same code in libffado is used to switch sample rates regardless of whether jackd or ffado-mixer/ffado-dbus-server is used. Since it fails for one user (ffado-mixer/ffado-dbus-server) logic suggests it'll fail for the other (jackd). Again, hopefully jackd can be tested by ruxxes soon and we'll have that data point too.