Re: [Alsa-user] ProFire 2626 question

[Takashi S. <o-t...@sa...>]

Hi,

On Fri, Aug 08, 2025 at 03:51:51PM +0200, Dmitry Sushkov wrote:
> Hello.
> 
> Is there a way to open jackd with all 26 ins and 26 outs on M-AUDIO ProFire
> 2626 with alsa backend? aplay see 2 devices, but I can use either one or
> another at a time. One have 10 inputs and 10 outputs, another have 16 inputs
> 16 outputs. So the driver knows about all I/O. Can they be used at same
> time?
>
> I have tried to specify io channels counts but jack wont start.

For this kind of topic, I've always suggested to use 'jack_in' and 'jack_out'
in jack-example-tools[1]. However, it is not what you want, I guess.

> Main problem for me is to use 3 snd-dice devices together interconnected via
> ADAT but actually record and playback only one of them. I still need them
> connected to firewire bus to control internal mixers for direct monitoring.

In my opinion, your M-Audio ProFire 2626 has standalone mode, so once
configured IEEE 1394 connection is needless in your case.

I guess the center of your issue is that configuration store operation
does not work or is not provided by any software, right?

> FFADO is always opening devices in daisy-chain mode showing all ports. This
> is causing sync issues and unstable playback.

I have never mentioned this before, as it is the technical detail
inconvenient to users and not widely recognized. However, all TC Applied
Technologies DICE ASICs - as well as other device solutions like BridgeCo's
BeBoB - do not synchronize timestamps between streams of isochronous packets.

This means that audio data frames in one packet stream have different
presentation times compared to those in another stream, even when the
device supports multiple streams, such as your ProFire 2626, or when
some devices are wired for synchronization aim.

For example, when observing two isochronous packet streams transferred by
your ProFire 2626 over an extended period (e.g. 1 hour), these two streams 
end up transmitting slightly different numbers of audio data frames --
even if they are connected via optical interface for ADAT data
synchronization. Upon further inspection of each packet's content, it
becomes clear that the presentation times for audio frames, as computed
from the timestamps within the packets, differ for each stream -- even
when the paired packets are transferred in the same isochronous cycle.

What users perceive as aggregated audio data frames may inadvertently
combine audio data frames captured at different times into the same
frame. This expains why the ALSA firewire stack does not implement such
kind of function.

> PipeWire show all devices, but as separate nodes and its adding a huge
> 90ms delay with ALSA backend. And I believe it performs some adaptive
> resampling on the fly. So for now the only  option I have is a second
> laptop with ffado driver, it's working just fine when connected alone.
> But it's a bit inconvenient.

The 90 msec delay is what expected, as the equivalent of packets queued
initially.


[1] https://github.com/jackaudio/jack-example-tools
[2] https://lore.kernel.org/alsa-devel/202...@wo.../


Regards

Takashi Sakamoto