After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 410403 - Alsasink needs to work differently for surround
Alsasink needs to work differently for surround
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 409661
 
 
Reported: 2007-02-21 14:54 UTC by Christian Fredrik Kalager Schaller
Modified: 2018-05-04 14:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Fredrik Kalager Schaller 2007-02-21 14:54:25 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.
Comment 1 Christian Fredrik Kalager Schaller 2007-02-21 15:09:23 UTC
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).
Comment 2 Christian Fredrik Kalager Schaller 2007-02-23 11:25:44 UTC
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 ...
Comment 3 Tim-Philipp Müller 2007-02-23 11:46:38 UTC
"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.
Comment 4 Christian Fredrik Kalager Schaller 2007-02-23 12:13:27 UTC
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

Comment 5 Jan Schmidt 2007-02-27 13:25:22 UTC
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.
Comment 6 Christian Fredrik Kalager Schaller 2007-02-27 13:39:13 UTC
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
Comment 7 Jan Schmidt 2007-02-27 14:19:55 UTC
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
Comment 8 Sebastian Dröge (slomo) 2011-05-18 12:54:35 UTC
Is this still a problem?
Comment 9 Christian Fredrik Kalager Schaller 2011-06-29 08:18:41 UTC
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.
Comment 10 Tim-Philipp Müller 2011-06-29 10:00:25 UTC
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).
Comment 11 Olivier Crête 2018-05-04 11:10:23 UTC
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.
Comment 12 Bastien Nocera 2018-05-04 14:17:49 UTC
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.