Make sure you disconnect any inputs from the source track when doing direct bounces.
If the track is also connect to an external source, Ardour uses that as alignment when recording.
e.g. change
In -> track [play] -> track [rec] -> master -> Out
to
track [play] -> track [rec] -> master -> Out
Alternatively you can change the capture alignment of the track you record onto (context menu of the track header).
–
This concerns “capture alignment” – which is related but different from latency.
Round-trip latency with direct ALSA is equal, (if not slightly reduced compared) to the alternatives with identical settings.
Check with
track [play] -> soundcard Out -> cable -> soundcard In -> track [rec]
This is like recording overdubs. Instead of a physical loopback cable, you can use a headphone → sing along → mic. But for testing a cable is preferable
track [play] -> soundcard Out -> cable -> soundcard In -> track [rec]
This is the method i was describing, i just wasn’t clear enough. I do this every time i track overdubs to measure the alignment so that i can manually adjust it. I would just like this to be aligned properly without manually having to do it.
I’ve been using Ardour/Mixbus for a long time and I’ve never noticed that option. I tried it with both a physical out/in and the closest i can get is 540 samples late using the align to capture. when using an internal send/return without going through my interface i get 150 samples late. this is a huge improvement over 250 ms early using the I/O alignment. would love to be able to tweak this a bit more and find where the discrepency is coming from.
You can just remove the Pipewire JACK API modules, which lets you use pipewire for normal desktop application use (lowest effort right now with default Fedora configuration), but use jackd when you want to use recording and production software. The process is not completely obvious, by default DNF will offer to remove all of your JACK compatible software when you attempt to remove the pipewire-jack-audio-connection-kit package, but there is a force option you can use which will let you remove just that package, then install the jack-audio-connection-kit as replacement.
Did you copy that command directly from the command you used? Because I think that should fail, the name of the package that provides JACK API is pipewire-jack-audio-connection-kit, not pipewire-jack. If that was just a mistake because you manually typed in the command you used then you can ignore that for now.
You can use rpm to verify that the swap did occur as you intended:
$ rpm -q pipewire-jack-audio-connection-kit
package pipewire-jack-audio-connection-kit is not installed
$ rpm -q jack-audio-connection-kit
jack-audio-connection-kit-1.9.19-1.fc35.x86_64
Copy the exact log message from the qjackctl log window, perhaps someone will be able to help understand what is happening.
ALSA is the kernel driver that interacts with the audio hardware, there is no way to not use ALSA. When you run jackd the JACK audio server sends audio to the ALSA driver, if you use the Ardour ALSA backend then Ardour sends audio to ALSA directly, if you run pipewire then the pipewire server uses the ALSA driver, etc.
The various audio server implementations have agreed on a mechanism where applications can request exclusive access to an audio interface, and the currently active software will close the ALSA interface so that a different application can use it. So if Pipewire is running on your system and using the interface that you want to use with Ardour, if you start Ardour with the ALSA backend Ardour will send a request to Pipewire to acquire exclusive access to that interface, pipewire will release the current exclusive open, then Ardour will open the interface instead.
That same process worked with Pulse before Pipewire was available.
Yes, and dnf is smarter than me so it substituted pipewire-jack for the correct package
running Mixbus with alsa works but i’d prefer using jack. i’d actually prefer nuking pipewire completely for now. can i run the same dnf swap command with pipewire-pulse to remove it altogether?
and installed alsa-firmware, alsa-plugins-jack and still have no desktop audio. Mixbus will still connect to my interface with alsa backend but jack will still not start. here are all of the alsa,pipewire,jack packages that i have installed. i must be missing something.
I totally agree. If there is no EASY way lo load sessions with different samplerate, the Pipewire is useless for professional usage. It’s like a superb car, with all the newest electronic features, strong engine and other bells and whistles, but with no steering wheel. And if you want to turn the wheels, you have to turn the car off, change wheels angle in a config file, and start the car again. In a 21st century this is just ridiculous.
This is how you would change sample rate to 44100 temporarily (assuming your system runs 48000 by default) and start ardour using the pipewire JACK API:
If you removed pipewire-jack and are using traditional jackd, then just start jackd as you usually would, it will request access to the audio interface from pipewire and set the sample rate as given, then when you stop jackd pipewire will take over again.
That removed the pipewire-pulse interface, but pipewire is still running. Probably most applications will be using the pipewire ALSA library emulation (not to be confused with direct ALSA hardware interface access).
And you still have not provided any log from jackd, so no one here can begin to help you with no detailed information. Likely the reason that jackd will not start is printed out explicitly in the log information.
Here is the output from qjackctl after failing to start
18:16:20.963 Statistics reset.
18:16:20.964 ALSA connection change.
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
18:16:20.980 ALSA connection graph change.
18:16:25.240 JACK is starting...
18:16:25.240 /usr/bin/jackd -dalsa -dhw:USBStreamer -r48000 -p256 -n3 -Xseq -I320 -O320
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
18:16:25.245 JACK was started with PID=4103.
no message buffer overruns
no message buffer overruns
no message buffer overruns
jackdmp 1.9.19
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2021 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Device reservation request with priority 2147483647 denied for "Audio0": org.freedesktop.DBus.Error.UnknownMethod (Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1)
Failed to acquire device name : Audio0 error : Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1
Audio device hw:USBStreamer cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
18:16:25.343 JACK was stopped
18:16:27.405 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info.
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
This is what i was initially using to switch the sample rate. i bound that command and a 48000 command to some hot keys and just hit it before starting Mixbus. It mostly worked but switching back afterwards wouldn’t always work.
Whatever software is using the audio interface will not release it.
There is a script on the web site somewhere you can run that will print all the audio devices in use and which software currently holds access. I have a copy saved on my system, I cannot find any of the old posts which have the link to download from ardour.org.
Perhaps @paul or @x42 will have the link at hand to add here.
I feel like I’m wasting everyone’s time here. I’m going to re-install pipewire as it shipped with F35 and try and work with it. Hopefully they keep making improvements.
My assumption is that pipewire is using the USBStreamer device and since i can’t get rid of pipewire without getting rid of gnome desktop I may be snookered unless i want to install MATE or Cinnamon.
Sure, but did you attempt to start jackd right after you ran that script? Because according to the script output nothing was using the USBStreamer at that time.
Have you kept up to date with updates? I have pipewire 0.3.42, and I can start jackd without problems, so you should not need to get rid of pipewire just to run jackd when you are using Ardour (although you can also just use the Ardour ALSA backend if you don’t need to route audio between other applications and Ardour).
Nothing is very obvious at this point, this feels like the point where Paul usually says just go on IRC and get help in real time, because going back and forth once or twice a day on the forum is a really inefficient way to debug a problem.
I may just run with ALSA backend for now. I don’t like using 44.1khz as a sample rate but some stuff i edit gets sent to me in that format. I’ll just convert the source material since I’m not working with any super critical stuff.
Fedora is currently using 0.3.40
I’ll look for an update and report back if anything changes.
