Jack Sample Rate Always Wrong when Creating or Opening w/ PW/JACK in Linux - Error this session was created in 48k but Ardour is running in 44.1k or vice versa

Installation & Configuration Linux
#1

Ardour sample rate dialog is misleading at best

Background

Ubuntu Studio was the coolest thing I had ever discovered. It had Ardour, Jack, a bunch of plugins and everything I needed to record. I’m a Linux guy and I know my way around, but it sure is nice not having to install all that stuff by hand. I install Ubuntu Studio for my friends and they love it. And Ardour is the biggest piece of the puzzle.

Problem

Then one day “This session was created in 48k and Ardour is running in 44.1k”. Oh but that’s not all. No matter were I look, I can’t change the sample rate because I’m using JACK and that’s not how it works. Jack controls the rate, but even after setting the rate in JACK and many other attempts, The unhelpful dialog pops up again and again, mocking me…taunting me…and of course ruining whatever musical inspiration I had. It’s already difficult after a 30 minute equipment setup to retain the magic.

Solution

I sort of wrote the solution first so you don’t have to relive my grief in the next section. The solution is, if you continually see this dialog, try this one thing first: unplug all your USB devices that show up as a recording interface in Jack, such as pedals, usb microphones, pianos, etc that connect via USB to your recording machine. Why? Ahh, you might still have to relive the pain below.
But first, the next section is important.

NOTE TO ARDOUR DEVELOPERS!!

This section originally was more descriptive, but has been redacted by the author after further review because it did not add anything of value. The following paragraph is the new paragraph:

As a note to the developers, I would suggest providing more information in this situation to educate a user why their rates could have mismatched and suggest helpful tips such as “Try unplugging all USB interfaces before starting Ardour to see if the problem goes away”. As you look at this issue through the eyes of the user you will see the dialog is true and accurate and difficult to decipher the root cause.

Steps to Diagnose

Ok, I would go step-by-step but that would be 50 pages. I have plenty of notes as I researched the problem.

But the general strategies I used are listed below with varying levels of success.

  • Flailing around aimlessly in a hot garage with a guitar in my hand, headphones on my head, and this stupid uninformative dialog box.
  • Researching, e.g. googling everything I could think of.
  • Screwing up all my Jack settings to get it to work.
  • Screwing up the sample rates in all my project files
  • Giving up and repeating every time I get the urge to record (like 5 separate occasions)
  • Finally stumbling upon a post (I wish I could give a cite or credit!) that recommends unplugging USB devices.

Ok, turns out not all USB recording interfaces are made the same. Some support different sampling rates. As you might expect, cheaper gear probably supports lower quality rates. Right? Wrong, I have a piece of gear that ONLY does 48k, and doesn’t support anything less, and it was very cheap indeed. I had at some point decided I wanted to back down to 44.1k to work with some cuts someone sent me and that’s when the chaos began. I remember now, thinking back a few months, I did modify the sample rates on some files trying to jigger with it and didn’t realize the next time I went to record was the first time I saw this error.

Conclusion

Well, that’s it, is this a rant? A bug report? A feature request? I dunno, your mileage may vary.

#2

One of the recent Ardour releases (I forget which) made 48Khz the default when you start a session, it was 44.1 for years. Whatever sessions you’ve created with 44.1 should still open at 44.1 but if you simply start a session without thinking it will be 48Khz by default now. If you’re using PipeWire and haven’t manually changed the system default sample rate from 48Kz with a Pipewire metadata command OR by changing PipeWire’s default config settings you’re going to bump into this issue. This again makes a golden case for simply using the ALSA backend which will roll with whatever you put in the dialog box and doesn’t care about what the Desktop Audio server has decided for a default…

AV Linux has a simple UI to change PW sample rate and quantum on the fly, not sure how UBStu handles this.

#3

Screenshot_20240906_221430

In Ubuntu Studio 24.04 version, you can find a corresponding menu with which Pipewire settings can be changed

1 Like
#4

Thank you for your tips.

Changing the Metadata

pw-metadata -n settings 0 clock.force-rate 44100
pw-metadata -n settings 0 clock.force-rate 48000

These two commands change the metadata in in pipewire to run jack at whatever rate you specify.
I can verify in qjackctl that the rate does change.

Ubuntu Studio – Changing Rate
This does sound like a useful tool Ubuntu Studio should include. They have a handy interface to switch between ALSA/PipeWire/Jack configurations but it works only with the package manager to config what type of setup you want.

End of Day
At the end of the day, I simply just have to recognize that I have one device that needs 48k, so I should just record and resample it with an external tool, which is trivial.

#5

Thank you, this is useful, and I do see now, where I can change the settings, but I have already been able to change the settings in other ways.

#6

  1. If you’re using Linux for the first time, you should likely not be using JACK and we actively recommend against it. It offers first time users nothing over using the ALSA backend.

  2. It is hard to tell whether a posting like this will nerd-snipe any of us into doing anything with one of the most insanely complex dialogs in Ardour (complexity that is almost completely inobvious to most users because “I Just to use my audio interface at X kHz, why is this so hard?” … or … to completely ignore it because, yeah, the internal complexity of this stuff is insanely hard if you want to cover the bases we are trying to cover

  3. I would suggest that writing a short post that asks a simple question such as “Why cannot I not fix the sample rate when it is wrong and I am using JACK” would likely bring more benefits and more understanding.

#7

Paul, this is unacceptable!!! You mean to tell me you haven’t conceived a means to determine within Ardour why a sample rate is being forced upon it at startup? How hard could this be, really? There are only 3 sound servers in Linux and only about 100 active distros that place their audio configuration files wherever they choose. That’s only 300 variables to take into account as you figure out how to write the code so Ardour knows if the sample rate is being forced by the sound server or the hardware. Get on this NOW!! You expect an owner of a piece of hardware to know its capabilities? That is Ardour’s job, not the owner of the hardware.

1 Like
#8

Less tongue, and more cheek: we are not going to add a way to change the SR of a running audio server. That’s the job of the tools used to manage the sound server, not the apps using it.

1 Like
#9

Thank you Paul for your suggestions and tips. Yeah, I use JACK exclusively, so I prefer it over the regular backend. It typically works flawlessly either way. Just this one edge case.

As to the nerd-snyping or whatever, my bad, wasn’t running anyone down. Ardour is fantastic. It’s my favourite DAW hands down.

I understand the woes of a developer
Most artists do what we did in kindegarten, we learn to trace the outline then colour it in. Professional artists are just really good at the colouring part and sometimes don’t need the outline because they see it in their mind.

Developers do the same, they look at a problem, build a fix in their mind, and sometimes outline it on paper, then just colour it in and viola you have a software product.

But paintings are intended to stand as a statement of the Artist’s will at that moment. Software applications, by comparison, need to work for their users or users will choose other things. And I don’t want users choosing anything else. I recommend Ardour to everyone who will listen.

But, like many DAWs, there are rough edges and this is one of them. Beauty is in the eye of the beholder, but the friggin soda machine just ate my dollar. Users don’t care about a statement, they care about getting the soda out of the machine. Getting the music from their DAW.

My opinions are easily offensive
So my opinion is contrary to your daily workload, which is plenty I assume. But it can still be thought about without adding anything to your workload.

But the solution could be easy
I understand that a dialog might be called in the course of an exception handler’s response just to report things downwind from where the problem arises originally. I understand that people who use jack take responsibility for their own setup and Ardour just hops on for the ride. So these constraints make it difficult to make a workaround. But I think simply telling the user to check their interfaces, including starting Ardour without any USB interfaces already plugged in, and all that isn’t out of line.

I also understand that the dialog box is very abstract and you can’t put anything there. But Ardour throws it upon loading when you have this unique set of circumstances I descried.

Conclusion
So, split the difference, when there is a difference allow Ardour to set the rate per track? This way my 48k-only usb microphone and my 44.1k max pedal can each record at the same time.

That may be more work than it’s worth, but just the existence of this post will reveal the solution quickly.

Great to see a dev in his own forums, thanks!

So, my apologies, but the point is the same. The app is very complex (as a SE I understand) but locating that dialogue and appending some useful info to the message isn’t complicated. I also know about the complexities of getting it into the whole pipeline among 1500 other things. But my intent wasn’t necessarily a feature request (it’s certainly not a bug even though it looks like one). I just wanted something other people can google and solve their problem.

1 Like
#10

Pipewire transcodes sample rates, so it should be possible to connect both devices and record them at the same time.

#11

Oh and also, Pipewire is built for applications to set their own sample rate. JACK applications don’t because they are made for a system where they are connecting to a set one. In the absence of this, there is a default sample rate that applications connect to that can be dictated in a text config file

Practically If you want to start Ardour at a different/specific sample rate then you can create a separate application menu entry where the command is PIPEWIRE_LATENCY=*quantum*/*sample rate* *command* which would be for example PIPEWIRE_LATENCY=256/48000 ardour8 You can also use this to launch from a terminal.

1 Like
#12

Important to note that for now (and perhaps forever) Ardour does not interact with Pipewire using the Pipewire API, only the JACK API.

#13

That is just not a reasonable suggestion for a professional audio production application. In order to mix the two tracks together one would have to be sample rate converted to the common project sample rate. Real time sample rate conversion involves making quality vs. latency vs. CPU load trade offs that don’t seem realistic to force on a user who ended up in that situation. For sophisticated users who understand why they are choosing that, there are solutions such as zita-a2j which are already available.

#14

DAW with per track sample rates

I like your point. But to mix them down, all the lower sampled files could be re-encoded at the highest common sample rate then mixed together? Maybe in realtime, or you could do it when the track is loaded or even whenever a user decides to run a “pre-production” step? It would make sense to offer to also downsample to a common denominator.

Then also a user could choose the strategy that best fits their needs?

And, you can ask if you want to operate on the original or create a new track.

Zita-aj2

This is orthogonal to the original edge case I found myself trapped in. But this is very valuable advice you have given.

I sincerely appreciate this, I love zita-aj2. I had never heard of it before your post. I wish it had a graphical interface so I can help my less technically inclined friends use it.

#15

That is already done when importing existing audio files. The context of your earlier post was recording at two different sample rates at the same time. Ardour has an undocumented way to do that, but you would be better off just not doing that.

re: zita-a2j

Not really, it would be a perfect solution for wanting to use a single sample rate device with a session already created with a different sample rate.

#16

Does this really matter when everything seems to be working pretty well at the moment?