I’m new to this forum and hope not to break the rules.
I have a working LINUX system with ffado, jack, Ardour, using a ff800. Due to higher processing demands I tried to change to a Ryzen processor. Everything on the same system image runs out of the box on the Ryzen, except the FF800.
I tried:
-lsmod finds my TI firewire card
-ffado-test ListDevices lists the RME fireface 800
-ffado-test Discover finds the ff800 but freezes directly in the process
-ffado-mixer says it can’t talk to jack server through DBUS
-qjackctrl says, it can’t start the server.
-I found relating infos on https://lore.kernel.org/linux-rt-users/ … ad.org/T/, which describes exactly my situation, but there seems to be no actual solution. I tried older versions aof avlinux (2020-05-10) but had the same issues.
Is there anybody around who knows how to get around this?
Newer ALSA drivers include firewire drivers. If you want to use the FFADO drivers you will probably need to prevent the ALSA firewire drivers from loading. Alternatively you can try the ALSA drivers instead of FFADO. There are reports that the FFADO drivers work better, so if FFADO has been working for you searching for the proper way to prevent the ALSA FW drivers from loading may be what you want.
There is a possibility that the problem you have is not related, but I would recommend starting with that to eliminate driver conflicts as a possible cause.
Thanks for your answers.
I knew about ALSA/FFADO not being able to run at the same time blacklistet e.g. snd-dice, cut off all the alsa stuff. With the old processor, everything was alright, just too slow. I just moved the ssd from the old to the new system and everything was well, except the firewire. As I have realtime requirements, I need the higher performance and low latency. Therefore, ALSA does not fit the bill as it only supports firewire buffer sizes of 256 and above (as far as I know). With 2 or three buffers this leads to a significant round trip latency. FFado did the job very well in the old system with 64 as the buffer size. That’s demanding on the CPU, one of the reasons to increase CPU power to the Ryzen.
What triggers my suspicions is, that -as I said-- ffado-test Discover freezes. I am a programmer myself (not linux, but embedded stuff) and freezing programs always make my alarm bell ringing.
Jack was not able to show the fireface 800, no matter if I used ALSA or FFADO, froze on ALSA and could not start the service (as I mentioned) with FFADO. So I guess it has something to to with the kernel module for firewire (firewire-core is the probable candidate for me).
Out of desperation I wanted to be able to debug the stuff now. My first trial was to build ffado from source. I had to remove the original ffado installed by package and built and installed using the actual download (2.4.4).
The result was, that immediately things were staring to work, although I didn’t use the debug version. That would have been the second step, but -up to now- was not necessary. I was able to start jack with ffado and a buffer size of 32 at 3 buffers. I started ardour and were able to use it as usual. It seems, that the ffado build in the MXE packages is not compatible with my Ryzen while the self-built ffado is.
After a while the audio became crackly and I looked up the messages. No surprise, there were plenty of xruns. To my astonishment, after another period of time, the crackling became less and vanished. Then again crackling, followed by times with brilliant audio. This to me sounds like time bases slowly drifting against each other. I will hunt down this problem as a next step.
But hooray, the general setup is working with my new killer machine. Plenty of power, two test channels in stereo with a plethora of plugins in each channel, some VCA and foldback strips to experiment with. The result: 8% DSP usage. That’s what I wanted to see.
Quite possibly. Glad you got it working. I use an audiofire and with the alsa module 256 was minimum buffer size (jack froze with anything lower) and even then xruns were a problem. (the newer kernel will not even load the alsa fw module for me) however, when using FFADO with jack I was able to set jack to 16/2 and run 3 or 4 days with no xruns past the 1st 30 minutes when there was 1 xrun. ffado was very stable.
Check that the audio device is set to internal clock. use a low latency kernel (I expect you are) I have an i5 with 4 cores and 4 threads, if your Ryzen has double the threads to core numbers it may be worth turning that feature off as well as setting the governor to performance. It is sometimes worth while turning cron off for lowlatency but to be honest I did not and had no problems.
One more thing to look for is that if you have pulseaudio bridged to jack and pulse has access to any audio device (even if it is not using that device) it will try to operate the pulse-jack bridge by the clock of that device causing xruns and crash on export problems (export uses free wheel in jack and the pulse bridge does not support that either). if you open pavucontrol (it is worth installing this even if your desktop has another app for sound control) to the config tab, go through all the devices listed there setting the profiles to “Off” and see if that makes a difference as that will keep pulse from using those clocks.
Thanks for the quick answer. I will try these things soon. I thought I removed everything with alsa and pulse but that is not certain.
It may well be that I worked on two errors, thinking of one. This is always a dangerous situation in programming. I concluded -as both ALSA and FFADO didn’t work- that the module used by both (the core driver) must be the culprit. It now seems that FFADO is my problem. It would be interesting to look at ALSA as well. But getting this working might take a lot of time again and doesn’t serve me any advantage, I guess, apart from understanding a bit more about the system.
I meddled so much with this system that I very likely will reinstall MXE from scratch, replace ffado immediately with the self-built one and then look what happens. It’s quite probable that I did some stupid things on the way.