16 Nov
2022
16 Nov
'22
1:24 a.m.
So, I am having an issue with zita-j2n ...
I have a setup for streaming audio across my home network. There are two
Linux boxes involved, both running Arch Linux; both are connected by
Ethernet to the router (well, actually the broadband modem, which serves as
a router). One is my desktop computer (which I will call the client), the
other is a headless media server (which I will call the server). The client
machine has headphones, and the server has speakers. I need to be able to
send the output from arbitrary sound sources on the client to either the
headphones or the speakers. So I have Jack running on both machines and
need to send audio from client-side Jack to server-side Jack. I also have
an Alsa loopback interface setup on the client, because I need to play
music from programs that don't support Jack - e.g Spotify or web-based
sources like YouTube and Soundcloud (BTW, I am a musician and sometimes use
pro audio software on my desktop system, but this particular setup is not
for that - it's mainly just for listening to music).
I had a version of this setup that worked fine for several years, but it
used Jack1 with the network backend. But a few days ago it stopped working
for some reason ... anyway, long story, but I decided it was time to switch
to Jack2. And I saw that Jack2's network backend isn't usable in the same
way, so I decided to try zita-njbridge.
So, I've more or less figured out how to do this, and have modified the
Python script that manages all the client-side components to use zita-n2j.
I can play music on the desktop machine and stream the output to the server
and hear it on the speakers. So, good. However, zita-j2n crashes frequently
(sometimes every 3-5 minutes) with the following message:
Fatal error condition, terminating.
I would like to find out what is causing these errors. The server-side
system seems solid: Jack and zita-n2j run continuously for several hours
with no apparent problems. So it seems likely that the cause of the problem
is either on the client machine or the network. Apparently zita-n2j doesn't
have a debug mode, so I don't know how to gather the info I need to solve
this. Any suggestions?
16 Nov
16 Nov
9:56 a.m.
On 16.11.22 00:24, Caelia Chapin wrote:
So, I am having an issue with zita-j2n ...
I have a setup for streaming audio across my home network. There are two
Linux boxes involved, both running Arch Linux; both are connected by
Ethernet to the router (well, actually the broadband modem, which serves
as a router). One is my desktop computer (which I will call the client),
the other is a headless media server (which I will call the server). The
client machine has headphones, and the server has speakers. I need to be
able to send the output from arbitrary sound sources on the client to
either the headphones or the speakers. So I have Jack running on both
machines and need to send audio from client-side Jack to server-side
Jack. I also have an Alsa loopback interface setup on the client,
because I need to play music from programs that don't support Jack - e.g
Spotify or web-based sources like YouTube and Soundcloud (BTW, I am a
musician and sometimes use pro audio software on my desktop system, but
this particular setup is not for that - it's mainly just for listening
to music).
I had a version of this setup that worked fine for several years, but it
used Jack1 with the network backend. But a few days ago it stopped
working for some reason ... anyway, long story, but I decided it was
time to switch to Jack2. And I saw that Jack2's network backend isn't
usable in the same way, so I decided to try zita-njbridge.
So, I've more or less figured out how to do this, and have modified the
Python script that manages all the client-side components to use
zita-n2j. I can play music on the desktop machine and stream the output
to the server and hear it on the speakers. So, good. However, zita-j2n
crashes frequently (sometimes every 3-5 minutes) with the following message:
Fatal error condition, terminating.
As far as I understand the code, the only condition when this can occur
in zita-j2n is when the jack buffer size changes, when the transmit
network queue is full, or when the jack server is shutting down.
Best.
Giso
I would like to find out what is causing these errors. The server-side
system seems solid: Jack and zita-n2j run continuously for several hours
with no apparent problems. So it seems likely that the cause of the
problem is either on the client machine or the network. Apparently
zita-n2j doesn't have a debug mode, so I don't know how to gather the
info I need to solve this. Any suggestions?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-user
11:50 a.m.
On Wed, Nov 16, 2022 at 08:56:17AM +0100, Giso Grimm wrote:
On 16.11.22 00:24, Caelia Chapin wrote:
Correct, and probably the first and last can be excluded.
The queue that links the Jack callback to the network sender thread
is dimensioned to hold at least 1/4 second of audio. So apparently
something is blocking transmission for that time.
Since the end-to-end latency in normal operation will be much less,
there is no point in increasing this time - even with 1/4 second the
receiver will have missing packets and insert silence welll before
the sender detects the problem.
I'd try bypassing the router, using a direct connection from sender
to receiver.
--
FA
So, I am having an issue with zita-j2n ...
Fatal error condition, terminating.
As far as I understand the code, the only condition when this can occur in
zita-j2n is when the jack buffer size changes, when the transmit network
queue is full, or when the jack server is shutting down.
537
days inactive
537
days old
linux-audio-user@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Caelia Chapin -
Fons Adriaensen -
Giso Grimm