For the record: I tried a loopback on alsa through jack again connecting Capture9 with Playback1 and Capture10 with Playback2. Went through every possible SPDIF option and no sound.
Reason why I dont consider this loopback test anymore is since it uses jack. Since there is no workable way I could find to loopback ALSA in this way without jack, it is not really a test if Jack is somehow the culprit. I went through ALSA config files to see if Capture 9&10 was not maybe muted in config, but none were. The problem is clearly with ALSA/1820driver unless Jack for some reason borks channels 9&10 specifically.
Dont know I am stumped on this.
There is no reason this should not work.
All that remains is to take out the videocard as its installation correlates about with the time SPDIF stopped working.
Will try this weekend or when it can go down.
I guess I will have to just use two Roland M-1000s then as the only alternative. Getting this extra spdif would have been enough to use only one M-1000.
The guy who copy pasted this to you accidentally cut off the last digits, it should be 44100.
I could NEVER connect Ardour straight to Alsa
This tells me there is something wrong with your software. Alsa is the software that is directly connected to the audio hardware and there is no other way to get sound than through Alsa. Ardour should not have any problem connecting to Alsa, if Jack can do it then Ardour can also.
Maybe the wrong automatic connections are caused by the same problem that prevents Ardour from connecting directly to alsa. Could it be that something starts jack automatically and reserves the sound card to jack. This āthingā might be responsible for the wrong automatic connections also. Maybe you used some software in the past to save the state of jack connections and these are recalled now. I think you should debug this until you can connect Ardour to Alsa without using jack.
Just FYI LTC is time code that is recorded onto a video or audio tape so that tape playback can be syncronised with other tape machines. So it has nothing to do with spdif. https://en.wikipedia.org/wiki/Linear_timecode
The guy who copy pasted this to you accidentally cut off the last digits, it should be 44100.
Most likely, but it works like that anyway and i checked that it switches to 44100 if I use that, so it is probably not necessary. It is not the problem though.
This tells me there is something wrong with your software. Alsa is the software that is directly connected to the audio hardware and there is no other way to get sound than through Alsa. Ardour should not have any problem connecting to Alsa, if Jack can do it then Ardour can also.
It would have been nice if that was the case.
Did you miss the part where I say this happened over several different OSās installed ?
In matters like this common denominator is key. And the common denominator is the same server all these OSās are running on and particularly it seems since i installed a powerful videocard, which unfortunately also had a huge lot of surround capability with its own sound card and 4 spdif connections.
That is the only thing that correlates.
As discussed i will take it out when the machine can be switched off to check.
ust FYI LTC is time code that is recorded onto a video or audio tape so that tape playback can be syncronised with other tape machines. So it has nothing to do with spdif. https://en.wikipedia.org
I know that, however if a bug is suspected you cannot take anything for granted and nothing may be as it seems. Point in case; LTC absolutely demand to be connected to capture 1. I cannot remove it. I can write a jack script to disconnect it and put that in cron, but the question is why Ardour/Jack always have LTC connected to capture 1 on my system. That is just not right that it automatically connects and you would be right that that entire automatic process may be the cause of all the trouble. You cannot just assume software or hardware always work perfect. There is always something that can be triggered to cause malfunction. It is the price you pay for not using a strong typed language. But the price is generally worthwhile to justify it.
The curious thing is that in both Ardour and Mixbus they are connected, but jack reports they are not;
Not showing the LTC connection which is clearly connected in Patchage.
This issue is a separate issue and a moderator asked that I create a separate post so I wont continue this issue here as it is OT.
This indicates you have something else on your system, another piece of software, making this connection. Until you can determine what that is, it is difficult to suggest a solution. To my knowledge there is no code in Jack that would do this, nor is there code in Ardour to automatically connect the TC ports I do not believe unless restoring a session that does it. The fact that this is not the default behavior on anyone elseās system suggests the problem is not in Ardour, and again we are back to external software.
$ jack_lsp -c |grep -i ltc
This wouldnāt show the connections as the jack_lsp -c shows connections as:
PORT
CONNECTION
So grep would filter out the connection that didnāt match the ltc expression, and only show the port. The fact that mixbus:ltc-in is indented indicates it was connected from a different port.
As Seablade said, this strange behavior is something that is specific to your setup, since I have not seen anybody else report this.
In my opinion your first goal should be getting Ardour to connect to Alsa without jack, because this would eliminate all the automatic wrong connections in jack. This could be just as easy as the following terminal commands:
killall jackd
Check that jack is not running:
ps aux | grep jackd
Start Ardour and select Alsa as the backend and select your sound device also. Create a new session without using any template. Now you should be able to test your spdif without those confusing wrong connections.