Here is Jack startup log using FFADO. This shows all ports available.

Thu Apr 21 02:07:05 2016: Starting jack server...

Thu Apr 21 02:07:05 2016: JACK server starting in realtime mode with priority 85

Thu Apr 21 02:07:05 2016: self-connect-mode is "Don't restrict self connect requests"

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH1/CH1/2_in'

Thu Apr 21 02:07:07 2016: New client 'firewire_pcm' with PID 0

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH2/CH1/2_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH3/CH3/4_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH4/CH3/4_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH5/CH5/6_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH6/CH5/6_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH7/CH7/8_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH8/CH7/8_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH9/CH9/10_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH10/CH9/10_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH11/CH11/12_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH12/CH11/12_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH13/CH13/14_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH14/CH13/14_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH15/CH15/16_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH16/CH15/16_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_midi 0_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_L/MAIN L/R_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_R/MAIN L/R_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT1/ADAT1/2_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT2/ADAT1/2_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT3/ADAT3/4_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT4/ADAT3/4_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT5/ADAT5/6_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT6/ADAT5/6_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT7/ADAT7/8_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT8/ADAT7/8_in'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH1/CH1/2_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH2/CH1/2_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH3/CH3/4_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH4/CH3/4_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH5/CH5/6_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH6/CH5/6_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH7/CH7/8_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH8/CH7/8_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH9/CH9/10_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH10/CH9/10_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH11/CH11/12_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH12/CH11/12_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH13/CH13/14_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH14/CH13/14_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH15/CH15/16_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_CH16/CH15/16_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_L/MAIN L/R_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_R/MAIN L/R_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT1/ADAT1/2_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT2/ADAT1/2_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT3/ADAT3/4_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT4/ADAT3/4_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT5/ADAT5/6_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT6/ADAT5/6_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT7/ADAT7/8_out'

Thu Apr 21 02:07:07 2016: graph reorder: new port 'firewire_pcm:0004c4040001c14f_ADAT8/ADAT7/8_out'

Thu Apr 21 02:07:07 2016: New client 'catia' with PID 3396

On Thu, Apr 21, 2016 at 2:03 AM Allan Klinbail aklinbail@gmail.com wrote:

Thanks for your reply.

This isn't really suitable yet to replace FFADO . It provides this as separate devices so I cannot access all channels at the same time in jack as in FFADO.

Although I don't typically use the ADAT ports other might, however I am always using a combination of channels 1-16 and channels 17 & 18 combined, sometimes all of them. The device is a hardware mixing desk and all ports are designed to be used simultaneously..

Latency performance is also much worse. FFADO will allow a buffer size of 64, ALSA will not start below 256. I prefer to work at 128 or lower.

Here is the output you requested.

root@kxdaw:/home/allan/Downloads# cat /proc/asound/card1/dice sections: global: offset 10, size 95 tx: offset 105, size 142 rx: offset 247, size 282 ext_sync: offset 529, size 4 unused2: offset 0, size 0 global: owner: ffc1:000100000000 notification: 00000040 nick name: ZED R16 clock select: internal 44100 enable: 1 status: locked 44100 ext status: 000000c0 sample rate: 44100 version: 1.0.11.0 clock caps: 44100 48000 88200 96000 adat internal clock source names: AES12\AES34\AES56\AES78\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\ tx 0: iso channel: 0 audio channels: 16 midi ports: 1 speed: S400 names: CH1/CH1/2\CH2/CH1/2\CH3/CH3/4\CH4/CH3/4\CH5/CH5/6\CH6/CH5/6\CH7/CH7/8\CH8/CH7/8\CH9/CH9/10\CH10/CH9/10\CH11/CH11/12\CH12/CH11/12\CH13/CH13/14\CH14/CH13/14\CH15/CH15/16\CH16/CH15/16\ ac3 caps: 00000000 ac3 enable: 00000000 tx 1: iso channel: 1 audio channels: 10 midi ports: 0 speed: S400 names: L/MAIN L/R\R/MAIN L/R\ADAT1/ADAT1/2\ADAT2/ADAT1/2\ADAT3/ADAT3/4\ADAT4/ADAT3/4\ADAT5/ADAT5/6\ADAT6/ADAT5/6\ADAT7/ADAT7/8\ADAT8/ADAT7/8\ ac3 caps: 00000000 ac3 enable: 00000000 rx 0: iso channel: 2 sequence start: 0 audio channels: 16 midi ports: 0 names: CH1/CH1/2\CH2/CH1/2\CH3/CH3/4\CH4/CH3/4\CH5/CH5/6\CH6/CH5/6\CH7/CH7/8\CH8/CH7/8\CH9/CH9/10\CH10/CH9/10\CH11/CH11/12\CH12/CH11/12\CH13/CH13/14\CH14/CH13/14\CH15/CH15/16\CH16/CH15/16\ ac3 caps: 00000000 ac3 enable: 00000000 rx 1: iso channel: 3 sequence start: 0 audio channels: 10 midi ports: 0 names: L/MAIN L/R\R/MAIN L/R\ADAT1/ADAT1/2\ADAT2/ADAT1/2\ADAT3/ADAT3/4\ADAT4/ADAT3/4\ADAT5/ADAT5/6\ADAT6/ADAT5/6\ADAT7/ADAT7/8\ADAT8/ADAT7/8\ ac3 caps: 00000000 ac3 enable: 00000000 ext status: clock source: internal locked: 1 rate: 44100 adat user data: -

On Thu, Apr 21, 2016 at 1:21 AM Takashi Sakamoto o-takashi@sakamocchi.jp wrote:

...

Hi,

On Apr 20 2016 23:31, Allan Klinbail wrote:

...

Using kernel 4.4.0 from Ubuntu

The ALSA driver limited the device to only 16 inputs and outputs,

however

...

it has a total capability of 26 This is comprises of 16 inputs and outputs on the desk channels, a

stereo

...

main pair of outputs and inputs for the master bus 8 additional ins and outs to support the ADAT ports on the back

(availoable

...

in 44.1 and 48 khz modes, but not 88.2 or 96 Khz

This is fixed in Linux kernel 4.6.

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105462.html

The backported codes are available in my private repository. After installing, You can see two PCM character devices to handle these PCM channels. https://github.com/takaswie/snd-firewire-improve

To clarify the capabilities of your model, please show me output of proc node, like

$ cat /proc/asound/card1/dice sections: global: offset 10, size 95 tx: offset 105, size 142 ...

Regards

Takashi Sakamoto

Thanks Takashi ,

It was my understanding that FFADO would eventually be deprecated, so am trying to provide test feedback for my device. I thought comparable performance would be a goal.

It was late last night when I was testing so I apologise if I sounded ungrateful.

Using ALSA is desirable as I have a large number of MIDI devices (2*AMT 8) and 3 other control devices.. Using ALSA provides better connectivity than a2jmidi..

I will try alsa in, plug.. I am concerned though this is not an ideal solution due to trying to sync multiple devices which in reality share a clock.. Adding even more latency..

I will continue using FFADO for production work, but am happy to keep testing if you believe improvements can be made On Thu, 21 Apr 2016 10:01 am Takashi Sakamoto o-takashi@sakamocchi.jp wrote:

Hi,

On Apr 21 2016 01:03, Allan Klinbail wrote:

...

It provides this as separate devices so I cannot access all channels at the same time in jack as in FFADO.

Although I don't typically use the ADAT ports other might, however I am always using a combination of channels 1-16 and channels 17 & 18 combined, sometimes all of them. The device is a hardware mixing desk and all ports are designed to be used simultaneously..

Use 'alsa_in' and 'alsa_out' as JACK clients, to use several ALSA PCM character devices in one JACK session. See: http://jackaudio.org/faq/multiple_devices.html

...

Latency performance is also much worse. FFADO will allow a buffer size of 64, ALSA will not start below 256. I prefer to work at 128 or lower.

If you think that FFADO implementation is suitable to your usage, and you believe that it's really proper for IEC 61883-1/6, please use it. ALSA firewire stack is just one of your available options in Linux-based system.

...

root@kxdaw:/home/allan/Downloads# cat /proc/asound/card1/dice sections: global: offset 10, size 95 ... global: ... version: 1.0.11.0

Hm. The global register has 95 quadlets. It has extra 5 quadlets as what we know. What information is in the extra fields, I don't know exactly, but I can confirm it in my Focusrite Saffire Pro 26 (interface version 1.0.12.0).

On Saffire Pro 26: $ cat /proc/asound/card1/dice sections: global: offset 10, size 95 ... global: ... version: 1.0.12.0

$ ./firewire-request /dev/fw1 read 0xffffe0000190 14 result: 000: 00 00 00 07 00 00 00 02 00 00 00 00 00 00 00 00 result: 010: 00 00 00 00

In short: 0x'ffff'e000'0190: 0x00000007 0x'ffff'e000'0194: 0x00000002 0x'ffff'e000'0198: 0x00000000 0x'ffff'e000'019c: 0x00000000 0x'ffff'e000'01a0: 0x00000000

If you can't have enough consideration about this kind of work, I'd like you to use FFADO, by blacklisting snd-dice, please.

Regards

Takashi Sakamoto

Hi Takashi,

Thanks for the advice. I am not upset with the case that the ALSA firewire drivers are not intending to replace ffado, although it would have been convenient.

I have read the posted paper, and while I basically understand it's premise, I don't feel that this approach is necessarily suitable for "prefoessional" audio use cases (with DAW software and other music production software). I feel I understand why the Jack developers have maintained the traditional approach. Although I admit my understanding is basic and limited.

Latency in this case is specifically important from a "Round trip" viewpoint, the time for the audio reaching the AD converter being processed by the DAW application (and associated plugins) to the time it reaches the DA converter. There are fixed latencies, such as introduced by the converters and also the latency from the speaker distance to the ears of the musician. (if monitoring headphones are not being used by the musician). For a musician to be able to process their mechnical movements at the correct time to the audio they are hearing requires a fixed latency to occur and typically this needs to be under 10ms for their not to be a perceived delay.

This is starkly different from typical desktop usage or even gaming usage where multiple random audio streams are expected.

Audio streams in DAW use cases, are highly predictable. In a typical setup, there will be no audio coming from sources outside of the DAW framework (this may involve and intercommunicating applications, however there would be no random media player startups, or sound coming from a new web page for example).

The ability to "rewind" to insert new streams into the path of the hardware buffers is not typical for these circumstances.

FYI - AMT 8 is an 8 in / 8 out MIDI device (128 channels capable). I use 2 of them, as I have many hardware devices (synthesizers and audio processing units) that need communication with MIDI protocol.

Regards

On Thu, Apr 21, 2016 at 12:11 PM Takashi Sakamoto o-takashi@sakamocchi.jp wrote:

Hi,

On Apr 21 2016 09:14, Allan Klinbail wrote:

...

Thanks Takashi ,

It was my understanding that FFADO would eventually be deprecated, so am trying to provide test feedback for my device. I thought comparable performance would be a goal.

Your misunderstanding.

ALSA firewire stack is not an alternative of FFADO implementation. Against understanding of most of FFADO users, the implementation of this stack doesn't come from FFADO implementation, therefore they're based on quite different designs and code bases.

(It's your misfortune that FFADO project has already lost well-established developers who can explain about it.)

And you should realize that the decrease of size of PCM buffer is an ancient technique to reduce communication latency in a past decade. JACK developers still adhere on it, against their aim, unfortunately. To understand this aspect, please read Alexander Patrakov's paper proposed in LAC 2015. http://lac.linuxaudio.org/2015/papers/10.pdf

It's a bit difficult to you. But when thinking about the 'latency' severely, at least, users and developers should understand what in the article, at least. About the communication latency, I'm willing to use my time for this direction, but not for the others.

...

Using ALSA is desirable as I have a large number of MIDI devices (2*AMT

...

and 3 other control devices.. Using ALSA provides better connectivity

than

...

a2jmidi..

What's the 'AMT'?

...

I will try alsa in, plug.. I am concerned though this is not an ideal solution due to trying to sync multiple devices which in reality share a clock.. Adding even more latency..

Even if using FFADO implementation, you can't achieve it. It pretends as what you say. Of cource, the size of PCM buffer is accumulated to the communication latency.

...

I will continue using FFADO for production work, but am happy to keep testing if you believe improvements can be made.

I haven no plan of my development for the direction about which you mentioned, sorry. There're more crutial issues than them.

Regards

Takashi Sakamoto

Thanks for the clarification.

As I admitted, my understanding is basic and limited. Clearly I have got it wrong.

However, whichever way you code it, as a musician many of us require a round trip latency from input to output of 10ms or less for us to be able to comfortably record performances in real time. (Or for engineers to provide an environment that makes the recording process comfortable for our clients)

Until that can be facilitated by the driver and also supported by the software, then it is a rather pointless argument.

For the moment jackd is the system that is best supported by the different applications for audio to pass between them. It also provides the best session management tools and also the best synchronisation between MIDI and audio signal.

If you can educate the software developers how to better utilise the driver to provide that environment, then that is great. Typically that process will then take time. So if you do get through your more crucial tasks, I'm sure there are many users who would appreciate an improvement in the buffer performance.

As I have stated, I have the equipment to help perform testing and am willing to do so (even if I will continue to use FFADO for my work). It doesn't have to be testing in that one specific area.

I do request for a more elegant way to ensure that the entire unit is treated as one device and while I am clearly ignorant in the detailed working of the driver, I am more capable than a typical user.

Regards

Allan

On Thu, Apr 21, 2016 at 2:59 PM Takashi Sakamoto o-takashi@sakamocchi.jp wrote:

Hi,

On Apr 21 2016 11:52, Allan Klinbail wrote:

...

I have read the posted paper, and while I basically understand it's premise, I don't feel that this approach is necessarily suitable for "prefoessional" audio use cases (with DAW software and other music production software). I feel I understand why the Jack developers have maintained the traditional approach. Although I admit my understanding

is

...

basic and limited.

Latency in this case is specifically important from a "Round trip" viewpoint, the time for the audio reaching the AD converter being

processed

...

by the DAW application (and associated plugins) to the time it reaches

the

...

DA converter. There are fixed latencies, such as introduced by the converters and also the latency from the speaker distance to the ears of the musician. (if monitoring headphones are not being used by the musician). For a musician to be able to process their mechnical movements at the correct time to

the

...

audio they are hearing requires a fixed latency to occur and typically

this

...

needs to be under 10ms for their not to be a perceived delay.

This is starkly different from typical desktop usage or even gaming usage where multiple random audio streams are expected.

Audio streams in DAW use cases, are highly predictable. In a typical

setup,

...

there will be no audio coming from sources outside of the DAW framework (this may involve and intercommunicating applications, however there

would

...

be no random media player startups, or sound coming from a new web page

for

...

example).

The ability to "rewind" to insert new streams into the path of the

hardware

...

buffers is not typical for these circumstances.

You have complete misunderstanding. The usage of audio workstation is not so special in an aspect of using sound devices.

It better for you to distinguish the size of PCM buffer, the communication delay on the data bus, process scheduling timing, and so on. I think you roughly lump them togather as a name of 'latency', and it brings unreasonable conclusions.

Regards

Takashi Sakamoto

Hi Takashi,

I'm sorry I've made you so upset. I'm only taking the perspective of how these devices are used. Which you may feel unproductive, however many of us feel is important.

I do work in system design for corporate IT, and while we sometimes come up with a perfect system, they might not fit the use case. It upsets and frustrates us, but if the design does not fit the use case it is not going to be used and our project will not get funding.

I really do understand where you are coming from, not from a technical perspective but how this might be frustrating.

The point of the last email wasn't to ask you to change focus on how you address the issue of latency but explaining the reality that until the software changes, that a new approach is not going to be utilised. This covers both open and closed (commercial) software.

That doesn't make it a bad endeavour it is always good to work for better solutions, but you are likely to come up against people like me who would like the driver to fit the existing use cases.

I did request one change, which was to make an abstraction so that a user does not have trouble addressing these devices as one device, without having to perform complex configuration tasks.. I do understand that technically that isn't how the device works, but it is not useful to for the user to treat it as separate devices.

While you may consider this an unproductive conversation from a technical standpoint, as you have stated, I am not the only person/owner of a device to raise this issue. That would indicate that the current implementation doesn't fit the real world use cases for the devices.

Whether that means someone else has to write a simple abstraction to make the device seen as one device, or something else has to happen, I don't know...

As Jonathan Woithe has pointed out on FFADO lists, the long term goal IS for ALSA to take over the streaming function. With FFADO to remain in userspace to potentially provide mixer tools or other functions.

For those off us that have bought these devices many have spent a lot of money for particular use cases and performance , and in the case of this specific device spending in the order of 3,000 USD. Many of us using the devices with commercial software for professional or semi-professional uses.

That makes this particular conversation quite scary and very important.

BTW, telling me my brain can't be fixed is pretty hostile.. However, I'll assume that this is a language issue rather than deliberately intending to offend me.

On Thu, 21 Apr 2016 7:49 pm Takashi Sakamoto o-takashi@sakamocchi.jp wrote:

Hi,

First, I have no hostility to you.

Since I extended snd-dice in the late of 2014, I have been exposed to the similar insistences many times, in public or private, from users who own Dice-based models. Their insistences tends to include unreasonbable judgements about something related, ignorance of developers' intension and the state of development for ALSA firewire stack. So I feel to have a waste of time to receive such intensions, because they're not productive at all.

On Apr 21 2016 14:38, Allan Klinbail wrote:

...

As I admitted, my understanding is basic and limited. Clearly I have got

it

...

wrong.

However, (snip)

Well, you still repeat the same insistences again, after our discussion. It means that I fail to refresh your knowledge about PCM frame handling in this operating systems. That's a pretty sad to me.

One of my motivation to work for ALSA firewire stack is to use sound and music units on IEEE 1394 bus for the purpose as you described, via ALSA kernel/userspace interface, according to ways reasonable to many system requirements.

The shape of ALSA firewire stack represents the requrements from design of actual operating system, actual sound subsystem in Linux, actual audio and music units on IEEE 1394 bus, actual packet streaming protocol and actual quirks of the units. If you need my technical explaination about them, I'm willing to describe them. You won't accept it even if I did, because I've already introduced a part of them and you won't refresh your brain.

This is the end of such an unproductive discussion, sorry.

Regards

Takashi Sakamoto