6 May
2017
6 May
'17
1:34 p.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Sat, 06 May 2017 19:15:02 +0200, David Kastrup
wrote:
For old cards, that amounts to providing a download for old stuff.
I doubt that the support will amount to more than that.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
They provide drivers and the audio interfaces mixer software by
themselves. RME does not support Linux by themselves, so even
if they made
something possible, there is no support.
So what do you call "support" that is available for other operating
systems? The only other OS I'm using is iOS. Actually I
need to use class
compliant audio interfaces for the iPad, there are no drivers
available at all and even not all class compliant audio interfaces
work with iOS, even not when using an active USB hub, to get rid of
power issues, caused by some audio interfaces, resp. by the iOS limit
of allowed poser consumption.
That does not sound like a description of "support".
You mentioned "current kernels". Rt patched?
A more or less vanilla
kernel with or without "threadirqs"?
Ubuntu lowlatency with threadirqs enabled.
The last time I made music, I used 4.9.13-rt12.
"persianrug" and
"pussytoes" are just mnemonics I added myself, the kernels are vanilla
with unimportant patches, resp. just one important patch, the rt
patch. Without the rt-patch, but with threadirqs, the latency is one
frames value less good, IOW instead of 128, I need to use 256 frames.
I am more in the 1024 or 2048 ballpark with 96kHz and the Hammerfall
DSP. Which is a bit irritating since the Mackie Onyx Firewire card is
better satisfied with 512 samples running over the builtin Ricoh
Firewire controller of the Thinkpad T61. That combination does not
sound like it should work better than the Hammerfall Cardbus interface.
How much latency would please you? Would 5 ms for
monitoring still be
too much latency?
I was not actually pitching for "pleasing me" but rather for figuring
out whether Jack/GNU/Linux get the best possible use of available
hardware.
Since the usual consequence of an xrun is to make whatever application
is currently running crash and burn (probably the process of bringing an
xrun to attention is tying up enough time to cause the next xrun), I am
not as much interested in latency optimization as I am in xrun
elimination at the moment. And the change between full and half duplex
makes a noticeable difference in my perception.
--
David Kastrup