FLAC stream abruptly ends when no samples are received

[Silun]

Hey there, I have tested V1.4.2, specifically the FLAC support. Great update, appreciate the additional codec! Latency is quite good with that one as far as I can tell. However, I have run into the following issue:

When selecting FLAC (16/24 Bit), the stream ends very soon after receiving no more samples. When LPCM or WAV are selected, it will just send silence rather than ending the stream. This behavior can easily be tested like so:

• Have media player 1 play some audio file to VB-Audio
• Open media player 2 to play the stream of swyh-rs on the same machine
• Pause playing the audio file in player 1
• With LPCM/WAV, player 2 will keep playing silence
• With FLAC, player 2 will complain that the stream is unavailable

You were so kind as to fix this issue a while ago for LPCM/WAV, I assume that maybe it was a fix specifically for the LPCM/WAV modules rather than the audio stream itself. I don't know if anybody will find it beneficial that the stream ends as soon as samples cease to come in, but my hardware player complains about it (and stops playing entirely).

Would it be possible to just have swyh-rs send silence in general when no samples are received? Or maybe have a toggle if some people find it useful to have streams end in this fashion?

[Silun]

Here is a debug logfile of the following process:

• Music is already playing on VB-Audio
• Start swyh-rs in FLAC 24 Bit mode
• Have second player play stream of swyh-rs at 02:24:17
• Pause music playing on VB-Audio, at roughly 02:24:20 but nothing is logged. The player shows that the stream is unavailable at this point pretty instantly
• Nothing is logged until at 02:24:43 I close swyh-rs

log.txt

[dheijl]

I'll see if I can add the silence to the flac stream too. Thanks for testing!

[dheijl]

You can test the new 1.4.3 release, it now sends silence when streaming FLAC with no sound being captured too. But because silence compresses so well considerable delays are introduced between the FLAC frames that are sent to the player, I don't know if this will solve your problem....

Edit: silence is being sent after 2 seconds have elapsed without any sound being captured, the same as it already was for WAV and LPCM.

[Silun]

Thanks for taking a look! The behaviour I am seeing is roughly like this:

• Stop playing audio
• Stream immediately gets stuck
• If I resume playing audio quick enough, my player will catch it again after a while, but play with severe delay
• If I don't resume playing audio, the stream resumes with silence after some seconds, but eventually stops playing (saying the file is unavailable)

And if I try to start playing the stream while it is in silence mode, I can't start playing it cause the file cannot be found.

It seems like maybe this issue here https://github.com/xiph/flac/issues/90 is about the same general situation? Notably this https://github.com/xiph/flac/issues/90#issuecomment-1114523864 post says it is fixed in the codebase, but there has been no release since that time. However you are probably compiling FLAC, so maybe the new function will work already in swyh-rs?

I mean, I hope I am not asking for useless busywork. WAV does work fine for me, your software has been in constant use :) FLAC just seems to perform better latency wise (as long as I don't pause anything, that is).

[dheijl]

You are right about the FLAC issue: the compression of the silence makes the bitrate too low.

Unfortunately I will have to wait for a new FLAC release, because the Rust bindings only work with the official releases.

I could replace the silence with white now noise at a very low (virtually silent) level, what do you think?

[dheijl]

Could you try the new binary in latest 1.4.3 prerelease?

I now send a faint white noise (at -60 db) instead of silence, and reduced the timeout before the white noise starts to 1 second.

[Silun]

Thank you, I have tested it!

• Audio is already playing on VB-Audio when swyh-rs is started.
• All seems fine before audio is paused.
• When audio pauses, the stream still breaks down. The player playing the stream instantly notices that the stream isn't working any more, as before.
• After a short while, it will start "playing" the silence. At the beginning of this, it will often play an audio artifact that sounds like the last few samples of audio from before the stream was interrupted. It is like a very,very short screetching sound.
• After some seconds of playing the silence, my player will complain that the stream is unavailable and stop playback.

I can actually restart the stream in my player after the disconnect in the last step, even when I have not started playing audio any more. In the previous version, I was not able to resume playing the stream without playing audio again.

Edit: Whoops, forgot the log: log_143.txt

Edit2: Also, this version is detected by Windows Defender as containing Trojan:Win32/AgentTesla!ml and Edge didn't even allow it to be downloaded, but Virustotal doesn't detect anything. It shows the tag invalid-rich-pe-linker-version, maybe that is a hint?

[dheijl]

I know about the defender false positive, nothing I can do about it. Sometimes changing something and recompiling will remove the false positive, and then suddenly it reappears....

Perhaps I should remove the noise/silence for Flac streams, as it causes nothing but trouble. I can always add the silence back later when the Flac bitrate fix becomes available in the next Flac release.

Thanks for all the testing!

[genekellyjr]

Try the latest release, it sounds like your player had a similar issue to mine and constant silence to fill the gaps will "fix" that issue https://github.com/dheijl/swyh-rs/releases/tag/1.4.5 ! Make sure to run 1.4.5 swyh-rs first to make it add the InjectSilence boolean to the config.toml, then edit InjectSilence in config.toml to True.

[dheijl]

@genekellyjr unfortunately flac will compress the silence so efficiently that the gap between successive flac frames becomes too big for the receiver. A future libflac version could fix this it seems. But perhaps it's worth a try.

[dheijl]

I'm closing this as it's probably no longer relevant.