[OpenIndiana-discuss] No audio on Ryzen system

[Gary Mills]

On Wed, Jul 11, 2018 at 08:53:46PM -0500, Gary Mills wrote:
> On Fri, Jul 06, 2018 at 06:17:14PM +0200, Aurélien Larcher wrote:
> > Probably fix the Pulseaudio OSS backend or merge Alexander's PR to
> > default libmatemixer to OSS.
> 
> The HDMI device, instance zero, is on the video card.  The other,
> instance one, is on the motherboard.  They show up this way in /dev:
> 
> lrwxrwxrwx   1 root     root           7 Sep 20  2017 /dev/audio -> sound/0
> lrwxrwxrwx   1 root     root           9 Sep 20  2017 /dev/sound/0 -> audiohd:0
> lrwxrwxrwx   1 root     root           9 Sep 20  2017 /dev/sound/1 -> audiohd:1
> 
> I've been investigating this problem since last week.  The solution
> seems to be putting AUDIODEV=/dev/sound/1 into the desktop
> environment.  I put that into my .profile and exported it from there,
> and then logged out and in again.
[...]
> However, there's still no audio from desktop applications.  I suspect
> that pulseaudio and mate-volume-control-applet are both ignoring the
> AUDIODEV environment variable.

It seems that I unfairly maligned pulseaudio.  It does have code, in
src/modules/module-detect.c, that detects the AUDIODEV environment
variable and makes use of it to load the module-solaris module.
However, I identified three problems in pulseaudio that may contribute
to the original error that I noticed.

First of all, the symbols HAVE_OSS_OUTPUT and HAVE_SOLARIS are both
defined during the build of module-detect.so .  The code there assumes
that only one of them is defined.  Consequently, this module loads
both module-oss and module-solaris.  I verified this conclusion by
running `strings' against module-detect.so .  The output shows
/dev/audio plus /dev/sndstat, /dev/dsp, /dev/dsp%u.0, and /dev/dsp%u .
Something is broken in the configuration of pulseaudio.

Second, something that changes ownership of audio devices is still
running when pulseaudio starts.  With full logging from pulseaudio,
these messages appear:

    Jul 12 19:36:56 qtpie pulseaudio[26675]: [ID 295310 user.warning] [solaris] module-solaris.c: open /dev/sound/1 failed (Permission denied)
    Jul 12 19:37:20 qtpie pulseaudio[29760]: [ID 295310 user.info] [(null)] module-solaris.c: device opened in O_RDWR mode.

It does seem to retry the open, but still this failure should not be
happening.  After a desktop login completes, these are the devices:

    $ ll -L /dev/sound/1
    crw-------   1 mills    staff     30, 19 Dec 27  1986 /dev/sound/1
    $ ll -L /dev/sound/0
    crw-------   1 mills    staff     30,  3 Dec 27  1986 /dev/sound/0

After I've logged out from the desktop, they look like this:

    $ ll -L /dev/sound/?
    crw-------   1 lightdm  lightdm   30,  3 Dec 27  1986 /dev/sound/0
    crw-------   1 lightdm  lightdm   30, 19 Dec 27  1986 /dev/sound/1

Something must change their ownership in the background, during the
desktop login.

Finally, the pulseaudio daemon process keeps running after a desktop
logout, even though all the other processes started by the login have
terminated.  Here's an example:

     UID   PID  PPID   C    STIME TTY         TIME CMD
   mills  2707     1   0   Jul 04 ?           9:30 /usr/bin/pulseaudio --start --log-target=syslog

It seems to be reused on the next desktop login.  The problem with
this behavior is that configuration changes have no effect.  It may
require an explicit `kill -15' to terminate that process.  That does
work from a remote terminal session.


-- 
-Gary Mills-		-refurb-		-Winnipeg, Manitoba, Canada-