After some deliberate configuration, I set my alsa settings in alsamixer and stored them via alsactl store. This works great - every time I reboot the settings in my alsamixer are set properly (the specific setting I’m concerned with is the “SPDIF clock sync”). However, after recording with Ardour today I noticed some pops & crackles - after looking through alsamixer I see that my SPDIF clock sync setting is changed back to internal.
After some further debugging, it appears that Ardour is changing my clock sync to internal every time I load a session. I’m not sure why that is, I thought Ardour would leave my alsa settings alone but it seems to want to reset the setting back to what it wishes. Is there a setting in Ardour to configure the SPDIF clock sync source? It is really frustrating to record a great track, and then afterwards I realize the clock source is wrong and the track really isn’t perfect.
Ardour does not explicitly modify your device (mixer) settings at all. This must be happening as a side effect of opening and configuring the device for use.
Strange. I just tested turning off and on my interface and it stays configured on my preferred clock sync setting. The moment I open up an ardour session and press “start” on the audio config dialog, ardour is then opened and at that moment the clock source changes back to internal. I can’t seem to do anything else outside ardour to trigger thos change, alsamixer shows my preferred setting until ardour seemingly overrides it.
There must be something going on in the ardour audio configuration that changes this.
I’m not even sure how to get this configured properly unless there is some ardour config I can set. My alsa settings are all set properly and to my knowledge ardour is the only thing changing this.
I just checked the code of the ALSA backend for every snd_ctl_*() call. There are none other than those required to get device info. You could check to see if JACK does this also. Otherwise my guess would be that it’s the use of the device in duplex mode (most other applications won’t)
Also, wouldn’t it have to change the sample rate at least via ALSA? Or is that handled internally in Ardour? I’m not too familiar with linux audio but from what I understand the SPDIF sample rate needs to be consistent or otherwise converted.
Even more strange is that the clock source doesn’t change when until I close out the audio config dialog. Using the config wizard doesn’t change any alsa settings. It only gets changed when I close that and Ardour continues the loading process and the editor controls then appear.
Ardour will configure the buffer (“period”) size, the sample rate, the number of buffers (“periods”) and a couple of other internal aspects of the PCM (audio streaming) side of the device. It does nothing to the CTL (“mixer”) side of the device.
The Audio/MIDI setup window doesn’t do anything at all while you are changing parameters. This can only be done when the device is stopped. When you leave that dialog, typically the device has just been (re)started.
I have tried restarting the device manually, as well as rebooting the computer entirely. Both of these result in my alsa configuration being reloaded to what I have set. Something else must be changing the settings here; it must not be a simple restart of the device if the settings are being changed.
For example, if I quit Ardour and then power cycle the device, the settings are restored to my pre-configured values. Once I start Ardour again my settings are then discarded for whatever reason. That is the part I’m trying to figure out the cause to.
I have UMC1820 and I use it with ADA8200 (and Ardour 5.12). UMC1820 is Adat master and ADA8200 is the slave. Adat uses the same port on UMC1820 as spdif. I haven’t had any problems with the clock between shutting / starting Ardour or computer but I always use Jack 1 and start it with QjackCTL before starting Ardour.
Pushing the SPDIF / ADAT selection button on the device resets the device (by design) but I guess your case has nothing to with that ?
I am not sure how to word this so that you are clear, but I’ll try again: Ardour contains no code to modify anything except the PCM (audio streaming) settings. If the device ends up with a reset clock source, that’s probably caused by the device driver doing this as a side-effect (intentional or not) of something else. I’m not telling you this from memory - I’ve already said that I checked all the code, just to be sure. In addition, Ardour wouldn’t know how to carry out such a modification - one reason we don’t touch the “mixer” settings is because they are always hardware specific, and we don’t want to try to build such “knowledge” into the program.
The UMC 1820 is used by at least a few other forum users. I’d wait for a bit and see if they answer.
Set UMC1820 sync to internal, connect both spdif - cables between your devices. Hopefully your other device then behaves as spdif - slave and follows sync from UMC1820.
Start jack 1 before starting Ardour and see if UMC1820 behaves differently. I doubt that this makes any difference but it’s best to rule out all possiblities.
By the way are you using copper or optical spdif - cables ?
I have a couple of spdif devices so I can do some tests if needed.
I’m using Alsa only at this point. I don’t see how Jack would affect this but I’m planning on trying that out soon to see if there are any changes. I don’t see how SPDIF would be any different from ADAT in this regard. My device will not operate in slave mode at all, hence the frustration.
I’m not sure how this would be happening if ardour isn’t do anything when power cycling both the device and the computer doesn’t result in this issue.
Does anybody use the UMC1820 in slave mode and have this issue? If not I would be grateful if somebody could try starting Ardour with the device in slave mode and see if the same thing happens to them.
I understand you searched the code, thanks for that. From my experience code is rarely so simple that a global search will find all issues. I’m specifically trying to debug the side effect you mentioned since Ardour appears to be the only application where this happens.
In my setup UMC1820 is always sync master. Anyway I will do some tests with two computers and audio devices connected together with spdif.
One more thing you can try is to test with another DAW. Waveform Tracktion version 7 is free (Linux, macOs, windows), it only requires registration to get a free license. Tracktion will use your audio device in full duplex mode and lets you see if it’s behavior changes. I used Tracktion 7 for some time but got frustrated it crashing every day. Its good for doing tests though.
In Ardour’s case it’s simple because all backend code is self-contained and separate. Also the ALSA API has nice prefixes. All of the library’s methods and data-types are prefixed with snd_.
There is not a single call to snd_mixer_* in all of Ardour and certainly not snd_mixer_open, and only a handful of snd_ctl_* which are used to list devices. Paul said he investigated those too for good measure.
That’ll print debug information for the ALSA backend.
However, I suspect the actual issue is caused by other software when the device is opened. Perhaps alsa-utils, that has an alsa-ctrl script to saves/restores settings of devices (it’s started by systemd, or /etc/init.d/alsa-utils).
UMC1820 switches clock to internal always if there is no signal to sync to on the spdif cable. Sync stays as: “Optical In” until Jack OR Ardour is started and then switches to: “Internal”.
If there is signal on the spdif - cable then sync stays on: “Optical In” when Jack or Ardour is started.
I tested this using an optical cable.
Edit: If you don’t always have signal on the spdif - cable then just keep the sync option open in alsamixer and hit a key when you want to sync to external signal.
I think I figured out a workaround for this. This issue seems really weird, I found out this morning after testing some more it only happens sometimes but not always. My current workaround is if I start the SPDIF device first and then open Ardour, it seems to stick with my configured settings.
I did find out if I manually switch the computer’s alsa output to my audio interface, it does trigger the behavior of resetting my clock sync setting. So this definitely does not seem to be a problem from Ardour. I’m sorry for any confusion, this must also be due to my lack of knowledge about these things.