A Number Of AMDGPU DRM Fixes Prepped Ahead Of Linux 4.19

[Brisse]

Sounds like it might be a audio driver or application issue. Most HDA codecs only support 48khz. The CPU has to do the re-sampling for other rates I think.

I'm no developer or expert on this but the way I see it:

Windows: Has a sample rate setting (def. 48khz) and resamples everything to that rate regardless of the source. It reports that my monitor can take 32, 44.1 and 48khz (https://imgur.com/kjfVKmH) and if I change the default of 48khz to either of these I still get audio.

Pulse Audio + ALSA: Defaults to 44.1khz but also has an "alternate rate" setting (def. 48khz) and automatically selects one of these rates depending on the first source it sees to try to stay "bit perfect" if possible, depending on what the output device supports. This works fine on several audio cards I've tested, including the motherboard internal audio which I'm currently using.

When I select display port as my audio device on Linux, I run into problems. Say I want to listen to some music in Rhythmbox which is typically 44.1khz. No audio from the speakers. If I then stop the music and open a video (typically 48khz) in MPV then I can hear the audio fine. If I start playing music in Rhythmbox while the video is playing, then the music will have to be resampled to 48khz to match the audio stream from the video, and this does make the music audible. I can also reconfigure pulse to resample everything to 48khz to work around this issue, but that's not a bug fix, that's just a workaround.

So it seems to me there's an issue somewhere. The monitor should be able to take 44.1khz, and if it didn't then ALSA would have to be aware that it doesn't, and if that's the case then the device driver (would that be AMDGPU DC in this case?) will have to tell ALSA that this output device only accepts 48khz.

Sorry for the wall of text. Anyone know where the best place to report this would be?

[agd5f]

The GPU driver is basically just a conduit for the audio. It passes the display/receiver audio caps (extracted from in the EDID) to the audio driver and enables the audio stream within the overall video stream. The audio driver then reads the display caps and exposes them to the user who can then request the type of stream they want to send. At that point once the display is up, it's up to the audio driver to send whatever stream they've worked out based on the display caps. I would start with ALSA.

[dwagner]

I still cannot reach uptimes of more than a few hours with the most recent kernels and amdgpu on a RX460. The old 4.13 kernel had a mean time between crashes of about two days, newer kernels are much less stable for me.

I recently found that if I replay the output of
youtube-dl -f 248+251 'https://www.youtube.com/watch?v=kYKE78Pcjog'
with mpv, the amdgpu driver reproduceably crashes before the 10 minute video is over. And that even with --vo=xv, so this isn't about stressing opengl.

(For more details, see https://bugs.freedesktop.org/show_bug.cgi?id=107152 )

[shmerl]

with mpv, the amdgpu driver reproduceably crashes before the 10 minute video is over. And that even with --vo=xv, so this isn't about stressing opengl.

Are you using latest AMD firmware?

One of my computers (with RX 460) had very similar symptoms, and using newest firmware fixed them.

[geearf]

It'd be nice to have powerplay on GCN 1 as well

[humbug]

Great to see some love for gcn 1.1

[M@GOid]

I'm no developer or expert on this but the way I see it:

Windows: Has a sample rate setting (def. 48khz) and resamples everything to that rate regardless of the source. It reports that my monitor can take 32, 44.1 and 48khz (https://imgur.com/kjfVKmH) and if I change the default of 48khz to either of these I still get audio.

Pulse Audio + ALSA: Defaults to 44.1khz but also has an "alternate rate" setting (def. 48khz) and automatically selects one of these rates depending on the first source it sees to try to stay "bit perfect" if possible, depending on what the output device supports. This works fine on several audio cards I've tested, including the motherboard internal audio which I'm currently using.

When I select display port as my audio device on Linux, I run into problems. Say I want to listen to some music in Rhythmbox which is typically 44.1khz. No audio from the speakers. If I then stop the music and open a video (typically 48khz) in MPV then I can hear the audio fine. If I start playing music in Rhythmbox while the video is playing, then the music will have to be resampled to 48khz to match the audio stream from the video, and this does make the music audible. I can also reconfigure pulse to resample everything to 48khz to work around this issue, but that's not a bug fix, that's just a workaround.

So it seems to me there's an issue somewhere. The monitor should be able to take 44.1khz, and if it didn't then ALSA would have to be aware that it doesn't, and if that's the case then the device driver (would that be AMDGPU DC in this case?) will have to tell ALSA that this output device only accepts 48khz.

Sorry for the wall of text. Anyone know where the best place to report this would be?

A couple weeks ago I was sucessifully using a Benq monitor (Displayport) as a audio output for my stereo speakers, with a RX 570 in a Kubuntu 18.04 installation. Maybe you can try Kubuntu via a USB flashdrive to check if the problem persists.

[Brisse]

A couple weeks ago I was sucessifully using a Benq monitor (Displayport) as a audio output for my stereo speakers, with a RX 570 in a Kubuntu 18.04 installation. Maybe you can try Kubuntu via a USB flashdrive to check if the problem persists.

I used to run Ubuntu 17.10 with custom kernels including DC amongst other things before moving on to Debian Sid and I had the same issue there, but yea, I might try 18.04 anyway.

One thing I'm noticing though is that whenever I bring this up, someone says they dont have the issue and they always have a Polaris GPU. Might be specific to my hardware.

[M@GOid]

I used to run Ubuntu 17.10 with custom kernels including DC amongst other things before moving on to Debian Sid and I had the same issue there, but yea, I might try 18.04 anyway.

One thing I'm noticing though is that whenever I bring this up, someone says they dont have the issue and they always have a Polaris GPU. Might be specific to my hardware.

Had you tried hocking it up with a TV (in HDMI)? Maybe is the monitor's fault. Mine have a poor DAC, so I changed to another setup.

[dwagner]

Are you using latest AMD firmware?
One of my computers (with RX 460) had very similar symptoms, and using newest firmware fixed them.

Of course I use this latest firmware (which, btw., is at this time also the version that Arch Linux distributes), but that does not help me.