12 Nov
2019
12 Nov
'19
12:02 p.m.
liquidsfz-0.1.0 has been released
The main goal of liquidsfz is to provide an SFZ sampler implementation
library that is easy to integrate into other projects. A standalone jack
client is also available.
liquidsfz is implemented in C++ and licensed under the GNU LGPL version
2.1 or later. The release tarball can be downloaded here:
https://github.com/swesterfeld/liquidsfz#releases
--
Stefan Westerfeld, http://space.twc.de/~stefan
2:49 p.m.
Hi!
Did you connect the audio outputs (you need to do this explicitely)?
Another possible cause is that the .sfz file is not yet properly
supported. Is it publicly available so I can test it? You can also try
Salamander Grand https://musical-artifacts.com/artifacts/3 which is
definitely supported. Finally you can run liquidsfz with --debug. You
should see the filenames of the files that will be played if you send
midi input.
Cu... Stefan
Am 13.11.19 um 23:28 schrieb - -:
Hi Stefan, I have compiled the project from the
release. Compilation
worked, sfz seem to load but the plugin doesn't react to midi input. I
tried in Carla, I can plug my midi input but nothing is sent. Any idea ?
Cheers
Bernard
> Le 12 novembre 2019 à 11:02, Stefan Westerfeld < stefan(a)space.twc.de
> <mailto:stefan@space.twc.de>> a écrit :
>
>
> liquidsfz-0.1.0 has been released
>
> The main goal of liquidsfz is to provide an SFZ sampler implementation
> library that is easy to integrate into other projects. A standalone jack
> client is also available.
>
> liquidsfz is implemented in C++ and licensed under the GNU LGPL version
> 2.1 or later. The release tarball can be downloaded here:
>
> https://github.com/swesterfeld/liquidsfz#releases
> --
> Stefan Westerfeld, http://space.twc.de/~stefan
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> <mailto:Linux-audio-dev@lists.linuxaudio.org>
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Stefan Westerfeld, http://space.twc.de/~stefan
10:45 p.m.
Hi!
At the moment, the most interesting thing for me are freely available
.sfz files which completely fail to load or produce no sound at all. So
if you find such a case during testing, please file a github issue or
drop me a mail, with a link where I can download the .sfz.
Cu... Stefan
Am 14.11.19 um 17:53 schrieb - -:
Hi now it works sorry for the false negative :) The
trick is that when I
use Carla patchbay, when I plug a midi input to a program, the virtual
keyboard of Carla is ungreyed and shows what keys I play, which doesn't
happen with liquidsfz. And the sfz I loaded at first time wasn't
certainly supported. Now time for further testing. Are there any tests
you'll like me to do ?
Cheers
Bernard
> Le 14 novembre 2019 à 13:49, Stefan Westerfeld < stefan(a)space.twc.de
> <mailto:stefan@space.twc.de>> a écrit :
>
>
> Hi!
>
> Did you connect the audio outputs (you need to do this explicitely)?
> Another possible cause is that the .sfz file is not yet properly
> supported. Is it publicly available so I can test it? You can also try
> Salamander Grand https://musical-artifacts.com/artifacts/3 which is
> definitely supported. Finally you can run liquidsfz with --debug. You
> should see the filenames of the files that will be played if you send
> midi input.
>
> Cu... Stefan
>
> Am 13.11.19 um 23:28 schrieb - -:
>> Hi Stefan, I have compiled the project from the release. Compilation
>> worked, sfz seem to load but the plugin doesn't react to midi input. I
>> tried in Carla, I can plug my midi input but nothing is sent. Any idea ?
>> Cheers
>> Bernard
>>> Le 12 novembre 2019 à 11:02, Stefan Westerfeld < stefan(a)space.twc.de
>>> <mailto:stefan@space.twc.de>
>>> <mailto: stefan(a)space.twc.de <mailto:stefan@space.twc.de>>> a
écrit :
> >>
> >> liquidsfz-0.1.0 has been released
> >>
> >> The main goal of liquidsfz is to provide an SFZ sampler implementation
> >> library that is easy to integrate into other projects. A standalone
> jack
> >> client is also available.
> >>
> >> liquidsfz is implemented in C++ and licensed under the GNU LGPL
> version
> >> 2.1 or later. The release tarball can be downloaded here:
> >>
> >> https://github.com/swesterfeld/liquidsfz#releases
> >> --
> >> Stefan Westerfeld, http://space.twc.de/~stefan
> >> _______________________________________________
> >> Linux-audio-dev mailing list
> >> Linux-audio-dev(a)lists.linuxaudio.org
> <mailto:Linux-audio-dev@lists.linuxaudio.org>
> >> <mailto: Linux-audio-dev(a)lists.linuxaudio.org
> <mailto:Linux-audio-dev@lists.linuxaudio.org>>
> >> https://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
> --
> Stefan Westerfeld, http://space.twc.de/~stefan
--
Stefan Westerfeld, http://space.twc.de/~stefan
11:02 p.m.
Hello,
As promised to Stefan privately, i just finished to write a tiny (and
ugly) GUI to libqliquidsfz that allow to load an SFZ file and play it
with a jack-ed midi keyboard. It is written in Qt/C++. It is called
QLiquidSFZ.
Any better GUI suggestion (with a mockup) is welcomed.
qliquidsfz is licensed under the GNU GPL version 3.
The clonable git project can be found at:
https://github.com/be1/qliquidsfz
Le 12/11/2019 à 11:02, Stefan Westerfeld a écrit :
liquidsfz-0.1.0 has been released
The main goal of liquidsfz is to provide an SFZ sampler implementation
library that is easy to integrate into other projects. A standalone jack
client is also available.
liquidsfz is implemented in C++ and licensed under the GNU LGPL version
2.1 or later. The release tarball can be downloaded here:
https://github.com/swesterfeld/liquidsfz#releases
16 Nov
16 Nov
11:47 p.m.
New subject: Jack audio questions to aid in my development of audiorack
I am in the process of porting a radio automation system that I
originally started writing for OSX/CoreAudio some 10 years ago. The OS
X version is currently in use at a radio station I am co-owner of, and
2 area LPFM radio station. But I have become progressively frustrated
with Apple as each new OS release is made, and find that that's with
the continued evolution of jack-audio and gstreamer, I can now ditch my
dependency on Apple's audio API. This a huge project, with GUI
elements, audio play-out/mixing elements, library management elements,
etc, to be ported. I decided to start with the CLI audio/automation
engine first, making use of jack to break the original CLI program up
into pieces that interconnect with jack: the mixer/automation/control
application, media players and media recorders/encoders. I haven't
decided what to code the GUI elements with... but I'm not at that point
yet. Without the GUI, the CLI pieces are a monster for a human to
operate. But again, I needed to start someplace.
My "alpha" release of the CLI pieces, so far tested on Ubuntu 19.10,
can be found here:
https://github.com/eafunk/audiorack
NOTE: there is a database bug in the libdbi mysql driver that I have
fixed locally. Without the libdbi fix, there are some multi-threading
stability problems. I'm working to get my fix into the libdbi code
base.
With the demise of the jack-audio email list, I have no place to go
with questions regarding jack. So is this list a reasonable place for
me to ask questions related to jack? By way of full disclosure, I am
developing on Ubuntu, with an eye on making the project build-able on
OS X and FreeBSD as well.
For example, I have some audio problem with low-latency jack audio on
Ubuntu right now that I could use some insight on:
1. With the low-latency kernel, jack dropouts/underruns are a problem
when jack is configured to bridge to pulseaudio. Without a pulseaudio
bridge, the dropout are nonexistent. Is there a way to increase the
"buffer/latency" on the bridge between pulseaudio and jack? Latency on
pulseaudio is already poor, so audio coming from/to pulseaudio wouldn't
be hurt by extra buffering to keep jack's low latency paths and
realtime thread happy.
2. I have a similar issue with zita-a2j and zita-j2a with lost of
dropouts on the ALAS side, even though the jack side shows no overruns.
Can extra buffering be applied to the zita programs? Maybe that is
what the -n option is for?
3. I'm using Ubuntu Studio Control to make jack integration with Ubuntu
easy. Does anyone know where I can find the source code for Ubuntu
Studio Control?
4. Can anyone recommend an audio effects host that doesn't also try to
manage jack connections? I can't have a "studio manager" host my audio
processing (compression, de-essing, etc) and decides to make
connections between my audio engine application and the media handler's
it spawns. I need my audio engine to make it's own connection
decisions.
Thanks,
Ethan...
17 Nov
17 Nov
12:12 a.m.
New subject: Jack audio questions to aid in my development of audiorack
On Sat, Nov 16, 2019 at 02:47:26PM -0700, Ethan Funk wrote:
1. With the low-latency kernel, jack
dropouts/underruns are a problem
when jack is configured to bridge to pulseaudio. Without a pulseaudio
bridge, the dropout are nonexistent.
I'd suggest to get rid of pulseaudio. It doesn't do anything useful
for an application like yours.
2. I have a similar issue with zita-a2j and zita-j2a
with lost of
dropouts on the ALAS side, even though the jack side shows no overruns.
How does this show up (i.e. how do you know it is the ALSA side) ?
What do you get with the -v option ?
Can extra buffering be applied to the zita programs?
Maybe that is
what the -n option is for?
Using more periods could hide the problem, but it's never a real
solution.
Are you sure things are running with real-time scheduling ?
This requires some configuration in /etc/security/limits.conf,
as well as for Jack itself.
Why do you need zita-a2j/j2a anyway ? Using a single multichannel
card is usually the better solution.
Ciao,
--
FA
12:49 a.m.
New subject: Jack audio questions to aid in my development of audiorack
On Sat, Nov 16, 2019 at 02:47:26PM -0700, Ethan Funk
wrote:
Getting rid of pulseaudio is probably the right thing to do. Thanks
for pushing me in that direction.
1. With the low-latency kernel, jack
dropouts/underruns are a
problemwhen jack is configured to bridge to pulseaudio. Without a
pulseaudiobridge, the dropout are nonexistent.
I'd suggest to get rid of pulseaudio. It doesn't do anything
usefulfor an application like yours. 2. I have a
similar issue with zita-a2j and zita-j2a with lost
ofdropouts on the ALAS side, even though the jack side shows no
overruns.
How does this show up (i.e. how do you know it is the ALSA side) ? What do you get with the -v option ?
I don't know because I am using Ubuntu Studio Control to manage the
create of zita-j2a/a2j instances on my test system. I wanted an "easy"
way for potential users to set up jack and Ubuntu Studio Control is
nice and easy. zita bridges are working fine on my development
machine, where I manually set them up, so there must be something in
how Ubuntu Studio Control is spawning the zita bridges. That's why I
am also looking for the source code for Ubuntu Studio Control. Ubuntu
Studio Control make jack setup supper simple, and almost a pleasure for
the average user.
Can extra
buffering be applied to the zita programs? Maybe that
iswhat the -n option is for?
Using more periods could hide the problem, but it's never a
realsolution.
Are you sure things are running with real-time scheduling ? This requires some configuration in
/etc/security/limits.conf,as well
as for Jack itself.
I had gone down that road originally on the machine I am using for
development. On my test system, I used the Ubuntu Studio Installer,
which does a very nice, friendly job of setting up a stock Ubuntu
machine for use with jack.
Why do you need zita-a2j/j2a anyway ? Using a single
multichannelcard
is usually the better solution.
I have one multichannel audio interface for everything important:
program out, studio monitors, headphones, guest mic, host mic,
etc. But it sure is nice to be able to use the built-in audio for a
cue channel and talkback mic, where latency is not important. Also
handy for USB turntables, and other random devices that are
occasionally used in a radio show without latency being important.
Thanks,
Ethan...
25 Nov
25 Nov
12:51 a.m.
New subject: jackdbus log controls?
I am almost a week into testing my jack-audio application with no
crashes of jackd or my application. Bug abound (in my code), but that
is the point of testing. Fixing as I go. I am using Ubuntu Studio
control to run jackd... actually jackdbus, which brings me to my
question:
How do I get control over jackdbus logging? I currently have an
gigantic log file it is creating at ~/.log/jack/jackdbus.log from my
testing.
It's huge because my application make extensive use of jacks inter-
process audio routing as a radio station automation system. My
application is endlessly forking new audio player processes that
connect back to a core mixer via jack, play when needed, then
disconnect when finished. So the above log file is crammed full of
jack port connect and disconnect notices. How do I make it stop?
There is no man page available for jackdbus, and "ps" indicates that it
was simply run as "/usr/bin/jackdbus auto." With some further poking
around I found that ubuntu-syudio-control is running something called
autojack, which seems to run jackdbus, and autojack does have a man
page, but not much help.
As a side note, the Patchage interconnection GUI does seem to cause
jackd to crash after about two days of running. I have not troubleshot
that any further, but I do know that without Patchage running, jackd
has been running with my program for 5 days. There may be something
worth investigating, but I haven't had time.
Thanks,
Ethan...
2:36 a.m.
New subject: jackdbus log controls?
On Sun, 24 Nov 2019, Ethan Funk wrote:
I am almost a week into testing my jack-audio
application with no crashes of
jackd or my application. Bug abound (in my code), but that is the point of
testing. Fixing as I go. I am using Ubuntu Studio control to run jackd...
actually jackdbus, which brings me to my question:
How do I get control over jackdbus logging? I currently have an gigantic log file
it is creating at ~/.log/jack/jackdbus.log from my testing.
Yes I have this concern too. jackdbus is controled by using jack_control
or dbus directly for which there is no documentation besides the source I
would guess. US_controls uses jack_control right now (which also has no
documentation) and by running jack_control with no parameters one gets a
list of commands some of which will tell you what some other commands
might be. None of them that I could find will set logging levels. The next
version of US_controls will use logrotate to help keep the log files from
getting too big. You may want to set up a cron job to do this for you
until that release. It would be possible to use jackd instead of jackdbus
but that would just mean the the US_controls log would start to grow
quicker instead because jackd logs to stdout and stderr.
So the answer is that while jackdbus seems to provide no way of doing
this, logroatate is already installed and gets run by cron once a day (I
think) by the system. However, because your log file is in userland you
would be better off running it from the user crontab with it's own config
file.
--
Len Ovens
www.ovenwerks.net
6:19 p.m.
New subject: jackdbus log controls?
Log rotation is not what I could consider the "correct" solution. But
I guess it's what I have to do for now until a log-level control is
implemented. All the little things my application needs to take care of
on a users system is getting really complicated. I am of the opinion
that default log levels should be low, with the option to get more
verbose when the user is interested in the extra information only.
Good to know others folks are see this as a bug as well.
Thanks everyone.
Ethan...
On Sun, 2019-11-24 at 16:36 -0800, Len Ovens wrote:
On Sun, 24 Nov 2019, Ethan Funk wrote:
I am almost a week into testing my jack-audio
application with no
crashes ofjackd or my application. Bug abound (in my code), but
that is the point oftesting. Fixing as I go. I am using Ubuntu
Studio control to run jackd...actually jackdbus, which brings me to
my question:
How do I get control over jackdbus logging? I currently have an
gigantic log fileit is creating at ~/.log/jack/jackdbus.log from my
testing.
Yes I have this concern too. jackdbus is controled by using
jack_control or dbus directly for which there is no documentation
besides the source I would guess. US_controls uses jack_control right
now (which also has no documentation) and by running jack_control
with no parameters one gets a list of commands some of which will
tell you what some other commands might be. None of them that I could
find will set logging levels. The next version of US_controls will
use logrotate to help keep the log files from getting too big. You
may want to set up a cron job to do this for you until that release.
It would be possible to use jackd instead of jackdbus but that would
just mean the the US_controls log would start to grow quicker instead
because jackd logs to stdout and stderr.
So the answer is that while jackdbus seems to provide no way of doing
this, logroatate is already installed and gets run by cron once a day
(I think) by the system. However, because your log file is in
userland you would be better off running it from the user crontab
with it's own config file.
--Len Ovenswww.ovenwerks.net
_______________________________________________Linux-audio-dev
mailing listLinux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
26 Nov
26 Nov
6:45 p.m.
New subject: Possible jack_port_disconnect() problem.
After days of testing, I got a crash (of sorts) out of my
program. More of a hang than a crash. So I attached gdb to the
process and looked around. My main thread appears to be hung deep
inside a jack call, via jack_port_disconnect(). This is a point in my
code where it cleans up after an jack-attached media player that is
done playing. The player process terminates when it's jack connections
are disconnected. I re-started the code execution and then stopped it
again to find that the main thread was still waiting at the same
libc_read() spot. After taking a look at the jack source code, I
didn't find that jack_port_disconnect() would result in a read any
place down the jack call chain. To be fair to jack, I am still mostly
unfamiliar with the library structure, so I could be missing
something. Any insight as to what I might be doing wrong? The port I
am passing to jack_port_disconnect() appears to be valid, unless my
code is overwriting memory. Backtrace of the main thread is below.
Thanks all.
Ethan...
(gdb) bt full
#0 __libc_read (nbytes=4, buf=0x7fffad4ed248, fd=5) at
../sysdeps/unix/sysv/linux/read.c:26
resultvar = 18446744073709551104
sc_cancel_oldtype = 0
__arg3 = <optimized out>
_a2 = <optimized out>
sc_ret = <optimized out>
__value = <optimized out>
__arg1 = <optimized out>
_a3 = <optimized out>
resultvar = <optimized out>
resultvar = <optimized out>
__arg2 = <optimized out>
_a1 = <optimized out>
#1 __libc_read (fd=5, buf=0x7fffad4ed248, nbytes=4) at
../sysdeps/unix/sysv/linux/read.c:24
No locals.
#2 0x00007fab6fe13ead in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#3 0x00007fab6fe02e2a in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#4 0x00007fab6fe03768 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#5 0x00007fab6fdf8598 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#6 0x0000564ac911610a in releaseQueueRecord (root=0x564ac9134260
<queueList>, rec=0x7fab3004c910, force=0 '\000') at data.c:473
[NOTE: this line is: jack_port_disconnect(mixEngine->client, *port);
]
c = 1
cmax = 2
port = 0x564acaf81278
prev = 0x564ac9134260 <queueList>
current = 0x7fab3004c910
instance = 0x564acaf80be0
logID = 9126049
tmp = <optimized out>
#7 0x0000564ac91057c5 in NextListItem (lastStat=2,
curQueRec=0x564ac9134260 <queueList>, firstp=0x7fffad4ed418,
sbtime=0x7fffad4ed41c, remtime=0, isPlaying=0x7fffad4ed416 "") at
automate.c:811
.... Blah, blah, blah....
7:10 p.m.
New subject: Possible jack_port_disconnect() problem.
jack clients and the server on linux communicate via reading and writing
through a FIFO. there's nothing unusual about read(2) showing up here - the
client has asked the server for a port disconnect and is waiting for a
response.
On Tue, Nov 26, 2019 at 9:45 AM Ethan Funk <ethan(a)redmountainradio.com>
wrote:
After days of testing, I got a crash (of sorts) out of
my program. More of
a hang than a crash. So I attached gdb to the process and looked around. My
main thread appears to be hung deep inside a jack call, via
jack_port_disconnect(). This is a point in my code where it cleans up after
an jack-attached media player that is done playing. The player process
terminates when it's jack connections are disconnected. I re-started the
code execution and then stopped it again to find that the main thread was
still waiting at the same libc_read() spot. After taking a look at the jack
source code, I didn't find that jack_port_disconnect() would result in a
read any place down the jack call chain. To be fair to jack, I am still
mostly unfamiliar with the library structure, so I could be missing
something. Any insight as to what I might be doing wrong? The port I am
passing to jack_port_disconnect() appears to be valid, unless my code is
overwriting memory. Backtrace of the main thread is below.
Thanks all.
Ethan...
(gdb) bt full
#0 __libc_read (nbytes=4, buf=0x7fffad4ed248, fd=5) at
../sysdeps/unix/sysv/linux/read.c:26
resultvar = 18446744073709551104
sc_cancel_oldtype = 0
__arg3 = <optimized out>
_a2 = <optimized out>
sc_ret = <optimized out>
__value = <optimized out>
__arg1 = <optimized out>
_a3 = <optimized out>
resultvar = <optimized out>
resultvar = <optimized out>
__arg2 = <optimized out>
_a1 = <optimized out>
#1 __libc_read (fd=5, buf=0x7fffad4ed248, nbytes=4) at
../sysdeps/unix/sysv/linux/read.c:24
No locals.
#2 0x00007fab6fe13ead in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#3 0x00007fab6fe02e2a in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#4 0x00007fab6fe03768 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#5 0x00007fab6fdf8598 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
No symbol table info available.
#6 0x0000564ac911610a in releaseQueueRecord (root=0x564ac9134260
<queueList>, rec=0x7fab3004c910, force=0 '\000') at data.c:473
[NOTE: this line is: jack_port_disconnect(mixEngine->client, *port); ]
c = 1
cmax = 2
port = 0x564acaf81278
prev = 0x564ac9134260 <queueList>
current = 0x7fab3004c910
instance = 0x564acaf80be0
logID = 9126049
tmp = <optimized out>
#7 0x0000564ac91057c5 in NextListItem (lastStat=2,
curQueRec=0x564ac9134260 <queueList>, firstp=0x7fffad4ed418,
sbtime=0x7fffad4ed41c, remtime=0, isPlaying=0x7fffad4ed416 "") at
automate.c:811
.... Blah, blah, blah....
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
10:44 p.m.
New subject: Possible jack_port_disconnect() problem.
Related question then: Any idea what my application could be doing
wrong to cause jack to not get back with a response? It had been
waiting for about an hour, while I was off doing paying work, and my
applications process function was still being called by jack when I
finally noticed it. My best plan for now is to test again, and wait for
it to happen, then see if I can get another jack program to
connect/disconnect after my program hangs, and check the jack logs
right away. The jack log file from this test is full of underruns from
my debugging, so that is mostly useless. Any other debuging approach I
should be taking?
Thanks,
Ethan...
On Tue, 2019-11-26 at 10:10 -0700, Paul Davis wrote:
jack clients and the server on linux communicate via
reading and
writingthrough a FIFO. there's nothing unusual about read(2) showing
up here - theclient has asked the server for a port disconnect and is
waiting for aresponse.
On Tue, Nov 26, 2019 at 9:45 AM Ethan Funk <
ethan(a)redmountainradio.com>wroteote:
> After days of testing, I got a crash (of sorts) out of my program.
> More ofa hang than a crash. So I attached gdb to the process and
> looked around. Mymain thread appears to be hung deep inside a jack
> call, viajack_port_disconnect(). This is a point in my code where
> it cleans up afteran jack-attached media player that is done
> playing. The player processterminates when it's jack connections
> are disconnected. I re-started thecode execution and then stopped
> it again to find that the main thread wasstill waiting at the same
> libc_read() spot. After taking a look at the jacksource code, I
> didn't find that jack_port_disconnect() would result in aread any
> place down the jack call chain. To be fair to jack, I am
> stillmostly unfamiliar with the library structure, so I could be
> missingsomething. Any insight as to what I might be doing wrong?
> The port I ampassing to jack_port_disconnect() appears to be valid,
> unless my code isoverwriting memory. Backtrace of the main thread
> is below.
> Thanks all.Ethan...
4 Dec
4 Dec
10:14 p.m.
New subject: Possible jack_port_disconnect() problem.
Happened again, this time slightly different place in my code, so not
at jack_port_disconnect() this time, but I am certain it's the same
problem:
STDERR output from my program:
Cannot read socket fd = 7 err = SuccessCheckRes
errorJackSocketClientChannel read failServer is not running
With a corresponding time stamped log entry in my programs log
file:
Dec 04, 2019 04:57:20 | ars9550 | jack-audio- jackd audio server has
gone away: We are shutting down too.
And then my program shuts itself down, as designed.
This corresponds to a jack log (~/.log/jack/jackdbus.log)
report...
Normal operation of my application:
Wed Dec 4 04:55:54 2019: New client 'arPlayer-3' with PID 13198Wed
Dec 4 04:55:54 2019: Connecting 'arPlayer-3:ctlOut' to
'ars9550:ctlIn'Wed Dec 4 04:55:54 2019: Connecting 'ars9550:ctlOut' to
'arPlayer-3:ctlIn'Wed Dec 4 04:55:54 2019: Connecting 'arPlayer-
3:Output0' to 'ars9550:In3ch0'Wed Dec 4 04:55:54 2019: Connecting
'arPlayer-3:Output1' to 'ars9550:In3ch1'Wed Dec 4 04:55:54 2019:
Disconnecting 'ars9550:ctlOut' from 'arPlayer-1:ctlIn'Wed Dec 4
04:55:54 2019: Disconnecting 'arPlayer-1:ctlOut' from
'ars9550:ctlIn'Wed Dec 4 04:55:54 2019: Client 'arPlayer-1' with PID
13145 is out
Then the trouble... looks like jackd crashed, and
UbuntuStudioControl presumably restart it:
Wed Dec 4 04:57:31 2019: ------------------Wed Dec 4 04:57:31 2019:
Controller activated. Version 1.9.12 (unknown) built on Mon Jan 14
13:01:07 2019Wed Dec 4 04:57:33 2019: Loading settings from
"/home/bcaster/.config/jack/conf.xml" using expat_2.2.7 ...Wed Dec 4
04:57:33 2019: setting parameter 'engine':'driver':'(null)' to
value
"alsa"Wed Dec 4 04:57:33 2019: setting parameter
'drivers':'alsa':'device' to value "hw:US4x4,0,0"Wed Dec
4 04:57:33
2019: setting parameter 'drivers':'alsa':'capture' to value
"none"Wed
Dec 4 04:57:33 2019: setting parameter
'drivers':'alsa':'playback' to
value "none"Wed Dec 4 04:57:33 2019: setting parameter
'drivers':'alsa':'rate' to value "48000"Wed Dec 4
04:57:33 2019:
setting parameter 'drivers':'alsa':'period' to value
"128"Wed Dec 4
04:57:33 2019: setting parameter 'drivers':'alsa':'nperiods' to
value
"3"Wed Dec 4 04:57:33 2019: Listening for D-Bus messagesWed Dec 4
04:57:34 2019: Starting jack server...Wed Dec 4 04:57:34 2019: JACK
server starting in realtime mode with priority 10Wed Dec 4 04:57:34
2019: self-connect-mode is "Don't restrict self connect requests"Wed
Dec 4 04:57:34 2019: Acquired audio card Audio1Wed Dec 4 04:57:34
2019: creating alsa driver ...
hw:US4x4,0,0|hw:US4x4,0,0|128|3|48000|0|0|nomon|swmeter|-|32bitWed
Dec 4 04:57:34 2019: configuring for 48000Hz, period = 128 frames (2.7
ms), buffer = 3 periodsWed Dec 4 04:57:34 2019: ALSA: final selected
sample format for capture: 32bit integer little-endianWed Dec 4
04:57:34 2019: ALSA: use 3 periods for captureWed Dec 4 04:57:34 2019:
ALSA: final selected sample format for playback: 32bit integer little-
endianWed Dec 4 04:57:34 2019: ALSA: use 3 periods for playbackWed
Dec 4 04:57:34 2019: graph reorder: new port 'system:capture_1'Wed
Dec 4 04:57:34 2019: New client 'system' with PID 0Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:capture_2'Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:capture_3'Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:capture_4'Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:playback_1'Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:playback_2'Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:playback_3'Wed Dec 4 04:57:34
2019: graph reorder: new port 'system:playback_4'Wed Dec 4 04:57:35
2019: Saving settings to "/home/bcaster/.config/jack/conf.xml" ...Wed
Dec 4 04:57:39 2019: New client 'NVidia,0,0-out' with PID 13374Wed
Dec 4 04:57:39 2019: New client 'NVidia,0,0-in' with PID 13379
Then it crashes and gets run again and crashes, two more
times every 20 seconds. No further run attempts are made seem to
be made to restart jackd for ***exactly** 3 hours, and final jackd
runs runs and stays running. My application is long gone:
Wed Dec 4 07:57:43 2019: ------------------Wed Dec 4 07:57:43 2019:
Controller activated. Version 1.9.12 (unknown) built on Mon Jan 14
13:01:07 2019Wed Dec 4 07:57:43 2019: Loading settings from
"/home/bcaster/.config/jack/conf.xml" using expat_2.2.7 ...Wed Dec 4
07:57:43 2019: setting parameter 'engine':'driver':'(null)' to
value
"alsa"Wed Dec 4 07:57:43 2019: setting parameter
'drivers':'alsa':'device' to value "hw:US4x4,0,0"Wed Dec
4 07:57:43
2019: setting parameter 'drivers':'alsa':'capture' to value
"none"Wed
Dec 4 07:57:43 2019: setting parameter
'drivers':'alsa':'playback' to
value "none"Wed Dec 4 07:57:43 2019: setting parameter
'drivers':'alsa':'rate' to value "48000"Wed Dec 4
07:57:43 2019:
setting parameter 'drivers':'alsa':'period' to value
"128"Wed Dec 4
07:57:43 2019: setting parameter 'drivers':'alsa':'nperiods' to
value
"3"Wed Dec 4 07:57:43 2019: Listening for D-Bus messagesWed Dec 4
07:57:43 2019: Starting jack server...Wed Dec 4 07:57:43 2019: JACK
server starting in realtime mode with priority 10Wed Dec 4 07:57:43
2019: self-connect-mode is "Don't restrict self connect requests"Wed
Dec 4 07:57:43 2019: Acquired audio card Audio1Wed Dec 4 07:57:43
2019: creating alsa driver ...
hw:US4x4,0,0|hw:US4x4,0,0|128|3|48000|0|0|nomon|swmeter|-|32bitWed
Dec 4 07:57:43 2019: configuring for 48000Hz, period = 128 frames (2.7
ms), buffer = 3 periodsWed Dec 4 07:57:43 2019: ALSA: final selected
sample format for capture: 32bit integer little-endianWed Dec 4
07:57:43 2019: ALSA: use 3 periods for captureWed Dec 4 07:57:43 2019:
ALSA: final selected sample format for playback: 32bit integer little-
endianWed Dec 4 07:57:43 2019: ALSA: use 3 periods for playbackWed
Dec 4 07:57:44 2019: graph reorder: new port 'system:capture_1'Wed
Dec 4 07:57:44 2019: New client 'system' with PID 0Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:capture_2'Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:capture_3'Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:capture_4'Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:playback_1'Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:playback_2'Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:playback_3'Wed Dec 4 07:57:44
2019: graph reorder: new port 'system:playback_4'Wed Dec 4 07:57:45
2019: Saving settings to "/home/bcaster/.config/jack/conf.xml" ...Wed
Dec 4 07:57:49 2019: New client 'NVidia,0,0-out' with PID 2329Wed
Dec 4 07:57:49 2019: New client 'NVidia,0,0-in' with PID 2330
Ubuntu Studio Control is managing jakld in the scenario. While I can't
rule out a bug in my program, it doesn't look like it is triggered by
my program. Does any one have any idea how I can troubleshoot this
further?
Thanks,Ethan...
On Tue, 2019-11-26 at 13:44 -0700, Ethan Funk wrote:
Related question then: Any idea what my application
could be
doingwrong to cause jack to not get back with a response? It had
beenwaiting for about an hour, while I was off doing paying work, and
myapplications process function was still being called by jack when
Ifinally noticed it. My best plan for now is to test again, and wait
forit to happen, then see if I can get another jack program
toconnect/disconnect after my program hangs, and check the jack
logsright away. The jack log file from this test is full of
underruns frommy debugging, so that is mostly useless. Any other
debuging approach Ishould be taking?
Thanks,Ethan...
On Tue, 2019-11-26 at 10:10 -0700, Paul Davis wrote:
jack clients and the server on linux communicate
via reading
andwritingthrough a FIFO. there's nothing unusual about read(2)
showingup here - theclient has asked the server for a port
disconnect and iswaiting for aresponse.On Tue, Nov 26, 2019 at 9:45
AM Ethan Funk <ethan(a)redmountainradio.com>wrote;wrote:
> After days of testing, I got a crash (of sorts) out of my
> program.More ofa hang than a crash. So I attached gdb to the
> process andlooked around. Mymain thread appears to be hung deep
> inside a jackcall, viajack_port_disconnect(). This is a point in
> my code whereit cleans up afteran jack-attached media player that
> is doneplaying. The player processterminates when it's jack
> connectionsare disconnected. I re-started thecode execution and
> then stoppedit again to find that the main thread wasstill
> waiting at the samelibc_read() spot. After taking a look at the
> jacksource code, Ididn't find that jack_port_disconnect() would
> result in aread anyplace down the jack call chain. To be fair to
> jack, I amstillmostly unfamiliar with the library structure, so I
> could bemissingsomething. Any insight as to what I might be doing
> wrong?The port I ampassing to jack_port_disconnect() appears to
> be valid,unless my code isoverwriting memory. Backtrace of the
> main threadis below.Thanks all.Ethan...
_______________________________________________Linux-audio-dev
mailing listLinux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev 
25 Nov
25 Nov
10:36 a.m.
New subject: jackdbus log controls?
On 2019-11-24 15:51:04 (-0700), Ethan Funk wrote:
How do I get control over jackdbus logging? I
currently have an
gigantic log file it is creating at ~/.log/jack/jackdbus.log from my
testing.
You can look into logrotate [1] to auto-cleanup and rotate the log
(check `man 5 logrotate.conf` and `man 8 logrotate`). You can run this
on a systemd timer or cron job.
It's huge because my application make extensive
use of jacks inter-
process audio routing as a radio station automation system. My
application is endlessly forking new audio player processes that
connect back to a core mixer via jack, play when needed, then
disconnect when finished. So the above log file is crammed full of
jack port connect and disconnect notices. How do I make it stop?
I'm uncertain (because I run jackd in a systemd user unit [2] and
haven't used jackdbus in a long time), but there is a ticket around the
logging facilities [3].
Best,
David
[1] https://github.com/logrotate/logrotate
[2] https://github.com/jackaudio/jack2/tree/develop/systemd
[3] https://github.com/jackaudio/jack2/issues/402
--
https://sleepmap.de
30 Nov
30 Nov
2:19 p.m.
New subject: jackdbus log controls?
On Sun, Nov 24, 2019 at 03:51:04PM -0700, Ethan Funk wrote:
i
My application is endlessly forking new audio player
processes that
connect back to a core mixer via jack, play when needed, then
disconnect when finished. So the above log file is crammed full of
jack port connect and disconnect notices. How do I make it stop?
Not really answering you questions, but avoiding the problem
that triggers it: just use a fixed set of players and control
them (load, stop, start, locate,...) instead of creating a new
player for each file...
Ciao,
--
FA
1 Dec
1 Dec
11:47 p.m.
New subject: jackdbus log controls?
While your correct that changing my approach to make use of pre-
allocated players that are re-load-able would work
for fixing the verbose log problem, it is a rather large design
philosophy change to make this late in the design. The
OS X version I am porting from had the media handling "builtin" using a
similar, pre-allocated object approach. My
new design is a departure form the original approach since I wanted to
make the most use of jack's inter-application
flexibility. Since I am at the testing stage at this point, a lot
of re-coding would be needed to go back to the old,
pre-allocated player approach. And I am kind of attached to leaving my
core mixer inputs open/disconnected when
not used my the automation algorithm, so they can be connected
to sources by the user if they want. For now, I'll
rotate log files.
Thanks,
Ethan...
On Sat, 2019-11-30 at 13:19 +0100, Fons Adriaensen wrote:
On Sun, Nov 24, 2019 at 03:51:04PM -0700, Ethan Funk
wrote:
i
My application is endlessly forking new audio
player processes that
connect back to a core mixer via jack, play when needed, then
disconnect when finished. So the above log file is crammed full of
jack port connect and disconnect notices. How do I make it stop?
Not really answering you questions, but avoiding the problem
that triggers it: just use a fixed set of players and control
them (load, stop, start, locate,...) instead of creating a new
player for each file...
Ciao,
1605
days inactive
1627
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
8 participants
participants (8)
-
- - -
Benoît Rouits -
David Runge -
Ethan Funk -
Fons Adriaensen -
Len Ovens -
Paul Davis -
Stefan Westerfeld