LinuxMusicians

Just finished my first round of testing sample rates on the 828ES with firmware 1.4.5+92559 set to UAB and 24 channels.

Here is each sample rate/frames/periods configuration I tried. For any of them that say "Pass" it means I was able to record audio from my microphone and play it back. Next up is a bit of stress testing at 192k.

@jkohls These are interesting results. I think I need to do some reading about how Jack's rate/period/frames interacts with the underlying ALSA driver.

The following thread on the subject is intriguing to me.

List of JACK Frame & Period settings ideal for USB interface

tbritton wrote: ↑Fri Feb 22, 2013 5:20 am

...
you can enter the numbers below and thus achieve an even multiple of 1ms (that is, a whole-numbered latency figure) for use with USB interfaces which require that.
...
(actual latency depends upon other factors, but USB devices want the math-derived latency to be an even multiple of 1ms)

The asserted importance of making USB period/frames work out to an even multiple of 1ms hints at something kind of interesting to me. I need to read more, but I have a hunch. The USB Audio Class ALSA driver submits 1ms worth of audio with each USB request block. This 1ms is measured by the USB host controller clock, not by the audio word clock. Many simpler audio interfaces may actually derive their word clock from the USB clock. For these devices that would mean that 1ms measured by the USB bus would be equal to exactly 1ms measured by the word clock. In the USB class specification, such a device would be called a "synchronous" device. Practically speaking, for a High Speed USB Audio Class devices running at 48Khz what this means is that each USB request block will submit 1ms of audio (8 USB micro-frames each containing 6 audio samples).

MOTU devices operate in an "asynchronous" USB Audio Class mode. This means that the word clock is not derived from the USB clock. Instead, the number of samples in each USB micro-frame is varied depending on how many word clock intervals elapse during the USB micro-frame interval of 125us. So, if for example, the word clock was slightly fast compared to the USB bus clock, every once in a while a USB micro-frame will have one extra sample in it. So on the bus you would see a majority of micro-frames containing 6 samples and a few micro-frames containing 7 samples. This means that 1ms of audio measured by the USB host may actually be 48 plus or minus a few samples. I think if I can justify this understanding against the even 1ms recommendation, I might be closer to understanding these XRUN issues.

Another observation that might support this area of inquiry is the difference in result between 192k/1024/2 and 192k/1024/3. At 192kHz there are nominally 24 samples in each USB micro-frame or 192 nominal samples for each request block. Dividing the number of nominal samples per 1ms (request block) by the frames * period product yields a fractional result in the non-working case (1024 * 2 / 192 = 10.6666) and yields a whole number result in the working case (1024 * 3 / 192 = 16).

That said, there are configurations that you are reporting as a Pass that yield fractional results, so I there is definitely more to the story. However, I am currently thinking that these non-pass results may be addressable through Jack configuration rather than through a driver or firmware change. If anyone has any thoughts or additional understanding about this 1ms Jack requirement for USB devices I'd be happy to hear more. Not being that familiar with Jack, I wonder if there is way to add an additional extra constant amount of buffering that can absorb any of the jitter from the variable frame counts coming over USB.

AudioNarwhal wrote: ↑Thu Dec 29, 2022 3:36 pm

@jkohls These are interesting results. I think I need to do some reading about how Jack's rate/period/frames interacts with the underlying ALSA driver.

Hi all,
I suspect that the interaction between Jack and the underlying driver layer is probably adding additional variation in results and overall observations.
I am wondering whether we should not all stick to a rather simplified setup when we are testing for the channel-hopping issue, so as not to inadvertently introduce more confusion and rabbit trails as we go on. Using more complex setups may be viable once the kernel driver and/or MOTU firmware have reached a state where a simple setup no longer shows any issues.

For my own tests I have tried to avoid additional test and results complexity by staying clear of Jack and testing with just Alsa directly.
Rather I simply use Ardour 6 with ALSA as layer (explicitly not choosing Jack or PulseAudio in the Audio setup).
I just have 1 track with a sine-wave repeatedly looping over and over in playback mode. With this setup I used to observe the channel hopping sooner or later (with official firmware, not repeated the test with the experimental FW yet). Meaning I get hit by the channel-hopping even without this 1ms Jack requirement.

Any thoughts on this suggestion?

So ... back at home. MOTU AVB 1.4.5+92559 for 828ES and 8PreES.update installed. So far, no more noise, cool. Now, I am going to test the stability of sound and the channel hop thing. @AudioNarwhal Would you like me to do some more specific testing ?

Edit : the first hardware input (microphone 1 on the front side of the 828ES) is still routed to input 17 in Carla or Ardour.

stanlea wrote: ↑Thu Dec 29, 2022 7:49 pm

Edit : the first hardware input (microphone 1 on the front side of the 828ES) is still routed to input 17 in Carla or Ardour.

While audio is running can you try this utility (motu-sync-rec) to see if it corrects the input channel mapping? Can you also share the output logs from this tool?
motu-sync-rec

Example:

$ ./motu-sync-rec 169.254.231.248
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 36

At first glance, it works : physical input 1 is now on capture 1.

here's a log

studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 30
Forcing Record Sync...
USB Record Delta: 39
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 39
Forcing Record Sync...
USB Record Delta: 36
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 39
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 39
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 39
Forcing Record Sync...
USB Record Delta: 33
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 33
Forcing Record Sync...
USB Record Delta: 36
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 33
Forcing Record Sync...
USB Record Delta: 36
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 36
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 33
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 39
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 39
Forcing Record Sync...
USB Record Delta: 33
studio@studio-ThinkPad-W530:~/Bureau$ ./motu-sync-rec 192.168.1.24
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 36

Note : I've set 24 channels for jack (I use Cadence) althought 828ES has only 22 AFAIK : 2 microphones + 8 line in + 2 Toslink + 8 ADAT + 2 SP/DIF

stanlea wrote: ↑Thu Dec 29, 2022 10:45 pm

Note : I've set 24 channels for jack (I use Cadence) althought 828ES has only 22 AFAIK : 2 microphones + 8 line in + 2 Toslink + 8 ADAT + 2 SP/DIF

The channel count is configurable on the routing grid web app page. In class compliant mode, the device always sends 24x24 channels to and from the host. On the routing grid page you can modify the number of USB channels to be anywhere between 2 and 24 to enable more routing slots, however since the USB pipe is always 24x24 all driver and sound server settings need to be setup for 24 channels. Because of the routing grid there isn't a strict 1 to 1 mapping between physical IO and computer channels. This gets a little more complicated in vendor mode, but we can cross that bridge later.

On my side I can't actually see what would be the advantage of the vendor mode, if the device works in Class Compliant mode. Better stability or latency ?

stanlea wrote: ↑Thu Dec 29, 2022 11:00 pm

On my side I can't actually see what would be the advantage of the vendor mode, if the device works in Class Compliant mode. Better stability or latency ?

The only difference in vendor mode is more channels (up to 64x64).

AudioNarwhal wrote: ↑Thu Dec 29, 2022 11:03 pm

stanlea wrote: ↑Thu Dec 29, 2022 11:00 pm

On my side I can't actually see what would be the advantage of the vendor mode, if the device works in Class Compliant mode. Better stability or latency ?

The only difference in vendor mode is more channels (up to 64x64).

Oh I see, with AVB.

AudioNarwhal wrote: ↑Thu Dec 29, 2022 11:03 pm

The only difference in vendor mode is more channels (up to 64x64).

Happy new year to all and a big thank you to @AudioNarwhal for trying to make us linux users happy!

For me, one of the biggest advantages of vendor mode is that there is no sample rate change if I reboot my computer or plug in the ultralite in, so no pops and cracks.
Any chance to also fix this somehow?

1.4.5+92559 looks pretty good, just normal xrun behaviour, short clicks or pops, no channel hopping or distortion until now.
hwlatdetect still gives trouble, but only jack somehow stops communicating with the interface.
I updated from 1.4.3+92494 to 1.4.5+92559, and I had to set the optical in from toslink to adata and back to get normal signal levels (just noise at max level otherwise), this never happened on updating, or i can't remember.
Also, I can't select 192kHz anymore, is that normal?

I have a question regarding the buffer settings.
How does one set "Host Buffer Size" ,"Host Safety Offset" and alsa/jack frames/period "right" ?

Amazing to have this level of engagement from MOTU! Thrilled to see it, thanks so much!

I have a 1248 that I'd be happy to setup some tests on with alt firmwares if that'd be helpful in any way, but I have some workarounds that are working well for me so no pressure to figure out any new builds if there's nothing additional to be gained by having additional testers.

Are there now any laptops with an ethernet chipset compatible with AVB protocol ?

I've installed the latest beta firmware on my 8pre-es yesterday and had it running for approx. 20 hours without any problems @48 kHz. Thank you so much, @AudioNarwhal!

AudioNarwhal wrote: ↑Thu Dec 29, 2022 9:02 pm

stanlea wrote: ↑Thu Dec 29, 2022 7:49 pm

Edit : the first hardware input (microphone 1 on the front side of the 828ES) is still routed to input 17 in Carla or Ardour.

While audio is running can you try this utility (motu-sync-rec) to see if it corrects the input channel mapping? Can you also share the output logs from this tool?
motu-sync-rec

Example:

Code: Select all

$ ./motu-sync-rec 169.254.231.248
USB Channel Count (-1): 23
USB State: 0x11
USB Record Delta: 36
Forcing Record Sync...
USB Record Delta: 36

@AudioNarwhal: holy cow, this is magical!!

Test conditions: 8M running firmware 1.3.5+1434, switching the audio interface to UAC (vendor) mode with the curl incantation, kernel 5.19.12 with "motu" driver started with "vendor=1" (not snd-usb-audio), 48KHz sampling rate, jackd with 256 frame buffers, 64 channels.

If after starting jackd the input channels (into the computer) are shifted (channel hopping) and I run this binary, the channels jump to the right location (well, at least channel 1+2 do). It seems to be repeatable. Jackd appears to not notice anything, except the channel order is suddenly fine. This is what is printed:

$ ./motu-sync-rec 169.254.150.117
USB Channel Count (-1): 63
USB State: 0x11
USB Record Delta: 146
Forcing Record Sync...
USB Record Delta: 88

On the other hand if jackd starts and the sound is "broken" (channels in the right place but sounds buzzy) running this program does not fix the problem. I actually turned on one of my synth systems to feed it a sine wave into it to record the effect and that fixed it (that system has a USB interface for multi-channel audio I/O - Expert Sleepers ES-8). Adding another audio interface must have reset something.

This alone makes my life much easier in the sense that it looks like I no longer would have to try to start jackd multiple times until the channel order happens to be right. Wow. Thanks!