Re: [Jack-Devel] How does --hwmon work?

Ralf Mardorf <[hidden]> writes:

> On Sat, 06 May 2017 19:15:02 +0200, David Kastrup wrote:
>>Ralf Mardorf <[hidden]> writes:
>>> 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?
>
> They provide drivers and the audio interfaces mixer software by
> themselves.

For old cards, that amounts to providing a download for old stuff.
I doubt that the support will amount to more than that.

> 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

1494095770.1181_0.ltw:2,a <87lgq925t9.fsf at fencepost dot gnu dot org>