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).
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).
Restarting the device at the ALSA level will change it again, and again ...
until it is finally fixed.
Tentative diagnostic: ALSA driver bug.
On Tue, Aug 8, 2017 at 3:40 PM, Anders Hellquist <lau@email-addr-hidden> wrote:
> 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..
>
> I don't think waiting before launching jack helps but I can try that and
> see if it helps.
>
> /Anders
>
>
> On Aug 8, 2017 9:33 PM, "Paul Davis" <paul@email-addr-hidden> wrote:
>
>> 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.
>>
>> On Tue, Aug 8, 2017 at 2:57 PM, Anders Hellquist <lau@email-addr-hidden>
>> wrote:
>>
>>> 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.
>>> Sometimes it starts on first attempt and sometimes I need more than 5
>>> but usually on second or third.
>>>
>>> I hope you can figure out whats causing the unreliable behaviour on your
>>> end.
>>>
>>> /Anders
>>>
>>> 2017-08-08 20:18 GMT+02:00 Paul Davis <paul@email-addr-hidden>:
>>>
>>>> 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.
>>>>
>>>> On Tue, Aug 8, 2017 at 1:27 PM, Anders Hellquist <lau@email-addr-hidden>
>>>> wrote:
>>>>
>>>>> Hi again and sorry for the delay
>>>>>
>>>>> uname -a
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> cat /proc/asound/version
>>>>>
>>>>> Advanced Linux Sound Architecture Driver Version
>>>>> k3.13.0-126-lowlatency.
>>>>>
>>>>>
>>>>> /Anders
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-audio-user mailing list
>>>>> Linux-audio-user@email-addr-hidden
>>>>> https://lists.linuxaudio.org/listinfo/linux-audio-user
>>>>>
>>>>>
>>>>
>>>
>>
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
https://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed Aug 9 04:15:01 2017
This archive was generated by hypermail 2.1.8 : Wed Aug 09 2017 - 04:15:01 EEST