Closed Digitalone1 closed 5 years ago
I am not sure I understand what you mean by pulseeffects toggles and untoggles its sink repeatedly
. I imagine you are talking about the mpv switch in PulseEffects interface. Our virtual sink has no toggle.
Looking at the logs I do not see any mention to mpv being enabled/diabled. So it does not feel like it was its switch that was being toggled. What is odd is the amount of times PE pipeline alternated between the playing and the paused state. This was probably caused by mpv alternating between play/pause. I know that it alternates between these states when we do seeks in the video. I imagine it also does that when alternating tracks.
In PulseEffects we only ask Pulseaudio if the app is playing or paused and update our pipeline state accordingly. All other interaction is done between mpv and Pulseaudio. All that info you gave about the tracks is relevant to Pulseaudio. Not to PE.
Does the same happens in vlc?
I am not sure I understand what you mean by
pulseeffects toggles and untoggles its sink repeatedly
. I imagine you are talking about the mpv switch in PulseEffects interface. Our virtual sink has no toggle.
To be sure pulseeffects is running, after I start mpv I take a brief look to kmix to see if pulseeffects sink has been loaded. mpv does not start to play automatically, so I switch to the second track, take a look to kmix and then I start to play the video. This time when I take a look to kmix, I see pulseeffect sink to appear and disappear (output hardware sink and mpv sink stay untouched). This lasts 4-5 seconds.
This happens only when I switch the track. If I start mpv with the argument --aid=2
, it will automatically load the second track and this behavior will not occur.
I also tried to change the track during the playback and it does the same behavior, but at least it lasts shortly and then the audio is played properly.
Looking at the logs I do not see any mention to mpv being enabled/diabled. So it does not feel like it was its switch that was being toggled. What is odd is the amount of times PE pipeline alternated between the playing and the paused state. This was probably caused by mpv alternating between play/pause. I know that it alternates between these states when we do seeks in the video. I imagine it also does that when alternating tracks.
In PulseEffects we only ask Pulseaudio if the app is playing or paused and update our pipeline state accordingly. All other interaction is done between mpv and Pulseaudio. All that info you gave about the tracks is relevant to Pulseaudio. Not to PE.
So do you think this could be an mpv issue in alternating its state during the audio switch?
Does the same happens in vlc?
I don't use vlc from quite a lot of time. I'll try just out of curiosity.
Installed vlc. It does the same behavior. Pulseeffects sink appear and disappear from kmix for about 1-2 seconds. I can test it only during playback, it's strange but with all its preferences, vlc has no option to load a file without autoplaying.
So it's not an mpv issue. Maybe something related to ffmpeg?
And it does the same also with the first series of videos during playback. With both vlc and mpv.
It's not a critical issue, it lasts only 1-2 sec, but I wonder if the player could be really the culprit. Could be also a pulseaudio issue?
I wonder what kmix is really doing. PE tries to load its virtual sinks only once. So if they are removed for some reason our audio routing will be totally broken. And nothing in PE will try to reload them. My guess is that kmix has some issue when listing virtual devices. Or it is applying some kind of strange criteria to show them.
In any case this could be a signal something is not alright with Pulseaudio. The sinks are clearly still there. Maybe the video players are just triggering an issue in Pulseaudio install that is reflecting in this weird kmix behavior
I wonder what kmix is really doing. PE tries to load its virtual sinks only once. So if they are removed for some reason our audio routing will be totally broken. And nothing in PE will try to reload them. My guess is that kmix has some issue when listing virtual devices. Or it is applying some kind of strange criteria to show them.
It could be, but you also saw the strange alternating from play/pause states inside the log, I don't think it's a kmix issue. Could you test with mpv/vlc and a file with two audio tracks?
If there is such a weird transition from play to pause during track switch, it could be also be an issue deriving from ffmpeg (both mpv and vlc rely on it) or pulseaudio.
My mkv files have only one track
Is there a free sample somewhere?
My mkv files have only one track
Could you download a file with two audio tracks? ^^''
Is there a free sample somewhere?
No, I could send to you a link to download one file of the series, but not here.
Send to my e-mail wellingtonwallace@gmail.com
Send to my e-mail wellingtonwallace@gmail.com
Sent. Check inside spam if you won't get notifications.
It happens on my computer too. With both players. So far what I am doing is taking a look at Pulseaudio logs as explained here https://github.com/wwmm/pulseeffects/wiki/Reporting-Bugs.
As Pulseaudio logs are huge it is a pain to find what is relevant but so far it seems to be what I thought. PE pipeline is alternating between play/pause
because the players are doing that when they change tracks. It seems to be the way they handle this operation. I will try to look at the logs more carefully but it really feels like this is the explanation.
I don't have how to test kmix but at least in Pavucontrol nothing disappears. As I would expect.
On a second look it seems that what the players really do is to kill their playback stream and then start a new one. From PE point of view there is no difference as in both cases Pulseaudio reports that the app (sink input) is corked(paused)
or uncorked(playing)
.
Pulseaudio does this because before the player kill its playback stream it has to finish it. What probably makes the stream to be corked before total destruction.
I am not sure if there is even a workaround I could do. Pulseaudio only tells me that the app was corked or uncorked. It does not tell the reason. So there is not a way I can know if it was a track change or a play/pause
initiated by the user
I am looking at your logs again and now I am not so sure I can reproduce your issue. In my installation moving from track 1 to track 2 results in PE pipeline alternating between playing/paused
2 or 3 times. In your log this happens more than that. Did you switch tracks multiple times when taking the logs? If not then something is not right. This is what is added to my logs when I change tracks once:
I did the tests during playback. On my computer mpv plays the video as soon as I double click the file.
On a second look it seems that what the players really do is to kill their playback stream and then start a new one. From PE point of view there is no difference as in both cases Pulseaudio reports that the app (sink input) is
corked(paused)
oruncorked(playing)
.Pulseaudio does this because before the player kill its playback stream it has to finish it. What probably makes the stream to be corked before total destruction.
And this makes me think that kmix is hiding corked sinks, because I have just noticed that when I pause the playback, pulseeffects is not shown in the kmix tray applet. But Pulseeffects is loaded and mpv is shown in app lists inside PE GUI. To reappear, I have to restart the playback and I can see Pulseeffects inside the applet. (To be more clear, for "restart playback" I mean restart from the point I paused, not restarting from the start.)
This explains why PE appear and disappear when I change the audio track. But now I wonder why it's happening only to PE. If this is the way mpv and vlc handle the track switch, why only PE is appearing/disappearing?
It's not a critical issue, you know, it's just to understand why it's happening and why it won't happen to player sinks (mpv/vlc).
I am looking at your logs again and now I am not so sure I can reproduce your issue. In my installation moving from track 1 to track 2 results in PE pipeline alternating between
playing/paused
2 or 3 times. In your log this happens more than that. Did you switch tracks multiple times when taking the logs? If not then something is not right. This is what is added to my logs when I change tracks once:short log I did the tests during playback. On my computer mpv plays the video as soon as I double click the file.
Yes, that happens to me too because the play/pause alternating during playback lasts very shortly as I already said.
It lasts more (about 4-5 seconds) when the track is switched when mpv is waiting to start the playback. To reproduce on your system, just start mpv with --pause option (autoplay disabled):
mpv --pause filename.mkv
or add pause
to ~/.config/mpv/mpv.conf
.
Another strange thing is that when I pause the playback, PE sees mpv paused and kmix hide PE sink from the systray applet, but when the video is paused in the initial state at 0 seconds (waiting to start in autoplay disabled mode) PE is seeing mpv in playing state and kmix is showing PE sink in the applet. It's totally weird.
p.s. can you tell me how you did that log text format? Thanks.
I want to share another behavior comparing mpv and chromium.
When I pause mpv, PE is immediately hidden from kmix systray while mpv stays there until I shut it down.
When I pause a video inside chromium (youtube or other) this is what happens:
PE reappears as soon as I restart the playback (from the point I paused, and in the second case, also chromium reappears).
I agree it is not critical. But it is still good to understand what is happening :-)
My guess is that kmix handles virtual sinks(null sinks in Pulseaudio terms) in a different way than hardware devices. That is why it would only happen when PE is used. If it is a kmix bug or a feature I have no idea.
Chromium/Chrome seems to handle audio streams in a different way. I do not remember exactly under which circumstances I noticed this. But they do not recreate the audio stream as often as mpv does.
I formatted the log as shown in our Basic Logs
section in the wiki https://github.com/wwmm/pulseeffects/wiki/Reporting-Bugs. The trick is combining <details>
and <summary>
.
Sure but I don't think there's something you can do. The weird thing is why players are alternating their state more than one time when switching an audio track.
Did you try with mpv in autoplay disabled mode? In that case the alternating is performed even more times.
I was thinking at an ffmpeg issue. It's the only library that links mpv and vlc (and even browsers like chromium). On Linux audio/video decoding is only done by ffmpeg.
I have just done a test with mpv --pause
. Here it is even worse. PulseEffects entered in an infinity loop alternating its pipeline state. I had to kill it.
After this bizarre experience I decided to do something I should have done before. Looking at Pulseaudio's logs when PE is not running and mpv is playing directly to my soundcard. It is insane! MPV changed its stream state 594 times
when I switched from track 1 to track 2. Lots and lots of lines like
[alsa-sink-ALC1220 Digital] sink-input.c: Requesting rewind due to uncorking
No wonder switching tracks is causing problems.
I still think the answer is in the way they are interacting with Pulseaudio. I have never written an audio app. But I imagine that they have to create streams https://freedesktop.org/software/pulseaudio/doxygen/streams.html. As far as I know you can't change things like the number of channels after the stream has been created. So you would have to kill it and create a new one when changing tracks. My guess is that something is going very wrong when they do this.
And by the way when you use mpv --pause
Pulseaudio reports mpv stream state as uncorked. So what mpv is really doing is playing silence.
I have just done a test with
mpv --pause
. Here it is even worse. PulseEffects entered in an infinity loop alternating its pipeline state. I had to kill it.
Are you sure? That's different from my behavior. It lasts 5-6 seconds to me, not infinite.
And by the way when you use
mpv --pause
Pulseaudio reports mpv stream state as uncorked. So what mpv is really doing is playing silence.
In fact, when mpv is waiting the user to start, PE app list reports mpv as "playing". While it's reported "paused" when you pause in the middle of the playback.
Looking at the mpv documentation, maybe I found the culprit. It something similar to gapless audio.
That feature does not handle the subject we are discussing here (it's related to audio file switch when a playlist is played, in fact trying to change its value will not resolve the issue), but I think it gives an hint on how mpv handles the audio track switch.
To put it simply, mpv always tries to keep audio device open during a track switch. As you said, you can't change format when a stream is set, so if you necessarily need to change audio format, you have to kill the previous stream and open the next one. Therefore if audio tracks have the same format, mpv will not kill anything, it just tries to keep the device open, maybe playing silence while the track is switching and that implementation results in frequent alternation in corked/uncorked state.
The proof is that the first series of videos does not have this issue as a mentioned in the previous post here. That's why that series had first track with 6 channels and second track with 2 channels. So, during switch, mpv is forced to kill and reopen a new stream and I was seeing nothing weird.
The second series has 2 channels in both audio tracks, so mpv will not kill anything during switch and that causes the weird issue I noticed and reported here.
But that's not all. Looking at mpv documentation I also found another interesting option just under gapless audio: no-initial-audio-sync.
Surprisingly, setting that option will partially resolve the issue because I'm very rarely seeing PE appearing/disappearing in kmix. It's not happening at all or, if it's happening, it lasts very shortly, just only 100 ms or even less. As the documentation says:
When starting a video file or after events such as seeking, mpv will by default modify the audio stream to make it start from the same timestamp as video, by either inserting silence at the start or cutting away the first samples. Disabling this option makes the player behave like older mpv versions did: video and audio are both started immediately even if their start timestamps differ, and then video timing is gradually adjusted if necessary to reach correct synchronization later.
So the default implementation that tries to keep the audio/video synchronization leads to frequent alternating in audio state, while the older implementation (which does not keep the sync and gradually adjust the playback speed to reach the correct sync later) will not cause that weird issue.
Can you test on your system and see if it's behaving like on mine?
I think I waited for almost 30 seconds. At this point I gave up and killed PE.
Yes. Using --no-initial-audio-sync
makes a huge difference. Now mpv changed its stream state only 4 times
.
By 4 times
understand this sequence of actions:
corked
uncorked
corked
uncorked
I'd say this is acceptable. Way better than having 594
.
This resolves the issue but introduces the disadvantage of the missing synchronisation.
I tested it and the desync is very noticeable when I seek in the middle of the video. Then it goes in sync, but that happens very slowly. Unfortunately I think this is not a real solution.
Do you think the alternating between corked/uncorked is an mpv issue? Maybe I can try to file an issue on their git for this, but I'm not really sure because maybe that's the only workaround to get synchronisation on seek using Pulseaudio (considering that the same behaviour is reproducible with vlc).
I don't know. It could be a bug considering that the problem only happens when switching tracks. But at the same time it is possible that they have no other way to implement this feature. In any case it is worth asking.
No, it's not happening only when switching track during playback, it's also happening on seek (but for a short time) and switch track on waiting to start in autoplay disabled mode (this lasts longer and in some cases is an infinite loop).
This is resolved using --no-initial-audio-sync
option, but it's not a good solution because synchronization is lost on seeking.
I also noticed that PE app sink appears and disappears in the volume manager after I close mpv.
And that's not all. I'm using kmix because I prefer it, but the default volume manager in Plasma is plasma-pa that is specific for plasma and it's the primary volume manager shipped with the most notable distro using KDE (KDE Neon, Manjaro KDE, etc.)
I installed plasma-pa and removed kmix and unfortunately that behavior is happening the same in plasma-pa, so that issue is reproducible by all users using Plasma Desktop.
Anyway I will try to open an issue on mpv github.
This is how to reproduce the loop after closing mpv. Open with mpv the mkv file with two audio tracks (of the same channel numbers) in autoplay disabled mode. Change track and close mpv. Pulseeffects goes in loop appearing and disappearing into the volume manager. mpv process is terminated, not present in process list.
Here is the log, that lasts almost a minute.
And this is when mpv is shut down after switching track during playback. As you can see, that lasts shorter than the previous case, but the issue is present:
It seems that the latest git is not causing the issue. I found out that upstream mpv package is very old getting the release of the last October 2018.
I have to test it, but can't compile now. @wwmm if you can do it, please let me know. Thanks.
So, did the compilation (it took less than I expected) and it's the same also with the latest git.
mpv --no-config --pause
File with 2 tracks, one 5.1, the other 2.0.
Only 4 changes.
File with 2 tracks, both 2.0.
154 changes. I'm suspecting that the second file is broken, but the first one is not broken and the issue is present also with only two changes. Another thing that I didn't mentioned is that while doing this some audio frames get dropped.
The first file with pulseeffects:
8 changes, but more considering due to latency
Neither the latest git resolved the issue, I'm giving up, I've blacklisted mpv inside PE. Once blacklisted mpv is more smooth and does not loose audio frames while switching track or seeking.
It is sad but I don't see another option other than blacklisting it. I use mpv too but on files that have only one track. And I never noticed problems while doing seeks. But it makes sense that some audio frames will be lost. Some buffering has to be done by GStreamer's pulsesrc
plugin used in PE pipeline. When PE restarts its pipeline the frames in these buffers are probably going to be discarded. How noticeable this will be depends on the buffer
, latency
and blocksize
parameters value. All of them have some kind of influence over the amount of buffered data.
Yes, it's sad, anyway I managed to load a pulseaudio module-ladspa-sink with the calf-ladspa stereo compressor and mpv it's more smooth. It's a difficult solution to build, I spent half a day to understand all the parameters, but when it's setup and loaded I think it's the best solution if someone is interested in compression only. I also used maximizer in PE, but I can increase the gain with the makeup option to get the same behavior.
With this configuration mpv works good and also other applications can use the ladspa-sink when set as default. So sadly I don't need Pulseeffects anymore. But if you need help with Italian translations, contact me and I'd be happy to help. :)
Ok :-) As I can not fix the source of this issue I will close it.
Hi @Digitalone1! I have been doing some changes to how PulseEffects pipeline is updated that could unintentionally serve as a workaround for this. Now I do not update the pipeline state immediately as soon as there is no app playing audio. A timeout of 5 seconds is used and if after that there is no app playing PulseEffects will pause its pipeline. I know you found another solution but it would be good to know if this makes the current mpv situation more bearable
I forgot to say that master branch has to used for testing.
Hello @wwmm I will give it a try.
Could I test it installing the AUR pulseeffects-git? Master branch is used for it, right? It's easier to me installing from the AUR rather than cloning and doing the compile stuff.
Yes. Installing from AUR should work.
Hello @wwmm, tested it and it's a very BIG improvement.
Resolved the issue in volume manager, pulseeffects sink is not appearing-disappearing.
There is no audio frame loss during seeking. There's a very small loss during track change, but now it's quite unnoticeable while it was very noticeable before.
It's good and also new tab with pulseaudio config is beautiful.
Anyway, I think I'll remain with calf module-ladspa-sink compressor because I feel it's a little bit better than lsp sidechain compressor. Maybe if you will add also calf compressor I'll surely return to use it. You already used it right?
It would be good to have a simple compressor and a sidechain compressor, but it's your choice. Good job anyway. ;)
It is ok :-) Good to know there was improvement :D
We used to have Calf compressor and their multiband compressor is still in PE. But at some point I started to like lsp compressor more. But there are other arguments besides personal choice. Calf compressor does not have the upward mode that could be useful in some situations and for reasons that are beyond me GStreamer can not load any Calf plugin that provides sidechain. My guess is that Calf implements sidechain through LV2 extensions GStreamer does not support. So in the end the overall feeling is that you have access to more features using lsp compressor.
It is obviously possible to add more compressors. But in my opinion PE should have as many features as possible while using less plugins as possible(I admit I am being a little lazy kkk XD :D). Duplicated plugins for the same task means more interface to write and maintain, maybe more bugs, etc.
Okay, no problem. I think Calf compressor is simple to use because it's no-sidechain. Instead sidechain is difficult to understand, neither in this moment I haven't got the real difference between feed-back mode and feed-forward mode, apart that feed-back sound is better. But in the overall experience, I felt Calf simple compressor sounds even better, but maybe it's a placebo effect.
Calf suite has also sidechain compressor in another plugin. I'm not a programmer expert, but if lv2 interface is a problem to you, there's a port of Calf plugins in ladspa interface on the AUR, the one I used for module-ladspa-sink.
Bye. ;)
Hello, I used to view a series of mkv videos selecting the second track through mpv player. Everything well.
Now I have another series of mkv videos and something weird happens. When I change from first to second audio track, pulseeffects toggles and untoggles its sink repeatedly for 4/5 seconds.
I captured a log. This tracks when I start PE, launch mpv selecting the mkv file, then change the audio track. At the end I close PE. https://pastebin.com/rAYfp8d6
I wonder why it's happening only with the second series of videos. I thought at an mpv issue, but if it were its problem, it should work bad also with the first series.
These are the audio tracks of the first series:
And these for the second: