A&H Zed R16 not completely working (DICE Jr)

A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

Hi,

I thought I would try the DICE chipset driver from ALSA, as it appears that
this will eventually take over from ffado..

It appears that it doesn't work very well for my Allen & Heath Zed -R16
which works very well under FFADO

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

Similiarly I was not able to set the device to run at a latency lower than
256 frames in jack, however in FFADO I could go as low as 64 frames.

Please let me know if I can help with any further testing to get this to
the same level as the FFADO driver.

Regards

Allan

Re: A&H Zed R16 not completely working (DICE Jr)

[Takashi Sakamoto]

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

Re: A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

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
>

Re: A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

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
>>
>

Re: A&H Zed R16 not completely working (DICE Jr)

[Takashi Sakamoto]

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

Re: A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

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
>

Re: A&H Zed R16 not completely working (DICE Jr)

[Takashi Sakamoto]

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 8)
> 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

Re: A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

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
> 8)
> > 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
>

Re: A&H Zed R16 not completely working (DICE Jr)

[Takashi Sakamoto]

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

Re: A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

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
>

Re: A&H Zed R16 not completely working (DICE Jr)

[Takashi Sakamoto]

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

Re: A&H Zed R16 not completely working (DICE Jr)

[Allan Klinbail]

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
>