A New Debian/Ubuntu Kernel Build With The Latest AMDGPU DC Patches

[dwagner]

it's definitely being detected as an audio output, but pulseaudio never picks it up as being connected.

That sounds like the default behaviour of pulseaudio, from what I experienced in the past, which told me to get rid of pulseaudio first after installing a Linux system.

Have you tried using the HDMI audio output more directly via alsa?

"aplay -l" should tell you which devices exist, then you could use something like
"mpv -audio-device='alsa/hdmi:CARD=HDMI,DEV=3' someaudio.mp3" to play some test file.

[Masush5]

That sounds like the default behaviour of pulseaudio, from what I experienced in the past, which told me to get rid of pulseaudio first after installing a Linux system.

Have you tried using the HDMI audio output more directly via alsa?

"aplay -l" should tell you which devices exist, then you could use something like
"mpv -audio-device='alsa/hdmi:CARD=HDMI,DEV=3' someaudio.mp3" to play some test file.

If it turns up on "aplay -l" pulse will pick it up too... it's not that broken anymore...
You can however also check if it uses the wrong profile. With amdgpu + dc its actually possible to choose to only output audio to a specific hdmi/dp port, which was not possible on radeon. Check the profile option in the config tab of pavucontrol or the output of "pactl list cards".
But, at least for me, if only one monitor is enabled, it only shows one profile to be available and uses that automatically, so that probably won't fix your issue.

[randomsalad]

If it turns up on "aplay -l" pulse will pick it up too... it's not that broken anymore...
You can however also check if it uses the wrong profile. With amdgpu + dc its actually possible to choose to only output audio to a specific hdmi/dp port, which was not possible on radeon. Check the profile option in the config tab of pavucontrol or the output of "pactl list cards".
But, at least for me, if only one monitor is enabled, it only shows one profile to be available and uses that automatically, so that probably won't fix your issue.

I have infact already tried this. The main thing to note here is that aside from one profile, all of them are listed as (unplugged). The one that stands out, is my DP-connected monitor. Using mpv to play a file and using the --audio-device toggle to cycle through all devices yielded no luck either, as expected, since it was just a different way of doing what I had already tried. I would like to hear from other Vega users though, since I want to narrow down what the actual cause of this problem is. A bug with the implementation affecting HDMI 1.x devices, or just something specific to my setup?

[Marc Driftmeyer]

Running pavcontrol on Debian PCM is the only option checked by default, but as you can see I am able to check the rest. The only error is the code registered as the RX 580 when I'm using the RX 480. Not that there is really any distinction other than a refined fab node.

[oleyska]

Running pavcontrol on Debian PCM is the only option checked by default, but as you can see I am able to check the rest. The only error is the code registered as the RX 580 when I'm using the RX 480. Not that there is really any distinction other than a refined fab node.

My ubuntu 17.04 picks mine up automatically on Vega.

[Brisse]

I would guess that he does not use pulseaudio while you do. When you use pulse, everything get resampled to 48khz automatically if thats the only supported sample rate. Thats what is happening on my RX560 with a dc patched kernel at least.

I am using Pulseaudio, but it doesn't quite work the way you think. Pulseaudio by default (at least on Ubuntu) has a default sample rate of 44100hz, but also defines an alternate sample rate which defaults to 48000hz. Which is used depends on the first audio source you feed into pulse. It will try to avoid resampling whenever it can, but if you feed two sources at the same time and the second has a different sample rate than the first, then the second gets resampled, otherwise it wouldn't be able to play at all.

Anyway, I changed my Pulseaudio config so it defaults to 48khz (and alternates to 48khz as well, so that's the only sample rate it's allowed to output) and now everything plays fine though my monitor using display port. However, I don't see this as a solution because I have other audio equipment hooked up and I want to avoid resampling to 48khz when I'm using that. This is something which has to be fixed in AMD's DC so that I don't have to do this kind of workaround.

[DarkFoss]

This is the 1st 4.14 based kernel since rc1 to actually create a display. Still unable to connect to the internet syslog is full of apparmor spam denying network manager from creating a connection also attacking cups-browsed in similar fashion. All 4.14's I've tested apparmor has been the culprit. The ones without a display left me without any input leaving a hard reset as the only option.
Other than denial of services the display was silky smooth in the few benchmarks I ran.

Oct 16 13:39:51 Mainpc-1 kernel: [ 1579.487092] audit: type=1400 audit(snip): apparmor="DENIED" operation="create" profile="/usr/lib/NetworkManager/nm-dhcp-helper" pid=3104 comm="nm-dhcp-helper" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create"

[grok]

What does DC mean? Honest, I'm surprised by the use of a two-letter initialism. I also don't know what "ROCm" stands for but as it's an OpenCL thing I don't need to know.

[Brisse]

What does DC mean? Honest, I'm surprised by the use of a two-letter initialism. I also don't know what "ROCm" stands for but as it's an OpenCL thing I don't need to know.

Display code? Anyway, it's for the developers mostly. We end user won't have to worry much about what it's called once it's mainlined.

[bridgman]

ROCm is Radeon Open Compute platforM.