[LAU] kernel 5.15 irqs

[Jeremy Jongepier]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20220225/7452f434/attachment.sig>