7 Mar
2020
7 Mar
'20
2:44 p.m.
Getting my Ultralite AVB working on Linux Mint 19.3 has been quite
a struggle and I've learnt a few things along the way, which may
save others some wondering.
Ignore any thoughts of USB power management causing any issue.
The device never uses any USB power, as confirmed with an inline
USB V/A meter.
Firmware more recent than 1.3.2+520 suffers from the 'bitcrusher'
effect, where audio can be heard for about 30 seconds, until it
fades to junk while appearing on higher number channels, until
it does the same again. That firmware is pre Touch Console™.
Firmware and release notes in the Ultralite AVB section here:
https://motu.com/techsupport/technotes/firmwarechangelog
A great deal of good information over at the Linux Musicians forum:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046
(Thanks to Eric Schoster for pointing me to that one.)
One gem is that it can be set to class compliant mode with:
curl --data 'json={"value":"UAC"}' IP
address/datastore/host/mode
curl --data 'json={"value":"24"}' IP
address/datastore/host/maxUSBToHost
(Replace "IP address" with its address on your network)
Change to its proprietary mode with:
curl --data 'json={"value":"USB2"}' IP
address/datastore/host/mode
curl --data 'json={"value":"64"}' IP
address/datastore/host/maxUSBToHost
On my current hardware (i7-8700K) the Ultralite takes 27 seconds
from first light in the display to showing detail in the display
and there's a further 20 second delay before any activity shows
up in a terminal window running 'tail -f /var/log/syslog'.
There are very many messages like:
'clock source 1 is not valid, cannot use'
Yesterday I was seeing 240 of those in blocks of 40, with each
block followed by:
'[pulseaudio] module-alsa-card.c: Failed to find a working profile.'
and etc.
Today, after trying the latest firmware, seeing the bitcrusher
effect and reverting to 1.3.2+520 again, I only see two complete
blocks and the reporting stops about half way through the third
block. Qjackctl will then start the server, on either hw:AVB or
hw:AVB,0. It always seems to need changing to the one of those
it isn't set to. :)
I can only think that my dual booting and using it on Windows 10
caused the trouble I was seeing when using it on Linux afterwards.
I still can't use anything which isn't 'jack aware', but I can
live with that, for now. VLC offers 13 'Ultralite AVB, USB Audio'
devices to chose from, including "Direct sample snooping device".
Linux, generally, doesn't seem to maintain an optical output if
a player app stops playing...
--
John.
7 Mar
7 Mar
4:23 p.m.
It would be great to use some kind of wiki to collect all this
information on one place. I have a MotU 624 AVB and most of what is
wrote about the Ultralite applies also to this model.
On 07.03.20 13:28, John Murphy wrote:
Getting my Ultralite AVB working on Linux Mint 19.3
has been quite
a struggle and I've learnt a few things along the way, which may
save others some wondering.
Ignore any thoughts of USB power management causing any issue.
The device never uses any USB power, as confirmed with an inline
USB V/A meter.
Firmware more recent than 1.3.2+520 suffers from the 'bitcrusher'
effect, where audio can be heard for about 30 seconds, until it
fades to junk while appearing on higher number channels, until
it does the same again. That firmware is pre Touch Console™.
Firmware and release notes in the Ultralite AVB section here:
https://motu.com/techsupport/technotes/firmwarechangelog
A great deal of good information over at the Linux Musicians forum:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046
(Thanks to Eric Schoster for pointing me to that one.)
One gem is that it can be set to class compliant mode with:
curl --data 'json={"value":"UAC"}' IP
address/datastore/host/mode
curl --data 'json={"value":"24"}' IP
address/datastore/host/maxUSBToHost
(Replace "IP address" with its address on your network)
Change to its proprietary mode with:
curl --data 'json={"value":"USB2"}' IP
address/datastore/host/mode
curl --data 'json={"value":"64"}' IP
address/datastore/host/maxUSBToHost
On my current hardware (i7-8700K) the Ultralite takes 27 seconds
from first light in the display to showing detail in the display
and there's a further 20 second delay before any activity shows
up in a terminal window running 'tail -f /var/log/syslog'.
There are very many messages like:
'clock source 1 is not valid, cannot use'
Yesterday I was seeing 240 of those in blocks of 40, with each
block followed by:
'[pulseaudio] module-alsa-card.c: Failed to find a working profile.'
and etc.
Today, after trying the latest firmware, seeing the bitcrusher
effect and reverting to 1.3.2+520 again, I only see two complete
blocks and the reporting stops about half way through the third
block. Qjackctl will then start the server, on either hw:AVB or
hw:AVB,0. It always seems to need changing to the one of those
it isn't set to. :)
I can only think that my dual booting and using it on Windows 10
caused the trouble I was seeing when using it on Linux afterwards.
I still can't use anything which isn't 'jack aware', but I can
live with that, for now. VLC offers 13 'Ultralite AVB, USB Audio'
devices to chose from, including "Direct sample snooping device".
Linux, generally, doesn't seem to maintain an optical output if
a player app stops playing...
8 Mar
8 Mar
12:19 a.m.
On Sat, 7 Mar 2020 12:28:26 +0000 John Murphy wrote:
[...]
I can only think that my dual booting and using it on
Windows 10
caused the trouble I was seeing when using it on Linux afterwards.
I seem to have narrowed it down to dependence on the setting of
'Clock Mode'. I do a lot of recordings from a 48kHz optical source
plugged into the S/Pdiff optical input. Seems to be that clock the
kernel can't use. Probably because it has somehow changed the device
to 44.1kHz (via 192kHz) and then demands a 44.1kHz clock.
If I set Clock Mode to internal, before booting Linux, or after
a failed start up, I see fewer 'clock source 1 is not valid'
messages in /var/log/syslog and jackd will work as usual. I've
even had sound in my (FireFox) browser, so Alsa must be working.
If I don't set Clock Mode to internal, /var/log/syslog gets the
full compliment of 6 blocks of 40 'not valid' messages, ending
with: [pulseaudio] module-udev-detect.c: Tried to configure
/devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/sound/card2
(alsa_card.usb-MOTU_UltraLite_AVB_0001f2fffe005ded-00) more often
than 5 times in 10s.
It had to be something like that.. Was doing my ed in a bit.
Big clue to the problem right there in the device's LCD display.
If the sample rate indicator keeps flashing - it isn't going to work.
--
John.
9 Mar
9 Mar
1:25 a.m.
On Sat, March 7, 2020 4:52 pm, John Murphy wrote:
I seem to have narrowed it down to dependence on the
setting of
'Clock Mode'. I do a lot of recordings from a 48kHz optical source
plugged into the S/Pdiff optical input. Seems to be that clock the
kernel can't use.
Do you have a valid S/PDIF bitstream running when you start your device?
If the default clock is S/PDIF then there must be a valid S/PDIF stream
to recover the clock.
Probably because it has somehow changed the device
to 44.1kHz (via 192kHz) and then demands a 44.1kHz clock.
So you think the ALSA driver may be configuring the device for 44.1k based
sample rates, but you have a 48k S/PDIF stream running?
If that is the case you should be able to figure out which software is
opening the audio device and change the default sample rate to 48k.
Depending on desktop environment it is likely PulseAudio.
--
Chris Caudle
10 Mar
10 Mar
2:29 a.m.
On Sun, 8 Mar 2020 18:25:08 -0500 "Chris Caudle" wrote:
It is indeed. Thank you. I'm amazed that in all these years of
using Linux, I hadn't realised there's a default setting for the
sound server sample rate. I've added the following lines near
the top of /etc/pulse/daemon.conf (I'm the only user):
### Changed default sample rate to 48kHz and alt sample rate to 44.1kHz
default-sample-rate = 48000
alternate-sample-rate = 44100
I'm now convinced the problem I'm seeing is due to using it on Windows,
which puts it in proprietary mode and causes:
[pulseaudio] alsa-util.c: Device hw:2 has 64 channels, but PulseAudio
supports only 32 channels. Unable to use the device.
After writing these settings to it:
curl --data 'json={"value":"UAC"}' IP
address/datastore/host/mode
curl --data 'json={"value":"24"}' IP
address/datastore/host/maxUSBToHost
Then switching it off and on again. PulseAudio syslog messages then stop
at a "clock source 1 is not valid, cannot use" and a few lines up from
there it says:
pulseaudio[1319]: [pulseaudio] module-alsa-card.c: Failed to find a
working profile.
pulseaudio[1319]: [pulseaudio] module.c: Failed to load module
"module-alsa-card" (argument: "device_id="2"
name="usbMOTU[...]"
card_name="alsa_card.usb-MOTU[...]" namereg_fail=false tsched=yes
fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes
card_properties="module-udev-detect.discovered=1""):
initialization failed.
But it works and all seems well now.
Without doing that (curl bit) it seems to me that anyone trying
to use one which has been used on Windows will get a variation of
'the bitcrusher effect' which today, for me, was to see and hear
thin audio on 'From computer' 1 & 2 and 9 & 10, whereas previously
I was seeing channel hopping (and hearing the crushed audio on one
pair at a time). I've seen some weird symptoms in my time, but...
Something I've found useful is to have PulseAudio Volume Control
running on the desktop on its Output Devices tab. The UltraLite
AVB Multichannel device appears there as soon as it's ready to use.
Thanks for the help.
--
John.
On Sat, March 7, 2020 4:52 pm, John Murphy wrote:
Yes. It's almost always running and should be 'valid'.
I seem to have narrowed it down to dependence on
the setting of
'Clock Mode'. I do a lot of recordings from a 48kHz optical source
plugged into the S/Pdiff optical input. Seems to be that clock the
kernel can't use.
Do you have a valid S/PDIF bitstream running when you start your device?
If the default clock is S/PDIF then there must be a valid S/PDIF stream
to recover the clock. Probably
because it has somehow changed the device
to 44.1kHz (via 192kHz) and then demands a 44.1kHz clock.
So you think the ALSA driver may be configuring the device for 44.1k based
sample rates, but you have a 48k S/PDIF stream running?
If that is the case you should be able to figure out which software is
opening the audio device and change the default sample rate to 48k.
Depending on desktop environment it is likely PulseAudio. 
9 Mar
9 Mar
9:56 p.m.
On 3/7/20 1:52 PM, John Murphy wrote:
On Sat, 7 Mar 2020 12:28:26 +0000 John Murphy wrote:
[...]
When the sampling rate changes in the Motu audio interface, it takes
some time (4-10 seconds) for the new sampling rate to "lock" (indicator
flashing).
During that time jack will not successfully start. It is a pain.
There is an amixer control that can be used to query the interface and
see if the sampling rate is locked or not.
This is further complicated by the fact that some software (ie:
pulseaudio) will change the sampling rate without you doing it manually.
For example, if you manage to start jackd at 48Khz and then stop it,
pulseaudio (if installed and enabled) will take control of the audio
interface and change the sampling rate to its default rate (44.1k).
-- Fernando
I can only think that my dual booting and using
it on Windows 10
caused the trouble I was seeing when using it on Linux afterwards.
I seem to have narrowed it down to dependence on the setting of
'Clock Mode'. I do a lot of recordings from a 48kHz optical source
plugged into the S/Pdiff optical input. Seems to be that clock the
kernel can't use. Probably because it has somehow changed the device
to 44.1kHz (via 192kHz) and then demands a 44.1kHz clock.
If I set Clock Mode to internal, before booting Linux, or after
a failed start up, I see fewer 'clock source 1 is not valid'
messages in /var/log/syslog and jackd will work as usual. I've
even had sound in my (FireFox) browser, so Alsa must be working.
If I don't set Clock Mode to internal, /var/log/syslog gets the
full compliment of 6 blocks of 40 'not valid' messages, ending
with: [pulseaudio] module-udev-detect.c: Tried to configure
/devices/pci0000:00/0000:00:14.0/usb1/1-14/1-14:1.0/sound/card2
(alsa_card.usb-MOTU_UltraLite_AVB_0001f2fffe005ded-00) more often
than 5 times in 10s.
It had to be something like that.. Was doing my ed in a bit.
Big clue to the problem right there in the device's LCD display.
If the sample rate indicator keeps flashing - it isn't going to work.
10:16 p.m.
On Mon, March 9, 2020 2:56 pm, Fernando Lopez-Lezcano wrote:
This is further complicated by the fact that some
software (ie:
pulseaudio) will change the sampling rate without you doing it manually.
For example, if you manage to start jackd at 48Khz and then stop it,
pulseaudio (if installed and enabled) will take control of the audio
interface and change the sampling rate to its default rate (44.1k).
You can change the default sampling rate which PulseAudio uses with a
configuration file option.
--
Chris Caudle
10:29 p.m.
On 10/3/20 7:16 am, Chris Caudle wrote:
On Mon, March 9, 2020 2:56 pm, Fernando Lopez-Lezcano
wrote:
Haha, snap! I was just writing the same thing. I'll post it anyway:
If PulseAudio is the culprit changing the sample rate, Maybe these
parameters can be uncommented and swapped in /etc/pulse/daemon.conf (or
preferably a user daemon.conf created in ~./config/pulse/)
; default-sample-rate = 44100
; alternate-sample-rate = 48000
Those are the default values. Change to:
default-sample-rate = 48000
alternate-sample-rate = 44100
Also there is:
; avoid-resampling = false
but I have found changing that to true can have unexpected consequences.
This is further complicated by the fact that some
software (ie:
pulseaudio) will change the sampling rate without you doing it manually.
For example, if you manage to start jackd at 48Khz and then stop it,
pulseaudio (if installed and enabled) will take control of the audio
interface and change the sampling rate to its default rate (44.1k).
You can change
the default sampling rate which PulseAudio uses with a
configuration file option.
10 Mar
10 Mar
2:28 a.m.
On 3/9/20 1:16 PM, Chris Caudle wrote:
On Mon, March 9, 2020 2:56 pm, Fernando Lopez-Lezcano
wrote:
Yes, of course, except that is not a generic solution. The behavior will
change depending on which sampling rate was last used by pulseaudio
(depends on the last thing played back) - and which one you need to use
in jackd. If those can be controlled then yes, it is a workaround.
A more generic solution would involve modifying jack so that it is aware
that the sampling rate is not stable and it has to wait. But that is a
special case - I doubt that would be realistic.
I guess the real solution would involve changes in the ALSA layer so
that this behavior is hidden somehow...
(other ALSA clients, for example audacity, do start "playing" regardless
of the state of the clock - it is just that there is no actual sound
until the clock locks)
-- Fernando
This is further complicated by the fact that some
software (ie:
pulseaudio) will change the sampling rate without you doing it manually.
For example, if you manage to start jackd at 48Khz and then stop it,
pulseaudio (if installed and enabled) will take control of the audio
interface and change the sampling rate to its default rate (44.1k).
You can change the default sampling rate which PulseAudio uses with a
configuration file option. 
11 Mar
11 Mar
12:01 p.m.
Hi.
I have a MOTU 8A in UAC mode running under Linux/JACK.
Firmware is from 2017, I don't remember the exact version off-hand.
Time from switching it on to Linux seeing the USB device is
roughly as you describe.
I haven't heard the bit-crush bug yet (lucky me).
The card seems to work pretty fine, except for one problem:
Sometimes, when I freshly power on the card and start up JACK (via a
udev rule[1]), JACK doesn't complain, but there is no audible output.
Restarting JACK (sometimes two or thre times) will fix the issue, and
once JACK has managed to init with audio being audible, the card
will work for hours without any problem until I power down.
What I discovered recently is, that the default analog output level
is pretty high. I use the following script to trim it down to something
that (hopefully) resembles line level:
#!/bin/sh -e
motu=http://8A.local/datastore
analog_out=ext/obank/1
# trimRange -24:0, we're guessing that -16 is +4dB
for ch in $(seq 0 7)
do curl --data 'json={"value":-16}' $motu/$analog_out/ch/$ch/trim
done
[1] /etc/udev/rules.d/10-MOTU-D8A.rules
ACTION=="add", SUBSYSTEMS=="sound", ATTRS{id}=="D8A",
TAG+="systemd", ENV{SYSTEMD_USER_WANTS}="motu(a)D8A.service"
~/.config/systemd/user/motu@.service:
[Unit]
Description=%I JACK Server
[Service]
ExecStart=/usr/bin/jackd -d alsa -d hw:%I -r 48000 -p 128 -n 3
John Murphy <rosegardener(a)freeode.co.uk> writes:
Getting my Ultralite AVB working on Linux Mint 19.3
has been quite
a struggle and I've learnt a few things along the way, which may
save others some wondering.
Ignore any thoughts of USB power management causing any issue.
The device never uses any USB power, as confirmed with an inline
USB V/A meter.
Firmware more recent than 1.3.2+520 suffers from the 'bitcrusher'
effect, where audio can be heard for about 30 seconds, until it
fades to junk while appearing on higher number channels, until
it does the same again. That firmware is pre Touch Console™.
Firmware and release notes in the Ultralite AVB section here:
https://motu.com/techsupport/technotes/firmwarechangelog
A great deal of good information over at the Linux Musicians forum:
https://linuxmusicians.com/viewtopic.php?f=6&t=18046
(Thanks to Eric Schoster for pointing me to that one.)
One gem is that it can be set to class compliant mode with:
curl --data 'json={"value":"UAC"}' IP
address/datastore/host/mode
curl --data 'json={"value":"24"}' IP
address/datastore/host/maxUSBToHost
(Replace "IP address" with its address on your network)
Change to its proprietary mode with:
curl --data 'json={"value":"USB2"}' IP
address/datastore/host/mode
curl --data 'json={"value":"64"}' IP
address/datastore/host/maxUSBToHost
On my current hardware (i7-8700K) the Ultralite takes 27 seconds
from first light in the display to showing detail in the display
and there's a further 20 second delay before any activity shows
up in a terminal window running 'tail -f /var/log/syslog'.
There are very many messages like:
'clock source 1 is not valid, cannot use'
Yesterday I was seeing 240 of those in blocks of 40, with each
block followed by:
'[pulseaudio] module-alsa-card.c: Failed to find a working profile.'
and etc.
Today, after trying the latest firmware, seeing the bitcrusher
effect and reverting to 1.3.2+520 again, I only see two complete
blocks and the reporting stops about half way through the third
block. Qjackctl will then start the server, on either hw:AVB or
hw:AVB,0. It always seems to need changing to the one of those
it isn't set to. :)
I can only think that my dual booting and using it on Windows 10
caused the trouble I was seeing when using it on Linux afterwards.
I still can't use anything which isn't 'jack aware', but I can
live with that, for now. VLC offers 13 'Ultralite AVB, USB Audio'
devices to chose from, including "Direct sample snooping device".
Linux, generally, doesn't seem to maintain an optical output if
a player app stops playing...
--
CYa,
⡍⠁⠗⠊⠕
1778
days inactive
1782
days old
linux-audio-user@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Chris Caudle -
Fernando Lopez-Lezcano -
John Murphy -
Mario Lang -
Max -
Roger