[alsa-devel] additional high input device for snd-dice (A&H Zed R16)

[Allan Klinbail]

Hi,

Was the issue of the device appearing as separate devices fixed for this
device.
I see this was addressed for devices with similar issue.

Regards

Allan

On Tue, 10 Jan 2017 at 10:55 Allan Klinbail <aklinbail at gmail.com> wrote:

> Thank you for your response.
>
> My statement was a little tongue in cheek after thought to the actual
> comment.
> All, I'm really hoping is that the full channel count will be available
> for ALSA users.
>
>
>
>
> On Tue, 10 Jan 2017 at 03:33 Takashi Sakamoto <o-takashi at sakamocchi.jp>
> wrote:
>
>> On Jan 9 2017 15:59, Allan Klinbail wrote:
>> > Hi,
>> >
>> > I noticed on the changelog that some devices are able to access all
>> > channels without doing any .asoundrc funkiness. Form 4.6 kernel onwards
>> >
>> >
>> >    - Add support for previously unavailable higher PCM channels on
>> certain
>> >    devices with high channel count, notably Focusrite Saffire PRO 40,
>> >    Focusrite Liquid Saffire 56, and TC Electronic Studio Konnekt 48.
>> These
>> >    devices spread the PCM and MIDI channels across 2 tx + 2 rx IEEE 1394
>> >    channels instead of just 1 tx + 1 rx IEEE 1394 channel, as most other
>> >    devices do.
>> >
>> >
>> > Pretty sure I've tested with 4.6 and wasn't able to achieve this with my
>> > device.  But can test again with 4.8 if I am wrong.
>> >
>> > My device is an Allen and Heath Zed R16..
>> > While latency performance in the way ALSA works is not satisfactory
>> for my
>> > usage others may wish to use this device with ALSA for simplicity.
>> (remove
>> > the need for FFADO entirely as there is no software mixer for this
>> device
>> > and remove the need for any MIDI bridge)
>> >
>> > Currently under ALSA in 44.1k or 48k the device has 16 inputs and 16
>> > outputs on the first firewire channel, and then and additional 10 ins
>> and
>> > 10 outs on the second.
>> >
>> > If this is any help, here is the vendor info, as used by FFADO
>> >
>> >
>> > { # Allen and Heath Zed R16.  Information from Brendan Pike.
>> >     vendorid    = 0x000004C4;
>> >     modelid     = 0x00000000;
>> >     vendorname  = "Allen and Heath";
>> >     modelname   = "Zed R16";
>> >     driver      = "DICE";
>> >     mixer       = "Generic_Dice_EAP";
>> > }
>> >
>> >
>> > On that latency topic- just voicing my opinion and I don't expect
>> change.
>> >
>> > When the paradigm of using periods/frames and buffers is common across
>> all
>> > OS and driver platforms, I don't believe that the driver should force
>> > developers to implement a new method, even if there are better ways of
>> > doing things.
>>
>> It's 2017 and the paradigm was already shifted since early 2000.
>> Timer-based scheduling is more popular in recent commercial operating
>> systems, to achieve PCM frame queueing delay within the size of period
>> in PCM buffer, with better power consumption.
>>
>> On the other hand, stuffs in your Linux audio still adhere old paradigm,
>> against their essential requirement.
>>
>> By the way, ALSA firewire stack supports both programming models. It
>> doesn't forces people for one of the directions.
>>
>> That might be okay for small open source projects, but bigger
>> > commercial applications would not be likely to maintain separate
>> > configuration options for Linux, they are more likely to drop Linux
>> > altogether if forced to adopt
>> >  I also know that Takashi S, does not agree but as FFADO devs have
>> agreed
>> > to keep the driver in FFADO I don't mind..
>>
>> My agreement is not so important for this topics, and it's just due to
>> few developers for this kind of devices. Recently I use more time for
>> ALSA itself, and have enough distance from this kind of devices, audio
>> and music units on IEEE 1394 bus,
>>
>> Anyway, thanks for your report.
>>
>>
>> Regards
>>
>> Takashi Sakamoto
>>
>