On 25-02-2022 17:50, Len Ovens wrote:
On Fri, 25 Feb 2022, Jeremy Jongepier wrote:
On 24-02-2022 19:57, Len Ovens wrote:
While there have been many rules of thumb in the
past for tuning a
system for audio, the reality is that each system is different and
requires different steps (with testing).
Those rules of thumb should still apply mostly.
The word "mostly" pretty much sums it up. There is no low latency audio
recipe that can be dropped in and just work. Each machine/device
combination will require tweaking. For some of us that tweaking comes
naturally (I generally don't really notice what I do to achieve a good
result) but when I try explaining it to someone else via email or irc,
it is obvious that many people either do not find it very natural or
just have an unsuitable machine.
Can't argue with that!
The other
reality is that some
of the newer systems have fewer choices (like
laptops) and the user
will just have to get used to higher latency audio use.
Personally I think every system is tunable/tweakable to a certain
degree. Haven't come across a system yet that I couldn't get to run
low latency audio within the limits of that system and I've tried
quite a few.
"to a certain degree" and "within the limits of that system" seem to
me
to be saying the same thing. each system has a limit as to how well it
will do low latency audio and the user will have to live within that.
You're right, what I'm trying to say is that it should be possible to
get the most out of your system but it surely depends on what kind of
system. A Raspberry Pi can do low latency audio but don't expect it to
run a full blown sample kit with all kinds of effects. But it's great
for stuff like MODEP or Zynthian for example.
Of course USB
2.0
audio has it's own group of difficulties as
well.
Which ones? Can't think of anything else but class compliance.
The same audio device plugged into different physical ports on most
machines will yield different results, I would say newer mother boards
but maybe newer kernels because I used to be able to at least raise the
priority of one port over the next, but at some point it did not make
any difference which port I plugged into my device ends up on the same
USB bus as everything else (printer, mouse, keyboard, webcam, external
drive, etc).
Maybe someone else here could clarify the situation when it comes to
xhci_hcd but it seems you can't raise priority on those buses anymore
since they don't get different designations. With ehci_hcd this is still
possible, buses get different designations and you can discern between
them for raising priorities.
The only cure seems to be adding a dedicated PCIe USB card
for the device. Class compliance is merely the entry
fee to get audio in
and out of the machine. One can record and play back with that and use
external monitoring no problem. Using a set of drum pads with a soft
synth maybe not. It seems a firewire device using the ffado driver for
jack, out performs any USB device.
I don't agree on that one. I've owned Firewire devices in the past
(Focusrite Saffire Pro) and never faced any big difficulties when
switching to USB2. My RME Babayface still works very well, also at low
latencies or coupled with an ADAT device to add more IO. It would be
cool though if a comparison could be made between FFADO/Firewire and USB!
Best,
Jeremy