FFADO

ffado-mixer: add device mixers to "View" menu. Xavier Forestier's November 2016 patchset included code which added an entry for each active device's mixer to the "View" menu. For users with a number of different devices this may prove useful. ... [More] This commits Xavier's original patch was with some minor changes to ensure the guid key is resolvable by setTabVisible() under PyQt?4. It has not been tested under PyQt?5. [Less]

ffado_mixer: add a "Themes" submenu to the "View" menu. Xavier Forestier's November 2016 patchset included code to add themes under the "Help" menu which could be selected by the user. The code to do this is relatively simple so there seems ... [More] little reason to hold it back. The only change compared to the submitted patch is to move the themes to a submenu of the "View" menu since conceptually this is a better place than the top of the "Help" menu. [Less]

matrixmixer.py: attempt to deal with UTF8 string changes in python3. PyQt?5 under python3 does not implement QString and instead relies on the native python UTF string type. Attempt to deal with this when drawing mixer elements which make use of ... [More] UTF characters. This has not yet been tested under python3 due to the author not having access to a system with python3, so testing may yet prove that the approach taken in this commit is insufficient. This commit is based on the suggestion from Xavier Forestier in his patch set from November 2016 submitted via the ffado-devel mailing list. [Less]

A first pass at optionally supporting PyQt?5 in the build system. This is an initial implementation of changes in the build system to support the use of PyQt?5 when building ffado-mixer. They are based on the patch set submitted to ffado-devel by ... [More] Xavier Forestier in November 2016. However, rather than removing PyQt?4 support, the idea is that either PyQt?4 or PyQt?5 can be used. This patch has been tested on a machine with only PyQt?4 installed. Testing with only PyQt?5 is yet to be done (the author presently does not have access to such a system). It is not known how well this patch will work on a machine with both PyQt?4 and PyQt?5 installed. r2694 assumes that PyQt?4 will be used in this situation on the basis that it has had the most testing, but it's unclear whether the build system will select pyuic4 over pyuic5 in this case. Further testing will be required, and adjustments will be made if problems are found. [Less]

ffado_diag_helpers.py: get_version_first_line(): print "Not found" if the command is available. Previously a shell error message would be shown which may be a little misleading in some situations.

import_pyqt.py: make licence format consistent with the rest of FFADO.

maudio_bebob: add missing licence description to the top of the mixer python source.

ffado-mixer: Centralise imports of PyQt? modules and make compatible with PyQt?5. In Xavier Forestier's patch set submitted to ffado-devel in November 2016, changes were required to every PyQt? import statement if PyQt?5 were to to be used ... [More] instead. Since the current intent is to retain compatiblity to both PyQt?4 and PyQt?5 a slightly different approach was needed. All PyQt? module imports are now handled by the newly added import_pyqt module. This transparently loads PyQt?4 or PyQt?5 modules depending on what is found on the system at runtime. Presently PyQt?4 is tried first with a fallback to PyQt?5 if PyQt?4 is not found, but this could change in future. The result is that the ffado-mixer code should now be very close to being compatible with PyQt?5 without additional patches. Having said that, some build system changes are still needed to make PyQt?5 an option, along with some other minor fixes. This is perhaps not the neatest way of achieving the desired result, but it seems to work. It avoids the need to patch every ffado-mixer source file depending on the PyQt? version in use, and allows ffado-mixer to adapt to the PyQt? version found at runtime. The import_pyqt module also sets two global version variables: ffado_pyqt_version (the version of PyQt? in use) and ffado_python3 (true if python3 is in use). These may be of use when addressing remaining PtQt?4/PyQt5 and Python 2/3 issues. This patch has been tested with PyQt?4 under Python 2.7. [Less]

rme: add a clarifying comment indicating that FFADO does not implement RME MIDI functionality yet.

rme: adjustments to maintain compatibility with the kernel snd-fireface driver for FF400 devices. This is a modified version of a patch submitted by Takashi Sakamoto. His original commit message follows. Changes from the original patch were: ... [More] 1. Abbreviate comments added to fireface_def.h. This file was never intended to contain verbose protocol-level descriptions, so a briefer version is fine. 2. In fireface_def.h, omit the added "Not used in user land." comment attached to RME_FF400_MIDI_HIGH_ADDR. While FFADO does not utilise this at present, it doesn't mean that it couldn't in future (at least in principle). Since this file describes the programming interface implemented by the device, the proposed annotation could be confusing in the future. 3. Do not remove the "provide_midi" device field. This infrastructure field helps document the device's programming interface and could be used in future to allow FFADO to support MIDI on the FF400 device. In the meantime, its current setting (0) continues to allow FFADO and the kernel snd-fireface module (kernel >= 4.12) to co-exist. To this end, the changes to CR2 requested in the patch are carried out if provide_midi is 0. [Takashi Sakamoto's commit message] As of May 2017, FFADO library has no support for MIDI functionality as a driver for RME fireface series. ALSA fireface driver, a.k.a. snd-fireface were added to Linux kernel v4.12. This driver is designed to just support functionalities to handle PCM frames and MIDI messages for ALSA userspace applications. The other features should be implemented in user space to avoid complexity in kernel land. Additionally, due to design of target hardware, the driver request userspace applications to handle some registers. In RME Fireface series, some registers are write-only. Fortunately, none of the registers is relevant to packet streaming feature; i.e. isochronous communication on IEEE 1394 bus, while asynchronous communication is controlled by such registers. MIDI functionality in ALSA fireface driver gets influences from this specification. The driver need a care of userspace applications to set the registers correctly. For the above reason, this commit changes this library to configure the registers so that ALSA fireface driver can handle MIDI messages properly. The issue is an address to which the unit transfers asynchronous transactions for MIDI messages. 4 byte in MSB of the address is represented in 0x'0000'8010'03f4 with node ID. This is readable/writable by ALSA fireface driver. Rest of the address is decided by write transaction to 0x'0000'8010'051c with bit flags. This register is write-only, it includes effects for the other features than MIDI functionality. ALSA fireface driver doesn't touch it but expects userspace applications to configure the register to transfer MIDI messagess to a certain address. Signed-off-by: Takashi Sakamoto [Less]