26 Mar
2020
26 Mar
'20
8:33 p.m.
Greetings once more,
The 'Vee One Suite' of so called 'old-school' software instruments,
synthv1 [1] as a polyphonic subtractive synthesizer, samplv1 [2] a
polyphonic sampler synthesizer, drumkv1 [3] as yet another drum-kit
sampler and padthv1 [4] as a polyphonic additive synthesizer, are all
being released now for the second 'QStuff*' Spring'20 batch of the
(quarantine) season.
All still available in dual form deliveries:
- a pure stand-alone JACK client with JACK-session [5], NSM (Non Session
management [6]) and both JACK MIDI and ALSA MIDI [7] input support;
- a LV2 instrument plug-in [8].
Not much of a ravishing change-log, just on the brink of utterly boring
maintenance stuff:
- Always keep the current sample loop-cycle on note-off, while entering
a DCA Release stage. (applies to samplv1 [2] only)
- Maximum pitch-bend range has been expanded to 0..400%, allegedly to
support some PME driven instruments.
- Make man page compression reproducible (after request by Jelle van der
Waa, thanks).
- Fixed crash when showing the tooltip of a negative note number that
results from dragging over and beyond the left edge of the virtual piano
keyboard.
- Remove -v (verbose) flag from 'strip' post-link command.
- Fixed CMake build by adding missing Custom Color Theme (palette) form
file (.ui).
- Bumped copyright headers into the New Year (2020).
The 'Vee One Suite' are free, open-source Linux Audio [10] software,
distributed under the terms of the GNU General Public License (GPL) [11]
version 2 or later.
**synthv1 - an old-school polyphonic synthesizer [1] **
synthv1 0.9.13 (spring'20) released!
synthv1 is an old-school all-digital 4-oscillator subtractive
polyphonic synthesizer with stereo fx.
LV2 URI: http://synthv1.sourceforge.net/lv2
website:
https://synthv1.sourceforge.io
http://synthv1.sourceforge.net
project page:
https://sourceforge.net/projects/synthv1
downloads:
https://sourceforge.net/projects/synthv1/files
- source tarball:
https://download.sf.net/synthv1/synthv1-0.9.13.tar.gz
- source package:
https://download.sf.net/synthv1/synthv1-0.9.13-53.rncbc.suse.src.rpm
- binary packages (openSUSE Tumbleweed):
https://download.sf.net/synthv1/synthv1-0.9.13-53.rncbc.suse.x86_84.rpm
https://download.sf.net/synthv1/synthv1-lv2-0.9.13-53.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
https://download.sf.net/synthv1/synthv1-0.9.13-53.x86_64.AppImage
git repos:
https://git.code.sf.net/p/synthv1/code
https://github.com/rncbc/synthv1.git
https://gitlab.com/rncbc/synthv1.git
https://bitbucket.org/rncbc/synthv1.git
**samplv1 - an old-school polyphonic sampler [2]**
samplv1 0.9.13 (spring'20) released!
samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.
LV2 URI: http://samplv1.sourceforge.net/lv2
website:
https://samplv1.sourceforge.io
http://samplv1.sourceforge.net
project page:
https://sourceforge.net/projects/samplv1
downloads:
https://sourceforge.net/projects/samplv1/files
- source tarball:
https://download.sf.net/samplv1/samplv1-0.9.13.tar.gz
- source package:
https://download.sf.net/samplv1/samplv1-0.9.13-53.rncbc.suse.src.rpm
- binary package (openSUSE Tumbleweed):
https://download.sf.net/samplv1/samplv1-0.9.13-53.rncbc.suse.x86_84.rpm
https://download.sf.net/samplv1/samplv1-lv2-0.9.13-53.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
https://download.sf.net/samplv1/samplv1-0.9.13-53.x86_64.AppImage
git repos:
https://git.code.sf.net/p/samplv1/code
https://github.com/rncbc/samplv1.git
https://gitlab.com/rncbc/samplv1.git
https://bitbucket.org/rncbc/samplv1.git
**drumkv1 - an old-school drum-kit sampler [3]**
drumkv1 0.9.13 (spring'20) released!
drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx.
LV2 URI: http://drumkv1.sourceforge.net/lv2
website:
https://drumkv1.sourceforge.io
http://drumkv1.sourceforge.net
project page:
https://sourceforge.net/projects/samplv1
downloads:
https://sourceforge.net/projects/drumkv1/files
- source tarball:
https://download.sf.net/drumkv1/drumkv1-0.9.13.tar.gz
- source package:
https://download.sf.net/drumkv1/drumkv1-0.9.13-43.rncbc.suse.src.rpm
- binary package (openSUSE Tumbleweed):
https://download.sf.net/drumkv1/drumkv1-0.9.13-43.rncbc.suse.x86_84.rpm
https://download.sf.net/drumkv1/drumkv1-lv2-0.9.13-43.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
https://download.sf.net/drumkv1/drumkv1-0.9.13-53.x86_64.AppImage
git repos:
https://git.code.sf.net/p/drumkv1/code
https://github.com/rncbc/drumkv1.git
https://gitlab.com/rncbc/drumkv1.git
https://bitbucket.org/rncbc/drumkv1.git
**padthv1 - an old-school polyphonic additive synthesizer [4]**
padthv1 0.9.13 (spring'20) released!
padthv1 is an old-school polyphonic additive synthesizer with stereo fx.
padthv1 is based on the PADsynth algorithm by Paul Nasca, as a special
variant of additive synthesis.
LV2 URI: http://padthv1.sourceforge.net/lv2
website:
http://padthv1.sourceforge.net
https://padthv1.sourceforge.io
project page:
https://sourceforge.net/projects/padthv1
downloads:
https://sourceforge.net/projects/padthv1/files
- source tarball:
https://download.sf.net/padthv1/padthv1-0.9.13.tar.gz
- source package:
https://download.sf.net/padthv1/padthv1-0.9.13-53.rncbc.suse.src.rpm
- binary package (openSUSE Tumbleweed):
https://download.sf.net/padthv1/padthv1-0.9.13-53.rncbc.suse.x86_84.rpm
https://download.sf.net/padthv1/padthv1-lv2-0.9.13-53.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
https://download.sf.net/padthv1/padthv1-0.9.13-53.x86_64.AppImage
git repos:
https://git.code.sf.net/p/padthv1/code
https://github.com/rncbc/padthv1.git
https://gitlab.com/rncbc/padthv1.git
https://bitbucket.org/rncbc/padthv1.git
References:
[1] synthv1 - an old-school polyphonic synthesizer
https://synthv1.sourceforge.io
http://synthv1.sourceforge.net/
[2] samplv1 - an old-school polyphonic sampler
https://samplv1.sourceforge.io
http://samplv1.sourceforge.net/
[3] drumkv1 - an old-school drum-kit sampler
https://drumkv1.sourceforge.io
http://drumkv1.sourceforge.net/
[4] padthv1 - an old-school polyphonic additive synthesizer
https://padthv1.sourceforge.io
http://padthv1.sourceforge.net/
[5] JACK Audio Connection Kit
https://jackaudio.org/
[6] NSM, Non Session Management
http://non.tuxfamily.org/nsm/
[7] ALSA, Advanced Linux Sound Architecture
https://www.alsa-project.org/
[8] LV2, Audio Plugin Standard, the extensible successor of LADSPA
http://lv2plug.in/
[9] AppImage, Linux apps that run anywhere
https://appimage.org/
[10] Linux Audio consortium of libre software for audio-related work
https://linuxaudio.org
[11] GNU General Public License
https://www.gnu.org/copyleft/gpl.html
See also:
https://www.rncbc.org/drupal/node/2076
Enjoy && Stay safe!
--
rncbc aka. Rui Nuno Capela
rncbc(a)rncbc.org
28 Mar
28 Mar
9:39 p.m.
New subject: Looking for some jackd debugging help
Hello audio developers,
I have been working slowly on a port of a radio automation system I
originally wrote for OSX to a more general, cross-platform design using
jack-audio and gstreamer instead of Apple's Core audio API. As part of
the design change, I have separated the mix-engine and media handling
into separate processes, where the mixer forks media players, which
connect back the core mixer via jack, then are disconnected by the
mixer when finished, prior to the media player instance shutting down.
It appears to me that there is a problem with jackd crashing after a
day or two of the core mixer (arServer4) running new media player
clients, connecting, disconnecting, and then quitting, as music is
loaded and played in a test automation scenario, on an Ubuntu 19.10
test setup. I have been debugging both the core-mixer programs and the
the media players over the course of the last few months. I don't see
any memory leaks any more, and all thread safety issues appear to have
been resolved. I am not calling jack calls in the real-time render
thread that are not intended for use in that thread. All jack client
client call backs are handles through a message queue, so they to are
also safe. All other jack calls are protected by a thread
lock. Again, my programs are not crashing, jackd is. And nothing
crashes for weeks when I keep one media player connected to my core-
mixer, playing the same file over and over. So it really does appear
to be the connections and disconnections that are causing the
trouble. As a side note, Carla is also crashing, but about 3 time more
often than jackd is.
Here is what I get from my arServer4 core-mixer program's stderr
(registered to jackd as "ars9550"), just before the jack-server
shutdown call back fires off:
Cannot read socket fd = 7 err = Success
CheckRes error
JackSocketClientChannel read fail
SuspendRefNum error
JackClient::Execute error name = ars9550
Server is not running
I am running jackd in a shell so I can watch it crash, and it just
appears to just die after a few days... no special messages.
jackd -v yields:
jackdmp 1.9.12
[copyright stuff...]
Which, even though it is version 1.9.12, I believe is a jack2 server
correct? This is supposed to support live client connection and
disconnection, so I don't think I am doing anything wrong.
I would like to run jackd in gdb so I can see where it is failing, but
I am unsure how to build it without breaking my system's installed jack
package, which is of course built without debugging enabled.
Any help would be appreciated.
Ethan Funk
Audiorack4 project hosted at:
https://github.com/eafunk/audiorack
29 Mar
29 Mar
1:35 p.m.
New subject: Looking for some jackd debugging help
On Sat, Mar 28, 2020 at 12:38:46PM -0700, Ethan Funk wrote:
I have been working slowly on a port of a radio
automation system I
originally wrote for OSX to a more general, cross-platform design using
jack-audio and gstreamer instead of Apple's Core audio API. As part of
the design change, I have separated the mix-engine and media handling
into separate processes, where the mixer forks media players, which
connect back the core mixer via jack, then are disconnected by the
mixer when finished, prior to the media player instance shutting down.
This *should* work of course, but I'm wondering why things are done
that way. In a 'real' studio, would you disconnect and remove e.g.
a CD player after each track, and install a new one for the next
track ?
The simple alternative is to have a fixed number of players running
all the time, and just outputting silence when not playing a track.
Whenever you need to play a track, find and idle player and use it.
But as said, your approach should just work. I'm not yet convinced
this is a Jack problem. I've had much more complex systems (with
tens of jack clients coming and going and hundreds of ports)
running for months.
I am not calling jack calls in the real-time render
thread that are not intended for use in that thread.
Which ones are you calling there ? Normally there is no need
at all to call Jack from the its own process() callback.
All jack client client call backs are handles through
a message queue,
Except for process() I hope. Which other callbacks are you
using ?
So it really does appear to be the connections and
disconnections that are causing the trouble.
Yes.
Here is what I get from my arServer4 core-mixer
program's stderr
(registered to jackd as "ars9550"), just before the jack-server
shutdown call back fires off:
What happens just before that, that would trigger a crash ?
In other words, does this happen when you call Jack for any
reason (e.g. connect or disconnect), or just by itself ?
Cannot read socket fd = 7 err = Success
CheckRes error
JackSocketClientChannel read fail
SuspendRefNum error
JackClient::Execute error name = ars9550
Server is not running
I'm not familiar with the Jack2 code, so I've no idea what
that could mean.
I would like to run jackd in gdb so I can see where it
is failing, but
I am unsure how to build it without breaking my system's installed jack
package, which is of course built without debugging enabled.
You could also try Jack1 instead. Note that this has its own problems,
in particular when connections are changing all the time -- it tends
to run clients out of order, which depending on the application may
go unnoticed, or be a serious problem.
Any help would be appreciated.
Sorry, I can't help more...
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
9:59 p.m.
New subject: Looking for some jackd debugging help
On Sun,
2020-03-29 at 11:35 +0200, Fons Adriaensen wrote:
This *should* work of course, but I'm wondering why things are
donethat way. In a 'real' studio, would you disconnect and remove
e.g.a CD player after each track, and install a new one for the
nexttrack ?
In a real studio of old, mixers had 16, 32, and some times more
stereo inputs, with a dedicated input for each of your 3 cart
machines, 3 CD players, 2 turn tables, 4 microphones, two or more
phone callers, 2 network feeds, RPU remote, a tape deck, and so
on. Huge mixers, with just a few channels used at a time. Why so
many channels? Because DJs are not technicians, and can't be trusted
to be allowed to change the mixer input configuration, even though
they are only using a few channels at a time, some time just two
channels as they segue between songs.
With a computer replacing the mixer entirely, I still have all sorts
of audio sources: some live like microphones and turn tables, some
virtual like audio file players, network streams, and SIP phone
sources. And additionally sources like a jack source coming out of
some other program. Keeping the media handling as separate programs
allows the core-mixer to have a relative small number of inputs, 8 by
default. Extra live inputs associated with physical audio device
inputs and be added when needed, then unloaded when done. Use 1 live
guest mic, or three if needed. Sources are treated as an abstrcation,
allowing all different types of sources to be used now, and ones not
thought of now, in the future. As long as you never need more than 8
sources running at once, your good. Pre-loading takes you back to
needing a lot of inputs for every possible source you could ever use,
most of which are used only occasionally.
I am not
calling jack calls in the real-time renderthread that
are not intended for use in that thread.
Which ones are you calling there ? Normally there is no needat all
to call Jack from the its own process() callback.
All jack client client call backs are handles
througha message
queue,
Except for process() I hope. Which other callbacks are youusing ? So it
really does appear to be the connections anddisconnections
that are causing the trouble.
Yes.
Here is what I get from my arServer4 core-mixer
program's
stderr(registered to jackd as "ars9550"), just before the jack-
servershutdown call back fires off:
What happens just before that, that would trigger a crash ?In other
words, does this happen when you call Jack for anyreason (e.g.
connect or disconnect), or just by itself ? You could also try Jack1 instead. Note that this
has its own
problems,in particular when connections are changing all the time
-- it tendsto run clients out of order, which depending on the
application maygo unnoticed, or be a serious problem.
Jack1 specifically doesn't provide glitch-less jack connection
changes, so that is not an option.
14 Jun
14 Jun
2:23 a.m.
New subject: Looking for some jackd debugging help
I was wrong in my thinking that jackd had a stability problem. After
spending (wasting) a lot of time troubleshooting jackd, a jackd crash
finally occurred while I was siting in front of the machine, and I
noticed that I lost the mouse and keyboard too for about 10 seconds.
So this whole time, the trouble has been flaky USB hardware on the
motherboard, not jackd.
Testing on a new computer has been flawless, for going on two weeks
now.
That leads me to a question regarding Ubuntu Studio Control, which I
have been using to manage jackd and additional audio interfaces via
zita-a2j. I have Ubuntu Studio Control configured to use a Tascam US-
4x4 as the main audio interface with 128 sample process frames at a 48
kHz sample rate on my test machine, with the built-in audio port on the
motherboard as a a2j/j2a bridge. Audio to and from the motherboard
interface is broken up with the zita-a2j and zita-j2a running as
launched by Ubuntu Studio Control. Notably, the -p run option is set to
64. If I run zita-a2j myself with -p set nice and high, to 1024 for
example, I get good clean audio, at the expense of latency on that
interface. That's fine for me, since I still have good, low latency on
the main interface. Does any one know where I can find the source code
for Ubuntu Studio Control so I can investigate a fix to make this
settable?
Thanks,
Ethan Funk
4:12 a.m.
New subject: Looking for some jackd debugging help
On Sat, 13 Jun 2020, Ethan Funk wrote:
That leads me to a question regarding Ubuntu Studio
Control, which I have been
using to manage jackd and additional audio interfaces via zita-a2j. I have Ubuntu
Studio Control configured to use a Tascam US-4x4 as the main audio interface with
128 sample process frames at a 48 kHz sample rate on my test machine, with the
built-in audio port on the motherboard as a a2j/j2a bridge. Audio to and from the
motherboard interface is broken up with the zita-a2j and zita-j2a running as
launched by Ubuntu Studio Control. Notably, the -p run option is set to 64. If I
run zita-a2j myself with -p set nice and high, to 1024 for example, I get good
clean audio, at the expense of latency on that interface. That's fine for me,
since I still have good, low latency on the main interface. Does any one know
where I can find the source code for Ubuntu Studio Control so I can investigate a
fix to make this settable?
-controls is written in python and so easy to change. You can view the
source directly by looking at /usr/bin/autojack. Zita-ajbridge has the
buffer to 1/2 that of jack... but that is proving to be a problem in some
cases. Internal should be at least 128 and hdmi should be 4096. The git
repo is https://github.com/ovenwerks/studio-controls (it has been
"unbranded" so other distros can feel free to use it)
This is a relatively new project and so is very much not bug free. Being
able to directly set buffer size for each device used sounds very much
like a reasonable feature request. (also a feature that has been thought
of before)
Be aware that autojack runs from session start and because of the way some
DEs use systemd/logind to start sessions... the session never really ends
so a reboot or a killall autojack may be needed to see how changes do. I
would suggest running autojack in a terminal while testing new code so
that you have access to terminal output. once you have finished with the
code running studio-controls should restart it in the background again if
you have closed the terminal.
--
Len Ovens
www.ovenwerks.net
5:07 a.m.
New subject: Looking for some jackd debugging help
Thanks. I found autojack, and know just enough Python to make some
sense of it. I am still confused as to where autojack is getting the
64 value. I easily found...
procin =
subprocess.Popen( ["/usr/bin/zita-a2j", "-j",
f"{ldev}-in", "-d", f"hw:{ldev}", "-r", dsr,
"-p",
def_config['ZFRAME'], "-n",
def_config['PERIOD'],
"-c", "100"], shell=False)
...which would seem to pull the -p parameter from the def_config array.
And I see that it's default value is 512, set early on in the code.
However, I assume this value is over ridden by my saved session setting
of 128 at some point when the code gets going. Where is the 64 coming
from? Maybe ZFRAME is set by the GUI to half frames?
In some ways Python does make life easier than C. I can just edit the
file with a "* 2" or "* 4", log out and back in again and go. I
assume
you are part of the group of people behind this project... so thank
you!
-Ethan
On Sat, 2020-06-13 at 17:12 -0700, Len Ovens wrote:
On Sat, 13 Jun 2020, Ethan Funk wrote:
That leads me to a question regarding Ubuntu
Studio Control, which
I have beenusing to manage jackd and additional audio interfaces
via zita-a2j. I have UbuntuStudio Control configured to use a
Tascam US-4x4 as the main audio interface with128 sample process
frames at a 48 kHz sample rate on my test machine, with thebuilt-in
audio port on the motherboard as a a2j/j2a bridge. Audio to and
from themotherboard interface is broken up with the zita-a2j and
zita-j2a running aslaunched by Ubuntu Studio Control. Notably, the
-p run option is set to 64. If Irun zita-a2j myself with -p set
nice and high, to 1024 for example, I get goodclean audio, at the
expense of latency on that interface. That's fine for me,since I
still have good, low latency on the main interface. Does any one
knowwhere I can find the source code for Ubuntu Studio Control so I
can investigate afix to make this settable?
-controls is written in python and so easy to change. You can view
the source directly by looking at /usr/bin/autojack. Zita-ajbridge
has the buffer to 1/2 that of jack... but that is proving to be a
problem in some cases. Internal should be at least 128 and hdmi
should be 4096. The git repo is
https://github.com/ovenwerks
id="-x-evo-selection-start-marker">/studio-controls (it has been
"unbranded" so other distros can feel free to use it)
This is a relatively new project and so is very much not bug free.
Being able to directly set buffer size for each device used sounds
very much like a reasonable feature request. (also a feature that has
been thought of before)
Be aware that autojack runs from session start and because of the way
some DEs use systemd/logind to start sessions... the session never
really ends so a reboot or a killall autojack may be needed to see
how changes do. I would suggest running autojack in a terminal while
testing new code so that you have access to terminal output. once you
have finished with the code running studio-controls should restart it
in the background again if you have closed the terminal.
--Len Ovenswww.ovenwerks.net
_______________________________________________Linux-audio-dev
mailing listLinux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
5:42 a.m.
New subject: Looking for some jackd debugging help
On Sat, 13 Jun 2020, Ethan Funk wrote:
Thanks. I found autojack, and know just enough Python
to make some sense of it. I
am still confused as to where autojack is getting the 64 value. I easily found...
procin = subprocess.Popen(
["/usr/bin/zita-a2j", "-j",
f"{ldev}-in", "-d", f"hw:{ldev}",
"-r", dsr, "-p", def_config['ZFRAME'],
"-n", def_config['PERIOD'], "-c",
"100"], shell=False)
...which would seem to pull the -p parameter from the def_config array. And I see
that it's default value is 512, set early on in the code. However, I assume this
value is over ridden by my saved session setting of 128 at some point when the
code gets going. Where is the 64 coming from? Maybe ZFRAME is set by the GUI to
half frames?
ubuntustudio-controls sets zframe to jack frame divided by 2. This is what
the man apge suggests (or maybe a coversation in the mailing list). So, in
$HOME/.config/autojack/autojackrc you will find that frame = 1024 and
zframe = 512 by default. You can change the value in this file to whatever
you want and tell jack to restart and it will pick it up. The next version
of -controls will need to handle this better.
I am glad you are finding it useful. It started as a "quick" script in
bash to set things up for my own use. Other people asked to be able to use
it and here we are.
--
Len Ovens
www.ovenwerks.net
24 Sep
24 Sep
1:45 a.m.
New subject: zita-a2j and zita-j2a zombie processes
I am using ubuntustudio-controls (and thus autojack) to manage multi-
USB audio interface scenarios as I continue to test my radio automation
software port/upgrade. I am seeing a weird problem over weeks of
operation where every few days a bunch of new zombie processes show up.
The original zita-j2a and a2j processes that autojack started are
still running, so this is not autojack restarting something. The
zombies are all a child of autojack. So best I can figure, autojack is
not detaching it's processes, or checking for process cleanup (some
python equivalent to fork/exec and wait/ join). But why are these
being spawned in the first place?
Or maybe I am misdiagnosing, and this isn't autojack related?
I wouldn't care, except after about a month, the process list gets full
enough that Ubuntu (20.04) can't run any new processes. This is
critical to my automation system, which creates and destroys player
processes as new audio items are loaded, played, and completed.
Any insight would be appreciated.
Thanks,
Ethan Funk
https://github.com/eafunk/audiorack
1:14 p.m.
New subject: zita-a2j and zita-j2a zombie processes
On Thu, Sep 23, 2021 at 02:45:34PM -0700, Ethan Funk wrote:
I am using ubuntustudio-controls (and thus autojack)
to manage multi-
USB audio interface scenarios as I continue to test my radio automation
software port/upgrade.
Can't answer your original question, as I'm not at all familiar with
autojack.
As an alternive way of implementing this sort of thing, you could
have a look at zita-jacktools. It contains a player (with resampling
if necessary), mixer, equaliser, limiter, and some other tools.
All are a jack client and a Python class, so you can control them
easily from a python program. There would be no nead at all to
start new processes etc. for each track.
Jacktools was originally meant to automate complex audio measurements,
but I see no reason why it couldn't do broadcast automation either.
And if you would need addional modules, just drop me a line...
Ciao,
--
FA
29 Mar
29 Mar
2:32 p.m.
New subject: Looking for some jackd debugging help
On Sat, Mar 28, 2020 at 12:38:46PM -0700, Ethan Funk wrote:
I would like to run jackd in gdb so I can see where it
is failing, but
I am unsure how to build it without breaking my system's installed jack
package, which is of course built without debugging enabled.
You could try installing the compiled version over the existing
package files. On Debian I add the following to the ./waf configure
command when I want to do this:
--prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu
Substitute the libdir path relevant for your distro
if not Debian based.
John
1151
days inactive
1698
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Ethan Funk -
Fons Adriaensen -
John Rigg -
Len Ovens -
Rui Nuno Capela