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 = Success
CheckRes error
JackSocketClientChannel read fail
Server 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 13198
Wed 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 2019
Wed 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 messages
Wed Dec 4 04:57:34 2019: Starting jack server...
Wed Dec 4 04:57:34 2019: JACK server starting in realtime mode with priority 10
Wed 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 Audio1
Wed Dec 4 04:57:34 2019: creating alsa driver ... hw:US4x4,0,0|hw:US4x4,0,0|128|3|48000|0|0|nomon|swmeter|-|32bit
Wed Dec 4 04:57:34 2019: configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 3 periods
Wed Dec 4 04:57:34 2019: ALSA: final selected sample format for capture: 32bit integer little-endian
Wed Dec 4 04:57:34 2019: ALSA: use 3 periods for capture
Wed Dec 4 04:57:34 2019: ALSA: final selected sample format for playback: 32bit integer little-endian
Wed Dec 4 04:57:34 2019: ALSA: use 3 periods for playback
Wed 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 0
Wed 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 13374
Wed 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 2019
Wed 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 messages
Wed Dec 4 07:57:43 2019: Starting jack server...
Wed Dec 4 07:57:43 2019: JACK server starting in realtime mode with priority 10
Wed 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 Audio1
Wed Dec 4 07:57:43 2019: creating alsa driver ... hw:US4x4,0,0|hw:US4x4,0,0|128|3|48000|0|0|nomon|swmeter|-|32bit
Wed Dec 4 07:57:43 2019: configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 3 periods
Wed Dec 4 07:57:43 2019: ALSA: final selected sample format for capture: 32bit integer little-endian
Wed Dec 4 07:57:43 2019: ALSA: use 3 periods for capture
Wed Dec 4 07:57:43 2019: ALSA: final selected sample format for playback: 32bit integer little-endian
Wed Dec 4 07:57:43 2019: ALSA: use 3 periods for playback
Wed 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 0
Wed 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 2329
Wed 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 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@redmountainradio.com
>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 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...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev