4 Dec
2019
4 Dec
'19
10:14 p.m.
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