Hi,
On Wed, Feb 08, 2023 at 05:00:31PM +0100, M. Armsby wrote:
I made a short video demonstrating this.
Thanks for your taking and uploading the video. The below figure illustrates your cases:
++======================++ +-------+ ++===============++ || Traveler || | frame | || Application || || || | | || || || headphone output 1/2 || <- | 0/1 | <- || Output 1/2 || || analog output 1/2 || <- | 2/3 | <- || Output 3/4 || || analog output 3/4 || <- | 4/5 | <- || Output 5/6 || || analog output 5/6 || <- | 6/7 | <- || Output 7/8 || || analog output 7/8 || <- | 8/9 | <- || Output 9/10 || || AES/EBU (XLR) 1/2 || <- | 10/11 | <- || Output 11/12 || || S/PDIF (opt) 1/2 || <- | 12/13 | <- || Output 13/14 || ++======================++ +-------+ ++===============++
I note that the effective source of headphone output is selectable between the above 7 pairs. Additionally, when enabling ADAT optical output, 8 channels are newly added to the frame thus 22 channels are available in a view of application. Well, inconveniently to you, the above mapping is expected. ALSA firewire-motu driver passes no information to the application about what the channel of frame is assigned to, due to technical reason of ALSA interface to user space application. As a result, the application just enumerates audio sample in its order.
I can understand your description but disagree that just because it's Linux, all Motu users must deal with false output allocation. The first pair should be 1+2 not headphones.
Is it not possible to find a remedy instead.
The Windows driver shows headphones much later in the output numbering.
Indeed, it is inconvenient in the view of user. But let us focus on how to support MOTU 896 mk3 hybrid at present, since the issue includes many technical topics; each application, drivers in kernel, libraries, and interface between them.
See Pictures taken from Reaper in Windows 10
Would I ask you to avoid attaching pictures to open mailing list? The message with many files is easily judged as spam message.
Regards
Takashi Sakamoto