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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
> 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
>>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
