Open tizo78 opened 6 years ago
is not perfectly synched with external sources
So you have a (noticeable) delay on starting the audio cue, but only the first time, right? Does this happen once for every audio cue in a session or only once per session?
Maybe there is a little dead time loading the file the first time?
I'm not sure how GStreamer loads the media files, but I think it doesn't load them all at once. I need to test with a slower drive, on my SSD I don't have any delay in starting audio cues (I've tried wave and other files).
I tried with the buffering option
Buffering is used only with network resources
So you have a (noticeable) delay on starting the audio cue, but only the first time, right?
Yes; I mean, maybe it's not noticeable when we are talking about a theater play, but I am making music, and using other sound sources. When I trigger an audio cue with a metronome for example, it's noticeable that is not perfectly synched with an external metronome that I am triggering at the same time. And this happens only the first time the audio is triggered. In fact, as for now, my workaround is to trigger all the audio cues at the begining and stop them a second later, so after that they are all "pre-loaded".
Does this happen once for every audio cue in a session or only once per session?
Don't really know. I will make some tests later, or tomorrow.
I'm not sure how GStreamer loads the media files, but I think it doesn't load them all at once. I need to test with a slower drive, on my SSD I don't have any delay in starting audio cues (I've tried wave and other files).
I am using an SSD too. Maybe the difference is what I said before (that I need more accuracy than other use cases).
Buffering is used only with network resources
Ok.
So, I've made a few test, I've consistently delays between 20 and 30 milliseconds to start an audio cue, which might not be ideal for some use cases. Most of the delay is spent by GStreamer to load the file, and probably other internal stuffs.
I can avoid this delay, it require some works, but it should eliminate the problem you have reported.
Thanks very much Francesco. I will be using something else for now, and maybe give it a try when this problem is resolved.
Hi Francesco! I recently started to use your software in a professional theater and it's totally amazing. I'm going to send you an appropriate donation right after receiving my salary. BUT yeah, I too have the problem stated above. The audio cues (16-bit wav, 256kbps mp3, flac - tested by now) start with a delay and it's significantly long (200-500 ms). You know for sure that's not acceptable in a theater show. What I do is I add a bit of a silence at the beginning of every track, but it's an ugly workaround. The delay varies, but I'm not sure what does it depend on. Still - it's always present, longer or shorter. Also doesn't matter if it's via JACK or PulseAudio or PulseAudio JACK sink. Also the lowlatency kernel doesn't help.
I run the shows on HP DV7, Linux Mint 18.3, integrated Intel audio card.
Do you have any clues? I'd be most grateful. Wojtek
I recently started to use your software in a professional theater and it's totally amazing
@ototto-wtk cool, thanks :-)
Can you explain me how you trigger your cues, and how you've measured the delay? To actually start a cue, interacting directly with the GUI, or using a virtual midi keyboard, on my laptop, LiSP takes about 20-30ms.
I use only the spacebar on my laptop, no big deal :) trying to keep things as simple as possible. About the delay - some of the tracks in a show are spoken (recorded voice) and originally it starts at the very first samples of the file. Playing back the original files caused missing first letters or a wholesyllabe - in speech it's easy to notice. I kept adding the silence longer and longer at the beginning of the file until it worked well. The silent part is about 200-300 ms long, but LiSP still eats some voice sometimes. I admit that 500 ms is an exaggeration, sorry for that, but even 300 ms is long enough to bother me.
Thank you for the quick response, my friend. Take care! :)
@ototto-wtk sorry for the late replay. The problem you are describing is different than the one initially discussed in this issue.
With delay I mean that the track start, correctly, but with a small (in theory) gap between the user interaction and the actual track start playing. In your case the track starts with few milliseconds truncated, which is, for obvious reason not acceptable :-)
Your problem is likely related to some problem with the flac decoder or GStreamer, I've already experienced some strange bugs with GStreamer when using Ubuntu based distro, can you try to test it with different files and formats?
Now I feel just stupid ;) I was so sure that my problem with LiSP is known to someone elsr that I actually didn't read the thread carefully. What distro do you use/recommend? It's a pity that Ubuntu is messing with LiSP, Mint is my all-time-favourite by now. I'll pay more attention to different file types, but as far as I recall I tried wav, mp3 and flac.
I'll try to take some notes and let you know when I'm more sure about everything: exact truncation time, file format association and maybe JACK influence. thank you :)
I’ve experienced the problem: cues start after the first 300ms, and the trigger after post wait/after end is often late. I’m using the latest version of Mint, but on a 2011 4GB of RAM computer… I will try with a more powerful machine, to see if that’s related to the computer speed or not.
When I trigger a cue wav audio file the first time after opening LiSP, is not perfectly synched with external sources. After this, all the subsequent times it is perfectly synched.
Maybe there is a little dead time loading the file the first time?. I tried with the buffering option, but the case is the same (besides, this configuration is lost after opening again LiSP, although it can be seen on the lisp file).