Pipewire surprise! 90ms added

[Largos]

Echofire4 is a firewire device. Have you tried ffado?

Thanks for your answer and No.
I'll explain.
Firstly because last time I looked it said on the FFADO website that no Firewire devices were made in the last ten years and secondly because the hard working devs over at ALSAdev have integrated just about all Firewire devices into our Linux kernel and they are just as low latency as in Windows.

Blacklisting working drivers is silly to then use pipewire? Blacklisting Pipewire would be the logical path.
Pipewire is causing this problem and it needs fixing. It can't be that difficult as the ALSA drivers already do the super low latency we (live musicians) need but can't use because we have PIPWIRE FORCED ON US from now on.

Don't get me wrong - I think pipewire is brilliant.
I ran a 34 track Reaper project through a motu 896Mk3 and had a youtu.be video running at the same time. (90ms delay is of no consequence when mixing)

You maybe don't understand the disabling thing. ALSA firewire drivers cause high live latency for a lot of devices. When it's the ALSA firewire driver/module that has the bad latency, FFADO fixes that but you have to disable the ALSA module to have it working. I have a focusrite saffire 40 and I've always had to do this, it has nothing to do with pipewire. It's an ALSA problem that FFADO fixes. It was also very good of Pipewire to include FFADO support as it would have been perfectly reasonable not to include Firewire support due it to being so obsolete.

[Martin A]

If you know that exactly, you have 2 options:.

Create a new issue on https://gitlab.freedesktop.org/pipewire ... /-/issues/
Fork pipewire and fix it.

Yes, I managed to narrow this dow to a pipewire problem before starting the thread as you can read above.

My purpose here is to find out if the problem is known or solved before making an official gitlab report.
2 Options?
No, I'm not a programmer. I'm more of an analyst / beta tester.
Imposter knows the problem though so thanks for thinking along . . . .

[Martin A]

When it's the ALSA firewire driver/module that has the bad latency

I know that in the past FFADO provided a solution but that is before the ALSAdev team, since kernel 5.7 has fixed all the firewire ALSA drivers and I mentioned already that ALSA is NOT the problem.
The ALSA Firewire Stack included drivers are working and have the same low latency as windows 10/11 -
Echo Audiofire4 = <8ms
Motu = <10ms
My testing showed that ALSA works as expected but Pipewire adds 90ms
Please read the whole thread.
You may find that Focusrite ALSA drivers are ok now.
Im not sure why the FFADO website is again suggesting blacklisting.

[Martin A]

try disabling time based scheduling

I'm going to try this today.

Just wasn't sure how to make the file as I'm not a programmer and am worried why different types of brackets apparently float on different lines and what difference they actually make.

[Largos]

When it's the ALSA firewire driver/module that has the bad latency

I know that in the past FFADO provided a solution but that is before the ALSAdev team, since kernel 5.7 has fixed all the firewire ALSA drivers and I mentioned already that ALSA is NOT the problem.
The ALSA Firewire Stack included drivers are working and have the same low latency as windows 10/11 -
Echo Audiofire4 = <8ms
Motu = <10ms
My testing showed that ALSA works as expected but Pipewire adds 90ms
Please read the whole thread.
You may find that Focusrite ALSA drivers are ok now.
Im not sure why the FFADO website is again suggesting blacklisting.

You need to blacklist the ALSA driver for FFADO to work, they conflict. This is what I am explaining to you.

So by chance Messing about with qpwgraph I set Echo Audiofire 4 to capture midi and voice into reaper but output to on board soundcard (Dell Latitude 6510) - and I fell off my chair in surprise as the 90ms Latency was gone!

I had the exact same thing. Was fixed by using the Pipewire FFADO Module.

[Impostor]

Imposter knows the problem though so thanks for thinking along . . . .

Actually I don't. Mine was just a shot-in-the-dark suggestion. I'd listen to @Largos if I were you. He actually knows what he's talking about.

[Martin A]

I had the exact same thing. Was fixed by using the Pipewire FFADO Module.

I'm glad it worked and I understand that it may be a solution if all else fails but this thread is about Pipewire / Alsa
and corners on the fact that ALSA Firewire Stack works fine since last year - the original reason for FFADO has gone.

So now I'm looking for the exact reason Pipewire adds 90ms to playback only but declares its only added 8ms, that's all.
Pipewire is the future and those trying firewire are few and far between and probably GAVE UP already.
Bare with me.

[Martin A]

.
Actually I don't. Mine was just a shot-in-the-dark suggestion. I'd listen to @Largos if I were you. He actually knows what he's talking about.

Oh thats a pitty.
Yes, Largos knows about FFADO for sure and that actually helps because, along with my tests showing current kernel ALSAfirewire to be working with the same RTT as windows, it proves again that pipewire doesn't work with firewire and is itself causing the problem (not ALSA as suggested).

I made the file disable.conf but it didn't do anything.
So my next step, if no one else knows, is to post an issue on the pipewire website.
Thanks to everyone who helped - just thought someone here might have cracked the pipewire problem.
I'll post the progress here just in case anyone gets stuck at the same point.

[Martin A]

.
So I've written a bug report to Pipewire devs:
https://gitlab.freedesktop.org/pipewire ... ssues/4785

It struck me that I must stress that this is a Pipewire-Jack issue which doesn't happen with Pipewire-Alsa-Firewire.

[Axel-Erfurt]

Maybe you could create a pw-dump while a project is playing and add it there.

Code: Select all

pw-dump > dump.txt

[Martin A]

It struck me that I must stress that this is a Pipewire-Jack issue which doesn't happen with Pipewire-Alsa-Firewire.

Just reading through my posts and found this error.
I assumed that Reaper, when in ALSA mode, uses Pipewire-Alsa but it actually bypasses Pipewire altogether even though Pipewire is active.

I finally convinced Wim Taymans, who appears to be the only developer of pipewire over at the Github, to look into the 90ms problem, so it's a matter of waiting and keeping fingers crossed now.

I'm surprised how few people use Firewire interfaces with Linux. If live monitoring isn't necessary, Reaper is now rock solid for mixing huge projects including lv2 / vst plugins like Pianoteq with Pipewire and extremely low cpu usage.

The other bug which I'm pushing at the moment is that Reaper can't do midi with native ALSA but Justin has said he'll look into it.

[sysrqer]

I finally convinced Wim Taymans

I'm sure he would have been 'convinced' much quicker if you had not acted with so much entitlement and rudeness. He doesn't owe you anything and doesn't 'have to' do or fix anything.

[talby]

I assumed that Reaper, when in ALSA mode, uses Pipewire-Alsa but it actually bypasses Pipewire altogether even though Pipewire is active.

Yes, that is a tricky one. I see the potentially similar confusion also in Tracktion Waveform. But once understood some details of the Linux audio pathways it is quite logic and clear:
In Waveform it can in general be selected between the audio device type being ALSA or JACK.
Choosing JACK connects to pipewire-jack, or old-fashioned jack2d, and then patch-bay apps like qpwgraph, or old-fashioned qjackctl, can be used without hassle.
If choosing ALSA, then it has to be carefully watched out for the various options becoming there offered as available Output devices, afterwards. If there from the many options choosing something like "Default ALSA" or "PipeWire Media Server" or "PipeWire Sound Server", then it is actually connecting to pipewire-pulse. I do not know what would be the difference between "PipeWire Media Server" or "PipeWire Sound Server", though. And I always found the "Default ALSA" to be by default configured to point to PipeWire. The other options there, carrying in its identifier string the name of the hardware device, like for instance "HDA Intel PCH ...." for my onboard chip in the Laptop, these connect directly to ALSA, to the low level layer of ALSA where only one connection can be made to, and in consequence then PipeWire cannot route something in parallel to that audio device anymore, because that only available one slot lower level ALSA is now occupied by my Tracktion Waveform app.

I assume, that what you see in Reaper is the same, that Reaper connects directly to that one only available lower level ALSA slot. I am surprised, that Reaper does not also offer to connect in an old-fashioned system to PulseAudio or in the current system to pipewire-pulse, which as some higher level mixing and routing entities then care to mix all their incoming streams from possibly various sources and for then connect this by them produced final mix to the available one only lower level ALSA slot.

The tricky thing thus is in the usage of the terms: sometimes it is correctly referred with the term ALSA to the lower level one-slot ALSA layer, but sometimes it is the term ALSA falsely used for referring to the overlayed PulseAudio or PipeWire-Pulse layers.
If someone could correct me, or could explain me how the higher level ALSA connector was positioned in all this, most likely it is in the current Linux offered as pipewire-alsa now, then I would appreciate this!

[Axel-Erfurt]

I am surprised, that Reaper does not also offer to connect in an old-fashioned system to PulseAudio or in the current system to pipewire-pulse

If you choose PulseAudio in Reaper Audio Settings then it uses pipewire-pulse.

[Martin A]

If you choose PulseAudio in Reaper Audio Settings then it uses pipewire-pulse.

That's true but watch out, Reaper has PulseAudio deactivated by default.
Pulse is not up to pro-audio really.