13 Apr
2023
13 Apr
'23
8:34 p.m.
Hi folks,
I'm trying to set up a fairly minimal system as a dedicated Digital Organ.
I started with Ubuntu Mate 22.04, as that's what I normally use for my
personal systems.
During the install I requested a minimal system, no Office, etc. and
ended up with what looked OK.
However, When it came to setting up the audio side, I wanted to run
Jack(D2/DBUS) and use Qjackctl
for initial setting up. I'm hoping to dispense with Qjackctl once its
all working, though the patchbay
might keep it in. I want a system that comes up headless (normally) so
the organist just switches on,
waits for a couple of minutes for it to start, then starts playing.
I'm having great difficulty in getting Qjackctl and Jack to start
reliably, I've tried jackd2 and jackdbus
(from the standard Ubuntu repositories) and Qjackctl nearly always fails
with messages saying it can't
contact jack: 'Server communications error, plesae check the message
window for more info'.
The window then says 'Cannot read socket fd = 36 err = Success' which
seems contradictory!
If anyone can help I'd like opinions on whether I should be pushing for
jackd2 or jackdbus.
The idea is to have a startup script which starts jack, then qjackctl,
then the organ software (GrandOrgue).
So far it's a mess.
Someone must know what I need to do. I'm happy to collect any
information and report back if you can
tell me what is needed.
Many thanks in advance!
Bill
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+
13 Apr
13 Apr
9:46 p.m.
Hi Bill,
On 13/04/2023 20:34, Bill Purvis wrote:
I'm trying to set up a fairly minimal system as a
dedicated Digital Organ.
setBfree or aeolus?
I started with Ubuntu Mate 22.04, as that's what I
normally use for my personal systems.
I'm in a similar situation. I'm
working with Mint Mate and a low latency kernel
5.19.0-1017-lowlatency from the repository. Meanwhile all works well.
However, When it came to setting up the audio side, I
wanted to run Jack(D2/DBUS) and use Qjackctl
for initial setting up. I'm hoping to dispense with Qjackctl once its all working,
though the patchbay
might keep it in. I want a system that comes up headless (normally) so the organist just
switches on,
waits for a couple of minutes for it to start, then starts playing.
Headless can
you launch Non-CLI programs? I'm using jack2 and jackdbus and meanwhile all is
working
well. I have one script to launch all. SetBfree, Pianoteq and others are running as lv2
plugins in
Carla, Midi goes into Konfyt (using filter capabilities and switching of programs with
Program
Change messages) and from there into Carla. In Konfyt you can define persistent jack
connections. In
your case Konfyt might be interesting but Carla seems not to be necessary for you are only
using one
synth.
I'm having great difficulty in getting Qjackctl and Jack to start reliably, I've
tried jackd2 and
jackdbus
(from the standard Ubuntu repositories) and Qjackctl nearly always fails with messages
saying it can't
contact jack: 'Server communications error, plesae check the message window for more
info'.
The window then says 'Cannot read socket fd = 36 err = Success' which seems
contradictory!
I'm not an expert here. In the beginning I had to kill often
jackdbus if something went wrong. Are
you using internal or external sound-card? Another hint from me (but no help at the
moment) - for
low latency it was best to switch off the wifi radio. I used command
$ nmcli radio wifi off / on
within the script. That reduced the occurrence of xruns.
The idea is to have a startup script which starts
jack, then qjackctl, then the organ software
(GrandOrgue).
Ah, already the answer to my above question :-) You might find Aeolus
interesting as well.
Sorry I can't give you dedicated help for the error message. Anyway, feel free to
contact me
off-list in case anything of my setup interests you.
Gerhard
9:56 p.m.
Hi Bill,
forgotten to mention
On 13/04/2023 20:34, Bill Purvis wrote:
The idea is to have a startup script which starts
jack, then qjackctl, then the organ software
(GrandOrgue).
I looked up the GrandOrgue Screencast video at YT. The organs could run with alsa without
using jack
obviously. In that case it might be much easier to avoid jack. As long as I play only
Pianoteq at
home I don't use Jackd and latency is fine nevertheless. As long as you do not use
additional tools
of jack's ecosystem it might work for you.
Gerhard
10:31 p.m.
On Thu, 13 Apr 2023 21:56:41 +0200
Gerhard Zintel <gerhard.zintel(a)web.de> wrote:
Hi Bill,
forgotten to mention
On 13/04/2023 20:34, Bill Purvis wrote:
I was wondering about this too.
If it *is* just a single synth then ALSA is all you need, and indeed takes out
a layer of buffering. Also I'd be inclined to run a distro that doesn't have
any other unnecessary stuff. i.e. no SystemD and no pulseaudio. KISS principle.
--
Will J Godfrey {apparently now an 'elderly'}
The idea is to have a startup script which starts
jack, then qjackctl, then the organ software
(GrandOrgue).
I looked up the GrandOrgue Screencast video at YT. The organs could run with alsa without
using jack
obviously. In that case it might be much easier to avoid jack. As long as I play only
Pianoteq at
home I don't use Jackd and latency is fine nevertheless. As long as you do not use
additional tools
of jack's ecosystem it might work for you.
Gerhard 
11:42 p.m.
On Thu, Apr 13, 2023 at 09:31:34PM +0100, Will Godfrey wrote:
If it *is* just a single synth then ALSA is all you
need, and indeed takes out
a layer of buffering.
There is no additional layer of buffering when using Jack1, or Jack2
with the -S option. Latency will be exactly the same as when using
ALSA directly.
Also I'd be inclined to run a distro that
doesn't have
any other unnecessary stuff. i.e. no SystemD and no pulseaudio.
KISS principle.
That is good advice. Systemd won't affect audio performance,
but pulseaudio certainly does.
--
FA
14 Apr
14 Apr
6:25 p.m.
Hi Will,
On 13/04/2023 21:31, you wrote:
On Thu, 13 Apr 2023 21:56:41 +0200
Gerhard Zintel <gerhard.zintel(a)web.de> wrote:
I
certainly want to keep it simple, though it is a pretty complex
requirement. We have several
input devices - pedal keyboard, voicing stops, thumb pistons, etc. which
are Arduino-based and
need to be injected into the software. I already have code which can
handle these (serial tty-like
devices over USB) and can inject the MIDI events into jack, whereas my
experience with ALSA is pretty minimal.
I will certainly be getting rid of pulseaudio, and see no need to
involve SystemD.
At present I'm running with the standard Ubuntu kernel, and will see if
there is a need for the low-latency
kernel once I get it up and running.
My request was prompted by a day spent trying various things to get
Jack/Qjackctl up and running. I'm
currently running a laptop and two desktops, and had no problem getting
Jack/Qjackctl to work, but this
one seems to be testing my patience.
Thanks to everyone for comments so far.
I'm away for the weekend, will resume testing next week when I get back.
Bill
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+
Hi Bill,
forgotten to mention
On 13/04/2023 20:34, Bill Purvis wrote:
I was wondering about this too.
If it *is* just a single synth then ALSA is all you need, and indeed takes out
a layer of buffering. Also I'd be inclined to run a distro that doesn't have
any other unnecessary stuff. i.e. no SystemD and no pulseaudio. KISS principle. The idea is to have a startup script which starts
jack, then qjackctl, then the organ software
(GrandOrgue).
I looked up the GrandOrgue Screencast video at YT. The organs could
run with alsa without using jack
obviously. In that case it might be much easier to avoid jack. As long as I play only
Pianoteq at
home I don't use Jackd and latency is fine nevertheless. As long as you do not use
additional tools
of jack's ecosystem it might work for you.
Gerhard 
7:17 p.m.
On Fri, 14 Apr 2023, Bill Purvis wrote:
I will certainly be getting rid of pulseaudio, and see
no need to involve
SystemD.
Pulse is easy to get rid of, systemd not so much unless you replace it
with something else. At some point you would be using systemd if you want
something to start with no user input.
At present I'm running with the standard Ubuntu
kernel, and will see if there
is a need for the low-latency
kernel once I get it up and running.
You may wish to stop cron. Ubuntu uses cron and utilities that depend on
cron. While cron does run with nice, there seem to be some operations
ubuntu does with it that are atomic enough to disturb sound. (at least in
the past when I tested it) I have not tried softsynth operation on a
regular kernel, so I can't really say. I have found for my uses that I
could get by with higher latency with softsynth than I can with guitar
effects. I think it will depend on your keyboard player. Some of the
mechanical pipe organs had a rather long delay from keypress to sound
anyway.
--
Len Ovens
www.ovenwerks.net
11:30 p.m.
On 14/04/2023 18:17, Len Ovens wrote:
On Fri, 14 Apr 2023, Bill Purvis wrote:
Len, many thanks for above, and previous email. Some useful tips there!
Cron I can do without, no problem.
I don't expect that there will be any need to connect in during a
performance. I anticipate any remote access
I can simply use ssh to get in. If there is any real work needing to be
done I will plug in a monitor, mouse
and keyboard.
No-one has said I should go with jack-dbus, so I'll stick with jackd,
and should be able to sort things out.
I'll have to experiment with setting up headless. A worst I can always
hide a small monitor inside the case!
I have seen people running GrandOrgue on organs similar to what I'm
aiming for, with a touch screen monitor
on top of the case, so it's not absolutely essential to go headless.
Bill
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+
I will certainly be getting rid of pulseaudio,
and see no need to
involve SystemD.
Pulse is easy to get rid of, systemd not so much unless you replace it
with something else. At some point you would be using systemd if you
want something to start with no user input.
At present I'm running with the standard
Ubuntu kernel, and will see
if there is a need for the low-latency
kernel once I get it up and running.
You may wish to stop cron. Ubuntu uses cron and utilities that depend
on cron. While cron does run with nice, there seem to be some
operations ubuntu does with it that are atomic enough to disturb
sound. (at least in the past when I tested it) I have not tried
softsynth operation on a regular kernel, so I can't really say. I have
found for my uses that I could get by with higher latency with
softsynth than I can with guitar effects. I think it will depend on
your keyboard player. Some of the mechanical pipe organs had a rather
long delay from keypress to sound anyway.
12:13 a.m.
On Thu, April 13, 2023 1:34 pm, Bill Purvis wrote:
However, When it came to setting up the audio side, I
wanted to run
Jack(D2/DBUS) and use Qjackctl
for initial setting up. I'm hoping to dispense with Qjackctl once its
all working, though the patchbay
might keep it in. I want a system that comes up headless (normally) so
the organist just switches on,
waits for a couple of minutes for it to start, then starts playing.
If the system is going to be headless, I would recommend going straight to
CLI programs for manipulating connections, so you don't get sucked into
relying on a GUI tool that will then make it much more difficult to go
truly headless.
Break your problem down into bite size pieces. First make sure that jackd
or jackdbus is starting correctly. That implies someway to log output
from jackd, since presumably the final configuration will be starting
jackd from a script of some kind (systemd unit file, autostart script,
init script, ...).
I'm having great difficulty in getting Qjackctl
and Jack to start
reliably, I've tried jackd2 and jackdbus
(from the standard Ubuntu repositories) and Qjackctl nearly always fails
with messages saying it can't
contact jack: 'Server communications error, plesae check the message
window for more info'.
The window then says 'Cannot read socket fd = 36 err = Success' which
seems contradictory!
How are you starting jackd or jackdbus? Is it possible that jackd is just
not finished initializing before you started qjackctl?
If anyone can help I'd like opinions on whether I
should be pushing for
jackd2 or jackdbus.
That depends on whether you would like to use dbus to control the jack
server. If you are not using some kind of dbus control program to
manipulate the jack server I do not think it will matter which you use.
The idea is to have a startup script which starts
jack, then qjackctl,
then the organ software (GrandOrgue).
So far it's a mess.
In the archives are some threads about starting jackd automatically when
the system starts up, but I think that was using systemd unit files, not
using an automatically logged in standard user account. Getting jackd to
run without a user account logged in is an additional level of
complication you don't want to deal with.
It is not obvious from your description if you are using a script already
to start jack server, or if you started by hand, if there was already an
existing sound server running (PulseAudio or Wireplumber).
More details including output of jackd when started would help.
--
Chris
6:57 p.m.
On Thu, 13 Apr 2023, Bill Purvis wrote:
I'm trying to set up a fairly minimal system as a
dedicated Digital Organ.
I started with Ubuntu Mate 22.04, as that's what I normally use for my
personal systems.
During the install I requested a minimal system, no Office, etc. and ended up
with what looked OK.
However, When it came to setting up the audio side, I wanted to run
Jack(D2/DBUS) and use Qjackctl
Tools for cli operation:
- screen (or similar) This gives you a session that can be auto started
at boot with one or more screens that auto start something.
The bonus is that you can login via any commandline terminal
like ssh for example, and reattach to the running session for
remote trouble shooting. You could even have a curses based
menu on one screen. (or just bash menu for that matter)
- dbus-launch: If you need dbus for anything then this should be used
to start screen (or whatever you replace screen with) That way
any dbus aware programs will be talking to the same instance
of dbus. Both jackd2 and jackdbus will try to talk to dbus.
jackdbus will fail without and jackd will at least throw an error
but should still run.
= jack-tools: this is a package that installs extra jack command line
tools for dealing with jack
- jack_control: this is what you use if you are using jackdbus, it can
set parameters as well as start and stop jack or find out jack's
status
- jackd: this is the command to use to start jackd if you are using that
instead of jackdbus (I have no opinion one way or the other).
Do note that if you use this, that screen will be locked as long
as jackd is running unless it is back grouonded. Screen makes
this a non-issue and leaving it forgroound may be a helpful
trouble shooting aid.
- jack_connect: allows connecting any jack port to any other jack port
(out to in of course). This can be used manually or scripted
- jack_disconnect: Disconnect a connection from an output to an input
- jack-plumbing: Allows automating the above connections. For example
can wait for your synth to startup and when it's ports appear in
the jack graph, connect them to the output or an effect.
For a longer list, after installing jack-tools, go to your command line
and type in jack and hit tab tab (or ls /usr/bin/jack* might be safer).
You will get a list of jack utilities. Some of which you can find out more
about with man, some you can <utility> --help or -h and some (like
jack_control) you can type in with no parameters. Some of these tools (you
may have jack-keyboard for example) need X to work. Some of these tools
require dbus as well (I think).
Another thing you may like:
https://superuser.com/questions/1170136/translating-midi-input-into-compute…
This has some hints on how to use a midi input device to run commandline
stuff from certain midi inputs. It might be easier though to get one of
those usb number pads made for laptops and use that with a menu. The user
does not have to be able to see the menu provided it is only one level.
Sub menus would require some sort of display... keep it simple. You will
need to rememeber that this can not run as part of your screen session
because if you grab screen from a remote login you will loose access to it
with your keypad. The menu will need to be run at boot time as some other
user than root (same for screen, jackd does not run well as root)
--
Len Ovens
www.ovenwerks.net
15 Apr
15 Apr
1:33 p.m.
On Thu, Apr 13, 2023, Bill Purvis wrote:
I'm trying to set up a fairly minimal system as a
dedicated Digital Organ.
Several have mentioned avoiding systemd and pulseaudio.
Ubuntu is based on debian and devuan(*1) is debian without
systemd. So deuvan might be an easy way to go. FWIW grandorgue
installed fine in in my devuan daedalus (bookworm) system.
Produced good sound through the ALSA device. I didn't test it
under jack.
1. https://devuan.org
--
Joel Roth
3:28 p.m.
On Sat, 15 Apr 2023 01:33:15 -1000
Joel Roth <joelz(a)pobox.com> wrote:
On Thu, Apr 13, 2023, Bill Purvis wrote:
FWIW I've been using devuan since it came out. The only problem I've ever
had
was with my own fat-fingering. Currently I have it on all the following:
AMD Ryzen 5 - used exclusively for music creation.
Quite old Intel based laptop - general purpose when travelling.
Slightly newer Intel desktop - development/office stuff/these lists :)
Raspberry Pi 4b - mostly music creation.
--
Will J Godfrey {apparently now an 'elderly'}
https://willgodfrey.bandcamp.com/
http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
I'm trying to set up a fairly minimal system
as a dedicated Digital Organ.
Several have mentioned avoiding systemd and pulseaudio.
Ubuntu is based on debian and devuan(*1) is debian without
systemd. So deuvan might be an easy way to go. FWIW grandorgue
installed fine in in my devuan daedalus (bookworm) system.
Produced good sound through the ALSA device. I didn't test it
under jack.
1. https://devuan.org
582
days inactive
584
days old
linux-audio-user@lists.linuxaudio.org
11 comments
7 participants
participants (7)
-
Bill Purvis -
Chris Caudle -
Fons Adriaensen -
Gerhard Zintel -
Joel Roth -
Len Ovens -
Will Godfrey