[LAU] can jackd or ardour be forced to use interleaved mode?

[Paul Davis]

On Sat, May 15, 2021 at 2:24 AM Fons Adriaensen <fons at linuxaudio.org> wrote:

>
> I always wondered why it should be necessary to test 'modes' until
> one of them succeeds. The ALSA code could easily find that out for
> itself, and in the end the same interface (using snd_pcm_channel_area_t)
> supports all of them, so for the user code the mode doesn't matter [1].
>
> [1] One could claim that knowing that the mode is non-interleaved
> would enable the user code to be simpler, like using memcpy()
> instead of looping over the samples. But
>
> * the channel_area params would reveal that anyway, and
> * usually the loop also does the sample format conversion,
>   so memcpy() would be ruled out anyway
>

In the case of JACK, it historically comes down to the RME hardware being
among the first to be supported on Linux that actually exposed
non-interleaved "in hardware" (mostly because RME was quite taken with
their idea of "ASIO in hardware". In 1999 or thereabouts, the cost of
deinterleaving the dta was still a notable cost to incur, so if the
hardware itself could support this (which is what the driver was really
supposed to indicate, not "well, i could make it look that way for you")
there was a small gain in performance.

Also, at that time, ALSA didn't yet properly support the mmap'ed mode ...
it was under development but not finished (as evidenced by the way it could
not handle non-interleaved devices like the RME digi series.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/linux-audio-user/attachments/20210515/da309d2f/attachment.html>