Yet Another KDE Sound Problem

microshaft

New Member


Messages: 13

#1
I haven't been able to get sound working properly through kde despite best efforts, desired output device is a USB DAC and is seleted as the default output in the kernel. It works perfectly fine with any application that bypasses kde's sound system (firefox, chrome, vlc, etc.)

Pulse has the USB DAC selected as the default sink and works.
pacmd play-file /tmp/test.wav output

Gstreamer also seems to be working fine and plays the test tone.
gst-launch audiotestsrc ! audioconvert ! audioresample ! osssink

I've swapped between the gstreamer and vlc output devices in kde and that hasn't helped. The "Audio Hardware Setup" tab is missing in the "Audio and Video Settings" applet.

When kde tries to play a sound, I see it connect to pulse but nothing happens. I'm guessing that it uses the wrong sink?

Code:
I: [(null)] client.c: Created 43 "Native client (UNIX socket client)"
D: [(null)] protocol-native.c: Protocol version: remote 30, local 30
D: [(null)] protocol-native.c: SHM possible: yes
D: [(null)] protocol-native.c: Negotiated SHM: yes
D: [(null)] protocol-native.c: Disabling srbchannel, reason: Must be enabled by module parameter
D: [(null)] module-augment-properties.c: Looking for .desktop file for U
I: [(null)] client.c: Freed 43 "Quassel IRC"
I: [(null)] protocol-native.c: Connection died.
I: [(null)] client.c: Created 44 "Native client (UNIX socket client)"
D: [(null)] protocol-native.c: Protocol version: remote 30, local 30
D: [(null)] protocol-native.c: SHM possible: yes
D: [(null)] protocol-native.c: Negotiated SHM: yes
D: [(null)] protocol-native.c: Disabling srbchannel, reason: Must be enabled by module parameter
D: [(null)] module-augment-properties.c: Looking for .desktop file for U
I: [(null)] client.c: Freed 44 "Quassel IRC"
I: [(null)] protocol-native.c: Connection died.
I: [(null)] client.c: Created 45 "Native client (UNIX socket client)"
D: [(null)] protocol-native.c: Protocol version: remote 30, local 30
D: [(null)] protocol-native.c: SHM possible: yes
D: [(null)] protocol-native.c: Negotiated SHM: yes
D: [(null)] protocol-native.c: Disabling srbchannel, reason: Must be enabled by module parameter
D: [(null)] module-augment-properties.c: Looking for .desktop file for 
I: [(null)] client.c: Freed 45 "kcmshell"
I: [(null)] protocol-native.c: Connection died.
 

protocelt

Daemon

Thanks: 407
Messages: 1,253

#2
Do you really have a need for audio/pulseaudio to be installed on the system? If not, rebuild multimedia/phonon without pulseaudio support(which is the default option) and problem should go away. There are a few ports that require it to work however I can't remember which ones and it isn't many. I won't allow audio/pulseaudio on my systems. It seems to cause more problems than anything.
 
Thanks: OJ
OP
OP
microshaft

microshaft

New Member


Messages: 13

#3
It doesn't look like anything was depending on pulseaudio so I removed it but I'm still getting no love from phonon with either the gstreamer, vlc or xine backends. Blacklisting the nvidia oss devices in hal doesn't seem to fix it either. At least at this point, kdeinit has the right dsp device open, but still, no sound. Frustrating.
 
OP
OP
microshaft

microshaft

New Member


Messages: 13

#5
Yes, sound works from everything but applications which use the kde sound subsystem. Chrome, virtualbox, firefox, linux-flashplayer, thunderbird, vlc and cli tools all work as expected (applications which use alsa need the included sample asound.conf copied.) From a usability perspective it isn't a big deal but there are a couple of applications like quassel that I'd like to have functional audio notifications.
 
OP
OP
microshaft

microshaft

New Member


Messages: 13

#7
KDE's mixer controls, ironically, have always worked just fine.
Code:
$ pkg info kmix
kmix-4.14.3
Name  : kmix
Version  : 4.14.3
Installed on  : Tue Mar 24 09:23:36 PDT 2015
Origin  : audio/kmix
Architecture  : freebsd:10:x86:64
Prefix  : /usr/local
Categories  : kde audio
Licenses  : GPLv2
Maintainer  : kde@FreeBSD.org
WWW  : http://www.kde.org/applications/multimedia/kmix/
Comment  : Sound mixer for KDE
Options  :
  ALSA  : off
  PULSEAUDIO  : off
Shared Libs required:
  libsolid.so.4
  libplasma.so.3
  libphonon.so.4
  libkdeui.so.5
  libkdecore.so.5
  libQtXml.so.4
  libQtSvg.so.4
  libQtGui.so.4
  libQtDBus.so.4
  libQtCore.so.4
Shared Libs provided:
  libkdeinit4_kmixctrl.so
  libkdeinit4_kmix.so
Annotations  :
  repo_type  : binary
  repository  : FreeBSD
Flat size  : 1.59MiB
Description  :
KMix is an application to allow you to change the volume of your sound
card. Though small, it is full-featured, and it supports several
platforms and sound drivers.

WWW: http://www.kde.org/applications/multimedia/kmix/
 

protocelt

Daemon

Thanks: 407
Messages: 1,253

#8
Ok, are you using the ports system or pkg(8)? I still think this is a problem with pulseaudio. You said you deleted audio/pulseaudio but did you then recompile any ports that are configured to depend on it, for example multimedia/phonon.
 
OP
OP
microshaft

microshaft

New Member


Messages: 13

#9
I'm using exclusively using pkg. There were no dependencies on audio/pulseaudio so I removed it - I'd probably added it at some point in the past trying to get sound to work in KDE. Phonon is compiled with it off by default from the FreeBSD repository.
 

protocelt

Daemon

Thanks: 407
Messages: 1,253

#10
Ok, that is certainly strange. I'll create a new 10-STABLE boot environment later today, install x11/kde4 and some applications with pkg(8) only and see if I can replicate the issue and/or dig into it some more. I don't have this issue in my current 10-STABLE or CURRENT environments but I compile all my packages locally.
 

mnd999

Member

Thanks: 2
Messages: 32

#11
I have the same issue, which I've had for a while. I've a similar setup, with an nvidia card grabbing the first three pcms and having previously had pulse installed (but no more).
 

CoryG

New Member


Messages: 7

#12
Ok, that is certainly strange. I'll create a new 10-STABLE boot environment later today, install x11/kde4 and some applications with pkg(8) only and see if I can replicate the issue and/or dig into it some more. I don't have this issue in my current 10-STABLE or CURRENT environments but I compile all my packages locally.
Any updates on this? I appear to be having the same issue, also installed via pkg. If you need it to help:

Code:
$ pkg info kmix
kmix-4.14.3
Name           : kmix
Version        : 4.14.3
Installed on   : Sat Mar 11 14:48:09 2017 EST
Origin         : audio/kmix
Architecture   : FreeBSD:11:amd64
Prefix         : /usr/local
Categories     : kde kde-kde4 audio
Licenses       : GPLv2
Maintainer     : kde@FreeBSD.org
WWW            : http://www.kde.org/applications/multimedia/kmix/
Comment        : Sound mixer for KDE
Options        :
        ALSA           : off
        PULSEAUDIO     : off
Shared Libs required:
        libQtXml.so.4
        libQtSvg.so.4
        libphonon.so.4
        libkdeui.so.5
        libplasma.so.3
        libQtCore.so.4
        libsolid.so.4
        libkdecore.so.5
        libQtDBus.so.4
        libQtGui.so.4
Shared Libs provided:
        libkdeinit4_kmixctrl.so
        libkdeinit4_kmix.so
Annotations    :
        repo_type      : binary
        repository     : FreeBSD
Flat size      : 1.59MiB
Description    :
KMix is an application to allow you to change the volume of your sound
card. Though small, it is full-featured, and it supports several
platforms and sound drivers.

WWW: http://www.kde.org/applications/multimedia/kmix/
 

Morrand

New Member


Messages: 2

#13
Same issue, on 10.3-RELEASE (and 10-STABLE) with the sound and snd_hda drivers loaded. Command-line playback works (gstreamer, for example), and some windowed applications (VLC), but KDE sounds are not playing.

However, if I turn up hw.sound.verbose to 4, and then hit the "Test" button in the KDE control panel, I get this on console:

Code:
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [4096] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=341
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [8192] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=2048
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [32768] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [65536] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[32768/1024/32] limit=4096
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [32768] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[65536/2048/32] limit=4096
Which is suggesting to me that KDE is passing sound off to the kernel, but it's getting lodged somewhere. For comparison, if I set up a test stream in Gstreamer, I get something like this:

Code:
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [8192] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [16384] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[4096/128/32] limit=170
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/] limit=940
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [16384] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[8192/256/32] limit=940
pcm1: chn_start(): VCHAN PARENT starting! (PCMDIR_PLAY/running) (ready=4096 force=1 i=1 j=0 intrtimeout=21 latency=21ms)
hdac0: 1536Kbps of 46080Kbps bandwidth used
pcm1: PCMDIR_PLAY: Stream setup fmt=00200010 (2.0) speed=48000
pcm1: PCMDIR_PLAY: Stream setup nid=2: fmt=0x0011, dfmt=0x0001, chan=0x0010, chan_count=0x01, stripe=0
pcm1: chn_trigger() pcm1:play:dsp1.p0: calling go=0x00000001 , prev=0xffffffff
pcm1: chn_trigger() pcm1:virtual:dsp1.vp0: calling go=0x00000001 , prev=0xffffffff
pcm1: chn_trigger() pcm1:play:dsp1.p0: calling go=0xffffffff , prev=0x00000001
pcm1: chn_trigger() pcm1:virtual:dsp1.vp0: calling go=0xffffffff , prev=0x00000001
pcm1: chn_resizebuf(): PCMDIR_PLAY (hardware) timeout=21 b[4096/2048/2] bs[4096/2048/2] limit=0
sndbuf_remalloc(): b=0xfffff800033d6600 65536 [8192] NOCHANGE
pcm1: chn_resizebuf(): PCMDIR_PLAY (virtual) timeout=21 b[0/0/0] bs[16384/512/32] limit=940
Really similar, except that in this case, I do eventually get a chn_start() call, which apparently triggers the channel to begin playback, which then leads to the test tone playing out to the speaker.

Over on /dev/sndstat, just to be complete, I've got:

Code:
FreeBSD Audio Driver (64bit 2009061500/amd64)
Installed devices:
pcm0: <Intel Eaglelake (HDMI 8ch)> on hdaa0  (1p:1v/0r:0v)
   snddev flags=0x2e7<SIMPLEX,AUTOVCHAN,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,VPC>
   [pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x00006100, 0x00000004
   interrupts 718, underruns 0, feed 718, ready 0 [b:4096/2048/2|bs:4096/2048/2]
   channel flags=0x6100<BUSY,HAS_VCHAN,VCHAN_PASSTHROUGH>
   {userland} -> feeder_mixer(0x00200010) -> {hardware}
   pcm0:play:dsp0.p0[pcm0:virtual:dsp0.vp0]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029
   interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:65536/2048/32]
   channel flags=0x10000000<VIRTUAL>
   {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> feeder_rate(0x00200010 q:1 44100 -> 48000) -> {hardware}
pcm1: <Realtek ALC662 (Rear Analog)> on hdaa1  (1p:1v/1r:1v) default
   snddev flags=0x2e2<AUTOVCHAN,BUSY,MPSAFE,REGISTERED,VPC>
   [pcm1:play:dsp1.p0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000004
   interrupts 704, underruns 0, feed 704, ready 0 [b:4096/2048/2|bs:4096/2048/2]
   channel flags=0x2100<BUSY,HAS_VCHAN>
   {userland} -> feeder_mixer(0x00200010) -> {hardware}
   pcm1:play:dsp1.p0[pcm1:virtual:dsp1.vp0]: spd 48000, fmt 0x00200010, flags 0x10000000, 0x00000021
   interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:65536/2048/32]
   channel flags=0x10000000<VIRTUAL>
   {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> {hardware}
   [pcm1:record:dsp1.r0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000005
   interrupts 680, overruns 0, feed 1360, hfree 4096, sfree 4096 [b:4096/2048/2|bs:4096/2048/2]
   channel flags=0x2100<BUSY,HAS_VCHAN>
   {hardware} -> feeder_root(0x00200010) -> feeder_mixer(0x00200010) -> {userland}
   pcm1:record:dsp1.r0[pcm1:virtual:dsp1.vr0]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029
   interrupts 0, overruns 0, feed 0, hfree 0, sfree 65536 [b:0/0/0|bs:65536/2048/32]
   channel flags=0x10000000<VIRTUAL>
   {hardware} -> feeder_root(0x00200010) -> feeder_rate(0x00200010 q:1 48000 -> 44100) -> feeder_volume(0x00200010) -> {userland}
pcm2: <Realtek ALC662 (Front Analog)> on hdaa1  (1p:1v/1r:1v)
   snddev flags=0x2e2<AUTOVCHAN,BUSY,MPSAFE,REGISTERED,VPC>
   [pcm2:play:dsp2.p0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000004
   interrupts 689, underruns 0, feed 689, ready 0 [b:4096/2048/2|bs:4096/2048/2]
   channel flags=0x2100<BUSY,HAS_VCHAN>
   {userland} -> feeder_mixer(0x00200010) -> {hardware}
   pcm2:play:dsp2.p0[pcm2:virtual:dsp2.vp0]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029
   interrupts 0, underruns 0, feed 0, ready 0 [b:0/0/0|bs:65536/2048/32]
   channel flags=0x10000000<VIRTUAL>
   {userland} -> feeder_root(0x00200010) -> feeder_volume(0x00200010) -> feeder_rate(0x00200010 q:1 44100 -> 48000) -> {hardware}
   [pcm2:record:dsp2.r0]: spd 48000, fmt 0x00200010, flags 0x00002100, 0x00000005
   interrupts 677, overruns 0, feed 1354, hfree 4096, sfree 4096 [b:4096/2048/2|bs:4096/2048/2]
   channel flags=0x2100<BUSY,HAS_VCHAN>
   {hardware} -> feeder_root(0x00200010) -> feeder_mixer(0x00200010) -> {userland}
   pcm2:record:dsp2.r0[pcm2:virtual:dsp2.vr0]: spd 44100/48000, fmt 0x00200010, flags 0x10000000, 0x00000029
   interrupts 0, overruns 0, feed 0, hfree 0, sfree 65536 [b:0/0/0|bs:65536/2048/32]
   channel flags=0x10000000<VIRTUAL>
   {hardware} -> feeder_root(0x00200010) -> feeder_rate(0x00200010 q:1 48000 -> 44100) -> feeder_volume(0x00200010) -> {userland}

$FreeBSD: stable/10/sys/dev/sound/pcm/channel.c 283950 2015-06-03 15:32:43Z hselasky $
$FreeBSD: stable/10/sys/dev/sound/pcm/buffer.c 319066 2017-05-28 10:44:43Z hselasky $
$FreeBSD: stable/10/sys/dev/sound/pcm/ac97_patch.c 193640 2009-06-07 19:12:08Z ariff $
$FreeBSD: stable/10/sys/dev/sound/pcm/ac97.c 227293 2011-11-07 06:44:47Z ed $
$FreeBSD: stable/10/sys/dev/sound/pci/hda/hdacc.c 312367 2017-01-18 02:57:22Z yongari $
$FreeBSD: stable/10/sys/dev/sound/pci/hda/hdac.c 314667 2017-03-04 13:03:31Z avg $
$FreeBSD: stable/10/sys/dev/sound/pci/hda/hdaa_patches.c 312367 2017-01-18 02:57:22Z yongari $
$FreeBSD: stable/10/sys/dev/sound/pci/hda/hdaa.c 314667 2017-03-04 13:03:31Z avg $
$FreeBSD: stable/10/sys/dev/sound/pci/ich.c 216518 2010-12-18 14:21:28Z tijl $
$FreeBSD: stable/10/sys/dev/sound/isa/sndbuf_dma.c 193640 2009-06-07 19:12:08Z ariff $
$FreeBSD: stable/10/sys/dev/sound/pcm/vchan.c 193640 2009-06-07 19:12:08Z ariff $
$FreeBSD: stable/10/sys/dev/sound/pcm/sound.c 243459 2012-11-23 15:31:00Z mav $
$FreeBSD: stable/10/sys/dev/sound/pcm/sndstat.c 248381 2013-03-16 17:57:00Z joel $
 

Morrand

New Member


Messages: 2

#14
In my case, the solution came through the following steps:
  1. Install the GStreamer backend to Phonon (multimedia/phonon-gstreamer). Set it up as the first choice of backends in KDE's System Preferences | Multimedia.
  2. Install audio/gstreamer1-plugins-sndio (which is also included by default in multimedia/gstreamer1-plugins-all).
  3. Set up sndiod(8) by running sysrc sndiod_enable=YES and start it by running service sndiod start. The startup script automatically points sndiod toward the default sound device (/dev/dsp1 in my case) and does a little more setup. There's more information at Thread 60829.
And that was all it took.

A little more detail: I wound up ticking through Dragon Player line-by-line in gdb to try to find out where it was failing. Dragon Player was just the handiest thing to engage the KDE sound system with, but I suspect pretty much anything else interacting with Phonon that you can hitch gdb onto would work as well. Running Dragon straight through would drop the following two errors into .xsession-errors:
Code:
(dragon:9993): GLib-GObject-WARNING **: invalid uninstantiatable type '(null)' 
in cast to 'GstElement'

(dragon:9993): GStreamer-CRITICAL **: gst_element_message_full_with_details: 
assertion 'GST_IS_ELEMENT (element)' failed
Trapping on that function (gst_element_message_full_with_details), I find
Code:
Thread 3.8 hit Breakpoint 5, gst_element_message_full_with_details (
    element=0x8207f6768, type=GST_MESSAGE_ERROR, domain=2783, code=6,
    text=0x82583d040 "Audio device refused requested parameters", debug=0x0,
    file=0x820c91f72 "gstsndio.c", function=0x820c9209d "gst_sndio_prepare",
    line=336, structure=0x0) at gstelement.c:1899
followed shortly by
Code:
Thread 3.8 hit Breakpoint 5, gst_element_message_full_with_details (
    element=0x8207f6450, type=GST_MESSAGE_ERROR, domain=2784, code=11, text=0x0,
    debug=0x824833060 "sink not negotiated.",
    file=0x81f435d57 "gstaudiobasesink.c",
    function=0x81f43613c "gst_audio_base_sink_preroll", line=1193, structure=0x0)
    at gstelement.c:1899
The problem really stems from code in gstsndio.c at line 306. That operation attempts to set parameters in sio (function sio_setpar), then tries to read them back for confirmation. What it should do is to set the parameters to match what GStreamer wants to send, which in turn should be determined from what the sound driver reports as its capabilities. The trouble seems to be that, lacking sndiod, the GStreamer plugin can't read out the actual capabilities of the sound driver, so it uses default values instead. In my case, that meant it tried to send 32-bit sound. Trouble is, the snd_hda(4) bridge driver by default only allows 24-bit sound. Evidently, when it gets a request to send more bits than this, it just refuses to accept the setting, which leads to the "refused requested parameters" error. (The snd_hda driver, at least, can be adjusted to play 32-bit samples using the dev.pcm.%d.play.32bit sysctl. That might be a good start for troubleshooting on non-sndio systems.)

It's worth pointing out that, by design, the sndio plugin takes priority over both the PulseAudio and OSS when an autosink is requested by GStreamer. I don't imagine too many tears would be shed over PulseAudio being overridden, but the fact that it overrides the OSS driver might explain why this is such a tough problem to troubleshoot. And since the sndio plugin comes in through multimedia/gstreamer1-plugins-all, no doubt it has a pretty good chance to sneak onto a system and block the OSS sink.

So much for the GStreamer backend. I still haven't figured out why the VLC plugin to Phonon also doesn't work (even though VLC itself works fine), but it's entirely possible that it's the same sort of problem. I still don't know what part of the stream is defaulting to 32-bit samples, but if it's far enough upstream in the KDE sound system, that could explain why none of the backends seem to work on KDE (and why manually running a GStream, or running programs that don't go through KDE, work fine).

Hope this is helpful to someone. Although the sndio ports didn't make it into the ports tree until about a year after this thread opened, they do seem to work to solve the problem.
 

tobik@

Daemon
Developer

Thanks: 1,357
Messages: 1,909

#15
The problem really stems from code in gstsndio.c at line 306. That operation attempts to set parameters in sio (function sio_setpar), then tries to read them back for confirmation. What it should do is to set the parameters to match what GStreamer wants to send, which in turn should be determined from what the sound driver reports as its capabilities. The trouble seems to be that, lacking sndiod, the GStreamer plugin can't read out the actual capabilities of the sound driver, so it uses default values instead. In my case, that meant it tried to send 32-bit sound. Trouble is, the snd_hda(4) bridge driver by default only allows 24-bit sound. Evidently, when it gets a request to send more bits than this, it just refuses to accept the setting, which leads to the "refused requested parameters" error. (The snd_hda driver, at least, can be adjusted to play 32-bit samples using the dev.pcm.%d.play.32bit sysctl. That might be a good start for troubleshooting on non-sndio systems.)
sound(4)'s conversion layer should take care of that already and convert to a sample format that the soundcard can handle. I'm not sure why you would have to run sndiod unless you've explicitly enabled bitperfect mode or something.
 
Top