Ardour not registering(Solved)

Installation & Configuration Linux
#1

I’m not sure if this is a bug (and I know I could be using alsa_in with jack)

Here I am using beta 2197 and could possibly be a reason, but I’m running on an overall stable linux setup.

I am using pulseaudio’s ‘copy’ resampler method (which avoids resampling when the data rates are the same), but the following occurs despite what resampler method I use, telling me it is more likely a problem in Ardour.

Ardour does not register as a pulseaudio client when typing “pacmd list-clients”… but other apps that play are listed as clients.

I’m not familiar enough to know whether Ardour registers or not because it is playing at the same sampling rate without needing resampling … And my understanding with pulseaudio is that as long as a client “connects” to pulseaudio that it should be listed whether resampling is done or not…

I just started noticing this after fiddling around with some settings…

It’s a benign issue of course, but I would like to see that there really is no resampling being done.

thanks

#2

Use Ardour/ALSA or JACK. Those requires exclusive access to the device for precisely that reason:
Ardour (or JACK) sets the soundcards settings and ensures that no other application can change them. This is the only way to assue reliable I/O latency, constant buffersize and sample-rate.

Pulseaudio is not an option.

#3

When you say “Ardour/ALSA or JACK”, are you referring to this ->
http://jackaudio.org/faq/routing_alsa.html ?

#4

Audio System: ALSA in the Audio/MIDI setup dialog: e.g.

That way Ardour directly communicates with the driver in the kernel without any middle man.
ALSA is the kernel interface to drivers. Behind the scene all sound-servers (JACK, Pulse,…) eventually use ALSA.

#5

yes that way works good too, I was refreshing things and I already had Ardour connecting to Jack, the audio/midi setup is not accessible unless a sound system is disabled… I prefer to have Ardour going to jack->alsa, and for fun I tested Ardour going through pulseaudio and I can list it. It is better that I have it set to Jack, I was just making sure…

I think don’t think I need to worry about using pa’s resampling as I can definitely make sure I do not have pulseaudio set when ardour starts (that is for things I want to use for other apps that stubbornly look for pa).

thanks

#6

I found out something was triggering my pulseaudio to auto-start here on my system so I had to use
->mkdir ~/.config/systemd/user
ln -s /dev/null pulseaudio.service
ln -s /dev/null pulseaudio.socket

systemctl --user daemon-reload

now when I login pulseaudio shouldn’t autostart itself…

#7

Ardour Menu > Window > Audio/MIDI setup

If you’re using JACK, jackd is running and you’ve used Ardour with JACK once before. Ardour auto-connects to jackd without asking questions. That offers some convenience to die-hard JACKers… :slight_smile:

#8

It’s a somewhat failed experiment. It kinda works, but will need more work before we can release it.

It is mostly intended for the following person(s):

“I’m editing on the road/in the train/…, latency doesn’t matter, live audio input and MIDI is not needed, probably even using bluetooth headphones.”

The fact that pulseaudio can resample is a feature here. A session may be at 96kHz while the average onboard soundcard can’t do this.

#9

includes Ardour here:

...
    index: 107
        driver: <protocol-native.c>
        owner module: 9
        properties:
                application.name = "Ardour"
                native-protocol.peer = "UNIX socket client"
                native-protocol.version = "32"
...

Also shows up in gui control app:

pulse_prefs
pulse_prefs.png633×526 26.2 KB

This is on a system without JACK.

#10

Yes, my system has been working very well with all three (alsa,jack,pulseaudio), but I needed to tinker pa’s things – however I got a grasp of finally getting to work with alsa-plugins-jack, and figured my issue was having a working ~/.asoundrc

Here it’s a desktop setup, so I did another run of apps that were using pa, and those could use alsa, — with alsa-plugins-jack working, the only thing I needed to add was a pcm.!default section – I don’t think I am using other definitions of this from elsewhere(as !default means to do override) as no matter what “jack” audio option I had available(eg, vlc) no sound would ever be produced…

If I ever need to use pa again, I’ve come up with the settings to do this… but such an application not talking to alsa prior requesting sound from pulseaudio I don’t think I have a problematic app that does this, so likely I will not be needing pa again (I hope tehehe)…

–> Alsa-plugins-jack doesn’t work out of the box here on debian and a little work had to be done in ~/.asoundrc…

I don’t think it would be a bad idea to point this out directly at the top of the FAQ for Linux users, merely that “pcm.!default” must be a necessity in order to have alsa-plugins-jack working correctly…

It is actually easier to resolve than pa, the only thing I have to do is make sure libasound2-plugins:amd64 is installed and that I have an adequeate ~/.asoundrc like this one,
"
pcm.!default {
type plug
slave { pcm “rawjack” }
}

pcm.rawjack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}

pcm.jack {
type plug
slave { pcm “rawjack” }
hint {
description “JACK Audio Connection Kit”
}
}
"

Ardour is a jack client, I dunno for some reason I thought it may have been a “pulseaudio” client because I saw that it has support for “Pulseaudio” on its audio-setup. So when Ardour now starts, it should ideally(in my case) always be connecting to Jack, and be sending audio data to Jack.

I think what confuses users is when they start looking at Midi things, and wonder how it plugs together

->
Alsa’s drivers --> support Midi
Jack --> supports Midi (it can be disabled, which is what I do because I prefer to have A2J do the Midi mapping)
A2J --> helps to remap better Midi names than Jack

PA does not support midi, so no confusion about it, … I can drop it, use alsa-plugin-jack and A2J still works and this is great…

#11

thanks for your feedback, would you by chance know if I need to use a ctl directive in .asoundrc settings when one uses alsa-plugin-jack? I don’t get volume controls for jack on my desktop here, maybe logically it doesn’t, and instead I should be setting CTL against the hardware device jack is mapping to.

#12

I’m unsure what you’re trying to accomplish, but it certainly seems like you’re over-complicating things significantly :wink:

I’d be interested to get to the bottom of the actual issue “Ardour not registering” in pulseaudio if that still is present when you use Ardour’s Pulseaudio backend. Preferably at http://tracker.ardour.org/

Could it be that you have been using Ardour with JACK at that time? And that was the reason why it wasn’t listed?

Did you get sound from Ardour when playing a session while it was using pulseaudio directly?

We’re getting off topic quickly again :frowning:

I think you’ll find that the alsa-jack-pcm plug is not very reliable and many ALSA apps cannot use it.

I also recommend to avoid using any asoundrc whenever possible.

If you really have to run non-pro audio (non JACK) apps in JACK’s context, the pulse-jack bridge is highly preferable. Keep in mind that it also adds overhead, which is not what you usually want during production. Pulseaudio also offers ALSA emulation. If you cannot use pulse for some reason, prefer ALSA Loopback devices. Those are actual devices (not user-space emulated).

It should be disabled for jack2 – see http://manual.ardour.org/setting-up-your-system/setting-up-midi/midi-on-linux/

#13

sorry I treked a bit, the fact of the matter is despite everything, it is now all much better

(I mention about having alsa-plugins-jack in place of pulseaudio – for solving everything that is outside ardour and didn’t want to indulge and thought the information may help other users like myself just starting with ardour)

I know about using alsa-plugin-jack as not as optimal as without it(so I point this out) – that’s why I refer to this as a user-case…

“I think you’ll find that the alsa-jack-pcm plug is not very reliable and many ALSA apps cannot use it.”

^ ?
Curious, what apps would these be? I can run chromium, vlc now alongside ardour…

I wanted to share my take on replacing pulseaudio today so I sort of explained on what I am using.

I should of mentioned earlier that the “registration” of Ardour was not showing up with “pacmd list-clients”,… mainly due to my mistaken notion that Ardour always connects to PA and only to Jack for Midi…

I tested again later, and Ardour does indeed show up with PA if I were to choose PA on Ardour’s startup… so I will mark this post as solved…

#14

“If you really have to run non-pro audio (non JACK) apps in JACK’s context, the pulse-jack bridge is highly preferable. Keep in mind that it also adds overhead, which is not what you usually want during production. Pulseaudio also offers ALSA emulation. If you cannot use pulse for some reason, prefer ALSA Loopback devices. Those are actual devices (not user-space emulated).”

Thanks for telling me, I’ll definitely look into it…

#15

I don’t mean to clutter, but people tell me not to use pulseaudio at all cost, so this is why I mention (apart from the post topic), about what related things I was working on …

You were telling me to use “Use Ardour/ALSA or JACK.” , so I favored towards removing pa… but you’re telling me now later that when using non pro-audio things (which I don’t mind on occassion because this is a workstation) that it is better to have the pulse-bridge, …

I suppose I was already using the pulse-bridge (if we’re referring to the same thing)…

thanks

#16

Interesting. Do they also tell you why?

Pulse is perfectly fine for default desktop audio. Browers, audio/video, music players and such.
I see no reason to not use it, actually on GNU/Linux I could not think of a better solution.

It’s not suitable for pro-audio, e.g. when you need reliable sample-rate and buffersize, constant well defined low latency to record overdubs and such.

Usually apps that require both capture and playback. or applications that rely on timing from the soudcard or use alsa’s hw: API.

pulse-jack bridge can offer that too for chromium. VLC has built-in JACK support, Firefox too (but it’s not enabled in debian’s default built).

I’m curious: how’s A/V sync when you play a video in chromium with your setup compared to pulseaudio?

#17

Here I am using a custom built kernel with HZ=1000, and I’ve tuned a bunch of scheduler parameters… I set pulseaudio to realtime and I throw a bunch of kernel bootline optimizations to help in the process… I’ve previously experimented with “low-latency RT”, but that gives poor scheduling switching for regular desktop use – so this is why I’ve built a kernel with a “fixed” periodic tick rather than dynamic(which I think is the default) – I get very good performance, better than RT in terms of using this workstation for regular desktop use. I believe the people telling me pa is bad, must be that they aren’t tuning it properly, because there’s many parameters that can affect its realtime performance… Currently my setup is not that sophisticated in hardware --> I use a Pro-Audio Keyboard 88-key (a basic compliant midi device that requires no special drivers), and the audio comes out live via nvidia-hdmi which uses the snd-intel driver with jack…

“I’m curious: how’s A/V sync when you play a video in chromium with your setup compared to pulseaudio?”

Chromium/Chrome are equally stable on this system, when I look in the process list, chromium always tries to elevate its priority runs…

This system is a 4-core i5-4670K CPU @ 3.40GHz – the cpu governor is fixed for its performance profile and not on-demand… It is not a high-end cpu system, but it definitely runs a lot better with the tuneups I’ve set.

What I will not do on this system is to make it a polling cpu(-> meaning to use “idle=poll” to the kern bootline) , I probably may be able to kick up performance on this but at the cost of damaging the cpu… lol

No overclocking, just keeping things legit …

I didn’t know apps now are starting to use built-in jack support, that’s probably a feature I could look more into…
[fwiw, pulseaudio works perfect here in the trio setup
-> pulseaudio has all modules unloaded and only keeps the null sink and jackdbus

Right now I’m comparing it to how well I can run things with alsa-plugin-jack…

So far they both equally are stable but I am not running that many audio apps to know if any could be failing…

If I remember at one time, chromium and firefox can only work through pulseaudio, – I’ve been on Linux for quite some time to remember this, which is why I am so inclined to have pa working primarily…

it wasn’t until today that I finally could potentially see the dis-use or need of having pulseaudio
]

-> The thing is (and I’m sure you are well aware) --> it is MUCH easier to startup Jack with alsa-plugin-jack than it is with pulseaudio, because there wouldn’t be fighting for using the alsa device-- from experience pa’s “module-jackdbus” is very flakey here on debian, sometimes it properly lets go of the alsa device for jack, sometimes not.

On the other hand, the alsa-plugin-jack doesn’t have this as an issue which is why I bothered looking into it but it’s for the times I am not using it for advanced audio…

thanks

#18

I meant if the picture is early compared to the sound (or late)?
Can chromium know how long to delay the video to align it with audio in your .asoundrc setup?

I think you should start a new thread or rather write a blog about your system.
I’m not a fan of this forum being used to spread potentially misleading information, so here it goes:

That is usually counter-productive. It used to be a good solution in the old days before hardware had high-precision event timers. Since at least 10 years tickless kernels and HPET perform significantly better for MIDI (and audio) and modern userspace apps do not uses RTC anymore. I’d expect that you’ll find that using that 1k Hz timer actually degrades performance.

No, I’m not aware of that. I use pulse as default on debian without issues.

Could it be that this is due to your system customization? It’s just a dbus request, Ardour’s ALSA backend does the same to request when it reserves the soundcard.

That alt least worked reliably here since perhaps debian/wheezy (other pulse bugs notwithstanding). I also don’t see any related reports at https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=pulseaudio;dist=unstable

#19

I’m currently working on a small issue or two unrelated, but here I’ve been using things that are better than hpet – If your machine has “tsc” support in the core cpu, the kernel will try to use that instead of hpet. Sometimes the kernel guesses wrong and so clocksource=tsc(appended to the kernel bootline) helps the kernel choose it over another clocksource…

Here I use “skew_tick=1” to offset the tick across the cpus and the results is + for Desktop things, the question is for me to know later if this helps or going with RT. I’ve been using skew_tick=1 quite awhile and never had any problems with it(it improves afaict the Desktop response, but I do not know if this is bad for RT tasks, I will find out eventually). If HZ=1000 degrades performance? I think it would because it would be getting in the way of anything RT… But here I’m using a hybrid of RT for jackaudio/ardour and then non-RT for standard desktop apps…

^ I was using an RT tickless kernel with isolcpus keeping time-scheduling on cpu0, … and the reason why I stopped using an RT(tickess) kernel is because I didn’t like the response I was getting when working with desktop apps (the context switching between apps is much slower to the point I could be waiting 3-5 seconds to make the switch)… The reason why I have HZ=1000 is because having more ticks should be better for scheduling/context-switching between applications on a Desktop setup…But you’re right it should be degrading performance for higher-ticks when you want just 1 application running on your cpu cores at full possible speed… but then you’re using a dedicated daw station and not one hybrid-suitable for regular desktop applications.

thanks