* A&H Zed R16 not completely working (DICE Jr) @ 2016-04-20 14:31 Allan Klinbail 2016-04-20 15:21 ` Takashi Sakamoto 0 siblings, 1 reply; 12+ messages in thread From: Allan Klinbail @ 2016-04-20 14:31 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-20 14:31 A&H Zed R16 not completely working (DICE Jr) Allan Klinbail @ 2016-04-20 15:21 ` Takashi Sakamoto 2016-04-20 16:03 ` Allan Klinbail 0 siblings, 1 reply; 12+ messages in thread From: Takashi Sakamoto @ 2016-04-20 15:21 UTC (permalink / raw) To: Allan Klinbail, alsa-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-20 15:21 ` Takashi Sakamoto @ 2016-04-20 16:03 ` Allan Klinbail 2016-04-20 16:09 ` Allan Klinbail 2016-04-21 0:01 ` Takashi Sakamoto 0 siblings, 2 replies; 12+ messages in thread From: Allan Klinbail @ 2016-04-20 16:03 UTC (permalink / raw) To: Takashi Sakamoto, alsa-devel 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-20 16:03 ` Allan Klinbail @ 2016-04-20 16:09 ` Allan Klinbail 2016-04-21 0:01 ` Takashi Sakamoto 1 sibling, 0 replies; 12+ messages in thread From: Allan Klinbail @ 2016-04-20 16:09 UTC (permalink / raw) To: Takashi Sakamoto, alsa-devel 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 >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-20 16:03 ` Allan Klinbail 2016-04-20 16:09 ` Allan Klinbail @ 2016-04-21 0:01 ` Takashi Sakamoto 2016-04-21 0:14 ` Allan Klinbail 1 sibling, 1 reply; 12+ messages in thread From: Takashi Sakamoto @ 2016-04-21 0:01 UTC (permalink / raw) To: Allan Klinbail, alsa-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 0:01 ` Takashi Sakamoto @ 2016-04-21 0:14 ` Allan Klinbail 2016-04-21 2:11 ` Takashi Sakamoto 0 siblings, 1 reply; 12+ messages in thread From: Allan Klinbail @ 2016-04-21 0:14 UTC (permalink / raw) To: Takashi Sakamoto, alsa-devel 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 0:14 ` Allan Klinbail @ 2016-04-21 2:11 ` Takashi Sakamoto 2016-04-21 2:52 ` Allan Klinbail 0 siblings, 1 reply; 12+ messages in thread From: Takashi Sakamoto @ 2016-04-21 2:11 UTC (permalink / raw) To: Allan Klinbail, alsa-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 2:11 ` Takashi Sakamoto @ 2016-04-21 2:52 ` Allan Klinbail 2016-04-21 4:59 ` Takashi Sakamoto 0 siblings, 1 reply; 12+ messages in thread From: Allan Klinbail @ 2016-04-21 2:52 UTC (permalink / raw) To: Takashi Sakamoto, alsa-devel 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 2:52 ` Allan Klinbail @ 2016-04-21 4:59 ` Takashi Sakamoto 2016-04-21 5:38 ` Allan Klinbail 0 siblings, 1 reply; 12+ messages in thread From: Takashi Sakamoto @ 2016-04-21 4:59 UTC (permalink / raw) To: Allan Klinbail, alsa-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 4:59 ` Takashi Sakamoto @ 2016-04-21 5:38 ` Allan Klinbail 2016-04-21 9:49 ` Takashi Sakamoto 0 siblings, 1 reply; 12+ messages in thread From: Allan Klinbail @ 2016-04-21 5:38 UTC (permalink / raw) To: Takashi Sakamoto, alsa-devel 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 5:38 ` Allan Klinbail @ 2016-04-21 9:49 ` Takashi Sakamoto 2016-04-21 21:16 ` Allan Klinbail 0 siblings, 1 reply; 12+ messages in thread From: Takashi Sakamoto @ 2016-04-21 9:49 UTC (permalink / raw) To: Allan Klinbail, alsa-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: A&H Zed R16 not completely working (DICE Jr) 2016-04-21 9:49 ` Takashi Sakamoto @ 2016-04-21 21:16 ` Allan Klinbail 0 siblings, 0 replies; 12+ messages in thread From: Allan Klinbail @ 2016-04-21 21:16 UTC (permalink / raw) To: Takashi Sakamoto, alsa-devel 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-04-21 21:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-20 14:31 A&H Zed R16 not completely working (DICE Jr) Allan Klinbail 2016-04-20 15:21 ` Takashi Sakamoto 2016-04-20 16:03 ` Allan Klinbail 2016-04-20 16:09 ` Allan Klinbail 2016-04-21 0:01 ` Takashi Sakamoto 2016-04-21 0:14 ` Allan Klinbail 2016-04-21 2:11 ` Takashi Sakamoto 2016-04-21 2:52 ` Allan Klinbail 2016-04-21 4:59 ` Takashi Sakamoto 2016-04-21 5:38 ` Allan Klinbail 2016-04-21 9:49 ` Takashi Sakamoto 2016-04-21 21:16 ` Allan Klinbail
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.