ProppFrexx ONAIR User-Forum

The shell commands only trigger very minor events :
- changing led lights statut in studios (writing values to COM port)
- evaluating the remaining time of the current track and showing remaining time in the countdown window
- sending show infos to RDS etc

My question about audio output is that our audio I/O is Dante Virtual Soundcard. A clock error on the Dante network could possibly lock the audio output, but just for few ms.

Is there any difference in the audio stream error managment between Overlay player and DJ player ?
The stall error is only on the overlay. In 3 days logs I only got the error on overlays, nothing on DJ Player

No. No difference.

I've try to reproduce the issue on my computer. Using a PF demo, i get the exact same issue.

Here is how to reproduce :

- start a playlist
- run an overlay (no specific settings, just playing a wav file)
- disable the play channel (on/off button on the mixer channel)

At that point, the overlay is ended with a "stalled error".
02-10-26 17:04:25: Overlay 'test @2026-10-02T16:56:20' Playback-Stream Stalled (Pos1=484,5, Pos2=484,5).
02-10-26 17:04:25: Overlay 'test @2026-10-02T16:56:20' Playback finished.
02-10-26 17:04:25: Overlay 'test @2026-10-02T16:56:20' resuming playlist 'test @ 02-10-26 11:15:00' (WasAutoPlay=True, NeverAutoPlay=False, MODStream=None, ManualOperation=False).

But, when you turn off the Play channel while just playing the playlist, there's no error.
In the playlist, the current track is just paused and restarted at the current position when the Play channel is again on ON.

So, the point is, why did the Overlay generate an error while the playlist did not, in the exact same condition ?
And, furthermore, could you correct the overlay (or add an option for that) to keep the overlay waiting when there is an audio output trouble ?

Thank you for your help.

Best regards

Can you explain how your mixer setup is done, ie. how many channels you have and to what are the different players are routed.
You can for example post screenshots of the related general settings… that way, I might try to reproduce and explain.

As of now, the explanation as in my previous post would match your experience.
But I can not explain the difference between the overlay player and the DJ Players - probably due to different routings.

The setup of of the demo PF, for the issue reproduction, is just the default setup. I didn't changed anything. And in our studio, the routing settings are the defaults ones.
We just have two inputs (one for each live production studio). Studios are used as input in PF, we didn't use PF playlists etc for live productions.
And one output (the OUT). CSA output is just a continuous recording for legal purposes.

So I still don't understand why, when disabling the PLAY channel, DJ players don't skip to next track and simply continue playing, while the overlay stops.

Except, that I would always use WASAPI I can not spot any issue.
I will have to make some tests myself… to see, if I can reproduce your issue. As so far I can not.

Yes, in the Overlay-Player I have added an extra check to 'finish' any current overlay track, if it's position is not advancing for more than 1 second!
This check is not done in a regular playlist (resp.the DJ Players). There, the playback simply halts at the position and resumes, if playback continues - if .

However, the error message you posted is the only one in the entire code, so this is a clear evidence, that the file is not advancing for more than 1 second.
This is not even any buffer or temp. issue. 1 second in real-time audio processing is breaking the sound for sure.
The question is, why this is happening?
Is your WAV file maybe corrupt? Is the file maybe extra large (some file systems have issues with files bigger than 4GB - which is even the defaut WAV file size limit; even ProppFrexx supports the RF64 wav file format - not sure how you recorded such wav files).
Maybe you can send me one to take a look?
Is the same file playing fine the next time, i.e. does the issue only happen sometimes even for the same file? Or is the issue reproducible with the same file?

OK, then it may be an option to make the Overlay player "finish check" optional ?
That could be very usefull in case of audio device troubles.

And/or user notifications for errors related to audio output. Theses errors can be difficult to spot otherwise.


For the root cause, I solved my problem.
The problem was coming from Dante Virtual Soundcard. Clock sync errors temporarly disabled audio output. Setting PF output to the onboard audio device solved it. I don't have anymore Stalled errors.

So, the issue was not directly linked to files, just to the fact that, without available audio output, file playing/reading was stopped for 1-2sec.

Glad you found it.

But why make it optional?
In your case the sound breaks for more than 1 second due to your hardware or environment issues. It is always difficult to find such issues. I am
Not sure, if such an option would actually help.

It seems a rare condition, but making it optional could help in two ways.

- As a temporary safe broadcast measure
Programs/contents can still be played while you search for the audio or file error. What could take days if you need external technicians etc

- As a long term solution if your system is, by design, in an unstale configuration
For studios where people could accidentaly turn of some equipments, unplug stufs,...