search

rafael2k / darkice

DarkIce is a live audio streamer. It records audio from an audio interface (e.g. sound card), encodes it and sends it to a streaming server. This is the official development repository of Darkice.
http://www.darkice.org
200 stars 47 forks source link

darkice + jack fails after 2-8 hours #131

Open BillGoldsmith opened 7 years ago

BillGoldsmith commented 7 years ago

I'm running darkice on a Centos7 system, using jack with a dummy device (no audio hardware on this box), encoding 2 Ogg Vorbis streams to a local Icecast2 server.

I've used darkice for years to encode 2 Ogg + 2 MP3 streams, with USB hardware as the input, and found it to be very, very stable (current runtime on my production encoder is 452 days).

On this development system, I'm seeing this:

25-Oct-2017 10:26:18 Using JACK audio server as input device. 25-Oct-2017 10:26:18 buffer size: 2646000 25-Oct-2017 10:26:18 buffer size: 2646000 25-Oct-2017 10:26:18 encoding 25-Oct-2017 10:26:18 scheduler high priority 99 25-Oct-2017 10:26:18 Using POSIX real-time scheduling, priority 4 25-Oct-2017 10:26:18 Registering as JACK client darkice-50006 25-Oct-2017 10:26:18 HTTP/1.0 200 25-Oct-2017 10:26:18 HTTP/1.0 200 25-Oct-2017 10:26:18 MultiThreadedConnector :: ThreadData :: threadFunction, was (thread, priority, type): 0x1e354a0 4 SCHED_FIFO 25-Oct-2017 10:26:18 MultiThreadedConnector :: transfer, bytes 0 25-Oct-2017 10:26:18 MultiThreadedConnector :: ThreadData :: threadFunction, was (thread, priority, type): 0x1e354c0 4 SCHED_FIFO 25-Oct-2017 10:26:18 MultiThreadedConnector :: ThreadData :: threadFunction, now is (thread, priority, type): 0x1e354c0 1 SCHED_FIFO 25-Oct-2017 10:26:18 MultiThreadedConnector :: ThreadData :: threadFunction, now is (thread, priority, type): 0x1e354a0 1 SCHED_FIFO cannot complete execution of the processing graph (Resource temporarily unavailable) zombified - calling shutdown handler 25-Oct-2017 23:35:47 JackDspSource :: shutdown_callback 25-Oct-2017 23:35:48 MultiThreadedConnector :: transfer, can't read 25-Oct-2017 23:35:48 4061196288 bytes transferred to the encoders cannot read result for request type 2 from server (Connection reset by peer)

jackd says:

subgraph starting at ecasound-01 timed out (subgraph_wait_fd=11, status = 0, state = Triggered, pollret = 0 revents = 0x0) pp: cannot clean up byte from graph wait fd (Resource temporarily unavailable) bad status (-2) for client darkice-50006 handling event (type = 5) unknown destination port in attempted connection [darkice-50006:left] unknown destination port in attempted connection [darkice-50006:right] unknown destination port in attempted connection [darkice-50006:left] unknown destination port in attempted connection [darkice-50006:right] unknown destination port in attempted connection [darkice-50006:left] unknown destination port in attempted connection [darkice-50006:right] unknown destination port in attempted connection [darkice-50006:left] unknown destination port in attempted connection [darkice-50006:right]

All input welcome & appreciated.

DanielEckl commented 7 years ago

Just an educated guess: I think it has nothing to do with jack. I think this might be the result of a flakey connection to the streaming server.

I assume your streaming server is remote. I use darkice only with an icecast2 running on localhost, and the remote icecast2 where the listeners are connecting to, is configured to relay the one running locally. This way darkice never has any connection issues, and all network issues to the outside are 100% self healing.

BillGoldsmith commented 7 years ago

No, darkice is pointed toward a local Icecast server. I always set things up the way you describe, with the public servers relaying a private server running on the encoder host.

DanielEckl commented 7 years ago

I see. Next question: Since the affected component is the MultithreadedConnector, do you use one darkice process for all streams? If yes would you mind trying one darkice process per stream instead?

BillGoldsmith commented 7 years ago

Good suggestion. Trying it now with just one stream.

BillGoldsmith commented 7 years ago

Unfortunately, I get the same result with just one stream.

DanielEckl commented 7 years ago

That's bad... I don't have a lot of jack experience, tho, so how about trying pulseaudio as sound server to work around the issue? I use it successfully for quite some time, on a headless server without audio hardware, just like you.

If that fails, too, then I think I'm out of ideas and hope for the devs to help. But they were rather quiet for some time now.

BillGoldsmith commented 7 years ago

@DanielEckl - I appreciate your input. Not too many folks have direct experience with this sort of thing -- & the willingness to share it.

I'm unclear as to how you'd route audio from the source to darkice using just pulseaudio (or alsa). In my development setup, jack performs that function -- but obviously I'm missing something.

DanielEckl commented 7 years ago

The concepts of pulseaudio clearly are quite different to jack. WHile jack follows the "cable" approach where you connect things, pulseaudio uses the sink/source model. It has sinks which is a destination you can play audio at, like your soundcard. And it has sources, which means something you can get audio from, like the line-in of your soundcard. Now this does not neccesarily have to be a soundcard, it also can be a module. depending what it does, this module can provide sinks and sources for other modules, players or recorders to connect to.

My setup is that I create a "null" sink and my player plays to this one. The "null" sink basically receives any audio played at it and discards it. Now pulseaudio automatically creates "monitoring sources" for each sink where another application can get the audio that is played to this sink.

So while my player plays to the "null" sink, my darkice uses "null.monitor" as source and this way it records what my player is sending.

If that's stable you still can go on with the multi-process approach and use one darkice process for every different stream. Every darkice process has it's own config file, getting audio from null.monitor source, encoding it as configured and this way your setup should be possible with pulseaudio.

EDIT: You also can use one darkice process for all your streams, like you did before. That's independent of jack or pulseaudio. But I would recommend to use a seperate darkice process for every stream, because the multithreading capabilities of darkice are not the best and can raise the chance of instabilities in some edge cases. When you use multiple processes, the OS below will handle the threading, which should be way more robust. But your mileage may vary, so feel free to use what feels better.

BillGoldsmith commented 7 years ago

@DanielEckl - can you contact me via email? bill at radioparadise.com