-
-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.2.0 has strange issue with source.say_metadata #3181
Comments
I have the exact same problem, and it has been boggling me for months, at least. If I can help with any code examples, please let me know. |
I can also provide a code example but really, in my case, it's as dead simple as it can be made:
Nothing fancy, no ladspa effect, no complicated or involved setup. It's as basic as I can make it. |
Reproduction script:
|
If this only happens with FLAC files perhaps Liquidsoap is using two different measurements for track length somewhere? Or perhaps an error is accumulating between queued tasks and the real clock? |
I have a local Liquidsoap instance making the radio feed from a mp3 library and mixing with an external TTS program for metadata announcements, and am sending with SRT to another remote liquidsoap which is making an AAC HLS stream. I am mainly sending over SRT with opus, but have tried with various containers and formats and the problem persists. The TTS will gradually start earlier and earlier as reported above. I am also using replaygain via metadatatag, and when the rest of the song is played it is without replaygain, so this can maybe indicate where in the process the bug is located. |
That's interesting. So, the issue happens at the liquidsoap with ogg/opus audio, correct I'm confused though, I thought the tts was mixed in with the mp3 feed, before it ever reached the second liquidsoap instance?? If so that means it could be an issue with the ogg container handling itself... Fwiw, I don't use replaygain at all over here. I've tried mp3 instead of flac and as far as I could determine here, there were no such cut. Maybe I just got lucky? |
Hereunder is an example script I am using where the TTS speaker will gradually start earlier and earlier when announcing the metadata of the last song played. After some hours it becomes noticeable. It does not matter which of the encoders or formats I use in OUTPUT SRT. The remaining part of the song is played without replaygain, so something like an error between queued tasks and the real clock in the first instance could sound likely. Nevermind the intricate TTS code. It is a local docker TTS daemon which is fed curl and returns the output WAV filename, e.g. First local instance:
Second remote instance:
|
It's most likely due to the new buffer code getting out of sync between audio and metadata. I would like to fix it before the release but I can't hold it up for too long for it. A full reproducible example (with files if needed) would really help. I'll have another pass at the the code tomorrow see if I can see anything obvious. |
Don't hang me up on it, but I would say I have experienced the bug about half a year. |
Could this be git bisected?
…On Thu, Jul 20, 2023 at 08:27:58PM -0700, Romain Beauxis wrote:
It's most likely due to the new buffer code getting out of sync between audio and metadata. I would like to fix it before the release but I can't hold it up for too long for it. A full reproducible example (with files if needed) would really help. I'll have another pass at the the code tomorrow see if I can see anything obvious.
--
Reply to this email directly or view it on GitHub:
#3181 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
@joe-ms I'm looking at this again. I'm gonna run a shorten version of your script to see if I can reproduce. Are you yourself in a position of trying to prune down that script? First thing would be to see if the delay still happens when doing a local output instead of srt. |
@toots Yes, I've been trying a few times to reproduce locally in a single script without any luck yet. So perhaps the time slip could be related to the network stream e.g. srt or icecast. Mind in my experience it will take hours before the slip is audible. If you wanna hear a live example of the bug try www.radioxound.com. I have just restarted, so it will gradually become more and more audible. |
@joe-ms I can definitely hear it. I haven't been able to figure out where/how this can happen yet but I'm actively looking at it. |
@joe-ms do you have logs to share around a transition that has the issue? Anything with |
@joe-ms I'm working on a scripted rewrite of
|
@toots Hereunder a log around a transition between two songs from a script similar to "first local instance" mentioned above. Thanks, I will give your
|
@joe-ms Should definitely be possible! Actually you made me remember that Lastly, it would be better to try with the branch rather than dropping the |
FWIW, I'm still experiencing the issue, even with the append operator rewritten as a script. I've been toying with the idea of making ls skip blanks to see what would happen, but I don't know if that would help trigger it faster or not. My theory is it's inaudible on a lot of songs at first, because they happen to have blanks at the end. If there was no blank, maybe it would become audible faster. What do you think? |
@joe-ms have you had any luck with the new scripted operator? |
@toots I have tried to let it run a few times overnight, and now the TTS append is played very seldom (but not time shifted), even though it should be called after each track. |
Here a log. It jumps directly from the first song to the second song without TTS.
|
Have just added to #3334 because it may be that #3334 is repaired, but this issue #3181 could be persisting. Here's my note on #3334. Using Liquidsoap 2.2.1+git@de9dc76 (the last commit to rolling-release-v2.2.x) Music crossfades from the playlist are still ok after 12 hours. But the problem with inserted files, via the request mechanism over telnet, persists. (Edit: I'll mention #3181 because this might be the problem in question.) An incoming inserted file plays over the last second or so of the outgoing music (before the liq_cross_duration would allow the next track in version 2.1.4). Then, after the inserted file, the last second of the previous outgoing file (from the playlist) plays, then the playlist's next track starts. Thank you for looking into this problem. Here's the log from around that time. The track "Gabriella's Gavotte" by John Dankworth had its last few notes crashed by the inserted 'cbsnews.mka'. After the news, the playout returned to the (almost silent) last second of the John Dankworth track. Then, without any overlap, just a silence, the Bob Dylan track began. The "cbsnews.mka" is the inserted track via the telnet request mechanism.
|
I have rewritten my tts-speaker to follow the say protocol, and with the time shift gone it all works perfectly now for my side. |
Awesome! |
Describe the bug
When using source.say_metadata to speak the metadata of each song, the metadata will get spoken sooner than at the end of the currently playing song.
Let's say you have a song playing, and you're soon at the end, about 6 seconds from it. Your audio will suddenly cut out and the decoder (libflac, ffmpeg...) will decode and send the audio for the metadata to liquidsoap, which will then be played on icecast. After this, your song will then resume and finish its actual playback with the few seconds of it remaining. It will then jump to a new song, and do this all over again when this new song is close to ending. It appears this issue is easier to reproduce with ffmpeg decoder, at least during my testing.
To Reproduce
Simply create a script which loads a minimal playlist of files, and use source.say_metadata on your source. Forward the audio to some icecast instance.
Load the stream into your favorite music player and listen to a few songs.
Try it both with ffmpeg and without. My own testing shows this is easier to hit with ffmpeg, but it is still possible to manage it without (in my case libflac). Particularly in songs which seem to have no blank at the end.
Expected behavior
I'd expect the songs to fully finish decoding before the metadata file is ever sent out to liquidsoap for playback, as interrupting the current song is very jarring.
Version details
Install method
Installed everything via opam.
The text was updated successfully, but these errors were encountered: