On Sat, Aug 09, 2025 at 01:51:34PM +0200, Dmitry Sushkov wrote: > On 09. 08. 25 13:06, Takashi Sakamoto wrote: > > 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. > It does some resampling, so will add some latency compared to first device. > And probably cause some phase issues of multiple mics connected. But If I > set latency compensation in DAW it could work. > > 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? > I need all 3 devices connected to IEEE1394 bus. I have wrote a small > websockets server forwarding controls from ffado-mixer to javascript app in > a mobile phone. And set up an IEM mixer. It works just fine until I want to > record something and start streaming. Or if I stream backing track from > laptop to devices through IEEE1394 bus. So for now two Focusrite Saffire PRO > 40 interfaces only working without streaming to/from laptop, synced through > ADAT and working just fine. I use third USB multichannel card to stream > backing track and click. Bud I have bought a third firewire and want to set > it up to play all together. Streaming through firewire bus is unstable when > I connect more then one device. Using FFADO it stops streaming occasionally > without any xruns or logs reported. Using ALSA I only see first 10 channels > of choosen device, or 16 channels if I choose HW 0.1 card.
Ah, you need packet streaming from your system. > > 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. > Even within one device? Or does it apply to daisy chained devices? Or > digital ADAT/SPDIF inputs? > > > > 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. > Again, does it applies for one device alone? Even for 2 main monitor left > and right streams? What a shame.... > > 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. > Will adaptive resampling of alsa_in with latency compensation in DAW solve > the issue? All of endpoints for incoming/outgoing packet streaming in the relevant devices have no function to synchronize, even if: - these endpoints are on the same device - these endpoints are on the different devices connected to the same IEEE 1394 bus - these endpoints are on the different devices connected to the same IEEE 1394 bus and connected to any digital audio interface such like ADAT (optical), Word clock (BNC), S/PDIF (either optical or coaxial). > > The 90 msec delay is what expected, as the equivalent of packets queued > > initially. > > Thats weird. Theres a discussion today at PipeWire tracker about 90ms > latency. Main argument is that when jack is started with ALSA backend it > just works with 10 ms latency without any xruns reported for hours. And when > pipewire is using same ALSA driver its only working with 100ms latency > whatever settings used. And now you confirm that 90ms addition is what > expected? For SNDRV_PCM_STREAM_PLAYBACK substream, the time of delay is determined by the number of packets queued initially. The size is computed by the size of PCM buffer configured by ALSA PCM application. In this point, the difference between pipewire and jackd processes just comes from the size of PCM buffer, in my opinion. Additionally, the way to use ALSA PCM substream differs between these processes; the former applies the modern SNDRV_PCM_HW_PARAMS_NO_PERIOD_WAKEUP, while the latter applied the old-fashioned way to rely on periodical process wakeup scheduled by interrupt service routine. They have the slight difference reflecting their application, I guess. Regards Takashi Sakamoto _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
