Help with SPDIF

retnev · August 25, 2020, 11:49pm

I need to get SPDIF working with ARDOUR. It is not really an Ardour problem, more of a system problem. I had spdif issues with several audio interfaces, so it is not the interfaces. SPDIF would work once but then never again.

It is clear to me it is ALSA at fault. The ALSA usergroup is basically dead and there are no responses. So i have to ask here.

Maybe someone here is an spdif boffin. I just cannot continue with audio cables to my keyboards anymore. Too many cables and screening issues. My Yamaha keyboards leaks some MIDI clock signal noise into the audio cables and I have to wiggle them a bit to get rid of the clicks. Once I use SPDIF, all this crap is gone + all the cables are unnecessary.

SPDIF, when it works is magic.

I run keyboards with spdif to a Behringer 1820 & Presonus 1818VSL into Linux with Alsa/Jack/Ardour & Mixbus.

Never mind how I set the clocks I get no spdif. signal.
It worked once but then gave up again.
No clue anymore.
Tested interface on windows and it works perfectly.
Everything else works spectacular on Linux except spdif.

My system
:~$ cat /etc/release
NAME=“MX”
VERSION=“18 (Continuum)”
ID=“mx”
VERSION_ID=“18”
PRETTY_NAME=“MX 18 (Continuum)”
ANSI_COLOR=“0;34”
HOME_URL=“https://mxlinux.org”
BUG_REPORT_URL=“https://mxlinux.org”
PRETTY_NAME=“MX 18.3 Continuum”
DISTRIB_ID=MX
DISTRIB_RELEASE=18.3
DISTRIB_CODENAME=Continuum
DISTRIB_DESCRIPTION=“MX 18.3 Continuum”
PRETTY_NAME=“Debian GNU/Linux 9 (stretch)”
NAME=“Debian GNU/Linux”
VERSION_ID=“9”
VERSION=“9 (stretch)”
VERSION_CODENAME=stretch
ID=debian
HOME_URL=“https://www.debian.org/”
SUPPORT_URL=“https://www.debian.org/support”
BUG_REPORT_URL=“https://bugs.debian.org/”

To: Moderators.
If you feel this is rather a question for Linux Audio group and you are a moderator let me know as it is highly unlikely to be Ardour, but it might be…

paul · August 26, 2020, 12:08am

Open a terminal window and run this command (it is all one line)

cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh

Paste the output here.

retnev · August 26, 2020, 12:14am

Thanks Paul.
Here it is.

~$ cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh
--2020-08-25 20:11:05--  https://community.ardour.org/files/adevices.sh
Resolving community.ardour.org (community.ardour.org)... 54.235.123.47
Connecting to community.ardour.org (community.ardour.org)|54.235.123.47|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2249 (2.2K) [application/octet-stream]
Saving to: ‘adevices.sh.1’

adevices.sh.1       100%[===================>]   2.20K  --.-KB/s    in 0s      

2020-08-25 20:11:05 (57.3 MB/s) - ‘adevices.sh.1’ saved [2249/2249]

========================================
Part I: ALSA
Advanced Linux Sound Architecture Driver Version k5.2.0-17.2-liquorix-amd64.

Card 0 (HDMI):
  * Playback Device 3 (HDMI 0):
    - Subdevice 0 (hw:HDMI,3,0):
      closed

  * Playback Device 7 (HDMI 1):
    - Subdevice 0 (hw:HDMI,7,0):
      closed

  * Playback Device 8 (HDMI 2):
    - Subdevice 0 (hw:HDMI,8,0):
      closed

  * Playback Device 9 (HDMI 3):
    - Subdevice 0 (hw:HDMI,9,0):
      closed

  * Playback Device 10 (HDMI 4):
    - Subdevice 0 (hw:HDMI,10,0):
      closed

Card 1 (UMC1820):
  * Playback Device 0 (USB Audio):
    - Subdevice 0 (hw:UMC1820,0,0):
      used by: jackd (PID 16451)
      access: MMAP_INTERLEAVED
      format: S24_3LE
      subformat: STD
      channels: 20
      rate: 44100 (44100/1)
      period_size: 128
      buffer_size: 256

  * Recording Device 0 (USB Audio):
    - Subdevice 0 (hw:UMC1820,0,0):
      used by: jackd (PID 16451)
      access: MMAP_INTERLEAVED
      format: S32_LE
      subformat: STD
      channels: 18
      rate: 44100 (44100/1)
      period_size: 128
      buffer_size: 256

Card 2 (MINI):

Card 3 (Interface):

Card 4 (FIRE):

Card 5 (M1x1):

Card 6 (XS8):

========================================
Part II: jack processes
10189 ?        Sl     1:01 /usr/bin/emacs24 --smid=23447aaf7-5240-496c-bbda-2ecd352e2dca --no-splash --chdir=/home/#Redacted --chdir=/home/#Redacted --no-splash --smid=23447aaf7-5240-496c-bbda-2ecd352e2dca /home/#Redacted/Desktop/jacklog
10195 ?        Sl     0:50 /usr/bin/emacs24 --smid=25adac0f9-6722-410d-a9b2-b63c1464545b --no-splash --chdir=/home/#Redacted --chdir=/home/#Redacted --no-splash --smid=24fa003cb-69be-451b-bc64-ac1033cc5519 --smid=2e64d6926-8639-4d6f-a1a9-d062bebb8e7b --smid=2812709e4-1a47-4984-972f-05446fc76f30 /home/#redacted/Desktop/jacklog
16451 ?        SLsl   5:20 /usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:UMC1820 -r441

paul · August 26, 2020, 12:15am

which device do you expect/know has an S/PDIF interface?

retnev · August 26, 2020, 12:17am

CARD6: The XS8 is my keyboard / has SPDIF out.
CARD1: is the audio interface 1820 / has SPDIF in.
Currently connected to each other with SPDIF.
Tried all clock options nothing works. Confirmed SPDIF works with windows without any changes to the connections. All the same.

Dont know if alsa maybe grabs clock from a completely different device like CARD0. That is the feeling I get. As I mentioned, plugged exactly as it is now, It did work once but then it just died. This looks like an alsa issue.

paul · August 26, 2020, 12:57am

in a terminal, just run:

aplay -l

and paste the output

retnev · August 26, 2020, 1:09am

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 9: HDMI 3 [HDMI 3]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 10: HDMI 4 [HDMI 4]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: UMC1820 [UMC1820], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

paul · August 26, 2020, 1:13am

It appears that ALSA sees the 1820 as a single device, with no differentiation between the outputs. From looking at the device documentation, it seems that the S/PDIF outputs are represented by channels 11 & 12 for output, and 9 & 10 for input. It seems very odd to me that these would not be a separate subdevice, because it is hard to share a clock across ADAT and S/PDIF connectors.

My guess is that alsactl will show some controls that can be used to set the clock mode appropriately. They likely will not show up in any generic alsamixer-style GUI, but it coule be worth checking to see if they do.

x42 · August 26, 2020, 1:21am

I have two devices that work like this (Focusrite 18i6, Presonus AudioBox 1818VSL). In both cases one has to switch the clock to S/PDIF (or ADAT) using alsamixer, and then the given clock is then used for all I/O.

retnev · August 26, 2020, 1:32am

Paul,

channels 11 & 12 for output, and 9 & 10 for input.

That is in fact correct.

Doesnt alsactl show 0/1 because there is no ADAT connected to the 1820. ?
Should it not show 1/2 as the 1820 itself is only 10x10 or somethibg (8x8 +SPDIF) +some monitor output and then the adat channel an extra 8x8 which makes up 1820.

I could never understand that 0/1 thing, and you seem to notice it too, so it must poin t to a problem with alsa .

Robin,
i already switched all combination of clocks on the 1820 and in alsamixer.
In fact I made a table of all possible combinations, tried them all and nothing worked,.

But … it did wok once for a day on Linux, and still works on Windows (which I only use to check the hardware as in this case)

retnev · August 26, 2020, 2:03am

Here are the options: Using the 1820.

I Activate the SPDIF button on the 1820
In alsamixer doing F6 select 1820, I then get the 1820 interface.
There are two options for clock

Internal
SPDIF.
I try both. None works

I then try the other option.
I select ADAT as the clock source in 1820
In alsamixer doing F6 select 1820, I then get the 1820 interface.
There are now THREE options for clock

Internal
Coax In SPDIF
Optical In Adat/SMUX
I try all three. None works

Is there a neat command line tool I can see if I receive spdif data from alsa ?
I just ask to see if there isnt matbe an argument between ardour and alsa.
Would be nice to rule that possibility out.

There are 4 SPDIF clocks for my HDMI card. I tried them also, in my table I made each option in there with every other option.
Nothing works. I know trying the hdmi 4 spdifs also is futile, but I just did it to see if I cannot maybe trigger alsa not to use the HDMI spdif … in case it does.

Come to think of it, I may be getting the spdif problems since I installed the hdmi video card in the server. I still think alsa looks at the spdif clocks on the hdmi card but tells you otherwise in alsamixer, although everything else alsa plays from the 1820 (same was with 1818vsl) is darn perfect.

No xruns with alsa/jack/ardour/mixbus at 2.8ms latency)
Could never get that on windows on the same huge server.
That is why I am hell bent to get this sorted out on Linux.
No way back.

Is there a way to tell alsa NOT to consider the HDMI audio and spdif ? I dont need that lowfi crap anyway…
I asked this question on Alsa UG , crickets, so I now have to entertain people here with these questions.
But I am grateful you are trying to help me.

If I dont get this resolved I either have to fork alsa and fix it and continue it my way (I am a good programmer as my publication record shows, but I dont necessarily want to do this) or hopefully wait for the new development that might replace Alsa. I cannot remember the name of that application, but I did run across a bunch of irrate people trying to replace Alsa and started development on a replacement, due to the non-response in the UG it seems.

For the record and to repeat again: Both the 1820 and 1818VSL works with same setup no cables replaced or any hardware changes on windows. So the problem is NOT hardware or wrong wiring.

paul · August 26, 2020, 2:34am

your HDMI device is totally distinct from the 1820, and its clocks have nothing at all to do with the 1820 clock situation. ALSA does not use, share or propagate clocking between devices.

there is no project to replace ALSA. you may be thinking of pipewire, which like JACK and all other audio I/O on linux, sits on top of ALSA, and does not replace it.

retnev · August 26, 2020, 3:20am

there is no way to know if alsa intended to handle them as distinct but due to a bug they get mixed up. There is really no way to know.

If alsa is sane it will do as you suggest it does, but from my experience working with alsa, stranger things happen like this spdif issue that is nonsensical, unless there is a bug such that alsa misreads spdif for a different device as intended.

I dont buy that alsa can only read spdif clock from a device it also receives the audio from. Entirely possible to mix clocks up and not report the mixup.

So any other suggestions I can try to see if alsa actually receive the spdif data.
How about a CLI tool to read spdif from alsa ? That will help. I couldnt find such a tool online.

paul · August 26, 2020, 3:46am

there is a way to know. i know the internal architecture of ALSA, and have written a few device drivers for ALSA.

Drivers for different devices have no connection to each other. ALSA has no concept of a “cross-system clock”. this just doesn’t happen. ALSA doesn’t even “read the clock” from any device. There’s no concept of a clock in ALSA - all you see is the presentation of switches/controls listed by the driver, which mirror capabilities in the hardware. The switches associated with the 1820 are associated with the 1820 hardware - ALSA doesn’t care at all which clock setting you use (though using the wrong one may prevent the PCM streaming from working correctly).

ALSA doesn’t handle s/pdif or ADAT or any other digital format in any particular way. Internally, a device driver presents the device as a PCM stream (read or write). The connector format and/or the data format used beyond the connector are of no consequence to ALSA.

x42 · August 26, 2020, 3:58am

For the devices I have, S/PDIF is just another channel (one of the 18 inputs).

retnev · August 26, 2020, 3:58am

If what you say is true, then there is absolutely no reason for spdif not to work as alsa knows no difference between the spdif channel data and the audio data. There is no other way then as I see it.

Then why the heck doesnt it work?
Then the only culprit must be Ardour or the driver.
It then is most likely the driver.

I have to rule ardour out completely.
I only have Mixbus and Ardour and mixbus is a skin for ardour with a custom processor, so cannot compare with these two.

Any suggestion how I can rule out Ardour ? so I can focus on the driver after that ?

x42 · August 26, 2020, 4:00am

Have you seen this?

retnev · August 26, 2020, 4:01am

Exactly. If that is true, the driver misses the extra channels for spdif or Ardour is at fault. Cannot see Jack having anything to do with it.

I have to use Jack and prefer it but Ardour could never connect directly to Alsa so I cannot check if jack is at fault, so I dont consider that route. Ardour/Alsa never worked over several distros. With Jack everything just works except spdif.

I have to consider buying a separate spdif/usb mixer box that hopefully can work without alsa and that I can pick up in Ardour.
Probably fastest way I can get rid of this problem.

retnev · August 26, 2020, 4:07am

Robin Gareus x42

6m

Have you seen this?

Yes I posted in it. See the last post or last few posts.

x42 · August 26, 2020, 4:07am

Yes, JACK has nothing to do with this, but the linked post also mentions the following:

When the UMC1820 is started with nothing connected to its Adat input Alsa sees it as a 12 out 10 in device. When The ADA8200 is connected to UMC1820 Adat input when UMC1820 starts up, then Alsa sees the UMC1820 as a 20 out 18 in device.

perhaps the same is also relevant for S/PDIF?