Ultralite AVB

[buonamorte.records]

Tomorrow will be a great day to test my: 828es; Ultralite AVB es; Stage B-16; 8M. The 828 with 1.4.5 seems to work fine, no news about ultralite (that means no way to mix at home to me... ). If Ultralite doesn't work I'll buy an audient just to work at home...@AudioNarwhal where are you?? I was and now

[supereb]

The new firmware has been working great for me but if I have firefox open to manipulate the internal mixer settings it will occasionally swap channels.

[stanlea]

For channel hoping, there is still this utility

motu-sync-rec

[AudioNarwhal]

Sorry to leave everyone hanging, unfortunately I still don't have any news to report at this time. I have been waiting to hear back on my request for additional information regarding how the differences with the UltraLite ES variant could effect this behavior. I will definitely provide an update when I learn more. It still doesn't really make sense to me why it behaves differently given how almost identical the two variants are to each other.

However, just to set expectations based on my current understanding, there is a strong possibility that the issues with UL ES variant can't be addressed in the same way. (I really hope this isn't the case)

Also I am not sure about the general status of the new beta firmware. I've not been able to test myself due to work overload, but as far as I understood from the various posts, the hopping seems to be gone, but there is still crackling etc. Can you confirm?

Yeah, basically the beta firmware just attempts to recover when audio doesn't stream continuously from the host, however there is still the issue that the audio doesn't stream continuously so you will hear those dropouts as cracking/pops and ticks.

I haven't tried this, but a solution similar to my patch might be to apply the already existent "QUIRK_FLAG_PLAYBACK_FIRST" quirk for the MOTU pro audio PID/VID in the existing linux audio class driver.

I use it with other OS's macos, windows 11 & manjaro Linux (now unusable with the channel skipping), so my question to @AudioNarwhal would the experimental firmware still work well with the latest drivers on macos & windows 11?

It should, although it has not been extensively tested.

[Musinux]

It still doesn't really make sense to me why it behaves differently given how almost identical the two variants are to each other.

Thanks for the update.
Is there the possibility to somehow lock the samplerate of the device (no matter if ES or not) ?
My main problem with using the Ultralite as a normal USB soundcard is that (I think) ALSA probes every possible samplerate on initialization (boot), leading to loud pops and clicks while probing, and distortion if there's spdif input while probing and until sample rate is set back manually.

Locking samplerate via modules-load worked, but this leads to problems with other sound interfaces (webcams, intel hda etc.).

Running drumfix' driver in vendor mode doesn't probe (since rate set in conf), so is this just a problem with class compliant mode?

It's still not clear to me why the spdif inputs have to distort when sample rate doesn't match. RME Babyface just mutes the input or changes its samplerate to match (which doesn't work with the Ultalite).

Is this a (HW-) feature or a bug?

[bluebell]

Running drumfix' driver in vendor mode doesn't probe (since rate set in conf), so is this just a problem with class compliant mode?

I use drumfix' ua101 in class compliant mode and it sets the sample rate from its parms, too.

Code: Select all

options snd_ua101 samplerate=48000 midi=1

[AudioNarwhal]

Is there the possibility to somehow lock the samplerate of the device (no matter if ES or not) ?
My main problem with using the Ultralite as a normal USB soundcard is that (I think) ALSA probes every possible samplerate on initialization (boot), leading to loud pops and clicks while probing, and distortion if there's spdif input while probing and until sample rate is set back manually.

The sample rate switching during enumeration is an unfortunate outcome of the USB Audio Class 2 specification. This is because USB audio class streaming interfaces can have multiple "alternate settings" each with a different number of channels and audio format. Each "alternate setting" may or may not be available at a given sampling frequency, so the host has to set the sampling rate then ask the device what the valid alternate settings are in order to build a list of what channel counts, formats, etc are available at each sampling frequency. This should be resolved in the USB Audio Class 4 specification with the addition of the "Valid Frequency Range Descriptor" that will accompany each alternate setting, however the specification is still being finalized.

It's still not clear to me why the spdif inputs have to distort when sample rate doesn't match. RME Babyface just mutes the input or changes its samplerate to match (which doesn't work with the Ultalite).

Is this a (HW-) feature or a bug?

The device doesn't have a way of measuring the S/PDIF frequency unless it is the currently selected clock source, so it just assumes the data is valid even if its coming in at the wrong rate. This is something that would be nice to improve on future devices. I wonder if selecting spdif as the clock source would help with the noise problem? It may cause other problems though

I wish I had the time/bandwidth to write a driver for this hardware since I think I have ideas on how doing things differently from the class implementation could provide a much better experience for you all. Maybe one day...

[Musinux]

I wonder if selecting spdif as the clock source would help with the noise problem? It may cause other problems though

Makes no difference what clock source is selected, as soon as the alsa driver probes sample rates, there will be clicks/noise.

I wish I had the time/bandwidth to write a driver for this hardware since I think I have ideas on how doing things differently from the class implementation could provide a much better experience for you all. Maybe one day...

Thanks for giving us some insights and a little hope to get some issues fixed in the long-term.

[shellwalker]

Sorry to leave everyone hanging, unfortunately I still don't have any news to report at this time.

Good to see you back here, Dylan. I was beginning to get worried

However, just to set expectations based on my current understanding, there is a strong possibility that the issues with UL ES variant can't be addressed in the same way. (I really hope this isn't the case)

I have a 828ES. Does this mean that even your Beta Firmware would not be of help for me?

Yeah, basically the beta firmware just attempts to recover when audio doesn't stream continuously from the host, however there is still the issue that the audio doesn't stream continuously so you will hear those dropouts as cracking/pops and ticks.

Is this the same experience MacOs users are having?
I would be surprised if there is acceptance of such noise in productions....
Have you found out whether this issue only occurs in playback direction or also in recording?

I haven't tried this, but a solution similar to my patch might be to apply the already existent "QUIRK_FLAG_PLAYBACK_FIRST" quirk for the MOTU pro audio PID/VID in the existing linux audio class driver.

So you mean doing this would be the same as using your beta Firmware?

[buonamorte.records]

Hi guys and hi @AudioNarwhal ,

I'm sorry, i've been really busy and i've not make test to give you more info about my problem with ultralite avb es. I bought also the 8m two months ago but i did'nt had time to turn it on...
A little question: with the beta firmware, which use cc mode only, will i be able to use the avb network between 8m, stage b16 and 828es, using 828es as the main interface connected to my pc?
If this will work, i'll be ok for the full recordings and i'll miss only the "mixing when i'm not at home" part (the reason why i bought the ultralite), which is an important part of my project studio (because i'm often not at home) but i can solve it buying another audio interface to work on the road.
Otherwise, i think i'll sell all the interfaces to buy the new neumann/merging interface (they have created an alsa driver for linux users! https://www.merging.com/products/alsa_r ... s67_driver ). I prefer to stay in the motu avb world if it will work!

Dylan, please keep helping us!

[bluebell]

I prefer to stay in the motu avb world if it will work!

A well supported USB-interface that could speak ADAT and AVB would be a dream. Since I have a non-ES UltraLite AVB I have that dream (with drumfix' ua101 driver) but I am afraid that a recent UltraLite AVB wouldn't work that perfectly.

[buonamorte.records]

Hi Everybody!
I'm testing the 1.4.5 firmware on my 828es (on pop os) as main of an avb network composed by an 8m and a stage b16. It is working really well, at 88.2 1024 2 periods; DSP @ 14% (i7 12700H) with the v9 of mixbus 32c. I can also record 24 channels from avb (b16 + 8m). With this setup, in cc 24x24, i can use 3 interfaces (828es, 8m, stage b16). If the ultralite will work one day, i'll be able to use it as lighter setup (leaving home the 828es and using b16 and 8m as stagebox) and to mix "on the road". If it will not work, i don't have free channels (24 ins in cc mode) to use it in the avb network, so i'll probably sell it to buy a little and stable interface (maybe the neve 88m or the new neumann, or a motu M if it works on linux...). I'll wait the 6.4 kernel and the latest news from @AudioNarwhal to decide.
Bye and have a good open music time!

[buonamorte.records]

So, not really happy about it but i choose to sell all my motu equipment (not the 8m, i'll use it as 8pre via adat) to buy the neumann mt48, that has an alsa driver made by merging technologies. A great thanks to @AudioNarwhal and everyone in this topic that have tried to solve the problems with motu avb. Dylan, are you at motu working on a compatibility layer between avb and aes67? Do you think the presonus d16 can connect motu avb to dante/aes67 devices?

[bluebell]

It seems there is an Open Source alternative to Merging's proprietary butler daemon binary:

https://github.com/bondagit/aes67-linux-daemon

[Lifted]

Gentlemen,

Has anyone tried writing drivers for MOTU Ultralite-MK5 on Windows 11, but without that bouncing ball, when screen goes to "sleep"

I want black screen, but instead I got eternal bouncing ball.
Can someone help me with that?

That refresh state on display makes my eyes dizzy. It doesn't look good to me.