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.
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.
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.
For the devices I have, S/PDIF is just another channel (one of the 18 inputs).
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 ?
Have you seen this?
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.
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?
I saw that, but could not really decipher the real implications of that.
So you are saying the driver possibly only works correctly regarding spdif if you use the 8200 with the 1820 as adat ?
If so I need to contact the developer of the driver (seemingly the same driver is used for 1818VSL and 1820 as both are compliant.
With ADAT you must connect an ADAT device before powering on the UMC1820, according to that post.
Perhaps the same is true for S/PDIF. Was an active S/PDIF device connected when you powered on the UMC and when connecting the UMC to your PC?
Yes my keyboards are always connected to the 1820 and switches on the same time as the UMC. They are all on the same remote control power switch. The Linux server is on 24/7. I just have one connected to SPDIF currently to make debug easy.
You mean we are back at late 1990s usb switch-on order issues again ? If booting my server is the solution tghen it isnt a solution.
But it makes sense why it worked initially just when I received the 1820. The 1818VSL worked for about 6 months without trouble and then spdif just died. After that I bought the 1820, which just sounds so much better than the 1818VSL. Worth every cent.
Have you tried doing this manually, step by step?
Does this work?
Robin.
I carefully did exactly as requested for all possible clock options in alsa and the two clock options on the 1820.
None works.
Alsa does report the correct clock sources on the 1820 as there are more in adat mode than spdif – as there should be. So the driver is alive and reads the spdif ports.
I could not upload a datafile so I had to paste it.
Maybe there is an interrupt clash somewhere.
I couldn’t immediately see it but is still looking.
Never mind. The data cannot be pasted into this forum. It comes out all wrong never mind how I paste it.
I will probably remove this post.
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16 CPU17 CPU18 CPU19 CPU20 CPU21 CPU22 CPU23
0: 38 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 2-edge timer
1: 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 1-edge i8042
8: 42 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 8-edge rtc0
9: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 9-fasteoi acpi
12: 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 12-edge i8042
14: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 14-edge pata_atiixp
15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 15-edge pata_atiixp
16: 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 16-fasteoi ohci_hcd:usb3, ohci_hcd:usb4
17: 0 800366267 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 17-fasteoi ehci_hcd:usb1
18: 0 72 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 18-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
19: 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 19-fasteoi ehci_hcd:usb2
22: 0 0 0 0 0 2305679 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IO-APIC 22-fasteoi ahci[0000:00:11.0]
25: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 32768-edge PCIe BW notif
26: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 65536-edge PCIe BW notif
28: 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048576-edge eth0
29: 0 0 0 0 0 1119492 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048577-edge eth0-TxRx-0
30: 1089741 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048578-edge eth0-TxRx-1
31: 0 1355713 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048579-edge eth0-TxRx-2
32: 0 0 1391818 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048580-edge eth0-TxRx-3
33: 0 0 0 2082762 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048581-edge eth0-TxRx-4
34: 0 0 0 0 1811837 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048582-edge eth0-TxRx-5
35: 0 0 0 0 0 1161161 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048583-edge eth0-TxRx-6
36: 1279521 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1048584-edge eth0-TxRx-7
49: 0 0 10401 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1574912-edge snd_hda_intel:card0
50: 0 0 0 28747264 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PCI-MSI 1572864-edge amdgpu
NMI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Non-maskable interrupts
LOC: 248960817 164673757 242245124 153786125 204731091 150917788 176975996 147077208 156317194 141684450 145823431 137364484 257024484 159151242 245168281 157247601 210900538 154005345 181329825 150417783 160169313 144237577 147365356 137855842 Local timer interrupts
SPU: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Performance monitoring interrupts
IWI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 IRQ work interrupts
RTR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 APIC ICR read retries
RES: 451091010 474211655 465621324 471658893 417326261 423616905 347361347 337756629 283742434 266881850 228918338 209423533 439797658 480423106 446112257 471609212 426947885 435500447 357761063 350264859 291097096 275657761 231940319 213212074 Rescheduling interrupts
CAL: 8976969 4123557 9048270 3498241 7484248 3502343 6508848 3164120 5011885 2681770 3721116 2039494 9502554 4465164 9175918 4101518 8039840 3708669 7114598 3391394 5708965 2867161 4299427 2100131 Function call interrupts
TLB: 56483315 16402588 59224302 14753539 41179855 14811607 26563079 12653450 18465376 9955656 13108112 7157206 55262659 19373263 60229870 18020814 42737706 16472445 29306330 14050700 21188646 11252112 15066672 7956045 TLB shootdowns
TRM: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Threshold APIC interrupts
DFR: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Machine check exceptions
MCP: 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 1631 Machine check polls
HYP: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Hypervisor callback interrupts
HRE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Hyper-V reenlightenment interrupts
HVS: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Hyper-V stimer0 interrupts
ERR: 1
MIS: 0
PIN: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Posted-interrupt notification event
NPI: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Nested posted-interrupt event
PIW: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Posted-interrupt wakeup event
EDIT: Fixed your formatting on the data and a few typos/misspellings in your post. For the record what you are looking for is pre-formatted data, which can be gotten in this forum (And any discourse forum) by utilizing three back ticks (Typically above the TAB key on US keyboards) before and after the pre-formatted data. – Seablade
Thank you seablade, it is however truncated and the rest of the iterrupts do not show so it is incomplete. i tried the formatting from the icons and highlighted the pasted text and pressed pre-formatted button. Did not work. I will do it manually as you suggest.
i will try and type slower. Not always possible.
Is it possible for you to take that video card out and put the old one in ? This might be worth doing considering how long you’ve been struggling with this problem.
It will be a while before I can do that., but I will try as the server is in use.
Probably this weekend and then I will report back.
Ardour does not have a preference for a specific pair of channels and has no knowledge of spdif clocks AFAIK and as far as I can see only receives the audio data like any other audio data from Alsa,
It just cannot be Ardour as far as I can see, unless there are clocks involved.
Looking at clocks. From what i can see as user, and not developer, there are some clock inputs to both Ardour and Mixbus, but they connect differently with Mixbus and Ardour.
I created two simple configurations with just the tracks needed for SPDIF and a usual Analog in for the same keyboard. I left it out from Ardour as I just use the analog inputs to test that I get sound from the keyboard, it is the spdif I am comparing.
Here is my patchage screenshot of routings to mixbus.
I just did this with Ardour’s derivative, mixbus as with the latter inputs and outputs are shown independently in patchage, but Ardour is shown with inputs and outputs combined into the Ardour object displayed resulting in a tangled mess. It is just a patchage thing.
Why is LTC connected to Capture 1, and why do we need it on Capture 1 in both cases ? If it is a clock, why not connected to spdif trackl ( 9 or 10 ) ?
I didnt write the software so I cannot know, and have to ask. It is most likely the world clock, and if the spdif capture outputs from alsa uses a clock different for spdif than my analog channels then there will be a problem if LTC is connected to Track1. It is most likely connected to Track 1 as all users will start there and you need a world clock and alsa will always have a capture 1.
It seems to me that there are two different clock existing which Ardour cannot differentiate. The clock for Audio analog signals and a separate clock for spdif. Why not have another clock input solely for spdif in Ardour ? You already have separate midi clocks so why not spdif clock inputs that can connect in this case to capture 9 ?
Could this be the problem ?
Is it worthwhile to try and connect LTC to capture_9 from alsa ? or is it somehow a stupid suggestion ?
On the other hand, here is Ardour configured with just the spdif track and Mixbus closed.
The clocks you see there have absolutely nothing to do with the clocks we’ve been discussing.
Sample clocks (like the S/PDIF and ADAT clocks) determine the timing of the analog->digital and digital->analog circuitry.
LTC/MIDI/MTC clocks are all positional clocks that identify position (and speed) relative to a timeline.
None of them need to be connected for Ardour to function.
Ok that settles that.
It isnt the world clock then
I had to ask.
Why are they connected by default then to Track 1 if they are not needed ?
I have no idea. Neither Ardour nor Mixbus should make those connections by default.
