Moderators: MattKingUSA, khz
These people are practically spreading disinformation, pretending like this is some kind of expected result with their top tier hardware and l33t skills & sheeeyit.
If you have evidence that any real world system set below 128|2 is going to handle a realistic musician workload without bleeding all over the place I'd love to learn more about achieving such a state of Zen. 
@asbak
If you have evidence that any real world system set below 128|2 is going to handle a realistic musician workload without bleeding all over the place I'd love to learn more about achieving such a state of Zen
I've never gotten consistent results (minimal / no x-runs) below 128|3 (8 ms latency) on my now-six-year-old studio machine, for any recording scenario where I need to play along with anything (even a click track): I haven't tried newer machines, and have resigned myself to fixing up recorded MIDI after the fact (nudging it earlier to deal with not-sufficiently-compensated lag). Recorded audio, OTOH, seems to be compensated correctly, at least at that setting.
OTOH, different people have different tolerances for latency: pro organists, for instance, routinely deal with looooong latencies: at 3 ms per meter from a pipe rank, leaving aside whatever lag is introduced in the mechanical linkages, the latency at the console can be measured in "seconds" sometimes. Even worse, they sometimes have to cope with different latencies (some setups have different pipe ranks at different distances from the console, or drive different "ranks" of the console through separate mechanical / pneumatic "circuits").
It's been similar for me with similarly aged PC hardware.
I'm now in the process of setting up new generation PC hardware but the results (with aged USB audio interfaces) are the same. 128|3 with USB or Firewire seem to be the sane limit. It's been a while since I've worked with a PCI or PCI-e card but suspect that beyond 128|2 it will become patchy with regards to xruns.
I have no idea how the latest generation Thunderbolt audio interfaces perform, that could be interesting assuming one could even get some of them to work under Linux.
I haven't tried newer machines, and have resigned myself to fixing up recorded MIDI after the fact (nudging it earlier to deal with not-sufficiently-compensated lag). Recorded audio, OTOH, seems to be compensated correctly, at least at that setting.
Thank you for sharing your experience!
OTOH, different people have different tolerances for latency: pro organists, for instance, routinely deal with looooong latencies: at 3 ms per meter from a pipe rank, leaving aside whatever lag is introduced in the mechanical linkages, the latency at the console can be measured in "seconds" sometimes. Even worse, they sometimes have to cope with different latencies (some setups have different pipe ranks at different distances from the console, or drive different "ranks" of the console through separate mechanical / pneumatic "circuits").
Yes for sure, different people have different requirements. In this case I was looking for a general consensus on what the realistic settings on their systems were to obtain a generally fault free user experience and the lowest realistic latency.
Thank you for the information.
When a person knows nothing about anything, more reading and less talking usually helps.
artix_linux_user wrote: ↑Wed Apr 12, 2023 7:27 amI would be concerned if I would understand what y'all talkin bout.
I have a steady 64|2 here (firewire over pcie, 12th gen i3[1], xanmod-rt kernel[2], debian). It is stable in the sense that xruns only occur when overall CPU usage is too high (no random xrun occuring at reasonnable load). I can run a mixing session (medium sized I guess, I don't do orchestral) without any hickups. I haven't tried with a proof-video capture tool running though 
.
Now when mixing there's no need to go that low, it just increases consumption with no benefit. When recording I set a higher buffer size too if I can do hardware monitoring (hardware monitor + software 100% wet reverb is fine too with higher latencies).
Going lower when recording doesn't make any sense to me, I don't need the sound in my monitors to arrive before the acoustic wave coming from the dums / guitar amp / whatever hits my ears.
[1] It worked the same with my 8 years old 4th gen i7, I went for an i3 on this new system because it's approximately as fast.
[2] I used to have satisfying results with debian's stock rt kernel but for some reason it doesn't do the job anymore (I'll keep testing it from time to time though)
Merci Jean-Emmanuel
So if I understand your usage case correctly, you do mixing of pre-recorded audio (and run some effects plugins perhaps while mixing?), and you record live sessions?
[1] And in your case you don't make much or any use of LV2i or VSTi instrument plugins to play keyboard parts live?
[2] May I also ask, which firewire card (chipset?) do you use? LSI? VIA? TI?
[3] And is this with FFADO or ALSA drivers?
[EDIT]
I just tried 64|2 on my desktop at home and it seems to work for casual use with FFADO drivers. With ALSA drivers it won't run at those settings.
My fw card is a VIA VT6315, and fw interface is a MOTU Traveler.
jean-emmanuel wrote: ↑Wed Apr 12, 2023 7:54 amI have a steady 64|2 here (firewire over pcie, 12th gen i3[1], xanmod-rt kernel[2], debian). It is stable in the sense that xruns only occur when overall CPU usage is too high (no random xrun occuring at reasonnable load). I can run a mixing session (medium sized I guess, I don't do orchestral) without any hickups. I haven't tried with a proof-video capture tool running though
Now when mixing there's no need to go that low, it just increases consumption with no benefit. When recording I set a higher buffer size too if I can do hardware monitoring (hardware monitor + software 100% wet reverb is fine too with higher latencies).Going lower when recording doesn't make any sense to me, I don't need the sound in my monitors to arrive before the acoustic wave coming from the dums / guitar amp / whatever hits my ears.
[1] It worked the same with my 8 years old 4th gen i7, I went for an i3 on this new system because it's approximately as fast.
[2] I used to have satisfying results with debian's stock rt kernel but for some reason it doesn't do the job anymore (I'll keep testing it from time to time though)
asbak wrote: ↑Wed Apr 12, 2023 8:21 amSo if I understand your usage case correctly, you do mixing of pre-recorded audio (and run some effects plugins perhaps while mixing?), and you record live sessions?
And in your case you don't make much or any use of LV2i or VSTi instrument plugins to play keyboard parts live?
Yes, that's pretty much it (with a decent pile of plugins while mixing). I have a live project where we make heavy use of keyboards, synths, sequencers, plugins and the likes on a different system (adat over pci rme hdsp / alsa, 4th gen i7); we've settled on 128|2 because there's a lot on this computer's plate.
It's a TI chipset, lspci actually reports it as PCIe->PCI bridge + TI Firewire controller. In my experience, the TI chipset recommendation is not a myth. Edit: I forgot to mention the card is a Focusrite Saffire Pro40.
FFADO, I need the ffado-mixer for hardware monitoring.
Edit: turns out I can use ffado-mixer and the alsa driver at the same time, unfortunately alsa doesn't perform as well and doesn't recognize all inputs/outputs.
I just tested on my system and your settings appear to work on my desktop for casual use, also when loading FFADO drivers. I have a VT6315 PCIe card.
I haven't tried to play VSTi's / LV2i's yet, but guess it may xrun a little especially with more resource intensive plugs.
A strange anomaly on my system (I don't know if others have encountered similar issues) is that jack refuses to start with FFADO drivers if -P is set higher than 89. I'm not sure what the cause is. It will start with ALSA.
The conclusion here seems to be that the FFADO drivers still outperform the ALSA drivers, at least on my older system with older kernel & drivers.
Yes, that's pretty much it (with a decent pile of plugins while mixing). I have a live project where we make heavy use of keyboards, synths, sequencers, plugins and the likes on a different system (adat over pci rme hdsp / alsa, 4th gen i7); we've settled on 128|2 because there's a lot on this computer's plate.
Yes, that makes total sense, thank you very much for that information. 128|2 on a "loaded" box sounds like a sane setting.
I probably need to reinstall a new system here (some day) with a new kernel and re-test.
Edit: turns out I can use ffado-mixer and the alsa driver at the same time, unfortunately alsa doesn't perform as well and doesn't recognize all inputs/outputs.
Yes this is how I use it on my desktop. And like you, it seems that ALSA performance is not great compared to FFADO although I have all my inputs and outputs working with this soundcard. (MOTU Traveler MK1).
What puzzles me now is why I ended up using the ALSA drivers in the first place when I set it up a year ago, and I cannot remember anymore. 
Perhaps it was because I had ambitions to merge some cards with ALSA. It seemed like a good idea at the time but I couldn't make it work well.
Thanks a lot for sharing your experience J-E!
To summarise, on this older system at home the best I can realistically get at the moment:
ALSA FW: 128|3 when loaded
FFADO FW: 64|2 under light load, it may struggle with more LV2i's and VSTi's loaded but this requires more testing.
Go make your own l33t thread somewhere else and leave this one to the adults, ok? Bye bye.
artix_linux_user wrote: ↑Wed Apr 12, 2023 10:18 amwhen first reading this topic I was curious and I hoped to get some good information about system tuning.
but there was no information, just misleading false information.
People here not interrested in exchgange of arguments but to push their agenda.
But I think this is more about the internet troll guerilla trying to overtake linuxmusicians.
Foss users, be aware!
Myth #6 - You must have a TI Chipset Firewire Card for best performance
TI make good chipsets, also good fw chipsets. But not all TI chipsets are equal and neither are all TI fw chipsets equal. My understanding (limited) from reading on other sources is that some (or many) "TI chipset" PCI-e fw cards are packaged with PCIe to PCI bridge chips. The fw chipsets were originally developed for PCI buses, not PCI-e buses and the cheapo way to make the same designs work with PCIe cards was to add a bridge and repackage the PCI card as a PCIe card.
As far as I can determine (could be mistaken?) there is a performance hit. Not necessarily a big one, but nevertheless it's there and could make the difference between running relatively xrun free at really low latencies and getting xruns.
It's not always totally clear which PCI-e fw card models from which vendors have native fw chipsets which don't have an integrated PCIe to PCI bridge. Some of these "TI" cards and chipsets are probably not going to perform optimally, so be aware of this before assuming that any TI chipset card is ideal.
Focusrite advises the following with regards to TI fw chipsets:
In general, we would recommend PCIe/Expresscards rather than PCI cards. The particular chipsets that we have tested to work on all of our test systems are:
Texas Instruments XIO2213B and the Startech PEX 1394B3. An example of a PCIe card with this chipset are the SIIG DP FireWire 800 (NN-FW0012-S1).
https://www.siig.com/dp-firewire-800-pcie.html
https://www.startech.com/uk/Cards-Adapt ... ~PEX1394B3
An example of a laptop Expresscard with this chipset would be the Unibrain FireCard800-e.
http://www.unibrain.com/products/fireca ... esscard34/
They further advise:
While we previously also recommended VIA chipsets and the Texas Instruments XIO2200A chipset we have seen more incompatibility issues with these cards since the release of Windows 10 and would no longer recommend them.
It's not my experience. In principle there is no problem with a PCIe to PCI bridge. I'm using an RME 9632 PCI card with a PCI bridge, and there is no problem. Of course that doesn't mean every card is going to work, but I don't think you can blame the PCI bridge for that.
For any noobs reading this, asbak's throw-it-at-the-wall-and-see-if-it-sticks approach is going to bork your system eventually. 
Eek eek ook ook
artix_linux_user wrote: ↑Fri Apr 14, 2023 12:45 pmGo make your own l33t thread somewhere else and leave this one to the adults, ok? Bye bye.
Yeah, I am following the commands of crazy people, sure
I do how you say, or maybe not,, I dont care...People trying to spread rumors by communicating misleading things - yeah fool the fools.
and don t forget to fool yourself.
Allways believe in the bullshit you are communicating - this way you can allways say: I am not telling lies
Learn to read son. I didn't say there was a problem, I said there could be a performance hit. It's also not a stretch to go with the assumption that a native PCIe chipset would be preferable to a PCI chipset with a bridge tacked on, or running via an adapter. Sure, it may work good enough for your purposes.
I'm using an RME 9632 PCI card with a PCI bridge, and there is no problem.
Of course that doesn't mean every card is going to work, but I don't think you can blame the PCI bridge for that.
And congratulations, you just managed the trifecta.
For any noobs reading this, asbak's throw-it-at-the-wall-and-see-if-it-sticks approach is going to bork your system eventually.
Name one "bork your system" example. Just one.
@merlyn
Can you tell me, which adapter you use? I'm probably facing the same problem with an PCI RME-card, there are only a few boards with PCI... Can you tell anything about the latency?
Currently working with
https://www.honeysuckers.rocks/?lang=en
Fiddling with sequencers does not evolve into music necessarily and Mac users have smelly feet and guzzle little children.
bhilmers wrote: ↑Sat Apr 08, 2023 4:38 pmIt's basically there now. When I started using Linux 13 years ago I cursed the sky at how hard it was to do audio. This year I have a System76 desktop with the newest version of Pop_OS! which comes with Pipewire. Out of the box, I installed Reaper (Linux), plugged in my MIDI controller and audio interface... and everything worked with low latency. I literally did no tweaking of my system. Didn't add myself to the audio group. Didn't edit limits.conf. Nothing. For the first time I feel that I can recommend Linux for audio to my friends because it's literally as easy to use as Win/Mac.
That is good news. I'm trying Pop!_OS ASAP.