SPDIF Ardour/Mixbus Motif XS8

#1

I successfully used my Motif XS8 SPDIF output to an 1818vsl into mixbus using AVLinux. AVLinux seems dead, so I moved to Debian.,

Absolutely all my sound works flawlessly on Debian and Ardour/Mixbus works great. AFAIK Mixbus is just a shell over Ardour with a diffent DSP engine so I guess it is not far off topic to ask here. (I did ask on both Mixbus and Alsa forums). On Mixbus it was unresolved, but on Alsa I did not even get a response to my question. Alsa development seems to be dying. If it works on Ardour it will work on Mixbus.

QUESTION: In Alsa, I can select SPDIF clock. On Alsa the SPDIF outputs are on channels 9 & 10. What else must I do to get spdif to work? The Ala System outputs 9&10 is now connected to Mixbus channels 9&10 as before when it worked with AVLinux. Is there any clock connection that needs to be forwarded from Alsa to Ardour/Mixbus or should the sound be present on the Alsa System Outputs 9&10 similar to other normal outputs ?

Any help will be appreciated as I am getting short on inputs on the 1818vsl and I need to save two inputs by using spdif.

#2

Not sure why you think AVLinux is dead? A quick glance at the forum shows the latest release was just over a month ago?

The latter, but you won’t hear anything unless the clock is sync’d with whatever you are plugging into it.

   Seablade
#3

It was even announced here:

Anyway debian is a fine OS (AVLinux is also debian based).

If you have the time, knowledge, know-how and patience to tweak your system for pro-audio, using debian as basis is a very good choice.

#4

My debian system, is working amazingly well and does what avlinux could never do. Avlinux is full of trouble and annoyances that could never work. Avlinux is only superior for mixbus in a single sense. Spdif works out of the box, otherwise there are litterally tons of sound issues in avlinux that i couldnt resolve but which was easily done with vanilla debian. I also got similar or better latency with debian. Avlinux was really a step backwards except for spdif.
My question is not about avlinux, which incidentally it is impossible to subscribe to the ug, but about getting spdif working on debian.

#5

Avlinux is a dead end for me after careful evaluation, cannot subscribe to ug and moderators do not respond = dead or as it seems zombie. Lets leave it at that, i have a very complex system that runs great on debian.

Regarding spdif, alsamixer shows that the spdif clock is selected, but i noticed that it says clock sour, which looks like clock source truncated. Clock is also set to spdif on the hardware interface 1818vsl. I cannot see what else i did wrong. If the clock sour message actually means sour and a problem, how do i fix that?

Here is an image of the alsa message.
“http://grossmann-venter.com/issues/ugroups/ClockSour.png”

#6

@GMaq any idea why that would be?

#7

Exactly right seablade.
I know I have a clock issue, but not sure if it is what alsa reports or how to fix it. See my post just before this one with an image of alsa clock sour message.

#8

Hi,

Well not a happy customer apparently…

I can’t speak to the specific sound issues without more detail, for many users AV Linux is much simpler than vanilla Debian and basically 1 click in Qjackctl brings ALSA, JACK and PulseAudio to life and routes everything through the selected JACK Audio device:

Page 78: http://bandshed.net/pdf/AVL2019UserManual.pdf

I can and will admit that there occasionally periods of time when posts go unanswered on the AV Linux forum, maintaining a project as complex as AV Linux is quite unmanageable at times for a single person who is otherwise employed full time, this is the beauty and curse of being the sole proprietor of an Open Source project. There are times when I can be very available and times when I can’t even check the forum more than once a week. I used to apologize for that, I don’t any more…

It is clearly stated on the website and in the User Manual (a manual that is a full-time job in itself) that I show up when I’m able and otherwise there are no guarantees… With the exception of a few longtime patrons AV Linux barely pays for it’s web hosting, I unfortunately can’t provide a 24/7 professional helpdesk experience on top of the rest…

Sorry to sound pissy, but I’m just being straight up…

#9

Its fine, AVLinux was just way too buggy.
For the record I use MXLinux which is Debian with great enhancements.
I will refer to it as Debian below.

  1. Bluetooth was a nightmare to get working properly on AVLinux, I now have it running perfectly on Debian with about 7 bluetooth devices interfacing through pulseaudio perfectly with files sent received properly.
  2. All my virtualmachines now run flawlessly on Debian doing all my legacy sound software. Midi is working great from Virtualbox and Qemu and I can edit devices, never could get virtualmachines to work on AVLinux.
  3. On Debian, I could run full symphonies with Miroslav and Notion under emulation in Virtualbox with 6 cores, Not one x-run - amazing. On Avlinux there were issues with Qemu and virtualbox with the AVLinux RT kernel and I got thousands of x-runs at the same latency as I use on Debian
  4. Could not configure more than 2 cores on a 24 core machine for the virtual machines due archaic kernel in AV Linux. On Debian with MX-core it was a breeze. 6 Cores per virtual machine
  5. Midi works great under debian, I had bad luck with AV Linux, where midi will just drop out or stop working for no reason
  6. Then the Usergroup registration requirement to solve a highschool physics problem mixing colors. Go figure, I entered the correct answers and it never worked. That said I did a PhD thesis in Physics, so I actually know how colors work. The registration interface and questionaire is clearly from an alternate universe -duh!.
    No response form moderators regarding registration issues.
  7. Jack was a breeze to configure with Debian, and so many more etc etc.
  8. To AVLinux credit, it did work very well with Mixbus which was fully functional, however I get better latency now with debian, 2.9ms with one x-run every 8 or so minutes. With AVLinux I had thousands of X-runs @2.9ms.

To me the ONLY purpose of AVLinux is to run mixbus with nothing else.

Lets leave the AVLinux conundrum and just focus on how to get spdif to work on Debian. Thanks

#10

Don’t worry, I’ll leave but not without some clarification…

I understand your issue, there was an issue found with the forum software not sending me notifications of failed registrations which is now monitored better, I regret that you were one of the (luckily) few people affected by difficulty registering…

As far as bluetooth, there is nothing customized in AV Linux regarding Bluetooth it is shipped with the Debian defaults so I can’t say with certainty from here where the problem was with Bluetooth, indeed the AVL Kernel is a custom RT kernel intended to give the best performance potential, there is nothing archaic about it… Debian Stretch ships with a 4.9 Kernel and AV Linux has had it’s own custom RT series from 4.9 to 4.16 so all equivalent or newer than the stock Debian Stretch Kernel. Yes indeed RT Kernels have some limitations regarding Proprietary Video drivers and Virtual Machine environments, AV Linux also provides non-RT lowlatency Kernels, optional tuned Liquorix Kernels and of course you are always free to install any of the stock Debian Kernels directly from Debian. All of this is also covered in the User Manual.

I’m posting this to separate facts from impressions for future readers of this thread…

All said MX Linux is an excellent distribution so best of luck with it, it’s somewhat ironic that we have a few MX Users tweaking MX for better Audio performance with those uhm…“archaic” RT Kernels from the AVL Kernel Repository…:wink:

#11

That is confusing, MXLinux is Debian as much as AVLinux is Debian, i.e. they are both closer than Ubuntu, but they are not straight Debian from the Debian repositories. They have customizations made, so just refer to the distributions by their names, MXLinux, or AVLinux, or actual Debian. No need to make the situation even more confusing.

But, to your current question, there is this note in the user manual:
“Power User Tip: Remember to set “S/PDIF” as the Clock Source and set the sample rate to correspond to the external device in the AudioBox VSL Setup Tab (Windows) or in Audio MIDI Setup (OS X) when using the S/PDIF input for external sync”

That implies to me that you have to both select S/PDIF as the clock source and set the sample rate correctly, that the interface will not force the sample rate to match the incoming clock rate.

In fact, later in the manual I found that it states that explicitly:
“Power User Tip: When slaved to an external clock, the AudioBox 1818VSL will not automatically change its sample rate to match the external clock. As a result, it may fail to sync to the clock source. If your AudioBox is not syncing to an external source, make sure that both your master device and the AudioBox 1818VSL are set to the same sample rate.”

The Motif XS8 manual says that the output is 44100, any chance you set the session sample rate to 48000?

Do you get indication from the sync light that the clock successfully switches from internal to S/PDIF sync?
"If you want the AudioBox to receive sync from an external device, choose the digital input to which the external device is connected (S/PDIF or ADAT). The AudioBox 1818VSL’s sync light will flash from blue to red. When the AudioBox is in sync, the light will be blue. "

I do not know if ALSAMixer exposes this, but the manual says there is an option to re-route main audio to inputs 9-10:
Main to S/PDIF In: Bypasses the SPDIF Input and Routes Main Mix to DAW Inputs 9 and 10.
Seems you would definitely want that not selected.

And please excuse the overly basic question, but is your interface mounted in a rack or somewhere that is difficult to see the back? Did you make sure you checked in good lighting to verify the connection from the keyboard was actually to the input connector, and not accidentally moved over to the output connector?

#12

Chris, thank you for the insightful post.
As to your observations and comments,

  1. SPDIF works there are no cabling issues and yes all is rack mounted.
    That is not the issue, I can connect the 1818 to windows and then the Motif works through SPDIF, so the connections are proper.
  2. Yes I do set the clock to spdif in the 1818.
  3. I did try external clock source also, did not work.
  4. If I boot into the defunct AVLinux distro, then spdif works, boot back into Debian it doesnt, so it MUST be something ALSA or whatever is handling the clock on the Debian system is doing that causes the trouble.
    The problem is that there is seemingly no way to figure the clock rate in alsa.
  5. Since everything else is working in Mixbus I cannot figure the clock issue. Is the “Clock SOUR” message authentic in the alsamixer or is that just a truncated “CLOCK SOURCE”. Alsamixer is an archaic old terminal graphic program and such truncations can happen with terminal graphics.
  6. The 1818VSL light goes blue as expected for normal operation when I connect it to the Debian system.

Is there a way in Alsa to set the SPDIF clock rate to a fixed value?
I have the feeling ALSA goes to some maximum rate such as 96000 which the Audiobox is not set to.

#13

You can’t stop bashing avlinux huh?
The only distro that actually solves your SPDIF trouble.

#14

Have you compared the kernel/ALSA versions between AVLinux and MXLinux? Unless there is an vendor specific utility for your interface, I believe alsamixer is the only way to set the clock source used by your interface.

The clock rate is set by the application which opens the ALSA interface. Since you are posting this on the Ardour forum, I assume that Ardour (or possibly Mixbus) is the application you are running which would be opening the interface, so in that case the clock rate requested would be set by the session sample rate. Ardour defaults to 48k if you do not change it; I am not sure of the Mixbus behavior.
I do not believe you responded to the previous question regarding verifying your session sample rate.

Does it have the behavior described in the manual when changing clock sources from S/PDIF to internal and back to S/PDIF, blinks red for a short time then changes back to blue?
If so that would seem to indicate that the clock circuitry is locking to the input clock correctly.
I think now that clock source is probably not the problem.

I notice in your screenshot of alsamixer that there are three meters which show L and R and the level at 100. Is that input level control? If so, the next several channels are shown as 00, probably indicating input level set to 0. Did you try setting all of those channels to level 100 also?

#15

Yes, but that is unfortunately all it does right. It breaks everything else.

Quote " Rghvdberg
You can’t stop bashing avlinux huh?
The only distro that actually solves your SPDIF trouble. "

#16

Thanks for the response Chris, I will doublecheck all the points you mentioned and will report back. Mixbus runs at 44100, same as 1818VSL is set, but it might be that Alsa (which I understand handles 1818vsl) might set the spdif clock to some different default value.

Is there any way you know of how to set the clock speed from linux on the 1818vsl? I have to do it in windows and then plug back into Linux. Then the lights go from red to blue again, but I have no clue if any changes have been made by Alsa.

#17

ALSA is just the driver for USB connected interfaces, when an application opens the ALSA device node, the application sends a request for desired sample rate, ALSA sends the request to the device, the device responds with the sample rate it can use (which should be the same as requested, but if the application for some reason requested an unsupported rate the response could be different).
If Mixbus is really running at 44100 then the interface should be running at 44100 at that time.

You send an open request to the ALSA device. That is what Mixbus (or Ardour or jackd or Audacity, etc.) does when you set the sample rate and start the audiobackend running.

That is probably from the USB interface resynchronizing. The light is actually labeled “USB Sync” so it is a little confusing that according to the user manual it is also used for S/PDIF sync (and presumably ADAT sync, although I did not look through that section of the manual).

#18

Thank you Chris. The information is helpful.

Remember that all the io in mixbus and the io in 1818vsl connects perfectly except for spdif. What I dont understand is that I can record an playback all I want with Mixbus to 1818VSL and vice versa at say 44100 except spdif is dead. So, if mixbus connects successfully with 1818vsl at 44100, then is the spdif clock rate separately configurable ?
If the answer is no, then it should just work as everything else works. Clearly it seems that SPDIF uses a separate clock or something completely different is going on. SPDIF works perfectly booting into windows as already mentioned, so there are no connection problems. The problem follows OS.

#19

The S/PDIF clock rate is set by the transmitter. In this case your synthesizer only supports 44100. The manual for 1818VSL clearly indicates that it will not automatically set the interface sample rate to the S/PDIF clock rate, you need to set the interface rate to match the S/PDIF rate. You indicated you did that by setting the Mixbus session rate to 44100, so I do not think there is anything additional to do regarding clock rate.

Ideally yes, obviously some setting is defaulting to the wrong value with your chosen MXLinux distribution.
The alsamixer screen shot would be easier to interpret with just the capture channels shown, there are too many channels on that device to show all settings on a single screen.
It may also be useful to show the output of amixer, that prints a text list of all the current settings.

#20

$ amixer
Simple mixer control ‘Master’,0
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ? - ? - ? - ? - ? - ?
Limits: Playback 0 - 65536
Mono:
Front Left: Playback 39976 [61%] [on]
Front Right: Playback 39976 [61%] [on]
Rear Left: Playback 39976 [61%] [on]
Rear Right: Playback 39976 [61%] [on]
Front Center: Playback 39976 [61%] [on]
Woofer: Playback 39976 [61%] [on]
Side Left: Playback 39976 [61%] [on]
Side Right: Playback 39976 [61%] [on]
Rear Center: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
?: Playback 39976 [61%] [on]
Simple mixer control ‘Capture’,0
Capabilities: cvolume cswitch cswitch-joined
Capture channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right - Rear Center - ? - ? - ? - ? - ? - ? - ? - ? - ?
Limits: Capture 0 - 65536
Front Left: Capture 65536 [100%] [on]
Front Right: Capture 65536 [100%] [on]
Rear Left: Capture 65536 [100%] [on]
Rear Right: Capture 65536 [100%] [on]
Front Center: Capture 65536 [100%] [on]
Woofer: Capture 65536 [100%] [on]
Side Left: Capture 65536 [100%] [on]
Side Right: Capture 65536 [100%] [on]
Rear Center: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]
?: Capture 65536 [100%] [on]

Here is an image of Alsa Capture only.
“http://grossmann-venter.com/issues/ugroups/alsa-capture.png"

Although capture is not going to show spdif.