The switch to Plasma 5 has, in my case, brought about a curious (and annoying) issue with HDMI audio on my workstation. Initially, I discovered that my HDMI audio connections were not working, and further, Pulseaudio Control indicated them to be “unplugged”.
After much unsuccessful fiddling to try to restore them to a working state, it magically began working on a couple of short lived occasions. Searching around for a possible cause, I stumbled across https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#No_HDMI_sound_output_after_some_time_with_the_monitor_turned_off which offered up a suggestion of cycling the connected monitor/device off and back on when Pulse insists that the connection is unplugged. Wonderbar! That worked (and must have been what I had done on the earlier occasions when it had “magically” come back to life). However, I very quickly discovered that the HDMI connection would again become “unplugged” (as far as Pulse was concerned) by simply opening up KDE components (i.e. from something as simple as starting KPatience to opening Configure Desktop) … which (the opening of KDE components) might also explain why the HDMI connections are in an “unplugged” state right from the start after booting/logging into a KDE session.
So, in summary, the HDMI audio connections become “unplugged” (as described in Pulseaudio Control) when KDE components are opened. I have not yet noticed this behaviour with non KDE components (for example, all is well opening firefox, chromium, gimp, … ). In addition, the analog audio connection is unaffected and works as expected.
Has anyone else witnessed or heard of such behaviour? It strikes me that something in the Plasma 5 Phonon arena is amiss … Its possible it might be unique to the configuration of my workstation – two radeon adapters (oss Radeon stack), with separate HDMI audio connections stemming from each of those. I haven’t yet tested to see if the situation persists when one of the adapters is disabled.
I don’t use HDMI and don’t know much about it, but maybe the output (or some other setting like the “Profile”) is set wrong in Plasma 5’s Multimedia settings?
(systemsettings5->Multimedia->Audio Hardware Setup)
If it worked in KDE4, it should work in Plasma 5 too. There has not been much change in Phonon AFAIK, even the version numbers are the same…
Maybe try to VLC backend (phonon4qt5-backend-vlc) instead of gstreamer (phonon4qt5-backend-gstreamer) or vice-versa.
Not sure if it’s related to you but radeon hdmi dual-mon and audio is broken from kernel 4.03 thru 4.1-RC5, fixed in RC6 and will probably back-port to stable on 4.05.
nope, all is “well” there … I say “well” there because [rant]I’ve always despised that gui design[/rant]
If it worked in KDE4, it should work in Plasma 5 too.
yep, worked fine in kde4
There has not been much change in Phonon AFAIK, even the version numbers are the same…
okay, thanks, hadn’t even looked at such yet
Maybe try to VLC backend (phonon4qt5-backend-vlc) instead of gstreamer (phonon4qt5-backend-gstreamer) or vice-versa.
ahh, yes, good suggestion. I suspect this will yield results … I vaguely recall one of the backends giving me problems in the past (but can’t recount whether it was vlc or gstreamer).
thanks, will have a look into it … fwiw, I’m experiencing no video problems that I know of (I drive 4 monitiors simultaneously - 1 hdmi, 1 dp, 2 dvi). The other hdmi is connected to a TV, but come to think of it, I haven’t run the two hdmi connections simultaneously in a while (definitely pre-Plasma 5 and kernel 4.03 upgrade), so will look to see if I encounter any issue there … though, if it is already fixed upstream as you’ve indicated, it will just be an academic test (though colour me curious lol! )
VLC backend instead of gstreamer … nope, that wasn’t it
Does the situation persist when one of the adapters is disabled … yep … further, the observed result was kinda telling that this is more then likely a driver problem (quite possibly the one referenced above, but I haven’t checked into that yet) … specifically, hdmi audio once again was unplugged by kde component activity under this single adapter configuration. Unlike previously, (with the two adapters running and) where cycling power on the hdmi connected monitor restored the audio connection to “plugged in”, the audio connection remained (as far as pluse audio is concerned) unplugged this time… at least, until I cycled the power on the displayport monitor LOL
That might sound a bit confusing, so to just provide a little bit more clarity: This adapter has three outputs (displayport, hdmi, and dvi). By default, the displayport is the primary output on this adapter. I have an audio device connected only to the hdmi output (connected via the hdmi connected monitor). Ordinarily, I configure the hdmi monitor as the primary display device via xorg & kscreen configuration.
So what is amusing by the simple test I performed (disabling the other video adapter), is that (as expected, given no manual configuration) the displayport connected monitor becomes the primary display, but in order for the hdmi audio (connected on the hdmi connected monitor!) to be registered as being plugged in, I had to power cycle the displayport connected monitor rotfl!
Ordinarily, that would make no fricking sense, but if memory serves correct, audio over displayport (which is introduced along side the existing hdmi audio support) was added into the radeon driver with kernel 4.xx … which, if I also recall, this tumbleweed based system got upgraded to at the very same time of the switch over to plasma 5.
So, to the extent that I can see so far, something does indeed appear to be a little bit screwy in the radeon kernel driver at the moment … (currently using kernel 4.0.4-1-desktop) … and my awareness to this problem was simply coincidental to the switch to plasma 5
(PS - haven’t got around to trying out the other test yet – two hdmi connections at the same time)
Speculation mode on]
Incidentally, since the switch over to kernel 4 and plasma 5, I also now have a very slow log in, marred by some video glitches and flickering. This is true with both sddm and kdm (I resort to kdm as sddm isn’t mature enough and provides worse glitching for some reason). I initially thought it might be something related to kscreen/xrandr configuration of the dual adapters. But that doesn’t appear to be the case (disabling one of the adapters still results in the same monkey business going on). Further, I now think there is some glitching going on before X (i.e. before the display manager log in pops up) during plymouth …(though plymouth is pretty flakey in its on right, as plenty of testimony of that here in the forums provides, so its hard to tell). Anyway, this brief investigation into the hdmi audio problem, and the indications I get that it is a radeon kernel driver problem, tend to suggest to me that this extended log in and glitching (and possibly plymouth glitching) problems are also kernel driver related.
/ Speculation mode off]
I never got around to updating the kernel myself, however, I pulled in 4.0.5 today within the TW updates, and it did indeed appear to resolve the hdmi audio issue. Further, it resolved the video glitching that I was also observing.
The speed/time required to log into the desktop seemed to improve a bit too, though it was still pretty slow and marred by flickering. I disabled the kscreen service at boot * and that (as I suspected previously) took care of the flickering and helped to further improve the time it takes to log . However, it ( the time it takes to log in) is still pretty laggy. My laptop (Intel video), for comparison, does not suffer from such slowness and takes relatively the same amount of time to log in now (under Plasma 5) as it did under the former KDE4 scenario. Not sure what the outstanding issue on the desktop is, though its quite possible its related to changes in the radeon kernel driver (introduced in 4.x.x) … grrrr, wish I hadn’t updated to Plasma 5 at the same time as the kernel update …
Note: I’m not sure if it has been reported, but there appears to be a minor gui bug for disabling the background services (Configure Desktop > Startup and Shutdown > Background Services > Startup Services). Specifically if the “Use” box is unchecked and then the apply button is clicked, the service is indeed stopped and this setting persists across boots (as denoted by “Not running” under the “Status” column), however, the “Use” box is repopulated/checked … that strikes me as being a bug.
Just as a note, disabling radeon kernel driver and booting into X with the generic fbdev is indeed very speedy, so it would appear the suspicions are on track.
Further, I also happened to notice last night that xrandr listproviders is listing three providers in this two adapter system – that’s funny rotfl! . I’ve seen this occur in the past before, but don’t recall the why or what of the issue. But I suspect that this is related to the sloth like boot up and log in I’m seeing.
Given its just a minor annoyance at this point, I’m inclined to see if things shake themselves out with the next kernel update before investigating further …
I only have a single card (HD6570) with two screens attached (PC monitor to DVI and HDTV to HDMI). Plasma(KDE4) loads the same speed with the HDTV on or off. With Plasma5, if the the HDTV is off, it loads the same as old Plasma. If the HDTV is on, it takes about twice as long, but it’s only about 25 seconds.
Might not be Plasma5’s problem as I was reading in the QT 5.x bugs some issues with multi-mon (can’t remember where, been a while), but I do remember there seemed to be a patch to 5.5 which fixed those issues. I don’t think it’s drm but instead probably something with QT5 and Plasma5. We’ll see when 5.5 comes here in a week or so.
fwiw, I’ve also noticed that my HDTV doesn’t have to be on for the load slow-down, it only has to be in standby mode (radeon doesn’t seem to differentiate between on and standby for HDMI for HDTV).