Bug 93544

It was once requested [1] to ArchLinux package system to use GStreamer backend due the fact that most users don't use PulseAudio.

[1] https://bugs.archlinux.org/task/46050

GStreamer should work with either PulseAudio or ALSA.

I don't see this as a bug for Spice.

PS: Consider using remote-viewer (part of virt-viewer package) instead of Spicy. Spicy is a testing tool.

I played around with the --with-audio flag for configure.  --with-audio=gstreamer does not seem to work with plain ALSA for me (I'm not sure why.  Maybe I am doing something wrong.), but it does work with PulseAudio.  I will attach the run output.

remote-viewer has the same problems I have with spicy.

Thanks for pointing me to the Arch Linux bug.  It looks like that change was reverted shortly after the bug was closed.  I will be following up with them because I am at the extent of my knowledge right now.

Created attachment 120750 [details]
spicy stdout (compiled with --with-audio=gstreamer)

(In reply to Kyle Terrien from comment #3)
> Created attachment 120750 [details]
> spicy stdout (compiled with --with-audio=gstreamer)

Could you check if you have alsa and pulseaudio elements?
The output of command bellow is what I have here.

$ gst-inspect-1.0 | grep -i "alsa\|pulse"
alsa:  alsasrc: Audio source (ALSA)
alsa:  alsasink: Audio sink (ALSA)
pulseaudio:  pulsesink: PulseAudio Audio Sink
pulseaudio:  pulsesrc: PulseAudio Audio Source
pulseaudio:  pulsedeviceprovider (GstDeviceProviderFactory)

I have PulseAudio installed.  Regardless of whether PulseAudio is actually running, I get the same records you are showing, but in a different order:

> $ gst-inspect-1.0 | grep -i "alsa\|pulse"
> alsa:  alsasink: Audio sink (ALSA)
> alsa:  alsasrc: Audio source (ALSA)
> pulseaudio:  pulsedeviceprovider (GstDeviceProviderFactory)
> pulseaudio:  pulsesrc: PulseAudio Audio Source
> pulseaudio:  pulsesink: PulseAudio Audio Sink

(In reply to Kyle Terrien from comment #5)
> I have PulseAudio installed.  Regardless of whether PulseAudio is actually
> running, I get the same records you are showing, but in a different order:
> 
> > $ gst-inspect-1.0 | grep -i "alsa\|pulse"
> > alsa:  alsasink: Audio sink (ALSA)
> > alsa:  alsasrc: Audio source (ALSA)
> > pulseaudio:  pulsedeviceprovider (GstDeviceProviderFactory)
> > pulseaudio:  pulsesrc: PulseAudio Audio Source
> > pulseaudio:  pulsesink: PulseAudio Audio Sink

It is really odd because it seems that the pipeline is using the wrong plugins.

Could you please attach a log by running:
GST_DEBUG=5 spicy --spice-debug

Thanks!

Created attachment 120751 [details]
GST_DEBUG=5 spicy --spice-debug -h localhost -p 5900

spicy stdout and stderr when compiled with --with-audio=gstreamer and with pulseaudio disabled

(In reply to Kyle Terrien from comment #7)
> Created attachment 120751 [details]
> GST_DEBUG=5 spicy --spice-debug -h localhost -p 5900
> 
> spicy stdout and stderr when compiled with --with-audio=gstreamer and with
> pulseaudio disabled

Thanks. I'll be investigating this next year (but not in 35 minutes)
I'll keep this bug open as it could be a bug in gstreamer backend of spice.

Thanks again.

Thanks.  I should probably clarify some of my setup in case I or someone else takes a look at this bug later on.

I have spice-gtk3 on Arch Linux custom compiled with --with-audio=pulse --with-audio=gstreamer both in the configure line.  See attached PKGBUILD, which is really the latest PKGBUILD with --with-audio=gstreamer appended and the gstreamer0.10-good dependency added.

PulseAudio is launched automatically, so you need to stop it and mask it.

systemctl --user stop pulseaudio.{service,socket}
systemctl --user mask pulseaudio.socket

Then you get a system that uses ALSA without PulseAudio running.

Created attachment 120752 [details]
Modified PKGBUILD for spice-gtk3

(In reply to Kyle Terrien from comment #9)
> Thanks.  I should probably clarify some of my setup in case I or someone
> else takes a look at this bug later on.
> 
> I have spice-gtk3 on Arch Linux custom compiled with --with-audio=pulse
> --with-audio=gstreamer both in the configure line.  See attached PKGBUILD,
> which is really the latest PKGBUILD with --with-audio=gstreamer appended and
> the gstreamer0.10-good dependency added.


Should be gstreamer-1.0-good :-)
Spice-gtk3 0.30 definetly does not use 0.10 version

I have both installed anyway, so it should have been linking against 1.0.  The dependency declaration is more of a formality.

Created attachment 120858 [details]
G_MESSAGES_DEBUG=all remote-viewer --spice-debug

I have same problem.
Gentoo linux, KDE (I have tried both VLC/Gstreamer sound engines), Qemu, virt-manager, Windows XP as guest OS. I don't have 'pulseaudio' in my system (as it's default).
net-misc/spice-gtk-0.30-r1::gentoo

(In reply to Andrey from comment #13)
> Created attachment 120858 [details]
> G_MESSAGES_DEBUG=all remote-viewer --spice-debug
> 
> I have same problem.
> Gentoo linux, KDE (I have tried both VLC/Gstreamer sound engines), Qemu,
> virt-manager, Windows XP as guest OS. I don't have 'pulseaudio' in my system
> (as it's default).
> net-misc/spice-gtk-0.30-r1::gentoo

Hi Andrei, thanks for this information.

Can you confirm that you have build spice-gtk-0.30 with config option: --with-audio-=gstreamer ?

Are you using ALSA?

Could you give me the output of comment #4 ?

I'm planning to take better look into this today/tomorrow.

Created attachment 120875 [details]
spice-gtk build.log

Yes, of course. I am attaching build.log from portage (Gentoo package manager).
Here is inspection:
$ gst-inspect-1.0 | grep -i "alsa\|pulse"
alsa:  alsasrc: Audio source (ALSA)
alsa:  alsasink: Audio sink (ALSA)
$

(In reply to Kyle Terrien from comment #7)
> Created attachment 120751 [details]
> GST_DEBUG=5 spicy --spice-debug -h localhost -p 5900
> 
> spicy stdout and stderr when compiled with --with-audio=gstreamer and with
> pulseaudio disabled

Right, I can see that pulsesink is tried and failed - that's okay

> WARN pulse pulsesink.c:615:gst_pulseringbuffer_open_device:
> <audiosink-actual-sink-pulse> error: Failed to connect: Connection refused

But for alsa, it get some warning related to config/parameters such as

> WARN alsa conf.c:4738:snd_config_expand: alsalib error:
> Unknown parameters {AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}

and

> WARN alsa pcm.c:2266:snd_pcm_open_noupdate: alsalib error:
> Unknown PCM default:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}

and

> alsa pcm.c:2266:snd_pcm_open_noupdate: alsalib error:
> Unknown PCM default:{AES0 0x02 AES1 0x82 AES2 0x00 AES3 0x02}

So, it could be the case that GStreamer back-end needs better configuration; or 
this is a alsasink bug; or alsa configuration error.

.. grumbles ..

I'll need to setup a pure alsa enviroment to test this.

Could you try the following commands and check if both does output a beep sound? :-)

1-) gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink
2-) gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink

(1) here uses pulsesink and output audio as it should but (2) does not output audio but as I have pulseaudio in my fedora/gnome so it might be necessary some alsa configuration/tweaks

In my case 1-) doesn't beep, and 2-) does.

$ LC_ALL=C gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink
WARNING: erroneous pipeline: no element "autoaudiosink"
$ LC_ALL=C gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
^C^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:04.154756024
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
$

Hi,

(In reply to Andrey from comment #17)
> In my case 1-) doesn't beep, and 2-) does.
> 
> $ LC_ALL=C gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink
> WARNING: erroneous pipeline: no element "autoaudiosink"

our GStreamer backend uses autoaudiosink to pick the right sink element. That could be the issue that you have. It should be part of gst-plugins-good

gst-inspect-1.0 autoaudiosink
(wingsuit) src $ gst-inspect-1.0 autoaudiosink
Factory Details:
  Rank                     none (0)
  Long-name                Auto audio sink
  Klass                    Sink/Audio
  Description              Wrapper audio sink for automatically detected audio sink
  Author                   Jan Schmidt <thaytan@noraisin.net>

Plugin Details:
  Name                     autodetect
  Description              Plugin contains auto-detection plugins for video/audio in- and outputs
  Filename                 /usr/lib64/gstreamer-1.0/libgstautodetect.so
  Version                  1.6.2
  License                  LGPL
  Source module            gst-plugins-good
  Source release date      2015-12-14
  Binary package           Fedora GStreamer-plugins-good package
  Origin URL               http://download.fedoraproject.org
(...)

All Right!
I have installed gst-plugins-good-1.4.5 (no else changes). And now I hear sound from both 1-) and 2-). Moreover, I hear sound from VM now! Thanks a lot.
As usual, the issue was simple - actual software version.

(In reply to Andrey from comment #19)
> All Right!
> I have installed gst-plugins-good-1.4.5 (no else changes). And now I hear
> sound from both 1-) and 2-). Moreover, I hear sound from VM now! Thanks a
> lot.

Great. There are extra checks around gstreamer elements at build time, it'll be there for spice-gtk 0.31. I'll double check that before the release.

@Kyle, could you please check the tests at the end of comment #16 ?
I'm a bit more confident that is not Spice issue for now.

Seems that audio is working fine when GStreamer elements are correctly installed in an alsa system without pulseaudio. Next spice-gtk version shall have better checks to necessary elements.

I'll be closing this bug now, @kyle feel free to re-open it with the info requested on Comment #20

Apologies for the delay.

In an ALSA-only environment, both tests give me a sine wave:

$ gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:01.677395508
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
$ gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:01.954847506
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

When running Pulseaudio, I get the same result.  Both tests play a sine wave.

But when I disable Pulseaudio, sound still breaks in spicy.  I am using gst-plugins-good 1.6.2-1.

So, gst seems to be working, but spicy is not.  (I have tried compiling with gstreamer and pulse backends--same results as in comments 2 and OP)

What is strange is that spicy compiled against gstreamer works with Pulseaudio running, but not without Pulseaudio running.  Could this be an Alsa configuration problem?

Sample configure with gstreamer backend:

        Spice-Gtk 0.30
        ==============

        prefix:                   /usr
        c compiler:               gcc
        Target:                   Unix

        Gtk:                      3.0
        Coroutine:                gthread
        Audio:                    gstreamer
        SASL support:             yes
        Smartcard support:        yes
        USB redirection support:  yes with libusb hotplug
        DBus:                     yes
        WebDAV support:           no
        LZ4 support:              no

        Now type 'make' to build spice-gtk

Please let me know if I can provide any more information.

(In reply to Kyle Terrien from comment #22)
> Apologies for the delay.

No problems

> In an ALSA-only environment, both tests give me a sine wave:

Odd. Really odd. Basically, the test with autoaudiosink has similar pipeline that we use in spice-gtk. Could you attach the GST_DEBUG=*:5 for it as well, like:

GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink
and
GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink

Then I can compare with the log from Comment #7 and see what's the difference

> When running Pulseaudio, I get the same result.  Both tests play a sine wave.
> 
> But when I disable Pulseaudio, sound still breaks in spicy.  I am using
> gst-plugins-good 1.6.2-1.

And when you disable Pulseaudio both tests above work as well, right?

> 
> So, gst seems to be working, but spicy is not.  (I have tried compiling with
> gstreamer and pulse backends--same results as in comments 2 and OP)
> 
> What is strange is that spicy compiled against gstreamer works with
> Pulseaudio running, but not without Pulseaudio running.  Could this be an
> Alsa configuration problem?

It could be, yes. I tried quickly here disabling the PulseAudio and then running the test with alsasink and I did not get any audio. I think the default for alsa conf is to use PulseAudio (as a device) and it does not fallback to the actual card if PulseAudio is disabled.
But I did not check this myself, let me know if the test with alsasink works with PulseAudio disabled.

Created attachment 121150 [details]
GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink

Created attachment 121151 [details]
GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink

> GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink
> and
> GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! alsasink

I am attaching the logs.

> And when you disable Pulseaudio both tests above work as well, right?

Yes.  Both of the gst-launch-1.0 commands play sound when pulseaudio is disabled.  spicy, however, does not.

> I think the default for alsa conf is to use PulseAudio (as a device)
> and it does not fallback to the actual card if PulseAudio is disabled.
> But I did not check this myself, let me know if the test with alsasink
> works with PulseAudio disabled.

Good catch.  There is a device called "pulse" that aplay -L says is the default:

> $ aplay -L
> null
>     Discard all samples (playback) or generate zero samples (capture)
> pulse
>     PulseAudio Sound Server
> default
>     Default ALSA Output (currently PulseAudio Sound Server)
> sysdefault:CARD=Intel
>     HDA Intel, ALC1200 Analog
>     Default Audio Device
> front:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     Front speakers
> surround21:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     2.1 Surround output to Front and Subwoofer speakers
> surround40:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     4.0 Surround output to Front and Rear speakers
> surround41:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     4.1 Surround output to Front, Rear and Subwoofer speakers
> surround50:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     5.0 Surround output to Front, Center and Rear speakers
> surround51:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     5.1 Surround output to Front, Center, Rear and Subwoofer speakers
> surround71:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Analog
>     7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
> iec958:CARD=Intel,DEV=0
>     HDA Intel, ALC1200 Digital
>     IEC958 (S/PDIF) Digital Audio Output
> hdmi:CARD=HDMI,DEV=0
>     HDA ATI HDMI, HDMI 0
>     HDMI Audio Output

However, when I run speaker-test, white noise is outputted through "front", even though speaker-test says it is using the "default" device.

> $ speaker-test -c2
> 
> speaker-test 1.1.0
> 
> Playback device is default
> Stream parameters are 48000Hz, S16_LE, 2 channels
> Using 16 octaves of pink noise
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 2048 to 16384
> Period size range from 1024 to 1024
> Using max buffer size 16384
> Periods = 4
> was set period_size = 1024
> was set buffer_size = 16384
>  0 - Front Left
>  1 - Front Right
> Time per period = 5.652113
>  0 - Front Left
> ^CWrite error: -4,Interrupted system call
> xrun_recovery failed: -4,Interrupted system call
> Transfer failed: Interrupted system call

However, when I explicitly specify "pulse", I (expectedly) get an error because Pulseaudio is not running.

> $ speaker-test -c2 -D pulse
> 
> speaker-test 1.1.0
> 
> Playback device is pulse
> Stream parameters are 48000Hz, S16_LE, 2 channels
> Using 16 octaves of pink noise
> ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
> 
> Playback open error: -111,Connection refused

(In reply to Kyle Terrien from comment #24)
> Created attachment 121150 [details]
> GST_DEBUG=5 gst-launch-1.0 audiotestsrc ! audioconvert ! autoaudiosink

As expected, it tries pulse first but it fails, which is fine.

At this moment, I wasn't able to go deeper in the logs but one think pop-up to me. The gst-launch-1.0 runs alsasink with 44100Hz while spice-gtk is using Opus on 48000Hz.

So, a cool test to do is disabling the opus (on client-side) which will most likely make the audio goes back to 44100Hz

SPICE_DISABLE_OPUS=1 ./spicy ...

< looking closer the comment #26 >

I can see that the speaker-test -c2 runs the audio on 48000Hz

Anyway, I'll try to give a better look afterwards

> SPICE_DISABLE_OPUS=1 ./spicy ...

No luck.  I am not quite sure whether spicy is trying to output 41000Hz or 48000Hz.

I guess I am sticking to PulseAudio for now.

(In reply to Kyle Terrien from comment #28)
> > SPICE_DISABLE_OPUS=1 ./spicy ...
> 
> No luck.  I am not quite sure whether spicy is trying to output 41000Hz or
> 48000Hz.
> 
> I guess I am sticking to PulseAudio for now.

For now it is a good 'workaround'
I'm not having much time to work on it this week, maybe next week...

BTW, I have sound from guest VM (as I mentioned before), but there is one nuisance - sound volume. It doesn't change, either sound exists, or not. If I try to change it via standart volume regulator (guest is Windows XP, virt. hw is AC97) - real volume doesn't change.
Is it refer to 'spice'?

(In reply to Andrey from comment #30)
> BTW, I have sound from guest VM (as I mentioned before), but there is one
> nuisance - sound volume. It doesn't change, either sound exists, or not. If
> I try to change it via standart volume regulator (guest is Windows XP, virt.
> hw is AC97) - real volume doesn't change.
> Is it refer to 'spice'?

As there are two people here I might be confusing myself a little. Your system is working with gstreamer backend under alsa, right?

As I can see on alsasink element, they don't have volume property implemented there. You could check with pulseaudio on gstreamer that the volume change will most likely works. You can check this with gst-inspect-1.0 pulsesink (it should output a volume and mute as element properties) while alsasink doesn't have it.

So I believe this is a RFE for alsa element in GStreamer. You can file a bug on GStreamer (if they don't have one open for this).

Are you still having issues with audio? Latest version of spice-gtk is 0.31

(In reply to Victor Toso from comment #32)
> Are you still having issues with audio? Latest version of spice-gtk is 0.31

Sound volume control is still not working.
Everything else seems to be OK.

(In reply to Andrey from comment #33)
> (In reply to Victor Toso from comment #32)
> > Are you still having issues with audio? Latest version of spice-gtk is 0.31
> 
> Sound volume control is still not working.
> Everything else seems to be OK.

If you are using alsasink, then that's the issue.. It does not have volume implemented[0]. Feel free to open a bug at https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer under gst-plugins-good component, requesting it as RFE :)

If no more issue, I'll be closing this.

[0] checked with gst-inspect-1.0

# pulsesink element from pulseaudio
$ gst-inspect-1.0 pulsesink | grep -i volume
  GstStreamVolume
  volume              : Linear volume of this stream, 1.0=100%

# alsasink element from alsa
$ gst-inspect-1.0 alsasink | grep -i volume
$

(In reply to Victor Toso from comment #34)
> Feel free to open a bug at
> https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer under
> gst-plugins-good component, requesting it as RFE :)
> 

Hello again. I have opened it https://bugzilla.gnome.org/show_bug.cgi?id=767698
but they mark it as 'NEEDINFO'. I discribed the issue as I could but as I can see it's not enough. Maybe you can help me there. 
Thanks.

(In reply to Andrey from comment #35)
> (In reply to Victor Toso from comment #34)
> > Feel free to open a bug at
> > https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer under
> > gst-plugins-good component, requesting it as RFE :)
> > 
> 
> Hello again. I have opened it
> https://bugzilla.gnome.org/show_bug.cgi?id=767698
> but they mark it as 'NEEDINFO'. I discribed the issue as I could but as I
> can see it's not enough. Maybe you can help me there. 
> Thanks.

Hi, thanks for opening the bug there!

If ALSA does not have API for controlling the volume per-stream, there is nothing that they can do there.

Maybe we can move our logic to use playbin instead, in the future which would allow the usage of volume element in this situation (this is software volume control).

I'll open a bug for it but may I ask why you don't give pulseaudio a try? :-)

Thanks for replying!
I have no doubts about pulseaudio, but the alternative would be great. So, well, if it comes to that, then this issue is not very serious for me. The story is simple. A year ago, I was using VirtualBox, and there, sound from guest OS has volume control working (also without pulseaudio at host OS). During some time the politics of Oracle Corp. compelled me to switch to Qemu. And it has the issue. So that's it.
As for 'playbin', maybe it's the way that used in VirtualBox? (sorry, if confussed expression).