#231: JACK causes silent failures when frame rate is low. No recovery or logging
is done
-------------------------+--------------------------------------------------
Reporter: MiiJaySung | Owner: admin
Type: Bugs | Status: new
Priority: 3 | Milestone: NEAR FUTURE
Component: Liquidsoap | Version: 0.9.0+svn
Resolution: | Keywords: jack input silent failure
Mac: 1 | Linux: 1
Netbsd: 1 | Other: 1
Freebsd: 1 |
-------------------------+--------------------------------------------------
Changes (by MiiJaySung):
* keywords: icecast jack disconnect => jack input silent failure
* priority: 5 => 3
* summary: jack with icecast (ogg) streaming causes hidden failures =>
JACK causes silent failures when frame rate is
low. No recovery or logging is done
Comment:
OK, to clear things up now I seem to have got totally down to the bottom
of what is triggering this, and tried a few suggestions too.
http://pastie.org/365407
This is a script that reproduces the problem I'm experiencing.
This most certainly is a critical JACK related issue. I've tried various
input sources (particularly a remote HTTP, to see if the fact the lag from
the remote site to liq would be greater than liq to icecast on localhost.
In this case I had to use mksafe, but the log reported when the HTTP
source fell behind and it switched to blank with a log message).
I've enabled telnet like you said, and that logs in. It seems to think the
stream is still active when it's dead from there, and there is little else
I can do in telnet it seems.
I've specifically inly used one jack input, so this probably rules out
possible deadlocks caused by multiple different sources (The only reason I
think it helps on the office PC is that each script has a core, so gets
more attention).
On Laptop and Dev PC, I seem to start to get reliable operation from 128
frames upwards (this was on a non RT kernel). On the office PC, I still
quickly run into issues with a 512 frame buffer, and even a 1024 frame
buffer (without XRUNs on JACK's side). In all situations I'm using 44.1Khz
sample rate.
I've also included output.file.mp3. Interestingly this also silently drops
out as well. This seems to rule out the issues being created at the output
side, and points the suspect at the JACK code.
JACK 0.116.1 was used as suggested here. Due to the fact output.file.mp3
was failing, sync = true for icecast does not make any difference.
This is critical for me as the sound card we use depends on JACK for
inputs. I can accept sampling failures / glitches will occur at very low
frame sizes, but the system needs to recover without totally dropping the
output processing, and likewise a quad core system with little load should
easily be able handle 512 frame sizes.
Let me know if the script recreates the issue on your end. Would be
reassuring to know that we've isolated a deterministic trigger condition.
(after all finding the cause of a problem is probably 50% of debugging it
seems)
--
Ticket URL: <http://savonet.rastageeks.org/ticket/231#comment:15>
Savonet <http://savonet.rastageeks.org/>
Let's program our stream !
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Savonet-trac mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-trac
