GNOME Bugzilla – Bug 410403
Alsasink needs to work differently for surround
Last modified: 2018-05-04 14:17:49 UTC
The alsasink currently relies and a list of prefered caps for how it handles surround sound. After a discussion with Wim and also some emails to ALSA devel it needs to be changed to do the following: a) Instead of prefered caps it should use the virtual alsa devices. So by default alsasink should just use the stereo device so that downmixing to stereo is always happening. b) The applications should be able to choose a different device through an element attribute like the 'surround51' device for 51 surround. Applications should not use this device though for mono/stereo streams, but instead use the default stereo output device.
Some info fromm the ALSA-devel list I thought I should include: The device name for this is "surround51" (but it's better to use "plug:surround51" because this virtual device doesn't have the sample format converter that "default" has enabled by default).
Tried this today with little success, getting the 'side' device from my alsa.conf file : gst-launch-0.10 -v filesrc location=Dust_to_Glory_720.wmv ! fluasfdemux ! fluwmadec ! alsasink device-name=side (gst-launch-0.10:8910): GLib-GObject-WARNING **: IA__g_object_set_property: property `device-name' of object class `GstAlsaSink' is not writable Setting pipeline to PAUSED ...
"device-name" is only readable, it's a description string used with the GstPropertyProbe interface. The property you want to set is the "device" property.
ok, interesting results with 'device' it seems that apart from 'front' I am not able to write to any of the other virtual devices (like side, rear, surround51), so it seems alsa is actually might be aware that I do not have a surround sound enabled card after all. Writing to 'default' gives me the normal behavious of only a two of the 6 channels actually played in my headphones. Writing to 'dmix' also gives me the correct stereo mixing. Used this pipeline for testing: gst-launch-0.10 -v filesrc location=Dust_to_Glory_720.wmv ! fluasfdemux ! fluwmadec ! audioconvert ! alsasink device=surround51
With a sample file I have here, the problem is that the speech occurs on the Centre channel, and Front-Left and Front-Right contain only the music+sound fx. When outputting to ALSA, it discards the Centre channel instead of down-mixing, presumably because ALSA has no way of knowing what the connected speaker arrangement is.
Well I think the issue is more basic than that even. It seems to me that when you write to 'default' alsa seems to accept anything even when alsa 'knows' you don't have a surround card. See my example of the device attribute testing in #4
We really need to get some ALSA people involved - it's too hard to figure out anything ALSA related without the input of someone who 'knows', there's just not enough documentation to make sense of it otherwise. As another data point, I get different behaviour when using plug:surround51:0 as xine does, versus surround51:0. Who knows why? plug:surround51:0 produces: 0:00:00.447798000 4128 0x840410 DEBUG alsa gstalsasink.c:335:set_hwparams:<alsasink0> Negotiating to 6 channels @ 48000 Hz (format = S16_LE) 0:00:00.447909000 4128 0x840410 WARN alsa pcm_params.c:2152:snd_pcm_hw_refine_slave: alsalib error: Slave PCM not usable 0:00:00.448022000 4128 0x840410 WARN alsa gstalsasink.c:429:set_hwparams:<alsasink0> error: Broken configuration for playback: no configurations available: Invalid argument where surround51:0 results in just: 0:00:00.529074000 4226 0x83eea0 DEBUG alsa gstalsasink.c:335:set_hwparams:<alsasink0> Negotiating to 6 channels @ 48000 Hz (format = S16_LE) 0:00:00.529196000 4226 0x83eea0 WARN alsa gstalsasink.c:429:set_hwparams:<alsasink0> error: Broken configuration for playback: no configurations available: Invalid argument 0:00:00.529448000 4226 0x83eea0 WARN alsa Both settings allow the device to be opened, but fail to probe available formats: 0:00:00.266000000 4114 0x66f030 ERROR alsa gstalsa.c:383:gst_alsa_probe_supported_formats:<alsasink0> failed to query formats: Invalid argument 0:00:00.266041000 4114 0x66f030 INFO alsa gstalsasink.c:319:gst_alsasink_getcaps:<alsasink0> returning caps (NULL) 0:00:00.268137000 4114 0x66f030 ERROR alsa gstalsa.c:383:gst_alsa_probe_supported_formats:<alsasink0> failed to query formats: Invalid argument 0:00:00.268171000 4114 0x66f030 INFO alsa gstalsasink.c:319:gst_alsasink_getcaps:<alsasink0> returning caps (NULL) 0:00:00.272176000 4114 0x66f030 ERROR alsa gstalsa.c:383:gst_alsa_probe_supported_formats:<alsasink0> failed to query formats: Invalid argument
Is this still a problem?
Re-opening as I don't think we really fixed it. At the GStreamer Conference this year the ALSA maintainer will also attend, so hopefully we can sit down accross GStreamer, Pulse Audio and ALSA and figure out the proper solution.
Re-opening for real. I also think this is still a problem (was trying to fix this the other day, but I don't think there's alsa API that really tells us reliably what we need to know).
Is this still a problem? This should all work through PulseAudio and doing some quick testing with alsasink seems to work. Please re-open if you can reproduce the problem.
FWIW, even with PulseAudio, we still need to set the caps on the stream to get the expected output: https://git.gnome.org//browse/totem/tree/src/backend/bacon-video-widget.c#n3653 I can't really think of a reason why PulseAudio knowing that the device can output 5.1, and PA advertising this, GStreamer couldn't deal with upmixing itself. Not an alsasink issue though, so let me know if you prefer dealing with this in a separate bug.