fireworks: Partial revert of r2452, remote several trials of EfcOverAVC

@2452, this trials were added for firmware version 5.0 or later of AudioFire12.
When adding it, the failure related some commands are considered due to command
failure so retry is reasonable.

But according to additional investigation, it's due to wrong contents of these
commands. So command are itself successful.

To give better experiences to users, these retries should removed and go to
fallback as soon as possible.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2509 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Remove useless execution of command for polled values

There are meaningless call of the command.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2510 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Supplemental modification for previous two commits

It's my mistake...


git-svn-id: svn+ssh://ffado.org/ffado/trunk@2511 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Improve codes for fallback to easily understand

Adding comments and changing the order of conditions.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2512 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Delete 'm_efc_version' member from FireWorks::Device class

This is not used.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2513 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Improve a workaround for AudioFire12 with recent firmwares

Firmware version 5.0 or later for AudioFire12 has quirks. One of the quirks is
to return invalid values in content of response against command of polled
values.

Acording to ticket #360, this causes assertion which prevents from
buffer-over-run:
http://subversion.ffado.org/ticket/360

Revision 2451 removes this assertion and adds a prevention of buffer-over-run.
http://subversion.ffado.org/changeset/2451

But this is not enough as a workaround because it returns false.

This commit allows to continue process after compensating these values.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2514 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Dump messages at fallback

To help out debugging.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2515 2be59082-3212-0410-8809-b0798e1608f0
README: Add supplemental information for M-Audio BeBoB devices

Some models need a bootup workasound with latest firmware. In detail,
please refer to this post. (It's for ALSA driver, FYI)
http://sourceforge.net/p/ffado/mailman/message/32268370/

Currently we give no tools for this purpose.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2516 2be59082-3212-0410-8809-b0798e1608f0
SConstruct: further refinement of debug control at build time.  A new DEBUG_MESSAGES option controls whether debug messages are printed (default is enabled).  DEBUG now turns on warnings, symbols and additional debug code (default is enabled).  If DEBUG is not enabled a '-O2' build is done.  The DEBUG_BUILD option added in r2507 has been removed.  Production builds are encouraged to leave DEBUG_MESSAGES enabled while disabling DEBUG.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2517 2be59082-3212-0410-8809-b0798e1608f0
SConstruct: if DEBUG is enabled DEBUG_MESSAGES should be forced on.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2518 2be59082-3212-0410-8809-b0798e1608f0
fireworks: Fix a bug of fallback mechanism for clock information

I'm working with wrong understanding about #360.

The log means some commands are successful but they includes wrong values.
In my previous work, I just tested a case that these commands are failed.
So this issue is not still resolved.

This commit adds Fireworks::Device::getClock() with fallback mechanism and
all of methods which get clock information call this method. This fallback
mechanism checks values in contents of response and correct the values if
they're invalid.



git-svn-id: svn+ssh://ffado.org/ffado/trunk@2519 2be59082-3212-0410-8809-b0798e1608f0
Correct a typo introduced in r2517.  Thanks to Jano Svitok for spotting this.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2520 2be59082-3212-0410-8809-b0798e1608f0
m-audio: fix uninitialised variable, spotted by Andreas Hehn.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2521 2be59082-3212-0410-8809-b0798e1608f0
rme: remove the compile-time warning about the state of the RME driver since it's on a par with most others now.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2522 2be59082-3212-0410-8809-b0798e1608f0
Fix 'set but not used' warning in the cycle timer code

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2523 2be59082-3212-0410-8809-b0798e1608f0
StreamProcessorManager: when variables or actions are taken which only have an effect via debugOutputExtreme(), enclose them in '#if DEBUG_EXTREME_ENABLE' conditionals.  This prevents some compiler warnings and removes otherwise dead code from the common case where DEBUG_EXTREME_ENABLE is not enabled.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2524 2be59082-3212-0410-8809-b0798e1608f0
rme: remove some calculations related to silent transmit packets which are not actually used when dealing with silent packets.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2525 2be59082-3212-0410-8809-b0798e1608f0
amdtp: remove a 'set but not used' warning associated with a variable which is only used when extreme debugging is enabled by making the entire code block conditional on DEBUG_EXTREME_ENABLE.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2526 2be59082-3212-0410-8809-b0798e1608f0
scons: the 'unused-but-set-variable' added in gcc 4.6 triggers warnings when compiling code generated by dbusxx-xml2cpp (such as controlserver-glue.h).  This is caused by numerous instances of the call.reader() return value being stored but not used.  Since we can do nothing about this, suppress this warning when compiling dbus-related files.  This change plus those in r2522 to r2526 inclusive allow FFADO to compile without warnings, at least under gcc 4.7.x.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2527 2be59082-3212-0410-8809-b0798e1608f0
IsoHandler::getPacket(): when keeping tabs of the last cycle, allow for cases where the m_Client indicates that handling of the cycle should be deferred.  If this is ignored and m_last_cycle is set regardless, the dropped packet logic will be triggered when the cycle is requested again at some later time because the cycle count - when compared to the stored m_last_cycle - will appear to have gone backwards.  This may go some way toward addressing ticket #379, although at the time of writing this is yet to be confirmed.

git-svn-id: svn+ssh://ffado.org/ffado/trunk@2528 2be59082-3212-0410-8809-b0798e1608f0