I’m running Ardour 2.8.12 on U. Studio. Selection of “mute” for a given track or bus is non-functional. This was reported on an earlier version of Ardour on U. Studio, and pursuant to that bug report, I checked the ardour.rc file in the home directory. All appeared correct in there, as:
FWIW I’m running the Debian testing package of 2.8.16 and it works fine. Those lines appear in .ardour2/ardour.rc (I’m guessing you have the correct XML syntax but the forum software refuses to display it).
What happens if you delete .ardour2/ardour.rc (after copying) and start again with the defaults?
But as far as I can tell, these are the defaults - I’ve not mucked about with much of the internal Ardour functions. It’s interesting that this snippet uses “yes”, whereas the earlier discussion regarding the file used ‘0’ and ‘1’, tho’ that might just be a syntax change. I experimented with changing a ‘yes’ to ‘1’, but the file was reloaded on restart with the defaults and the mod wasn’t preserved.
I’d forgotten about that syntax change. 2.8.12 is pretty old now. What happens if you change the “yes” to 1 in the system rc file (/etc/ardour2/ardour_system.rc here)?
Not precisely, Seablade. I’d gotten some new studio hardware this summer and experimented with the Harrison Mixbus platform. I spent four months severely frustrated by assorted hums and buzzes and general lack of audio clarity, and eventually I tossed the Harrison and opened Ardour alone and all the problems were gone. I know other folks have had good experiences with Harrison, but I certainly haven’t, and after losing four months of recording time, I’m a wee bit hesitant to upgrade and risk whatever dependecy issues might rear their heads.
thats really bizare that mixbus would cause hums and buzes.
hums and buzes are almost always from ground loops. the dead givaway is the hum being at the same frequency of your electricity supply (50hz or 60hz )
cant help you any on this unfortunatly as i dont use ardour 2 but back when i did i dont recall having any issues with mutting.
anyway if your projects dont contain much editing, ie they have jus tbeen recorded, id check out ardour 3. you can have it installed side by side so you can always go back. Ardour should save a backup but make a backup to be safe.
ive loaded up several simple projects in 3 that were started in 2 with little issues. some settings may be lost but the features in 3 make it worthwhile.
cant help you any on this unfortunatly as i dont use ardour 2 but back when i did i dont recall having any issues with mutting.
This was an issue that I am fairly certain I remember rearing it’s head between 2.8.12 and 2.8.14 IIRC. It had to do with XML parsing, as was suggested above.
Not precisely, Seablade. I'd gotten some new studio hardware this summer and experimented with the Harrison Mixbus platform. I spent four months severely frustrated by assorted hums and buzzes and general lack of audio clarity, and eventually I tossed the Harrison and opened Ardour alone and all the problems were gone. I know other folks have had good experiences with Harrison, but I certainly haven't, and after losing four months of recording time, I'm a wee bit hesitant to upgrade and risk whatever dependecy issues might rear their heads.
Well a couple of things…
One, you can download the packages for A3, or even a nightly from this site. They can be installed in parallel with existing installs and are easy to remove. They will install into their own directory in /opt IIRC and I would highly recommend trying out a more modern version or Ardour, as I said, make a backup of your session file first.
Two, Mixbus causing hums and buzzes is beyond strange, and likely a coincidence I suspect with something else going wrong in your setup. Mixbus really IS Ardour, with some UI tweaks and customizations, and their own DSP on top of that. I don’t think I have ever heard of anyone having their DSP fail in a way to cause a hum or buzz, I suppose other plugins might though. And as others have said, did you try to contact Harrison about the issue at all?
Well, you’re all perfectly correct - the idea that the Harrison gui caused some sort of audio glitch is absolutely counter-intuitive, which is why I spent months trying to figure it out. I did indeed find some signal chain issues that I corrected, I did a ton of experiments with mic placements and such, and as I live in Alaska, I’d be the first to suggest some issues around dirty power (I tried the set-up in every room in the house and with the entire fuse-box turned off except the relevant room). I’m sure a good sound engineer who is familiar with the code could pinpoint the issue, but opening the tracks in Ardour instead of Harrison was remarkable, like water in the desert, and QUIET. I didn’t contact Harrison, though.
But the idea of doing a separate build of 3 from the source is a good one - I’ll check that out and report back. Thanks!!!
No need to do a separate build from source necessarily(And if you do one, don’t install it, just run it with ardev). Likely easier to download from this site, though if you are not a financial supporter then you may want to build to get the ability to save plugin settings. Make sure you back up your session file though.
I went ahead and bought a download of 3.5.403 and it looks most excellent indeed!! It’s not playing well with JACK, though, which is a wee bit confusing. It appears that starting Ardour also starts an instance of JACK, but the engine can’t detect it. If I begin JACK first (as I usually do), the Ardour start returns:
[ERROR] JACK: Cannot set scheduling priority for RT thread res = 22
[ERROR] JACK: Cannot use real-time scheduling (RR/-4)(22:Invalid argument)
[ERROR] JACK: JackClient::AcquireSelfRealTIME error
I’m running jackd2 1.9.8; 1.9.10 is available, but I’m not imagining updating the jack engine would fix this.
For both installations of Ardour, I got the warning regarding frequency scaling, but haven’t ever been able to turn it off successfully.
Sorry to post a basic install issue on this thread…
I would be curious to see the output out of Jack then, something is odd then. That error indicates you not having realtime permissions set up correctly. Can you start it on the command line with the appropriate flags and copy and paste the output here surrounded by CODE tags?
I confess to some puzzlement myself - attempting to start jack from the terminal with ~$ jackd -[options] -v produces nothing other than a list of options:
~$ jackd -R -alsa -r44100 p1024 -v
jackdmp 1.9.8
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2011 Grame.
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
usage: jackdmp [ --no-realtime OR -r ]
[ --realtime OR -R [ --realtime-priority OR -P priority ] ]
(the two previous arguments are mutually exclusive. The default is --realtime)
[ --name OR -n server-name ]
[ --timeout OR -t client-timeout-in-msecs ]
[ --loopback OR -L loopback-port-number ]
[ --port-max OR -p maximum-number-of-ports]
[ --slave-backend OR -X slave-backend-name ]
[ --internal-client OR -I internal-client-name ]
[ --verbose OR -v ]
[ --clocksource OR -c [ c(ycle) | h(pet) | s(ystem) ]
[ --replace-registry ]
[ --silent OR -s ]
[ --sync OR -S ]
[ --temporary OR -T ]
[ --version OR -V ]
-d master-backend-name [ … master-backend args … ]
Available master backends may include: alsa, dummy, freebob, firewire, net or netone.
jackdmp -d master-backend-name --help
to display options for each master backend
Recent versions of jack2 start with realtime priority by default, so the -R is actually redundant. As Seablade says, it looks like you don’t have realtime permissions set up for the user running jackd. Is the user in audio group?
Absolutely - I’ve not had any of these issues with the earlier version of Ardour (just the mute ones), and the user was included in the audio group. I also noticed that in opening Ardour, my firewire driver is not present as an option, meaning I can’t detect my Presonus digital-analog interface. Is this connected with the RT issue? The output below includes the line “create non RT thread”
I did notice a line in the /etc/security/limits.d/audio.conf file, replicated in the usr/share/jackd/audio.conf file (essentially the same file):
If you want to enable/disable realtime permissions, run
dpkg-reconfigure -p high jackd
So I did that, and using the proper syntax in the termial (thanks, jrigg!):
~$ jackd -v -R -d alsa -r44100 -p1024
jackdmp 1.9.8
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2011 Grame.
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 10
Jack: Create non RT thread
Jack: ThreadHandler: start
Jack: apparent rate = 44100
Jack: frames per period = 1024
Jack: JackDriver::Open capture_driver_name = hw:0
Jack: JackDriver::Open playback_driver_name = hw:0
Jack: Check protocol client = 8 server = 8
Jack: JackEngine::ClientInternalOpen: name = system
Jack: JackEngine::AllocateRefNum ref = 0
Jack: JackPosixSemaphore::Allocate name = jack_sem.1000_default_system val = 0
Jack: JackEngine::NotifyAddClient: name = system
Jack: JackGraphManager::SetBufferSize size = 1024
Jack: JackConnectionManager::DirectConnect first: ref1 = 0 ref2 = 0
Jack: JackGraphManager::ConnectRefNum cur_index = 0 ref1 = 0 ref2 = 0
Jack: JackDriver::SetupDriverSync driver sem in flush mode
control device hw:0
control device hw:0
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
Jack: JackSocketServerChannel::Open
Jack: Bind: addr.sun_path /dev/shm/jack_default_1000_0
Jack: JackSocketServerChannel::BuildPoolTable size = 1
Jack: JackEngine::Open
Jack: Connect: addr.sun_path /dev/shm/jack_default_1000_0
Jack: JackEngine::ClientInternalOpen: name = freewheel
Jack: JackEngine::AllocateRefNum ref = 1
Jack: JackPosixSemaphore::Allocate name = jack_sem.1000_default_freewheel val = 0
Jack: JackEngine::NotifyAddClient: name = freewheel
Jack: JackDriver::ClientNotify ref = 1 driver = system name = freewheel notify = 0
Jack: JackDriver::ClientNotify ref = 0 driver = freewheel name = system notify = 0
Jack: JackConnectionManager::DirectConnect first: ref1 = 1 ref2 = 1
Jack: JackGraphManager::ConnectRefNum cur_index = 0 ref1 = 1 ref2 = 1
Jack: JackDriver::SetupDriverSync driver sem in flush mode
Jack: JackGraphManager::SetBufferSize size = 1024
Jack: JackAlsaDriver::Attach fBufferSize 1024 fSampleRate 44100
Jack: JackEngine::PortRegister ref = 0 name = system:capture_1 type = 32 bit float mono audio flags = 22 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 1 name = system:capture_1 type = 32 bit float mono audio
Jack: JackConnectionManager::AddOutputPort ref = 0 port = 1
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fCapturePortList[i] 1
Jack: JackEngine::PortRegister ref = 0 name = system:capture_2 type = 32 bit float mono audio flags = 22 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 2 name = system:capture_2 type = 32 bit float mono audio
Jack: JackConnectionManager::AddOutputPort ref = 0 port = 2
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fCapturePortList[i] 2
Jack: JackEngine::PortRegister ref = 0 name = system:playback_1 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 3 name = system:playback_1 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 3
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 3
Jack: JackEngine::PortRegister ref = 0 name = system:playback_2 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 4 name = system:playback_2 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 4
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 4
Jack: JackEngine::PortRegister ref = 0 name = system:playback_3 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 5 name = system:playback_3 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 5
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 5
Jack: JackEngine::PortRegister ref = 0 name = system:playback_4 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 6 name = system:playback_4 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 6
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 6
Jack: JackEngine::PortRegister ref = 0 name = system:playback_5 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 7 name = system:playback_5 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 7
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 7
Jack: JackEngine::PortRegister ref = 0 name = system:playback_6 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 8 name = system:playback_6 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 8
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 8
Jack: JackEngine::PortRegister ref = 0 name = system:playback_7 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 9 name = system:playback_7 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 9
Jack: JackEngine::PortRegister ref = 0 name = system:playback_8 type = 32 bit float mono audio flags = 21 buffer_size = 1024
Jack: JackGraphManager::AllocatePortAux port_index = 10 name = system:playback_8 type = 32 bit float mono audio
Jack: JackConnectionManager::AddInputPort ref = 0 port = 10
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackEngine::NotifyClient: no callback for event = 9
Jack: JackAlsaDriver::Attach fPlaybackPortList[i] 10
Jack: Clock source : system clock via clock_gettime
Jack: JackServer::Start
Jack: JackThreadedDriver::Start
Jack: Create non RT thread
Jack: ThreadHandler: start
Jack: JackThreadedDriver::Init real-time
Jack: JackPosixThread::AcquireRealTimeImp priority = 10
Jack: Create non RT thread
Jack: ThreadHandler: start
Jack: JackSocketServerChannel::ClientCreate socket
Jack: JackSocketServerChannel::BuildPoolTable size = 2
Jack: fSocketTable i = 1 fd = 9
Jack: fPollTable i = 1 fd = 9
I got the warning regarding frequency scaling, but haven’t ever been able to turn it off successfully.
If you can’t turn it off in BIOS settings, cpufrequtils should work on recent Debian-based systems. Make sure cpufrequtils package is installed, then in /etc/default/cpufrequtils (create the file if it doesn’t already exist) make sure there’s a line saying GOVERNOR=“performance” .
(I’m not sure if your version of Ubuntu is recent enough to use this - if not you might have to recompile the kernel with frequency scaling disabled in the config).