<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 15, 2021 at 2:24 AM Fons Adriaensen <<a href="mailto:fons@linuxaudio.org">fons@linuxaudio.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span>
<br>
I always wondered why it should be necessary to test 'modes' until<br>
one of them succeeds. The ALSA code could easily find that out for<br>
itself, and in the end the same interface (using snd_pcm_channel_area_t) <br>
supports all of them, so for the user code the mode doesn't matter [1]. <br>
<br>
[1] One could claim that knowing that the mode is non-interleaved<br>
would enable the user code to be simpler, like using memcpy() <br>
instead of looping over the samples. But <br>
<br>
* the channel_area params would reveal that anyway, and<br>
* usually the loop also does the sample format conversion,<br>
  so memcpy() would be ruled out anyway<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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. <br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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.</div></div></div>