ffado-user — List for FFADO users

Re: [FFADO-user] Help with 2.5

[Dmitry S. <sus...@gm...>]

pipewire can't be removed in modern Linux because it's used for video 
streams in wayland. I leave it to work with system sounds and use 
ffado-jack alongside pipewire for pro audio. This works fine so far for 
recording.

On 4/18/26 12:17, Kevin Hasselquist wrote:
> Hello, I am very new to ffado and to firewire devices on linux. I have just
> purchased an M-Audio profire 2626 and I am looking forward to using it with
> the updates in 2.5. I have compiled and installed ffado from the release
> tarball but I am lost after that. I'm on pop os which uses pipewire. How do
> I get pipewire to see my build of 2.5? Pop os comes with a package called
> libffado2 which is version 2.4.7. It won't let me uninstall it due to
> dependency issues with pipewire.
> Any help is appreciated.
>
> Thanks.
>
> _______________________________________________
> FFADO-user mailing list
> FFA...@li...
> https://lists.sourceforge.net/lists/listinfo/ffado-user

Re: [FFADO-user] Help with 2.5

[Dmitry S. <sus...@gm...>]

Hello.

Pipewire still don't work well with ffado. Neither with alsa it's not 
very stable when it comes to firewire. When I want to record, I unload 
snd-dice module and disable pipewire-jack. Not sure about pop os, but 
UbuntuStudio have GUI for disabling pipewire-jack. And unload the module 
with "sudo rmmod snd-dice" in terminal. Then start jack with qjackctl 
and firewire driver. And only this way autio streaming is stable enough 
for production. ffado-mixer works well regardless of alsa or pipewire is 
used for audio streaming.

Feel free to ask. I wrote ffado-mixer features for profire 2626.

Regards

Dmitry.

On 4/18/26 12:17, Kevin Hasselquist wrote:
> Hello, I am very new to ffado and to firewire devices on linux. I have just
> purchased an M-Audio profire 2626 and I am looking forward to using it with
> the updates in 2.5. I have compiled and installed ffado from the release
> tarball but I am lost after that. I'm on pop os which uses pipewire. How do
> I get pipewire to see my build of 2.5? Pop os comes with a package called
> libffado2 which is version 2.4.7. It won't let me uninstall it due to
> dependency issues with pipewire.
> Any help is appreciated.
>
> Thanks.
>
> _______________________________________________
> FFADO-user mailing list
> FFA...@li...
> https://lists.sourceforge.net/lists/listinfo/ffado-user

[FFADO-user] Help with 2.5

[Kevin H. <sav...@gm...>]

Hello, I am very new to ffado and to firewire devices on linux. I have just
purchased an M-Audio profire 2626 and I am looking forward to using it with
the updates in 2.5. I have compiled and installed ffado from the release
tarball but I am lost after that. I'm on pop os which uses pipewire. How do
I get pipewire to see my build of 2.5? Pop os comes with a package called
libffado2 which is version 2.4.7. It won't let me uninstall it due to
dependency issues with pipewire.
Any help is appreciated.

Thanks.

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Brian H. <wo...@4a...>]

I tried 0x40 because I also have an AMD system, but 0x14 is what ended 
up working for me. Thanks for the input!

On 3/12/26 08:27, AreYouLoco? via FFADO-user wrote:
> I sent off-list message to OP. I also think its controller. I have the same one.
>
> Some previous email; LSI (Agere) FW643. Those are considered the best controllers because of no PCIe-to-PCIe bridge as VIA or TI. But they require quirks for different platforms as they are really old. I have MBP Mid-2012 with FW643 there was previous e-mail thread titled "Fedora 42" you may check out list archive and OP there was struggling with same adapter.
>
> Quirks required for firewire-ohci there were quirks=0x10.
>
> I have also AMD platform with full-size LSI FW643 firewire card and for AMD to make it work -> quirks=0x40.
>
> So I once again (this time on list) suggest OP to try different quirks untill interface is recognized each time. And hot-plug works.
>
> Reference: <https://github.com/torvalds/linux/blob/master/drivers/firewire/ohci.c#L281>
>
> I am on kernels 6.18 and 6.19. Some quirks set and it just works.
>
> BR,
> Orest
>
> On 12 March 2026 08:14:37 UTC, Dmitry Sushkov <sus...@gm...> wrote:
>> Hello.
>>
>> Just to confirm the issue most likely related to firewire controller.
>>
>> I have multiple firewire interfaces including Saffire PRO 40 and multiple firewire controllers from VIA and TI and haven't noticed any issues updating kernels through all 6.18.x to 6.19 now.
>>
>> Best regards
>>
>> Dmitry
>>
>> On 3/11/26 23:24, Jonathan Woithe wrote:
>>> Hi Brian
>>>
>>> On Wed, Mar 11, 2026 at 01:49:37PM +0000, Brian Hechinger wrote:
>>>> On 3/9/26 22:23, Jonathan Woithe wrote:
>>>>> Hi Brian
>>>>>
>>>>> On Mon, Mar 09, 2026 at 09:09:02PM +0000, Brian Hechinger wrote:
>>>>>> When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test
>>>>>> ListDevices` shows zero devices.
>>>>> That's certainly rather annoying and it definitely sounds like a regression.
>>>>> Presumedly if you return to 6.16 everything's fine again.
>>>> Yes, 6.16 reliably works.
>>>> :
>>>> So I'm currently on 6.18.15 and was previously on 6.16.12.  I had a
>>>> similar issue while I was running CachyOS, which runs either a 6.18 or
>>>> 6.19 kernel, but I don't remember what it was when I last ran it.
>>> Okay, so collectively this is a fairly strong indication that there's been a
>>> regression in the kernel.  Based on the above, it appears that the problem
>>> was introduced somewhere between 6.16.12 and 6.18.15.  Is that right, or is
>>> it possible to narrow down the versions further based on what you've already
>>> tried and observed?
>>>
>>> Thanks also for your subsequent follow up which made it clear that you were
>>> dealing with a 6.18.x kernel later than 6.18.9.
>>>
>>>>> Secondly, could you please run
>>>>>
>>>>>        lsmod | grep fire
>>>>>        dmesg | grep fire
>>>>>
>>>>> under 6.18.x with one of your interfaces connected and powered, and post the
>>>>> results?  The aim here is see if the kernel logs anything which might
>>>>> suggest what the problem is.
>>>>> lsmod | grep fire
>>>> firewire_ohci          69632  0
>>>> firewire_core         249856  1 firewire_ohci
>>>> crc_itu_t              12288  1 firewire_core
>>> Good - this confirms the firewire drivers are being loaded by the kernel.
>>>
>>>>> sudo dmesg | grep fire
>>>> [    3.200866] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_core...
>>>> [    3.206599] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_ohci...
>>>> [    3.208122] firewire_ohci 0000:06:00.0: enabling device (0000 -> 0002)
>>>> [    3.259360] firewire_ohci 0000:06:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
>>>> [    3.259396] firewire_ohci 0000:07:00.0: enabling device (0000 -> 0002)
>>>> [    3.310362] firewire_ohci 0000:07:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0, physUB
>>>> [    3.815437] firewire_core 0000:07:00.0: created device fw0: GUID 00027a16000139dc, S800
>>>> [    4.920694] Bridge firewalling registered
>>> Hmm.  The interface card is being detected, but the device on the bus seems
>>> not to be.  To be certain, could you do
>>>
>>>       ls -l /dev/fw*
>>>
>>> and send the result?  If you see only /dev/fw0 then it means the audio
>>> interface isn't being detected.
>>>
>>> Do you have two firewire cards in your system?
>>>
>>>>> Finally, could you confirm the firewire host adapter you've got (in case
>>>>> it's not evident from the above command outputs)?  Running
>>>>> "lspci | grep -i fire" should reveal this.
>>>> ❯ lspci | grep -i fire
>>>> 06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
>>>> 07:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
>>> FW643 are generally regarded as a solid card.
>>>
>>> Last year a separate kernel regression was identified with these cards which
>>> had very similar symptoms to what you're seeing.  The discussion was on the
>>> FFADO-user mailing list in the thread with subject "[FFADO-user] Fedora 42"
>>> which ran from April to around July 2025.  This involved kernel version
>>> 6.14.x, so the fact that 6.16.x works for you implies that the issue was
>>> since resolved.  However, I wonder if it's been inadvertently reactivated.
>>> At the time the following workaround (necessary after each boot) was found
>>> to make things work most of the time:
>>>
>>>       sudo modprobe -r firewire-ohci
>>>       sudo modprobe -r firewire-core
>>>       sleep 2
>>>       sudo modprobe firewire-ohci
>>>
>>> The "sleep 2" command is mainly relevant if putting the commands in a
>>> script.  If doing this manually it's sufficient to "wait at least 2 seconds"
>>> at that point.  Could you try the above command sequence and then see what
>>> might have happened as a result:
>>>
>>>       ls -l /dev/fw*
>>>       sudo dmesg | grep fire
>>>
>>> A later workaround was found which would make things work after a boot:  add
>>> "quirks=0x14" as an option to the firewire-ohci module.  This would be done
>>> along the following lines:
>>>
>>>       sudo echo "options firewire-ohci quirks=0x14" > /etc/modprobe.d/firewire-ohci-quirks.conf
>>>
>>>       [update any initrd/initramfs images if relevant to your distribution]
>>>
>>>       [reboot]
>>>
>>> It would be worth checking to see if this makes any difference too.
>>>
>>> If neither of these two workarounds have any effect we can conclude that the
>>> issue is a new one, rather than being a reappearance of an old one.
>>>
>>> Regards
>>>     jonathan
>>>
>>>
>>> _______________________________________________
>>> FFADO-user mailing list
>>> FFA...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ffado-user
>>
>> _______________________________________________
>> FFADO-user mailing list
>> FFA...@li...
>> https://lists.sourceforge.net/lists/listinfo/ffado-user
>
> _______________________________________________
> FFADO-user mailing list
> FFA...@li...
> https://lists.sourceforge.net/lists/listinfo/ffado-user

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Brian H. <wo...@4a...>]

On 3/11/26 22:24, Jonathan Woithe wrote:
> Hi Brian
>
> On Wed, Mar 11, 2026 at 01:49:37PM +0000, Brian Hechinger wrote:
>> Yes, 6.16 reliably works.
>> :
>> So I'm currently on 6.18.15 and was previously on 6.16.12.  I had a
>> similar issue while I was running CachyOS, which runs either a 6.18 or
>> 6.19 kernel, but I don't remember what it was when I last ran it.
> Okay, so collectively this is a fairly strong indication that there's been a
> regression in the kernel.  Based on the above, it appears that the problem
> was introduced somewhere between 6.16.12 and 6.18.15.  Is that right, or is
> it possible to narrow down the versions further based on what you've already
> tried and observed?

I'd have to dig into how to get the specific kernel version I want (I know that's something NixOS can do very easily, I just don't know how off the top of my head). Let me know if this is interesting information for you and I will gladly do so.

> Thanks also for your subsequent follow up which made it clear that you were
> dealing with a 6.18.x kernel later than 6.18.9.

Hey, I'm here for help so I'm going to do whatever you need to help assist you in helping me. :-D

>>> lsmod | grep fire
>> firewire_ohci          69632  0
>> firewire_core         249856  1 firewire_ohci
>> crc_itu_t              12288  1 firewire_core
> Good - this confirms the firewire drivers are being loaded by the kernel.
>
>>> sudo dmesg | grep fire
>> [    3.200866] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_core...
>> [    3.206599] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_ohci...
>> [    3.208122] firewire_ohci 0000:06:00.0: enabling device (0000 -> 0002)
>> [    3.259360] firewire_ohci 0000:06:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
>> [    3.259396] firewire_ohci 0000:07:00.0: enabling device (0000 -> 0002)
>> [    3.310362] firewire_ohci 0000:07:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0, physUB
>> [    3.815437] firewire_core 0000:07:00.0: created device fw0: GUID 00027a16000139dc, S800
>> [    4.920694] Bridge firewalling registered
> Hmm.  The interface card is being detected, but the device on the bus seems
> not to be.  To be certain, could you do
>
>      ls -l /dev/fw*
>
> and send the result?  If you see only /dev/fw0 then it means the audio
> interface isn't being detected.

I was only seeing fw0, yes.

> Do you have two firewire cards in your system?

No, but the card I have has two FW643 chips on it (4 port card, two ports per chip).

>>> Finally, could you confirm the firewire host adapter you've got (in case
>>> it's not evident from the above command outputs)?  Running
>>> "lspci | grep -i fire" should reveal this.
>> ❯ lspci | grep -i fire
>> 06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
>> 07:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
> FW643 are generally regarded as a solid card.

Which is how I ended up owning it. I had a different card (I forget what, it's floating around here somewhere) before. I had tons of issues which I eventually narrowed down to the card/chip being a bit crap and the FW643 came up in searches as *the* FW card to have. So I found one. (Two, actually. One is stuck at my friend's house in the UK thanks to Portugal's customs system being incredibly stupid and annoying.)

> Last year a separate kernel regression was identified with these cards which
> had very similar symptoms to what you're seeing.  The discussion was on the
> FFADO-user mailing list in the thread with subject "[FFADO-user] Fedora 42"
> which ran from April to around July 2025.  This involved kernel version
> 6.14.x, so the fact that 6.16.x works for you implies that the issue was
> since resolved.  However, I wonder if it's been inadvertently reactivated.
> At the time the following workaround (necessary after each boot) was found
> to make things work most of the time:
>
>      sudo modprobe -r firewire-ohci
>      sudo modprobe -r firewire-core
>      sleep 2
>      sudo modprobe firewire-ohci
>
> The "sleep 2" command is mainly relevant if putting the commands in a
> script.  If doing this manually it's sufficient to "wait at least 2 seconds"
> at that point.  Could you try the above command sequence and then see what
> might have happened as a result:
>
>      ls -l /dev/fw*
>      sudo dmesg | grep fire

This had no effect.

> A later workaround was found which would make things work after a boot:  add
> "quirks=0x14" as an option to the firewire-ohci module.  This would be done
> along the following lines:
>
>      sudo echo "options firewire-ohci quirks=0x14" > /etc/modprobe.d/firewire-ohci-quirks.conf
>
>      [update any initrd/initramfs images if relevant to your distribution]
>
>      [reboot]
>
> It would be worth checking to see if this makes any difference too.

This is the magic sauce. quirks=0x14 makes the audio devices show up reliably!

> If neither of these two workarounds have any effect we can conclude that the
> issue is a new one, rather than being a reappearance of an old one.

It looks like we're lucky enough to have stumbled into an old issue. I'm assuming this is a good thing as quirks=0x14 should point you to exactly what the issue is to look for the current regression?

Regardless, it's working again, for which I can't thank you enough.

Thank you so much, Jonathan!

-brian

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[AreYouLoco? <or...@pa...>]

I sent off-list message to OP. I also think its controller. I have the same one.

Some previous email; LSI (Agere) FW643. Those are considered the best controllers because of no PCIe-to-PCIe bridge as VIA or TI. But they require quirks for different platforms as they are really old. I have MBP Mid-2012 with FW643 there was previous e-mail thread titled "Fedora 42" you may check out list archive and OP there was struggling with same adapter.

Quirks required for firewire-ohci there were quirks=0x10.

I have also AMD platform with full-size LSI FW643 firewire card and for AMD to make it work -> quirks=0x40.

So I once again (this time on list) suggest OP to try different quirks untill interface is recognized each time. And hot-plug works.

Reference: <https://github.com/torvalds/linux/blob/master/drivers/firewire/ohci.c#L281>

I am on kernels 6.18 and 6.19. Some quirks set and it just works.

BR,
Orest

On 12 March 2026 08:14:37 UTC, Dmitry Sushkov <sus...@gm...> wrote:
>Hello.
>
>Just to confirm the issue most likely related to firewire controller.
>
>I have multiple firewire interfaces including Saffire PRO 40 and multiple firewire controllers from VIA and TI and haven't noticed any issues updating kernels through all 6.18.x to 6.19 now.
>
>Best regards
>
>Dmitry
>
>On 3/11/26 23:24, Jonathan Woithe wrote:
>> Hi Brian
>> 
>> On Wed, Mar 11, 2026 at 01:49:37PM +0000, Brian Hechinger wrote:
>>> On 3/9/26 22:23, Jonathan Woithe wrote:
>>>> Hi Brian
>>>> 
>>>> On Mon, Mar 09, 2026 at 09:09:02PM +0000, Brian Hechinger wrote:
>>>>> When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test
>>>>> ListDevices` shows zero devices.
>>>> That's certainly rather annoying and it definitely sounds like a regression.
>>>> Presumedly if you return to 6.16 everything's fine again.
>>> Yes, 6.16 reliably works.
>>> :
>>> So I'm currently on 6.18.15 and was previously on 6.16.12.  I had a
>>> similar issue while I was running CachyOS, which runs either a 6.18 or
>>> 6.19 kernel, but I don't remember what it was when I last ran it.
>> Okay, so collectively this is a fairly strong indication that there's been a
>> regression in the kernel.  Based on the above, it appears that the problem
>> was introduced somewhere between 6.16.12 and 6.18.15.  Is that right, or is
>> it possible to narrow down the versions further based on what you've already
>> tried and observed?
>> 
>> Thanks also for your subsequent follow up which made it clear that you were
>> dealing with a 6.18.x kernel later than 6.18.9.
>> 
>>>> Secondly, could you please run
>>>> 
>>>>       lsmod | grep fire
>>>>       dmesg | grep fire
>>>> 
>>>> under 6.18.x with one of your interfaces connected and powered, and post the
>>>> results?  The aim here is see if the kernel logs anything which might
>>>> suggest what the problem is.
>>>> lsmod | grep fire
>>> firewire_ohci          69632  0
>>> firewire_core         249856  1 firewire_ohci
>>> crc_itu_t              12288  1 firewire_core
>> Good - this confirms the firewire drivers are being loaded by the kernel.
>> 
>>>> sudo dmesg | grep fire
>>> [    3.200866] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_core...
>>> [    3.206599] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_ohci...
>>> [    3.208122] firewire_ohci 0000:06:00.0: enabling device (0000 -> 0002)
>>> [    3.259360] firewire_ohci 0000:06:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
>>> [    3.259396] firewire_ohci 0000:07:00.0: enabling device (0000 -> 0002)
>>> [    3.310362] firewire_ohci 0000:07:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0, physUB
>>> [    3.815437] firewire_core 0000:07:00.0: created device fw0: GUID 00027a16000139dc, S800
>>> [    4.920694] Bridge firewalling registered
>> Hmm.  The interface card is being detected, but the device on the bus seems
>> not to be.  To be certain, could you do
>> 
>>      ls -l /dev/fw*
>> 
>> and send the result?  If you see only /dev/fw0 then it means the audio
>> interface isn't being detected.
>> 
>> Do you have two firewire cards in your system?
>> 
>>>> Finally, could you confirm the firewire host adapter you've got (in case
>>>> it's not evident from the above command outputs)?  Running
>>>> "lspci | grep -i fire" should reveal this.
>>> ❯ lspci | grep -i fire
>>> 06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
>>> 07:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
>> FW643 are generally regarded as a solid card.
>> 
>> Last year a separate kernel regression was identified with these cards which
>> had very similar symptoms to what you're seeing.  The discussion was on the
>> FFADO-user mailing list in the thread with subject "[FFADO-user] Fedora 42"
>> which ran from April to around July 2025.  This involved kernel version
>> 6.14.x, so the fact that 6.16.x works for you implies that the issue was
>> since resolved.  However, I wonder if it's been inadvertently reactivated.
>> At the time the following workaround (necessary after each boot) was found
>> to make things work most of the time:
>> 
>>      sudo modprobe -r firewire-ohci
>>      sudo modprobe -r firewire-core
>>      sleep 2
>>      sudo modprobe firewire-ohci
>> 
>> The "sleep 2" command is mainly relevant if putting the commands in a
>> script.  If doing this manually it's sufficient to "wait at least 2 seconds"
>> at that point.  Could you try the above command sequence and then see what
>> might have happened as a result:
>> 
>>      ls -l /dev/fw*
>>      sudo dmesg | grep fire
>> 
>> A later workaround was found which would make things work after a boot:  add
>> "quirks=0x14" as an option to the firewire-ohci module.  This would be done
>> along the following lines:
>> 
>>      sudo echo "options firewire-ohci quirks=0x14" > /etc/modprobe.d/firewire-ohci-quirks.conf
>> 
>>      [update any initrd/initramfs images if relevant to your distribution]
>> 
>>      [reboot]
>> 
>> It would be worth checking to see if this makes any difference too.
>> 
>> If neither of these two workarounds have any effect we can conclude that the
>> issue is a new one, rather than being a reappearance of an old one.
>> 
>> Regards
>>    jonathan
>> 
>> 
>> _______________________________________________
>> FFADO-user mailing list
>> FFA...@li...
>> https://lists.sourceforge.net/lists/listinfo/ffado-user
>
>
>_______________________________________________
>FFADO-user mailing list
>FFA...@li...
>https://lists.sourceforge.net/lists/listinfo/ffado-user

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Dmitry S. <sus...@gm...>]

Hello.

Just to confirm the issue most likely related to firewire controller.

I have multiple firewire interfaces including Saffire PRO 40 and 
multiple firewire controllers from VIA and TI and haven't noticed any 
issues updating kernels through all 6.18.x to 6.19 now.

Best regards

Dmitry

On 3/11/26 23:24, Jonathan Woithe wrote:
> Hi Brian
>
> On Wed, Mar 11, 2026 at 01:49:37PM +0000, Brian Hechinger wrote:
>> On 3/9/26 22:23, Jonathan Woithe wrote:
>>> Hi Brian
>>>
>>> On Mon, Mar 09, 2026 at 09:09:02PM +0000, Brian Hechinger wrote:
>>>> When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test
>>>> ListDevices` shows zero devices.
>>> That's certainly rather annoying and it definitely sounds like a regression.
>>> Presumedly if you return to 6.16 everything's fine again.
>> Yes, 6.16 reliably works.
>> :
>> So I'm currently on 6.18.15 and was previously on 6.16.12.  I had a
>> similar issue while I was running CachyOS, which runs either a 6.18 or
>> 6.19 kernel, but I don't remember what it was when I last ran it.
> Okay, so collectively this is a fairly strong indication that there's been a
> regression in the kernel.  Based on the above, it appears that the problem
> was introduced somewhere between 6.16.12 and 6.18.15.  Is that right, or is
> it possible to narrow down the versions further based on what you've already
> tried and observed?
>
> Thanks also for your subsequent follow up which made it clear that you were
> dealing with a 6.18.x kernel later than 6.18.9.
>
>>> Secondly, could you please run
>>>
>>>       lsmod | grep fire
>>>       dmesg | grep fire
>>>
>>> under 6.18.x with one of your interfaces connected and powered, and post the
>>> results?  The aim here is see if the kernel logs anything which might
>>> suggest what the problem is.
>>> lsmod | grep fire
>> firewire_ohci          69632  0
>> firewire_core         249856  1 firewire_ohci
>> crc_itu_t              12288  1 firewire_core
> Good - this confirms the firewire drivers are being loaded by the kernel.
>
>>> sudo dmesg | grep fire
>> [    3.200866] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_core...
>> [    3.206599] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_ohci...
>> [    3.208122] firewire_ohci 0000:06:00.0: enabling device (0000 -> 0002)
>> [    3.259360] firewire_ohci 0000:06:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
>> [    3.259396] firewire_ohci 0000:07:00.0: enabling device (0000 -> 0002)
>> [    3.310362] firewire_ohci 0000:07:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0, physUB
>> [    3.815437] firewire_core 0000:07:00.0: created device fw0: GUID 00027a16000139dc, S800
>> [    4.920694] Bridge firewalling registered
> Hmm.  The interface card is being detected, but the device on the bus seems
> not to be.  To be certain, could you do
>
>      ls -l /dev/fw*
>
> and send the result?  If you see only /dev/fw0 then it means the audio
> interface isn't being detected.
>
> Do you have two firewire cards in your system?
>
>>> Finally, could you confirm the firewire host adapter you've got (in case
>>> it's not evident from the above command outputs)?  Running
>>> "lspci | grep -i fire" should reveal this.
>> ❯ lspci | grep -i fire
>> 06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
>> 07:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
> FW643 are generally regarded as a solid card.
>
> Last year a separate kernel regression was identified with these cards which
> had very similar symptoms to what you're seeing.  The discussion was on the
> FFADO-user mailing list in the thread with subject "[FFADO-user] Fedora 42"
> which ran from April to around July 2025.  This involved kernel version
> 6.14.x, so the fact that 6.16.x works for you implies that the issue was
> since resolved.  However, I wonder if it's been inadvertently reactivated.
> At the time the following workaround (necessary after each boot) was found
> to make things work most of the time:
>
>      sudo modprobe -r firewire-ohci
>      sudo modprobe -r firewire-core
>      sleep 2
>      sudo modprobe firewire-ohci
>
> The "sleep 2" command is mainly relevant if putting the commands in a
> script.  If doing this manually it's sufficient to "wait at least 2 seconds"
> at that point.  Could you try the above command sequence and then see what
> might have happened as a result:
>
>      ls -l /dev/fw*
>      sudo dmesg | grep fire
>
> A later workaround was found which would make things work after a boot:  add
> "quirks=0x14" as an option to the firewire-ohci module.  This would be done
> along the following lines:
>
>      sudo echo "options firewire-ohci quirks=0x14" > /etc/modprobe.d/firewire-ohci-quirks.conf
>
>      [update any initrd/initramfs images if relevant to your distribution]
>
>      [reboot]
>
> It would be worth checking to see if this makes any difference too.
>
> If neither of these two workarounds have any effect we can conclude that the
> issue is a new one, rather than being a reappearance of an old one.
>
> Regards
>    jonathan
>
>
> _______________________________________________
> FFADO-user mailing list
> FFA...@li...
> https://lists.sourceforge.net/lists/listinfo/ffado-user

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Jonathan W. <jw...@ju...>]

Hi Brian

On Wed, Mar 11, 2026 at 01:49:37PM +0000, Brian Hechinger wrote:
> On 3/9/26 22:23, Jonathan Woithe wrote:
> > Hi Brian
> > 
> > On Mon, Mar 09, 2026 at 09:09:02PM +0000, Brian Hechinger wrote:
> > > When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test
> > > ListDevices` shows zero devices.
> > That's certainly rather annoying and it definitely sounds like a regression.
> > Presumedly if you return to 6.16 everything's fine again.
> 
> Yes, 6.16 reliably works.
> :
> So I'm currently on 6.18.15 and was previously on 6.16.12.  I had a
> similar issue while I was running CachyOS, which runs either a 6.18 or
> 6.19 kernel, but I don't remember what it was when I last ran it.

Okay, so collectively this is a fairly strong indication that there's been a
regression in the kernel.  Based on the above, it appears that the problem
was introduced somewhere between 6.16.12 and 6.18.15.  Is that right, or is
it possible to narrow down the versions further based on what you've already
tried and observed?

Thanks also for your subsequent follow up which made it clear that you were
dealing with a 6.18.x kernel later than 6.18.9.

> > Secondly, could you please run
> > 
> >      lsmod | grep fire
> >      dmesg | grep fire
> > 
> > under 6.18.x with one of your interfaces connected and powered, and post the
> > results?  The aim here is see if the kernel logs anything which might
> > suggest what the problem is.
> 
> > lsmod | grep fire
> firewire_ohci          69632  0
> firewire_core         249856  1 firewire_ohci
> crc_itu_t              12288  1 firewire_core

Good - this confirms the firewire drivers are being loaded by the kernel.

> > sudo dmesg | grep fire
> [    3.200866] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_core...
> [    3.206599] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_ohci...
> [    3.208122] firewire_ohci 0000:06:00.0: enabling device (0000 -> 0002)
> [    3.259360] firewire_ohci 0000:06:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
> [    3.259396] firewire_ohci 0000:07:00.0: enabling device (0000 -> 0002)
> [    3.310362] firewire_ohci 0000:07:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0, physUB
> [    3.815437] firewire_core 0000:07:00.0: created device fw0: GUID 00027a16000139dc, S800
> [    4.920694] Bridge firewalling registered

Hmm.  The interface card is being detected, but the device on the bus seems
not to be.  To be certain, could you do

    ls -l /dev/fw*

and send the result?  If you see only /dev/fw0 then it means the audio
interface isn't being detected.

Do you have two firewire cards in your system?

> > Finally, could you confirm the firewire host adapter you've got (in case
> > it's not evident from the above command outputs)?  Running
> > "lspci | grep -i fire" should reveal this.
> 
> ❯ lspci | grep -i fire
> 06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
> 07:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)

FW643 are generally regarded as a solid card.

Last year a separate kernel regression was identified with these cards which
had very similar symptoms to what you're seeing.  The discussion was on the
FFADO-user mailing list in the thread with subject "[FFADO-user] Fedora 42"
which ran from April to around July 2025.  This involved kernel version
6.14.x, so the fact that 6.16.x works for you implies that the issue was
since resolved.  However, I wonder if it's been inadvertently reactivated. 
At the time the following workaround (necessary after each boot) was found
to make things work most of the time:

    sudo modprobe -r firewire-ohci
    sudo modprobe -r firewire-core
    sleep 2
    sudo modprobe firewire-ohci

The "sleep 2" command is mainly relevant if putting the commands in a
script.  If doing this manually it's sufficient to "wait at least 2 seconds"
at that point.  Could you try the above command sequence and then see what
might have happened as a result:

    ls -l /dev/fw*
    sudo dmesg | grep fire

A later workaround was found which would make things work after a boot:  add
"quirks=0x14" as an option to the firewire-ohci module.  This would be done
along the following lines:

    sudo echo "options firewire-ohci quirks=0x14" > /etc/modprobe.d/firewire-ohci-quirks.conf

    [update any initrd/initramfs images if relevant to your distribution]

    [reboot]

It would be worth checking to see if this makes any difference too.

If neither of these two workarounds have any effect we can conclude that the
issue is a new one, rather than being a reappearance of an old one.

Regards
  jonathan

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Brian H. <wo...@4a...>]

On 3/9/26 22:23, Jonathan Woithe wrote:
> Hi Brian
>
> On Mon, Mar 09, 2026 at 09:09:02PM +0000, Brian Hechinger wrote:
>> Are there known issues with the newer kernels? I have a Focusrite Saffire
>> Pro 24 and an Echo Audiofire4. Both of which works flawlessly under a 6.16
>> kernel.
> Yours if the first report I've seen about a possible breakage in the 6.18
> kernel.  However, nothing can ever be ruled out.
>
>> When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test
>> ListDevices` shows zero devices.
> That's certainly rather annoying and it definitely sounds like a regression.
> Presumedly if you return to 6.16 everything's fine again.

Yes, 6.16 reliably works.

>> Am I just destined to no longer be able to use my FW devices if I expect to
>> be able to use a newer kernel?
> This would not be the intention.  If something worked on a previous kernel
> then it generally ought to work with a newer one.  It seems like there might
> have been a regression somewhere between 6.16 and 6.18.  Over the last few
> kernel versions there has been some work done on the firewire driver, so
> it's not impossible that something's inadvertently gone wrong.

Ok, I just wanted to verify my assumption that things should continue to keep functioning.

>> If this is supposed to work, how do I diagnose the issue?
> There are a couple of things to check in the first instance.  The first is
> the exact kernel versions you're dealing with: which 6.16.x kernel and which
> 6.18.x kernel ("uname -r").  This provides a definitive indication of where
> the regression was introduced.

So I'm currently on 6.18.15 and was previously on 6.16.12. I had a similar issue while I was running CachyOS, which runs either a 6.18 or 6.19 kernel, but I don't remember what it was when I last ran it.

❯ nh os info
NixOS 25.11.20260304.fabb8c9
Closure Size: Unknown

Generation No Build Date           NixOS Version          Kernel  Configuration Revision Specialisations
28 (current)  2026-03-09 15:51:57  25.11.20260304.fabb8c9 6.18.15
27            2026-03-05 17:52:54  25.11.20260304.fabb8c9 6.18.15
26            2026-03-05 17:40:47  25.11.20260304.fabb8c9 6.18.15
25            2026-03-02 13:45:15  25.05.20251019.33c6dca 6.16.12

> Secondly, could you please run
>
>      lsmod | grep fire
>      dmesg | grep fire
>
> under 6.18.x with one of your interfaces connected and powered, and post the
> results?  The aim here is see if the kernel logs anything which might
> suggest what the problem is.

❯ lsmod | grep fire
firewire_ohci          69632  0
firewire_core         249856  1 firewire_ohci
crc_itu_t              12288  1 firewire_core

❯ sudo dmesg | grep fire
[    3.200866] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_core...
[    3.206599] stage-1-init: [Thu Mar  5 18:08:49 UTC 2026] loading module firewire_ohci...
[    3.208122] firewire_ohci 0000:06:00.0: enabling device (0000 -> 0002)
[    3.259360] firewire_ohci 0000:06:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
[    3.259396] firewire_ohci 0000:07:00.0: enabling device (0000 -> 0002)
[    3.310362] firewire_ohci 0000:07:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0, physUB
[    3.815437] firewire_core 0000:07:00.0: created device fw0: GUID 00027a16000139dc, S800
[    4.920694] Bridge firewalling registered

>
> Finally, could you confirm the firewire host adapter you've got (in case
> it's not evident from the above command outputs)?  Running
> "lspci | grep -i fire" should reveal this.

❯ lspci | grep -i fire
06:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)
07:00.0 FireWire (IEEE 1394): LSI Corporation FW643 [TrueFire] PCIe 1394b Controller (rev 08)

Thanks for your help!

-brian

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Brian H. <wo...@4a...>]

I kinda answered these in the last one, but just to make sure:

1. Whether you were using a 6.18.x kernel before 6.18.9.

No

2. If your devices still fail to show up under 6.18.9 or later.

Yes


On 3/10/26 00:12, Jonathan Woithe wrote:
> Hi again Brian
>
> I've taken a look through the kernel changelogs starting with 6.18 for any
> fixes which may be related to your issue.  I didn't spot anything
> immediately.  However, this one from 6.19 caught my eye due to the explicit
> mention of a Saffire Pro 40, which is closely related to the Saffire Pro 24
> you were using:
>
>> commit 2912d799e5342de7c06821668b930fd94639bd78
>> Merge: 283073725700d4 20e01bba2ae489
>> Author: Linus Torvalds<tor...@li...>
>> Date:   Fri Jan 30 17:07:45 2026 -0800
>>
>>      Merge tag 'firewire-fixes-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
>>
>>      Pull firewire fix from Takashi Sakamoto:
>>       "Fix a race condition introduced in v6.18.
>>
>>        Andreas Persson discovered this issue while working with Focusrite
>>        Saffire Pro 40 (TCD33070). The fw_card instance maintains a linked
>>        list of pending transactions, which must be protected against
>>        concurrent access.
>>
>>        However, a commit b5725cfa4120 ("firewire: core: use spin lock
>>        specific to timer for split transaction") unintentionally allowed
>>        concurrent accesses to this list.
>>
>>        Fix this by adjusting the relevant critical sections to properly
>>        serialize access"
> There's also
>
>> commit 20e01bba2ae4898ce65cdcacd1bd6bec5111abd9
>> Author: Takashi Sakamoto<o-t...@sa...>
>> Date:   Wed Jan 28 07:34:13 2026 +0900
>>
>>      firewire: core: fix race condition against transaction list
> which I think is the fix drawn in by the afore-mentioned merge.  Going back
> through 6.18's changelogs, it appears that this might have been addressed in
> there too, as of 6.18.9:
>
>> commit b038874e31fc3caa0b0d5abd259dd54b918ad4a1
>> Author: Takashi Sakamoto<o-t...@sa...>
>> Date:   Wed Jan 28 07:34:13 2026 +0900
>>
>>      firewire: core: fix race condition against transaction list
> Given this, it would be very interesting to know:
>
>   1. Whether you were using a 6.18.x kernel before 6.18.9.
>
>   2. If your devices still fail to show up under 6.18.9 or later.
>
> Regards
>    jonathan

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Jonathan W. <jw...@ju...>]

Hi again Brian

I've taken a look through the kernel changelogs starting with 6.18 for any
fixes which may be related to your issue.  I didn't spot anything
immediately.  However, this one from 6.19 caught my eye due to the explicit
mention of a Saffire Pro 40, which is closely related to the Saffire Pro 24
you were using:

> commit 2912d799e5342de7c06821668b930fd94639bd78
> Merge: 283073725700d4 20e01bba2ae489
> Author: Linus Torvalds <tor...@li...>
> Date:   Fri Jan 30 17:07:45 2026 -0800
>
>     Merge tag 'firewire-fixes-6.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
>
>     Pull firewire fix from Takashi Sakamoto:
>      "Fix a race condition introduced in v6.18.
>
>       Andreas Persson discovered this issue while working with Focusrite
>       Saffire Pro 40 (TCD33070). The fw_card instance maintains a linked
>       list of pending transactions, which must be protected against
>       concurrent access.
>
>       However, a commit b5725cfa4120 ("firewire: core: use spin lock
>       specific to timer for split transaction") unintentionally allowed
>       concurrent accesses to this list.
>
>       Fix this by adjusting the relevant critical sections to properly
>       serialize access"

There's also

> commit 20e01bba2ae4898ce65cdcacd1bd6bec5111abd9
> Author: Takashi Sakamoto <o-t...@sa...>
> Date:   Wed Jan 28 07:34:13 2026 +0900
>
>     firewire: core: fix race condition against transaction list

which I think is the fix drawn in by the afore-mentioned merge.  Going back
through 6.18's changelogs, it appears that this might have been addressed in
there too, as of 6.18.9:

> commit b038874e31fc3caa0b0d5abd259dd54b918ad4a1
> Author: Takashi Sakamoto <o-t...@sa...>
> Date:   Wed Jan 28 07:34:13 2026 +0900
>
>     firewire: core: fix race condition against transaction list

Given this, it would be very interesting to know:

 1. Whether you were using a 6.18.x kernel before 6.18.9.

 2. If your devices still fail to show up under 6.18.9 or later.

Regards
  jonathan

Re: [FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Jonathan W. <jw...@ju...>]

Hi Brian

On Mon, Mar 09, 2026 at 09:09:02PM +0000, Brian Hechinger wrote:
> Are there known issues with the newer kernels? I have a Focusrite Saffire
> Pro 24 and an Echo Audiofire4. Both of which works flawlessly under a 6.16
> kernel.

Yours if the first report I've seen about a possible breakage in the 6.18
kernel.  However, nothing can ever be ruled out.

> When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test
> ListDevices` shows zero devices.

That's certainly rather annoying and it definitely sounds like a regression. 
Presumedly if you return to 6.16 everything's fine again.

> Am I just destined to no longer be able to use my FW devices if I expect to
> be able to use a newer kernel?

This would not be the intention.  If something worked on a previous kernel
then it generally ought to work with a newer one.  It seems like there might
have been a regression somewhere between 6.16 and 6.18.  Over the last few
kernel versions there has been some work done on the firewire driver, so
it's not impossible that something's inadvertently gone wrong.

> If this is supposed to work, how do I diagnose the issue?

There are a couple of things to check in the first instance.  The first is
the exact kernel versions you're dealing with: which 6.16.x kernel and which
6.18.x kernel ("uname -r").  This provides a definitive indication of where
the regression was introduced.

Secondly, could you please run

    lsmod | grep fire
    dmesg | grep fire

under 6.18.x with one of your interfaces connected and powered, and post the
results?  The aim here is see if the kernel logs anything which might
suggest what the problem is.

Finally, could you confirm the firewire host adapter you've got (in case
it's not evident from the above command outputs)?  Running
"lspci | grep -i fire" should reveal this.

Regards
  jonathan

[FFADO-user] FW devices work fine under 6.16 but not under 6.18

[Brian H. <wo...@4a...>]

Are there known issues with the newer kernels? I have a Focusrite 
Saffire Pro 24 and an Echo Audiofire4. Both of which works flawlessly 
under a 6.16 kernel.

When I upgrade to a 6.18 kernel they just stop appearing. `ffado-test 
ListDevices` shows zero devices.

Am I just destined to no longer be able to use my FW devices if I expect 
to be able to use a newer kernel? If this is supposed to work, how do I 
diagnose the issue?

-brian

Re: [FFADO-user] Daisy chain Presonus FP10 on kernel 6.*

[Dmitry S. <sus...@gm...>]

Hello.
Sorry for offtopic, but give a try ubuntustudio 26.04 lts. For now I'm
using beta snapshot 4 on both modern desktop and 10 years old laptop  and
have to conclude it's already huge performance improvement, even with
kernel 6.19.
The pros:
It works out of the box.
It has latest pipewire with fixed firewire latency.
It has gui for setting pipewire latency.
It has latest alsa with lot of firewire job done last years.
It has latest ffado with some fixes and improvements.
It has gui for switching audio configurations so you can run jack alongside
pipewire without any issues. Just switch off jack emulatuon in pipewire,
unload snd-dice module and you can run jack with ffado backend.
It has even gui for configuring pipewire with ffado backend.
Not necessary to dive into configuration, all my firewire devices works
flawlessly with minimal latency out of the box.
It has Ardour 9 packaged in 4 days after release.

The cons:
It's still beta and may have some issues ( i have got broken desktop after
downloading update to plasma 6.6, but reinstalling plasma solved it).
Alsa still showing just one of 2 audio ports of dice asic. Depending on
device it may led to showing just half of input ports. So if you need all
inputs, you may want jack/ffado. Takashi Sakamoto, the alsa/firewire
maintainer claimed dice asic (and others like bebob) do not sync
isochronous streams of different ports which causes xruns and jitter, so if
you want all inputs, you need to use alsa_in with adaptive resampling. I
have no idea why ffado works fine...

Best regards
Dmitry.

пн, 2 мар. 2026 г., 23:48 Jonathan Woithe <jw...@ju...>:

> Hi Davide
>
> On Mon, Mar 02, 2026 at 04:47:33PM +0100, dav...@ti... wrote:
> > I've finally bought the three Presonus FP10 units and,
> > after fixing some hardware issues, I've been able to get everything
> > running on an old Core 2 Quad system with 4 GB RAM and a 256 GB
> > SSD.
>
> That's great news.  Well done!
>
> > I'll post a full blog post that will mostly cover what I'm
> > summarizing below soon. Here in my blog:
> > https://davidegironi.blogspot.com/.
>
> Thanks so much for taking the time to post about both here and on your
> blog.
> Your extensive notes are sure to be helpful for others, especially since
> they
> relate to a recent distribution and kernel.
>
> Regards
>   jonathan
>
>
> _______________________________________________
> FFADO-user mailing list
> FFA...@li...
> https://lists.sourceforge.net/lists/listinfo/ffado-user
>

Re: [FFADO-user] Daisy chain Presonus FP10 on kernel 6.*

[Jonathan W. <jw...@ju...>]

Hi Davide

On Mon, Mar 02, 2026 at 04:47:33PM +0100, dav...@ti... wrote:
> I've finally bought the three Presonus FP10 units and,
> after fixing some hardware issues, I've been able to get everything
> running on an old Core 2 Quad system with 4 GB RAM and a 256 GB
> SSD.

That's great news.  Well done!

> I'll post a full blog post that will mostly cover what I'm
> summarizing below soon. Here in my blog:
> https://davidegironi.blogspot.com/.

Thanks so much for taking the time to post about both here and on your blog.
Your extensive notes are sure to be helpful for others, especially since they
relate to a recent distribution and kernel.

Regards
  jonathan

Re: [FFADO-user] Daisy chain Presonus FP10 on kernel 6.*

[<dav...@ti...>]

  

Hi all,
I've finally bought the three Presonus FP10 units and,
after fixing some hardware issues, I've been able to get everything
running on an old Core 2 Quad system with 4 GB RAM and a 256 GB
SSD.
I'll post a full blog post that will mostly cover what I'm
summarizing below soon. Here in my blog:
https://davidegironi.blogspot.com/.
The FireWire interface I've use is a
VIA VT6306. It's cheap, but it works. I've also tested with other
FireWire interfaces and they work as well.
Hope it helps.

Below you can
find my installation helper.

 Environment
PreSonus FIREPOD
Debian
12
ffado 2.4.7
Linux kernel 6.1.0-37-amd64

 Install ffado, jack and
tools
sudo apt install jackd qjackctl ffado-tools

 List
devices
ffado-test ListDevices

 Fix realtime permissions for user
sudo
usermod -aG audio $USER
 Add to file audio realtime permissions
sudo
nano /etc/security/limits.d/audio.conf
# add following lines
@audio -
rtprio 95
@audio - memlock unlimited
 Add pam limits to pam
sessions
sudo nano /etc/pam.d/common-session
sudo nano
/etc/pam.d/common-session-noninteractive
# should have this line, if not
add it
session required pam_limits.so

 Blacklist other firewire
devices
sudo nano /etc/modprobe.d/blacklist.conf
blacklist
firewire-net
blacklist snd_bebob
blacklist snd_firewire_lib
blacklist
snd_raw1394
blacklist snd_firewire_transcode
 Update initramfs
sudo
update-initramfs -u

 Reboot your system

 Check your cards are
listed
ffado-test ListDevices

 Try to start jackd in firewire mode, you
may have to tweek options according to your hardware
jackd -d firewire
-p 256

 Install pulseaudio with jack module
sudo apt install
pulseaudio-module-jack

 Disable DBus on pulseaudio default config file
and add sink source jack modules
nano /etc/pulse/default.pa
 Edit like
below
#.ifexists module-jackdbus-detect.so
#.nofail
#load-module
module-jackdbus-detect channels=2
#.fail
#.endif
.ifexists
module-jack-sink.so
load-module module-jack-sink
load-module
module-jack-source
.endif

 Disable the auto start of pulseaudio
nano
~/.config/pulse/client.conf
 Check the following line exists on
both
autospawn = no

 Edit pulseaudio.service file to make it start
after jackd.service
systemctl --user edit --force --full
pulseaudio.service
 Find the [Unit] portion and check it contains
jackd.service
After=pulseaudio.socket jackd.service

 If you want to
check for number of card before starting jackd use step jackd_0_A)
jackd_0_B) jackd_0_C)
 If you just want to start the jackd service
without checking for card number use jackd_1_A)

 jackd_0_A) Create the
jack start batch file
nano .config/jackd_start.sh
 Add the following
content, adjust the numeber of devices you request
#!/bin/bash
# Number
of devices to check
numdev=3
# Timeout counters
count=0
timeout=30
#
Start pulseaudio
startpulseaudio=1
# Ensure pulseaudio is not running
if
[ "$startpulseaudio" -eq 1 ]; then
 pulseaudio -k || true
fi
# Wait
until FireWire devices are available
while [ $count -lt $timeout ]; do

device_count=$(ffado-test ListDevices | grep -c 'PreSonus')
 if [
"$device_count" -ge $numdev ]; then
 break
 fi
 sleep 1
 count=$((count
+ 1))
done
# Start JACK in background
/usr/bin/jackd -d firewire -p 512
-n 3 &
jackd_pid=$!
# Wait a few seconds to confirm jackd is
running
sleep 5
if ps -p $jackd_pid > /dev/null; then
 echo "jackd
started successfully."
 # Start PulseAudio if it's not already running

if [ "$startpulseaudio" -eq 1 ]; then
 if ! pgrep -x "pulseaudio" >
/dev/null; then
 echo "Starting PulseAudio..."
 pulseaudio --start

else
 echo "PulseAudio is already running."
 fi
 fi
 # Wait for JACK to
exit
 wait $jackd_pid
else
 echo "jackd failed to start."
 exit 1
fi


jackd_0_B) Create jackd service
systemctl --user edit --force --full
jackd.service
 Insert in file, use jackd options as step
above
[Unit]
Description=JACK audio
server
After=sound.target
[Service]
ExecStart=/home/youruser/.config/jackd_start.sh
Restart=on-failure
RestartSec=30s
[Install]
WantedBy=default.target


jackd_0_C) If you have set startpulseaudio=1 in the script, disable
pulseaudio service, we are gonna enable it by script
systemctl --user
stop pulseaudio.service
systemctl --user disable
pulseaudio.service
systemctl --user mask pulseaudio.service
systemctl
--user stop pulseaudio.socket
systemctl --user disable
pulseaudio.socket
systemctl --user mask pulseaudio.socket

 jackd_1_A)
Create jackd service
systemctl --user edit --force --full jackd.service

Insert in file, use jackd options as step above
[Unit]
Description=JACK
audio server
After=sound.target
[Service]
ExecStart=jackd -d firewire -p
512 -n
3
Restart=on-failure
RestartSec=30s
[Install]
WantedBy=default.target


Enable the jackd service
systemctl --user enable jackd.service
systemctl
--user start jackd.service

 Check loop dependencies
systemctl --user
list-dependencies

 Ensure pipewire is not installed, remove pipewire
and disable associated services
sudo apt remove pipewire
pipewire-audio-client-libraries
sudo systemctl --user disable --now
pipewire pipewire-pulse pipewire-media-session
 Prevent PipeWire from
start
systemctl --user mask pipewire-pulse
systemctl --user stop
pipewire-pulse
  

Re: [FFADO-user] Need to identify missing qt plugin or find a way to start the dbus server independently from the mixer

[Jonathan W. <jw...@ju...>]

Hi Octavio

On Sat, Feb 28, 2026 at 10:33:59AM -0300, Octavio Duarte wrote:
>   I kept working yesterday during the night and sorted the missing QT stuff
> but landed in a different issue: I don't have the `ffado-dbus-server`
> executable. It is not within the contents of my result package.

That's clearly a problem.  Given what comes later in the email it appears
you're compiling FFADO yourself, as opposed to using a pre-built package
from your distribution.  If ffado-dbus-server is not getting built and
installed it probably means that one or more of its dependencies are
missing.

>   I've triple checking across the scons scripts, the NixOS installer and
> the Arch Linux installer. It seems to me that it only gets built/installed
> if some dependencies exist in the environment and I'm maybe failing to
> provide that.

That is possible, yes.

>  I'm pasting my new error just in case it means anything to you, but it
> seems to be mostly stating in different phrasings "the ffado dbus server is
> nowhere to be found".
> :
> Could not get owner of name 'org.ffado.Control': no such name
> :
> FileNotFoundError: [Errno 2] No such file or directory: 'ffado-dbus-server'

I agree with your conclusion.  If ffado-dbus-server is not present on the
system then ffado-mixer will fail to run, as you have discovered.

If you are building ffado, the first lines output to the terminal by scons
describe tests for dependencies and what the outcome was.  It might be
helpful if you could post those lines.  We don't need the lines
corresponding to the building - just those which mention the tests and
dependencies.  That is, everything up to the line that reads

    scons: Building targets ...

Off the top of my head, ffado-dbus-server requires the following libraries. 
If compiling you will also need the corresponding development packages on
Linux distributions which split library packages into runtime and compile
parts.

  * libraw1394
  * libiec61883
  * libconfig++
  * libxml++-2.6 or libxml++-3.0
  * dbus-1
  * dbus-c++ (which I think includes the dbusxx-xml2cpp utility)

The graphical ffado-mixer application requires:

  * Qt
  * PyQt
  * dbus-python

If all you need in your situation is ffado-dbus-server there's no compelling
reason to worry too much about the graphical ffado-mixer.

Regards
  jonathan

Re: [FFADO-user] Need to identify missing qt plugin or find a way to start the dbus server independently from the mixer

[Octavio D. <oct...@gm...>]

  Hello! Thanks for such a fast response!

  I kept working yesterday during the night and sorted the missing QT stuff
but landed in a different issue: I don't have the `ffado-dbus-server`
executable. It is not within the contents of my result package.

  I've triple checking across the scons scripts, the NixOS installer and
the Arch Linux installer. It seems to me that it only gets built/installed
if some dependencies exist in the environment and I'm maybe failing to
provide that.

 I'm pasting my new error just in case it means anything to you, but it
seems to be mostly stating in different phrasings "the ffado dbus server is
nowhere to be found".


 ffado-mixer
Traceback (most recent call last):
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/bus.py",
line 173, in activate_name_owner
    return self.get_name_owner(bus_name)
           ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/bus.py",
line 348, in get_name_owner
    return self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
           ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                              BUS_DAEMON_IFACE, 'GetNameOwner',
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                              's', (bus_name,))
                              ^^^^^^^^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/connection.py",
line 696, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
        message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner:
Could not get owner of name 'org.ffado.Control': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/nix/store/rfvbpaafrlwqaam0jifh76rz1vpjfsj0-ffado-2.4.9/lib/python3.13/site-packages/ffado/ffadowindow.py",
line 179, in tryStartDBUSServer
    self.setupDeviceManager()
    ~~~~~~~~~~~~~~~~~~~~~~~^^
  File
"/nix/store/rfvbpaafrlwqaam0jifh76rz1vpjfsj0-ffado-2.4.9/lib/python3.13/site-packages/ffado/ffadowindow.py",
line 187, in setupDeviceManager
    devmgr = DeviceManagerInterface(FFADO_DBUS_SERVER, FFADO_DBUS_BASEPATH)
  File
"/nix/store/rfvbpaafrlwqaam0jifh76rz1vpjfsj0-ffado-2.4.9/lib/python3.13/site-packages/ffado/dbus_util.py",
line 221, in __init__
    self.dev = self.bus.get_object(self.servername, self.basepath)
               ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/bus.py",
line 237, in get_object
    return self.ProxyObjectClass(self, bus_name, object_path,
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                 introspect=introspect,
                                 ^^^^^^^^^^^^^^^^^^^^^^

 follow_name_owner_changes=follow_name_owner_changes)

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/proxies.py",
line 250, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
                          ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/bus.py",
line 178, in activate_name_owner
    self.start_service_by_name(bus_name)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/bus.py",
line 273, in start_service_by_name
    return (True, self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
                  ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                     BUS_DAEMON_IFACE,
                                     ^^^^^^^^^^^^^^^^^
                                     'StartServiceByName',
                                     ^^^^^^^^^^^^^^^^^^^^^
                                     'su', (bus_name, flags)))
                                     ^^^^^^^^^^^^^^^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/site-packages/dbus/connection.py",
line 696, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
        message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown:
The name org.ffado.Control was not provided by any .service files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/nix/store/rfvbpaafrlwqaam0jifh76rz1vpjfsj0-ffado-2.4.9/lib/python3.13/site-packages/ffado/ffadowindow.py",
line 183, in tryStartDBUSServer
    subprocess.Popen(['ffado-dbus-server', '-v3'], close_fds=True).pid
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/subprocess.py",
line 1039, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        pass_fds, cwd, env,
                        ^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
                        gid, gids, uid, umask,
                        ^^^^^^^^^^^^^^^^^^^^^^
                        start_new_session, process_group)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File
"/nix/store/8v4jp0klacwyc2ix7dw6dn1v80if4lq6-python3-3.13.9-env/lib/python3.13/subprocess.py",
line 1972, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'ffado-dbus-server'
[1]    3765 abort (core dumped)  ffado-mixer

El sáb, 28 feb 2026 a las 3:18, Jonathan Woithe (<jw...@ju...>)
escribió:

> Hi Octavio
>
> On Fri, Feb 27, 2026 at 11:18:25PM -0300, Octavio Duarte wrote:
> >   I'm having issues to run the mixer on my system. I would be fine just
> > getting the dbus server to run, but couldn't find a way to do it besides
> > starting the graphical mixer.
>
> The dbus server that's used by ffado-mixer can be manually started with the
> command
>
>     ffado-dbus-server
>
> >   My OS is a little weird and I know that makes it harder to help, but
> any
> > input is welcome. I am running NixOS and my desktop is a fairly barebones
> > window manager (XMonad) without a full installation of neither Gnome nor
> > KDE.
>
> Okay, that probably means that some X-related libraries are not installed.
>
> >   That said, the FFADO mixer was working wonderfully for me until some
> > months ago.
>
> Curious.  Do you know what changed in the meantime?
>
> >   I'm getting the following error when I try to invoke the mixer.
> >
> > ```
> >  export QT_DEBUG_PLUGINS=1 && ffado-mixer
> > QFactoryLoader::QFactoryLoader() checking directory path
> > "/home/oc/.local/lib/qt-5.15.18/plugins/platforms" ...
> > :
> > ...
> > qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
> > This application failed to start because no Qt platform plugin could be
> > initialized. Reinstalling the application may fix this problem.
>
> Using "QT_DEBUG_PLUGINS=1" is the usual way to get a handle on what's
> causing the "Could not find the Qt platform plugin..." message.  The most
> common cause I've seen cross different applications is a missing shared
> library (dependency).  Because of the indirect way Qt loads these they are
> not always declared as formal dependencies in the distribution's package
> manager, so they don't get installed on a barebones system.
>
> In your case, I'm wondering what was included in the "..." part of the
> original report.  I would expect you to see a message or messages along
> these lines somewhere:
>
>     Cannot load library /path/to/libqxcb.so (libXXXX.so.N: cannot open
>     shared object file: no such file or directory)
>
> This means that libqxcb.so tried to open the named shared library
> (libXXXX.so.N) but couldn't because it wasn't on your system.  Another
> albeit less likely possibility is that libXXXX.so.N couldn't be opened
> because one of its dependencies is missing.  In that case "no such file or
> directory" will be replaced with some other message.
>
> After finding these messages, it's a case of working out which package
> supplies the missing shared library and installing it.  It is quite likely
> that there is more than one missing library, in which case you repeat the
> above process for each library identified.  Eventually you'll end up with
> everything installed and the Qt application (ffado-mixer in your case) will
> start.
>
> For example, at work I had a user who encountered the same general "Could
> not find the Qt platform plugin" message you did for something they needed.
> This was on Almalinux 9.  Using "export QT_DEBUG_PLUGINS=1", we were able
> to
> identify that libxcb-icccm.so.4 was missing.  On Almalinux 9 this is found
> in the xcb-util-wm package.  With that installed, repeated testing showed
> the following packages were also needed:
>
>   * xcb-util-image (pulls in xcb-util as s dependency)
>   * xcb-util-keysyms
>   * xcb-util-renderutil
>   * libxkbcommon-x11
>
> Once these were all installed the application could run.
>
> Regards
>   jonathan
>

Re: [FFADO-user] Need to identify missing qt plugin or find a way to start the dbus server independently from the mixer

[Jonathan W. <jw...@ju...>]

Hi Octavio

On Fri, Feb 27, 2026 at 11:18:25PM -0300, Octavio Duarte wrote:
>   I'm having issues to run the mixer on my system. I would be fine just
> getting the dbus server to run, but couldn't find a way to do it besides
> starting the graphical mixer.

The dbus server that's used by ffado-mixer can be manually started with the
command

    ffado-dbus-server

>   My OS is a little weird and I know that makes it harder to help, but any
> input is welcome. I am running NixOS and my desktop is a fairly barebones
> window manager (XMonad) without a full installation of neither Gnome nor
> KDE.

Okay, that probably means that some X-related libraries are not installed.

>   That said, the FFADO mixer was working wonderfully for me until some
> months ago.

Curious.  Do you know what changed in the meantime?

>   I'm getting the following error when I try to invoke the mixer.
> 
> ```
>  export QT_DEBUG_PLUGINS=1 && ffado-mixer
> QFactoryLoader::QFactoryLoader() checking directory path
> "/home/oc/.local/lib/qt-5.15.18/plugins/platforms" ...
> :
> ...
> qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
> This application failed to start because no Qt platform plugin could be
> initialized. Reinstalling the application may fix this problem.

Using "QT_DEBUG_PLUGINS=1" is the usual way to get a handle on what's
causing the "Could not find the Qt platform plugin..." message.  The most
common cause I've seen cross different applications is a missing shared
library (dependency).  Because of the indirect way Qt loads these they are
not always declared as formal dependencies in the distribution's package
manager, so they don't get installed on a barebones system.

In your case, I'm wondering what was included in the "..." part of the
original report.  I would expect you to see a message or messages along
these lines somewhere:

    Cannot load library /path/to/libqxcb.so (libXXXX.so.N: cannot open
    shared object file: no such file or directory)

This means that libqxcb.so tried to open the named shared library
(libXXXX.so.N) but couldn't because it wasn't on your system.  Another
albeit less likely possibility is that libXXXX.so.N couldn't be opened
because one of its dependencies is missing.  In that case "no such file or
directory" will be replaced with some other message.

After finding these messages, it's a case of working out which package
supplies the missing shared library and installing it.  It is quite likely
that there is more than one missing library, in which case you repeat the
above process for each library identified.  Eventually you'll end up with
everything installed and the Qt application (ffado-mixer in your case) will
start.

For example, at work I had a user who encountered the same general "Could
not find the Qt platform plugin" message you did for something they needed.
This was on Almalinux 9.  Using "export QT_DEBUG_PLUGINS=1", we were able to
identify that libxcb-icccm.so.4 was missing.  On Almalinux 9 this is found
in the xcb-util-wm package.  With that installed, repeated testing showed
the following packages were also needed:

  * xcb-util-image (pulls in xcb-util as s dependency)
  * xcb-util-keysyms
  * xcb-util-renderutil
  * libxkbcommon-x11

Once these were all installed the application could run.

Regards
  jonathan

[FFADO-user] Need to identify missing qt plugin or find a way to start the dbus server independently from the mixer

[Octavio D. <oct...@gm...>]

  Hello!

  I'm having issues to run the mixer on my system. I would be fine just
getting the dbus server to run, but couldn't find a way to do it besides
starting the graphical mixer.

  My OS is a little weird and I know that makes it harder to help, but any
input is welcome. I am running NixOS and my desktop is a fairly barebones
window manager (XMonad) without a full installation of neither Gnome nor
KDE.

  That said, the FFADO mixer was working wonderfully for me until some
months ago.

  I'm getting the following error when I try to invoke the mixer.

```
 export QT_DEBUG_PLUGINS=1 && ffado-mixer
QFactoryLoader::QFactoryLoader() checking directory path
"/home/oc/.local/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/run/wrappers/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/home/oc/.nix-profile/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/nix/profile/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/home/oc/.local/state/nix/profile/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/etc/profiles/per-user/oc/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/nix/var/nix/profiles/default/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/run/current-system/sw/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/home/oc/.nargo/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/home/oc/lib/qt-5.15.18/plugins/platforms" ...
QFactoryLoader::QFactoryLoader() checking directory path
"/nix/store/jj6jldlw37r8yy9kc1smrax9dhnjm2x4-python3-3.13.9/bin/platforms"
...
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.

[1]    1208092 abort (core dumped)  ffado-mixer
```

Re: [FFADO-user] Alesis firewire IO14/26 Ubuntu Studio 25.10

[Jonathan W. <jw...@ju...>]

Hi Petter

On Thu, Jan 22, 2026 at 04:23:36PM +0100, Petter Dahlander wrote:
> Want to share my experience with this combo.

Thanks for taking the time to send this information through.

> ffado 2.49

This would have been FFADO 2.4.9, which was the current version of FFADO
until a couple of weeks ago.

> I can play/record Alesis IO14 with 2 channels in/out with pipewire default
> settings.
> But then I don't get ADAT inputs. To do this I need jack/ffado.
> 
> Blacklisted snd-dice in /etc/modeprobe.d/blacklist-firewire.conf
> Turned pipewire off in Audio configuration tool.
> Reboot.
> 
> In earlier versions before pipewire I started audioserver with Qjackctl.
> Tried Qjackctl in current 25.10 but it does not see my Alesis IO, so no
> point of using it.

With the ALSA firewire driver for this device (snd-dice) disabled and
pipewire turned off, I would expect Qjackctl to behave similarly to what you
found in earlier versions.  Perhaps there are some optional packages needed
to make this happen in this version of Ubuntu.

> Skip Qjackctl and start Ardour directly, choose Jack/Pipewire
> Then select driver FFADO.
> Under Device there is nothing to select - I don't see my Alesis IO14 there.
> I just says default.
> 
> Why does it say Jack/Pipewire? Shouldn't it be Jack only?

I'm not sure.  I don't have pipewire installed on any of my systems, and in
any case I don't know how Ubuntu has integrated it into their software
packages.  One thing to keep in mind is that pipewire contains its own
implementation of at least some parts of JACK, so maybe that's what the
above item is referring to.  It's worth noting that pipewire's built-in JACK
functionality does not substitute for a real JACK+FFADO setup because
pipewire's JACK doesn't include an equivalent to JACK's "firewire" driver as
far as I know.

> I click autostart twice.
> Then "start".
> Nothing happens.
> Then click start again!...
> Now Ardour starts and I can see all 14 inputs including ADAT inputs under
> firewire_pcm.

That's curious.  I'm not sure what might be happening there.  It would be
necessary to study the output produced by Ardour to see if it provides any
clues as to what it's doing.

> Tested recording with inputs 1-2 and playback on out 1-2, works!
> I cannot verify that ADAT inputs work but likely they do since I see them
> in Ardour.

That's progress of sorts.

> Why do I need to press buttons more than once??
> Very weird.

I agree - there's no reason obvious to me at the moment.

> If I run inxi -xA
> I see that
> Server 1 Jack 1.9.2 is: OFF
> Server 2 Pipewire 1.47 is: active
> 
> But I just turned pipewire in Ubuntu Studio Audio Configuration OFF!?
> Don't get it. What happens here?

Maybe something is causing pipewire to restart despite what you did.  If
that's the case though it's strange that it's listing all the device's
channels when you noted earlier that the default pipewire settings only gave
access to channels 1 and 2.  It would have been interesting to know whether
snd-dice ended up being loaded again under the above scenario.  With JACK
1.9.2 not running, I can't see any other way that the system could have been
accessing the Alesis IO14.

Another thought: maybe the change made in Ubuntu Studio Audio Configuration
were not permanent and were reset when the system was rebooted.

> Am I doing this the correct way?

Unfortunately I can't provide specific guidance because I don't have
pipewire myself.  I agree with you that there must be some things going on
in the background that we're not currently aware of.  It sounds like you're
going about this in a sensible way, but perhaps there's an additional trick
needed.  Hopefully others might be able to provide some feedback.

> Ardour crashes if the monitor goes into sleep - can live with that but is
> there a solution?

My guess is that the crashing of Ardour is an Ardour problem.  You may wish
to make the Ardour developers aware of it via one of the communication
channels at

    https://community.ardour.org/

It is unlikely that we (as in FFADO) can help much with this unless it is
discovered that the Ardour crash is somehow linked to FFADO.

Regards
  jonathan

[FFADO-user] Alesis firewire IO14/26 Ubuntu Studio 25.10

[Petter D. <pet...@gm...>]

Hi!

Want to share my experience with this combo.

Dell OptiPlex 7060, i7, 32GB
Ubuntu Studio 25.10

Alesis IO14/26 Firewire audio interface.
Adaptec Firewire PCI card with Texas instrument chipset.
ffado 2.49

I can play/record Alesis IO14 with 2 channels in/out with pipewire default
settings.
But then I don't get ADAT inputs. To do this I need jack/ffado.

Blacklisted snd-dice in /etc/modeprobe.d/blacklist-firewire.conf
Turned pipewire off in Audio configuration tool.
Reboot.

In earlier versions before pipewire I started audioserver with Qjackctl.
Tried Qjackctl in current 25.10 but it does not see my Alesis IO, so no
point of using it.

Skip Qjackctl and start Ardour directly, choose Jack/Pipewire
Then select driver FFADO.
Under Device there is nothing to select - I don't see my Alesis IO14 there.
I just says default.

Why does it say Jack/Pipewire? Shouldn't it be Jack only?

I click autostart twice.
Then "start".
Nothing happens.
Then click start again!...
Now Ardour starts and I can see all 14 inputs including ADAT inputs under
firewire_pcm.
Tested recording with inputs 1-2 and playback on out 1-2, works!
I cannot verify that ADAT inputs work but likely they do since I see them
in Ardour.
Why do I need to press buttons more than once??
Very weird.

If I run inxi -xA
I see that
Server 1 Jack 1.9.2 is: OFF
Server 2 Pipewire 1.47 is: active

But I just turned pipewire in Ubuntu Studio Audio Configuration OFF!?
Don't get it. What happens here?
Am I doing this the correct way?

Can anybody help?

Ardour crashes if the monitor goes into sleep - can live with that but is
there a solution?

So I'm nearly there!
Hope it helps somebody else!

Kind regards
Petter

[FFADO-user] [Announce] FFADO version 2.5.0

[Jonathan W. <jw...@ju...>]

The FFADO project (https://ffado.org) announces the availability of FFADO
version 2.5.0.  This version includes some new features and helpful fixes.

This is a source-only release that can be downloaded from

    https://ffado.org/files/libffado-2.5.0.tgz

New features since FFADO 2.4.9:

  * Visual and functional improvements to ffado-mixer by Edmund Raile.

  * The geometry and state of ffado-mixer is restored when started (thanks
    to Dmitry Sushkov.

  * Device state can be restored automatically when ffado-mixer starts if
    enabled in the preferences dialog (from Dmitry Sushkov).

Other changes since FFADO 2.4.9:

  * Fix crossbar router state restoration (reported by Nick Sorenson).

  * Try to make MAudio ProFire 2626 GUIDs unique so more than one can be used 
    simultaneously in ffado-mixer.

  * Fix text formatting in "About" window (reported by Pander).

  * Additional python type mismatch fixes from Dmitry Sushkov.

  * Avoid calling non-existent methods when dealing with device nicknames.

  * Fixes for the ProFire 2626 mixer and crossbar router from Dmitry Sushkov.

  * Fix setting restoration when more than one device is present (Dmitry
    Sushkov).

  * Be more flexible when restoring device settings when streaming is active
    (Dmitry Sushkov).

Thanks to those who have helped with this release, including Edmund Raile,
Dmitry Sushkov, Pander and Nick Sorenson.


Jonathan Woithe
(on behalf of ffado.org)

Re: [FFADO-user] SConstruct errors

[Jonathan W. <jw...@ju...>]

Hi all

There have been an off-list follow ups to the response I sent earlier which
may be useful to summarise for future readers of the list archives.  Based
on further testing it appears that the root cause of the issue lies in the
detail about how scons works, what exactly is in its cache, and the
management of configuration test results.

When scons runs its tests it stores the result of those tests for later
reference.  The reasoning seems to be that some tests can be quite time
consuming and the result rarely changes.  Considerable time can therefore be
saved during subsequent builds if the previous results are reused.

Contrary to what might be expected, the configuration test results are not
stored in scons's cache.  Instead they are stored separately (in
.sconsign.dblite I think).  In contrast, the scons cache stores historical
versions of generated files.  In the case of the C language, this would
include object files and executables.

There are some other sources of potential confusion.  Running
"scons --clean" removes all target files, where target files in this context
are files created as a result of the build process.  It will not remove or
invalidate the stored configuration test results.  Similarly, using the
"--no-cache" option won't affect the stored test results because they are
not stored in the cache.

While there is apparently some logic within scons which attempts to
determine when test results are out of date, it doesn't appear to always
cover the case where a dependency is added after an initial run of scons. 
This means that if an initial scons run fails due to a missing dependency
and gets far enough that the configuration test results are written, then
runs of scons after installing that dependency will still report it to be
missing.  This is because the test for the dependency wouldn't be rerun: ths
stored result of the previous test would be used instead.

All this means that if a run of scons identifies a missing dependency which
is then installed, the next run of scons needs to include "--config=force"
option to guarantee that the newly installed package is picked up.

The confusing situation described in the original post seems to be the
result of the stored configuration test results and uncertainty over when
and how these are regenerated.  It is expected that the dependencies which
were reported as missing even after being installed would be correctly
detected if the "--config=force" scons option was used following the
installation.

For the avoidance of doubt, neither "--no-cache" nor "--clean" have any
effect on the stored test results.  To rerun dependency tests after
installing a dependency, the "--config=force" scons option should be used. 
So long as no changes are made to dependencies, all subsequent scons runs do
not need to include it.

Regards
  jonathan

Re: [FFADO-user] SConstruct errors

[Jonathan W. <jw...@ju...>]

Hi Dmitry

On Sat, Nov 01, 2025 at 10:02:38PM +0100, Dmitry Sushkov wrote:
> I have installed recent Ubuntu 25.10 due to old SSD failure and dove info
> ffado building from source. Seems SConstruct Is outdated, most checks works
> incorrect. Is there a guide for proper checking prerequisites somewhere?

I'm not sure what exactly you're asking for.  Perhaps the SCons manual is
what you're after, but I'm not convinced.

The FFADO SConstruct file uses standard mechanisms to test for the presence
of packages.  "which", "pkg-config" and the like are all very well
established methods.  I've seen no mention of plans to deprecate either on
Linux systems.

> What i have found so far:
> Checking against version '0' doesnt work, changing alsa requirement to
> version '1' passed the test.

I am not sure what to make of this.  The check as coded should use pkg-config
to test whether the version installed is at least the one specified.  In the
case of ALSA, the test should be for version 0 of ALSA or higher.  If the
check is truly failing with 0 with version 1 installed then the behaviour of
the underlying tools (pkg-config for example) must have changed.  That seems
unlikely.

I vaguely recall reading somewhere that pkg-config was being replaced in
some places with pkgconf, billed as a drop-in replacement If Ubuntu 25.10
has done this and the new tool behaves differently to pkg-config when
testing versions then I expect many package builds to fail, not just FFADO. 
Thus this scenario seems unlikely.  FFADO isn't doing anything special here,
and is in fact using infrastructure as it was intended.

To permit further investigation, could you send through the full output you
get when running scons to compile ffado?  The contents of the
cache/config.log file may be helpful too.  If the list rejects the latter as
being too big please sent it to me off-list.

> Checking output of 'which something' doesnt work because it returns 0 even
> if printing '/usr/bin/something' in terminal. When i change checks to
> 'something --version' some checks passed, some not because programs have no
> --version parameter.

Using "which" is a well defined way to determine if an executable is found
in a directory in the PATH, and which directory it was in.  I can't imagine
Ubuntu would change the way it behaves - doing so would break a huge number
of tools, not just build scripts.

Could you explain in more detail what is going wrong with "which" on your
system?  "Which" *should* behave as follows:

    > which foobar
    which: no foobar in (...)

    > echo $?
    1

    > which ls
    /usr/bin/ls

    > echo $?
    0

Could you run these and let us know the outputs produced:

    which foobar
    echo $?
    which ls
    echo $?

> So despite all requirements are installed, most checka failed.

Just out of interest, are all the "devel" packages installed along with
their runtime packages?

One other thought I just had: Ubuntu 25.10 switched to the rust
reimplementation of the coreutils package (they are the first major
distribution to do so I think).  I know a difference in the rust-cooreutils
"date" program has caused issues with unattended updates.  Perhaps there are
other corner cases too.  That said, neither "which" nor "pkg-config" are
part of coreutils, so this wouldn't explain any breakage with these.  That
aside, perhaps some of the issues you're seeing are the result of the
rust-coreutils package.  It may be possible to replace rust-coreutils with
gnu-coreutils using a command long the lines of the following:

    sudo apt install coreutils-from-gnu coreutils-from-uutils
         --allow-remove-essential

However, please satisfy yourself that this is correct before doing so.  I
don't have an Ubuntu system to test it on and I don't use Ubuntu.  I cannot
provide any guarantees that this won't break your system.  This may also
have nothing to do with the issues you have encountered.

Regards
  jonathan