On Sat, May 15, 2021 at 2:24 AM Fons Adriaensen <fons@xxxxxxxxxxxxxx> 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.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
