I all, i use ardour+jack, no RT and flexible latency config.
With my Alesis IO4 or integreted sound card i have no problem,
but if i use my Midas MR18 soundcard/mixing-console i have some random slow-down and cracky/noisy sound when i try to listen anything from ardour., absoluty no X-runs, and ardour show that it use my proc around 5 to 10% max.
Some times it works well, and just if i pause and play again the problem comes again.
I have to make severals pause/play/pause/play to make it sound good again before the problem comes back if i make a pause.
As its the first time i face this kind of trouble, i dont know if it comes from Jack, Ardour and/or the way it works with the MIDAS MR18 as it’s the only device i have issue with.
The MR18 is class complient. I have been using an XR18, which is the same beast but with different preamps, for years without any issues.
I’ve not actually used it for a couple of years as I’m currently living around 11,000 km away from it so it is possible that recent kernel updates have broken something.
I normally used it with ALSA but have, occasionally, used it with Jack. I wonder if it’s Pipewire related.
I am reading this and read this as you are not using Realtime configurations? Is there a reason? In general this is a bad idea, and could result in exactly what you are describing at random.
Thx for you reply,
Yes the reason is that i dont need monitoring, i use ardour juste to send clic and samples, as i know that rt is not necessary in this case, i thought that was good to help my computer running without consuming much ressources.
I will give it a try with rt this weekend cause i don’t have the MR18 with me actualy.
There are two different concepts which both get described by the “RT” term.
The first is using a kernel with PREEMPT_RT patches applied, which may be what you are thinking of as consuming additional power when used.
The second is configuring your user account to have realtime scheduling permissions, which is useful even without PREEMPT_RT patches to make sure that software which needs regular access (such as audio software which needs to provide the next audio data in timely fashion) has higher priority.
That is what Seablade referred to as realtime configuration, and should always be done.
Might be different, but just in case. I had exactly the same issue on modern hardware. It was caused by Intel VMD and the solution is to disable it in the BIOS.