I have had 13.1 installed since the Beta, and just updated to each new version as it came up. At some point after an update, PulseAudio started acting rather strangely: all sound is delayed by about 1 second. So everything is not synced: videos, game audio, etc. Also, in pavucontrol, I can also see the volume meters going up one second before I actually hear the sound. There are no latency offsets specified in pavucontrol for any sound devices. Also, restarting PulseAudio (pulseaudio -k) makes it work fine again, without a delay, until a reboot.
The system logs only show this (this is a clean boot, without restarting the daemon after boot):
> sudo journalctl -b | grep -i pulse
Lap 07 11:07:08 mahobay rtkit-daemon[1110]: Successfully made thread 1109 of process 1109 (/usr/bin/pulseaudio) owned by 'dainius' high priority at nice level -11.
Lap 07 11:07:09 mahobay rtkit-daemon[1110]: Successfully made thread 1115 of process 1109 (/usr/bin/pulseaudio) owned by 'dainius' RT at priority 5.
Lap 07 11:07:09 mahobay rtkit-daemon[1110]: Successfully made thread 1116 of process 1109 (/usr/bin/pulseaudio) owned by 'dainius' RT at priority 5.
Lap 07 11:07:15 mahobay rtkit-daemon[1110]: Successfully made thread 1360 of process 1360 (/usr/bin/pulseaudio) owned by 'dainius' high priority at nice level -11.
Lap 07 11:07:15 mahobay pulseaudio[1360]: [pulseaudio] pid.c: Daemon already running.
Lap 07 11:07:15 mahobay rtkit-daemon[1110]: Successfully made thread 1364 of process 1364 (/usr/bin/pulseaudio) owned by 'dainius' high priority at nice level -11.
Lap 07 11:07:15 mahobay pulseaudio[1364]: [pulseaudio] pid.c: Daemon already running.
From sound devices, I’m using a Creative X-Fi card as the primary sound card, an integrated Intel Azalia chip (although I have it disabled in Phonon) and also have a Logitech USB microphone (snd-usb-audio) connected.
Have you checked the status of the settings in YaST > Hardware > Sound or tried any command level ALSA tests?
You could spend much time on trying to diagnose, when a clean install of RC2 or the final release might save time. You could first try disabling pulseaudio via YaST and reinstalling all the P/A packages.
The settings in the Sound module seem to be good. I could try and reconfigure them, though. No, I haven’t tried any ALSA tests, since I don’t know what test could help in this case.
I’m not sure that making a clean install would be faster… It takes a long time to customise and install all of the software, and I have already done that since Beta. If anything, it would be faster to just make a systemd job that restarts PulseAudio on every boot… And I suppose I can try the reinstall method as well.
In YaST > Sound, there is a sound test in that “Other” menu. Do you get the same delay running that test?
The stickies at the head of the Multimedia forum contain some help and links to further guides, e.g. SDB:Audio troubleshooting - openSUSE. Towards the end of that guide is “Some Magic” including some low-level alsa command line utilities e.g. aplay (see its man page for more detail), which IIRC will use alsa (i.e. below P/A). I will leave you to browse the guide and its sub-links, but may be little there to assist this problem. The idea was to isolate P/A as the source of the problem or not.
I’m not sure that making a clean install would be faster… It takes a long time to customise and install all of the software, and I have already done that since Beta. If anything, it would be faster to just make a systemd job that restarts PulseAudio on every boot… And I suppose I can try the reinstall method as well.
I understand, only you can judge that, especially if additional repos were to be present. The re-install P/A method may not be as easy as it sounds, due to complaints re dependency violation.
There is always the “zypper dup” option to affect a repair, but beware of additional repos and packages. It’s usually safer with just the four standard repos (plus Packman arguably).
I’m pretty sure aplay still goes through PulseAudio, unless pasuspender is used or PulseAudio isn’t running. Given that restarting PulseAudio makes the delay go away, I’m pretty sure that without it running there will also be no delay. But I’ll test that after restarting.
Yea, I regularly update all my system packages when using the development versions of openSUSE (Apper kind of makes it a point to remind me to update it regularly ). I did upgrade PulseAudio as well a bit back, already after the issue appeared, but it didn’t fix the problem.
And I ran some of the tests, and the results are pretty much as I expected. aplay, paplay and Phonon tests all have delay. The test in YaST does not have any delay (and it doesn’t appear on pavucontrol, so I guess YaST talks to hardware directly).
I also tried to test it by switching to the internal Azalia chip; it produced no delay, but when I switched back to X-Fi, it produced no delay as well. So I suspect that changing the sound device profiles also makes the problem go away until next boot.
Well obviously IDNRC re the aplay etc. tests. Although they are still useful for isolating problem audio apps. The YaST test still has a role, it seems.
If you haven’t already, it might be worth adding an additional new userid, and test when the delay has returned to the normal userid. It’s a relatively quick procedure, and may expose KDE4 settings issues wrt the current userid. That makes me wonder if your user is a member of “audio” group? It can make a difference in certain situations (e.g. needed for Jack sound server).
I already mentioned that I do the 1st part regularly, I already have done the 2nd part, and I am aware of the things mentioned in your blog post. The script I haven’t tried, but it doesn’t seem like it would have anything useful for my case. But I might try it later on.
I just found out something else interesting. It’s very peculiar, actually. As I mentioned, there is no delay if I switch to the integrated card, and it stays like that if I switch back. It is indeed connected to sound profiles. If I have both of my cards set to output (or duplex), then I get no delay. However, if my integrated card is turned off or set to input, I get the delay issue. Very odd.
I deconfigured all the cards and reconfigured my X-Fi, leaving the others unconfigured. But it seems that Phonon and PulseAudio don’t care if it’s configured or not – if it’s plugged in, they’ll use them, and there is no way to actually delete them, aside from physically unplugging.
Having both cards active adds to the complexity needlessly, but at least it’s a workaround that doesn’t involve killing PulseAudio on every boot. That’s a start.
No, my user isn’t part of the Audio group. And I’ll give a new user suggestion a try.
And now I tried that, and while adding the audio group doesn’t do anything, you’re right that a new user works fine. That’s very interesting. I deleted my ~/.pulse directory, but it didn’t do anything, either… I wonder what might be causing this strange and peculiar issue.
(Huh, 10 minute edit limit… That’s not particularly nice to thread lengths.)
That figures since I think Phonon maintains it’s own configuration data, getting info on hardware devices from “Solid” (features a lot on KDE4), and the backend (gstreamer is still the default in 13.1 with KDE 4.11.2). That is why I suggested the new userid test, since KDE/Phonon are very much involved in the audio stack, and the multiple devices may complicate matters there. KDE’s support for P/A relies on what you see in Phonon settings and KMix.
Ugh. So I tried every suggestion. I removed all the related directories from ~ to see if setting things back to default would solve the issue. Then disabled PulseAudio, reinstalled it, enabled it again. No effect. It’s still having delay like that.
I’m tempted now to create a new user and just copy over the files from this one there, then see if things are the same or not…
If that does not work, you should restore it back to how it was.
And another approach (more consistent with a new user not having a problem) is to instead try to move /etc/xdg/autostart/pulseaudio.desktop to your homedir and reboot your computer.
Very confident. I tried it a dozen times: logging into my user, the sound has delay. Logging out, logging in with the test user, the sound has no delay. Logging out and logging in with my user, sound has delay again. Again relogging with the test user, sound has no delay once again. No matter what I changed the new user never had sound delay, and my current user always had sound delay.
Even if disabling timer-based scheduling did work, I can’t use it because it completely breaks Wine.
Move the file as in remove from the original directory? All right, I can try that.
And moving the files out of the xdg directory didn’t do anything, either. Though it makes me wonder what they’re doing there to begin with, shouldn’t PulseAudio be managed by systemd instead?
I don’t know anything about systemd to ask such a question nor to answer such a question (wrt appropriateness). I do believe the test harmless as it can be easily restored afterward.
I also believe the wording ‘move’ from the original reference I quoted, and also in my post (where I copied from the original) can be misleading, and ‘copy’ is the more accurate instruction. I hope copy, followed by a reboot is what you tried.
This reference refers to an arch linux approach which may not be appropriate for openSUSE.
AFAIK the pulseaudio daemon runs for every user (with user permissions), so it is not managed by systemd.
The .desktop file is in /etc/xdg/autostart so that the daemon is started for every user at login.
You really should move the file back to that directory. If you move it to your user’s home dir, the daemon is only started for this particular user but not for others.
This cannot be the reason for your problem anyway, since a new user didn’t have the problem.
Have you tried to remove KDE’s phonon config?
Should be somewhere in ~/.config I think.
Its a bit puzzling to read that your nominal user has the problem, but a new user does not. That really suggests that something in the /home/yourusername configuration has caused this. Without knowing any past changes made, intentionally or unintentionally, it is difficult to understand what is causing this.
). I did upgrade PulseAudio as well a bit back, already after the issue appeared, but it didn’t fix the problem.