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.
Paul,
They are always there by default from clean install in both Ardour and Mixbus.
They are inconsequential right?
Or should i remove them anyway
Paul,
Basically seems impossible to remove the LTC connection to Capture1. It is seemingly a prerequisite in Ardour to have it connected to something.
I can remove it and check in patchage that it is not connected.
As soon as I restart Ardour or Mixbus it is back again with LTC connected to Capture 1.
Works fine here. And these connections do not exist by default when I test it here.
There is no way to shake them here theyh are always there with both mixbus and Ardour. So what makes this connection if it is not Ardour and why ?
You can clearly see them in my patchage screenshots I posted. I did not make them from cli or within the daws.
This is getting completely off topic. The LTC connection has nothing to do with the subject at hand. I suggest to focus on solving that.
Well if things happens automatically in Ardour or Jack then it is on topic in my view, but it is your decision. Lots of other automated nonsense may be happening such as this causing my problem. If it happens once it can happen again and if none knows why it happens then it can happen for other things like spdif also.
It is your decision to mark it as off topic and I will abide by that henceforth no argument, but it is conceptually a serious issue. Things cannot just happen by themselves like this. Either Jack does it or Ardour does it. and I have no Jack scripts doing this and nothing that configures or start jack except the simple string I send to make a jack/alsa connection. No Cadence, no qjackctl nothing else.
I will not mention it anymore, although conceptually it is serious.
Well, we can (and should) discuss this later, and ideally in a different thread (not titled SPDIF). If someone else come here with a S/PDIF issue they won’t be distracted, then.
Right now it likely only gets in the way to solve the actual issue and add to the frustration.
So let’s recap:
Is this correct so far?
re (4). does this also apply to analog inputs? e.g. here when I change the 1818VSL to use external clock , the analog inputs only work if and only if there is an external clock signal.
Testing this can be helpful to see if the digital I/O works.
This indicates that you have given a nonsensical value for clock rate to the card:
16451 ? SLsl 5:20 /usr/bin/jackd --sync -P80 -ndefault -dalsa -dhw:UMC1820 -r441
The argument to -r should be either 44100 or 48000.
You do not mention what model of Yamaha keyboard you have, the Motif line of synthesizers only outputs 44.1k sample rate data, so you should check the jackd console output to see what sample rate it actually used when you requested 441 Hz instead of 44100 Hz. 44100 is the lowest rate that the UMC1820 supports, so likely jackd defaulted to that anyway, but it would be good to verify.
You must choose SPDIF as the clock source if you are using the S/PDIF input, there is no need to try all the wrong settings.
arecord
I do not think arecord allows you to choose which channels are recorded, so to record the capture from the S/PDIF channels you may have to record 10 channels and then only check channels 9 and 10 after you stop recording.
As Paul previously pointed out the HDMI card is not relevant (assuming you are not using your video card as an audio interface).
A stand-alone mixer can presumably operate as a mixer without ALSA, but you will not be able to get the audio into your computer without ALSA. Linux has one audio driver subsystem, and that is ALSA. There is no alternative when using a modern linux kernel.
Does patchage save connections? I am not familiar with using that tool, I see from a screenshot that it has a file menu which seems to be for storing setups. Does patchage attempt to load the most recently used configuration when patchage starts?
But you showed connections in patchage before. If you are only using Ardour why not just show the connections in the audio connections window? Is patchage in use, or do you really have “nothing else” except Ardour and jackd?
For that matter, why even use jackd? If you are trying to isolate problems with the configuration of your audio interface it is easiest to start with the most basic configuration, just Ardour or Mixbus alone without using jackd, or even the arecord utility I mentioned previously
Or if you want to use jackd, you do not need to use Ardour, just connect input channels 9 and 10 to the channels you use for output to your speakers (probably 1 and 2, but whatever channels you use).
That would allow you to verify that audio is received on channels 9 and 10.
Hi Chris here are my answers.
I received the 441 directly from the jack developers group. They told me to use 441. I found it curious too but that is what it was. The first time I used that string back then I did check and it did switch tio 44100.
I take a developers advice literally so I used it. Who am I to argue, they wrote the code so I used what they gave me and it works.
Eg. With 441 entered after jack was set to higher rate, it gives me correctly
~$ jack_samplerate
44100
Connected for this debug.
Motif XS8 (It is in the Patchage screenshots I posted earlier)
The XS SPDIF, is 44.1kHz at 24bit and always on.
The only discrepancy can be the 24bit output.
If the interface does not do 24 bit it will drop the necessary LSB, but should still work.
It wont drop MSB by design.
I dont agree. If software has a bug things can be misreported. Therefore in cases like this I will try EVERY option in case e.g. SPDI FCOAX was mislabeled as SPDIF OPTICAL. Developers are human and make lots of mistakes so I need to make sure I consider every option in order to solve the problem.
No it doesnt it only keeps a text list of where every object is placed on the canvas. It does send jack connection commands and can make or break connections. Regarding the LTC bogus connection. I can break the connection and test it is broken and remain broken. Then with Patchage shut down, so it cannot interfere I shut down and restart Ardour, and then Ardour or Jack just go right back and connect LTC to Track1 again. Clear proof that Patchage doesnt create the connection.
[/quote]
That would have been nice for debug to connect straight to ALSA from Ardour. Unfortunately years passed later and about 6 different installations running Ardour I could NEVER connect Ardour straight to Alsa. It just doesnt work for me. It completely refuses on at least 6 distros cleanly installed over the years. As soon as I install jack send the string it connects first time. Brilliant. I just LOVE jack and it gives me no extra latency. I run 2,8ms latency without a single xrun except during Ardour or Mixbus startup. Could never get that low latency on windows. This system runs like absolute heaven !! It is just the small stuff like this spdif issue.
That is one of the first things I tried long ago. I was looking more for a direct alsa to alsa loopback test as you suggest without using jack. I should have been more clear in my initial posts sorry.