<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">So the story seems to be this: ALSA stream reconfiguration (the sort of thing done by JACK or by an application running on top of ALSA) *while the device is running* will result in random re-arrangement of the input channel mapping. In particular, JACK does this when an xrun happens (also when dynamically changing the buffer size). <br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">What the MOTU web app shows as a routing to "To Computer N" can end up sort of anywhere in the full range of possibilities. Result: it looks as if no signal is flowing through to the CPU, but it is ... just on the wrong channel(s). <br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Restarting the device at the ALSA level will change it again, and again ... until it is finally fixed.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Tentative diagnostic: ALSA driver bug.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 3:40 PM, Anders Hellquist <span dir="ltr"><<a href="mailto:lau@hellquist.net" target="_blank">lau@hellquist.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Could be but the device remembers the sample rate and everything else between bootups and the display is showing 48k before I hit start in cadence (or qjackctl) so from my point of view, sample rate change does not occur..<div dir="auto"><br></div><div dir="auto">I don't think waiting before launching jack helps but I can try that and see if it helps.</div><span class="HOEnZb"><font color="#888888"><div dir="auto"><br></div><div dir="auto">/Anders</div><div dir="auto"><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Aug 8, 2017 9:33 PM, "Paul Davis" <<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">That seems to be a function of the device taking a noticeably long time to switch sample rates and be "ready for action". If JACK changes the device state as a part of the startup, it takes a while before it is actually ready.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 2:57 PM, Anders Hellquist <span dir="ltr"><<a href="mailto:lau@hellquist.net" target="_blank">lau@hellquist.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Ok, the only quirk with my setup that others have experienced too according to Ardour forum threads is that I often need two to four attempts to start jackd (actually using cadence in kxstudio to starti jackd) but when successfully started, it has never failed.<br></div>Sometimes it starts on first attempt and sometimes I need more than 5 but usually on second or third.<br><br></div>I hope you can figure out whats causing the unreliable behaviour on your end.<span class="m_6224276581568304783m_5550895380104857962HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_6224276581568304783m_5550895380104857962HOEnZb"><font color="#888888">/Anders<br></font></span></div><div class="m_6224276581568304783m_5550895380104857962HOEnZb"><div class="m_6224276581568304783m_5550895380104857962h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-08-08 20:18 GMT+02:00 Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I got mine to work (kernel 4.9) but it seems a little unreliable and may have needed to be used on a MacOS box first. Still trying to figure out what causes the lack of signal at the CPU. Certainly not caused by config changes on the MOTU itself.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_6224276581568304783m_5550895380104857962m_-8394402595546996907h5">On Tue, Aug 8, 2017 at 1:27 PM, Anders Hellquist <span dir="ltr"><<a href="mailto:lau@hellquist.net" target="_blank">lau@hellquist.net</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_6224276581568304783m_5550895380104857962m_-8394402595546996907h5"><div dir="ltr"><div><div><div>Hi again and sorry for the delay<br><br></div>uname -a<br><br>Linux 3.13.0-126-lowlatency #175-Ubuntu SMP PREEMPT Thu Jul 20 19:13:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux<br><br><br><br></div>cat /proc/asound/version<br><br>Advanced Linux Sound Architecture Driver Version k3.13.0-126-lowlatency.<br><br><br></div>/Anders<br><br></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Linux-audio-user mailing list<br>
<a href="mailto:Linux-audio-user@lists.linuxaudio.org" target="_blank">Linux-audio-user@lists.linuxau<wbr>dio.org</a><br>
<a href="https://lists.linuxaudio.org/listinfo/linux-audio-user" rel="noreferrer" target="_blank">https://lists.linuxaudio.org/l<wbr>istinfo/linux-audio-user</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
</div></div></blockquote></div><br></div>