Hi Takashi, Thanks for trying to help us with trying to resolve http://bugzilla.gnome.org/show_bug.cgi?id=410403.

I tested a bit with a 6-channel .wav file and aplay. It seems it shows the same issues that we are seeing in GStreamer. Namely that if I try:

aplay -D front dust51.wav Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6 aplay: set_params:905: Channels count non available

It correctly tells me that it doesn't support outputting this many channels. This is fine for GStreamer as it allows our negotiation to plug in a downmixing element.

However if I do: aplay -D default dust51.wav Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6

It plays out the 'front' channels, but the remainders just get lost. So when outputting to default neither do alsa downmix by itself or fail telling you that you don't have the needed 6 channels available.

Since Jan brought up the issue of behaviour differences between plug:surround51 ad surround51 I thought I give you the output of that too.

aplay -D surround51:0 dust51.wav Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6 aplay: set_params:878: Broken configuration for this PCM: no configurations available

aplay -D plug:surround51:0 dust51.wav Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6 ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not usable aplay: set_params:878: Broken configuration for this PCM: no configurations available

Christian

On Thu, 2007-03-29 at 12:52 +0200, Takashi Iwai wrote:

At Wed, 28 Mar 2007 17:52:21 +0200, Christian F.K. Schaller wrote:

...

Hi, We are still having issues resolving how to deal with Surround sound and ALSA in GStreamer. If anyone knowledgeable about ALSA would be willing to comment on this bug: http://bugzilla.gnome.org/show_bug.cgi?id=410403

We would much appreciate it.

Not sure what actually the code is doing, but does simply aplay work on that system?

% aplay -D surround51:0 foo.wav

or

% aplay -D plug:surround51:0 foo.wav

The 5.1 output is sensible to devices, so it's helpful to know what hardware is used, too.

Takashi

At Thu, 29 Mar 2007 14:01:50 +0200, I wrote:

At Thu, 29 Mar 2007 13:55:27 +0200, Christian F.K. Schaller wrote:

...

Hi Takashi, Thanks for trying to help us with trying to resolve http://bugzilla.gnome.org/show_bug.cgi?id=410403.

I tested a bit with a 6-channel .wav file and aplay. It seems it shows the same issues that we are seeing in GStreamer. Namely that if I try:

aplay -D front dust51.wav Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6 aplay: set_params:905: Channels count non available

It correctly tells me that it doesn't support outputting this many channels. This is fine for GStreamer as it allows our negotiation to plug in a downmixing element.

However if I do: aplay -D default dust51.wav Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Channels 6

It plays out the 'front' channels, but the remainders just get lost. So when outputting to default neither do alsa downmix by itself or fail telling you that you don't have the needed 6 channels available.

This is expected behavior. The "default" PCM is built with plug player which absorbs the channel / format / rate differences. The

s/player/layer/

Takashi

At Thu, 29 Mar 2007 15:57:22 +0200, Christian F.K. Schaller wrote:

On Thu, 2007-03-29 at 14:01 +0200, Takashi Iwai wrote:

<snip> > > Since Jan brought up the issue of behaviour differences between > > plug:surround51 ad surround51 I thought I give you the output of that > > too. > > > > aplay -D surround51:0 dust51.wav > > Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > > Channels 6 > > aplay: set_params:878: Broken configuration for this PCM: no > > configurations available > > > > aplay -D plug:surround51:0 dust51.wav > > Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > > Channels 6 > > ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not > > usable > > aplay: set_params:878: Broken configuration for this PCM: no > > configurations available > > Which hardware do you have and which alsa-lib version are you using? > surround51 should work in this case...

[cschalle@localhost Desktop]$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel 82801DB-ICH4 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0

[cschalle@localhost Desktop]$ rpm -qa|grep alsa alsa-lib-1.0.14-0.1.rc1.fc6 alsa-lib-devel-1.0.14-0.1.rc1.fc6 alsa-tools-1.0.12-4.fc6 alsa-utils-1.0.14-0.1.rc1.fc6

So far, so good. And which codec chip?

You may see more (sometimes too) verbose errors when you set the environment variable LIBASOUND_DEBUG=1 or 2. Give it a try.

Takashi

At Thu, 29 Mar 2007 16:37:51 +0200, Christian F.K. Schaller wrote:

On Thu, 2007-03-29 at 16:17 +0200, Takashi Iwai wrote:

...

At Thu, 29 Mar 2007 15:57:22 +0200, Christian F.K. Schaller wrote:

...

On Thu, 2007-03-29 at 14:01 +0200, Takashi Iwai wrote:

<snip> > > Since Jan brought up the issue of behaviour differences between > > plug:surround51 ad surround51 I thought I give you the output of that > > too. > > > > aplay -D surround51:0 dust51.wav > > Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > > Channels 6 > > aplay: set_params:878: Broken configuration for this PCM: no > > configurations available > > > > aplay -D plug:surround51:0 dust51.wav > > Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > > Channels 6 > > ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not > > usable > > aplay: set_params:878: Broken configuration for this PCM: no > > configurations available > > Which hardware do you have and which alsa-lib version are you using? > surround51 should work in this case...

[cschalle@localhost Desktop]$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel 82801DB-ICH4 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0

[cschalle@localhost Desktop]$ rpm -qa|grep alsa alsa-lib-1.0.14-0.1.rc1.fc6 alsa-lib-devel-1.0.14-0.1.rc1.fc6 alsa-tools-1.0.12-4.fc6 alsa-utils-1.0.14-0.1.rc1.fc6

So far, so good. And which codec chip?

You may see more (sometimes too) verbose errors when you set the environment variable LIBASOUND_DEBUG=1 or 2. Give it a try.

Hi Takashi

How do I figure out the codec chip?

Grr, sorry, I removed a line while I corected the later sentenses. Look at /proc/asound/card0/codec97#0/* files.

Also I am not sure what you are looking for here, are you saying that the surround51 device should work even on stereo only soundcards?

No, "surround51" is exclusive to 6 channels.

and by using that Alsa should automatically downmix?

Actually, it's a bit complicated. Currently, "default" PCM is set up for two channels. You can override it as 5.1 channels, or even a virtual 5.1 surround for headphone. The automatic upmix is also possible if you set up 5.1 as default. However, all these things are not provided "as is". This is really what we have to consider how to do better.

I personally am not satisfied by the current implementation from usability POV. So, any suggestions for further improvements are welcome.

thanks,

Takashi

At Thu, 29 Mar 2007 17:05:00 +0200, Christian F.K. Schaller wrote:

On Thu, 2007-03-29 at 16:41 +0200, Takashi Iwai wrote:

...

At Thu, 29 Mar 2007 16:37:51 +0200, Christian F.K. Schaller wrote:

...

On Thu, 2007-03-29 at 16:17 +0200, Takashi Iwai wrote:

...

At Thu, 29 Mar 2007 15:57:22 +0200, Christian F.K. Schaller wrote:

...

On Thu, 2007-03-29 at 14:01 +0200, Takashi Iwai wrote:

<snip> > > Since Jan brought up the issue of behaviour differences between > > plug:surround51 ad surround51 I thought I give you the output of that > > too. > > > > aplay -D surround51:0 dust51.wav > > Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > > Channels 6 > > aplay: set_params:878: Broken configuration for this PCM: no > > configurations available > > > > aplay -D plug:surround51:0 dust51.wav > > Playing WAVE 'dust51.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > > Channels 6 > > ALSA lib pcm_params.c:2152:(snd_pcm_hw_refine_slave) Slave PCM not > > usable > > aplay: set_params:878: Broken configuration for this PCM: no > > configurations available > > Which hardware do you have and which alsa-lib version are you using? > surround51 should work in this case...

[cschalle@localhost Desktop]$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 0: Intel ICH [Intel 82801DB-ICH4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: I82801DBICH4 [Intel 82801DB-ICH4], device 4: Intel ICH - IEC958 [Intel 82801DB-ICH4 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0

[cschalle@localhost Desktop]$ rpm -qa|grep alsa alsa-lib-1.0.14-0.1.rc1.fc6 alsa-lib-devel-1.0.14-0.1.rc1.fc6 alsa-tools-1.0.12-4.fc6 alsa-utils-1.0.14-0.1.rc1.fc6

So far, so good. And which codec chip?

You may see more (sometimes too) verbose errors when you set the environment variable LIBASOUND_DEBUG=1 or 2. Give it a try.

Hi Takashi

How do I figure out the codec chip?

Grr, sorry, I removed a line while I corected the later sentenses. Look at /proc/asound/card0/codec97#0/* files.

...

Also I am not sure what you are looking for here, are you saying that the surround51 device should work even on stereo only soundcards?

No, "surround51" is exclusive to 6 channels.

...

and by using that Alsa should automatically downmix?

Actually, it's a bit complicated. Currently, "default" PCM is set up for two channels. You can override it as 5.1 channels, or even a virtual 5.1 surround for headphone. The automatic upmix is also possible if you set up 5.1 as default. However, all these things are not provided "as is". This is really what we have to consider how to do better.

I personally am not satisfied by the current implementation from usability POV. So, any suggestions for further improvements are welcome.

thanks,

Takashi

Ok, so the content of that file is: 0-0/0: SigmaTel STAC9750,51

PCI Subsys Vendor: 0x1028 PCI Subsys Device: 0x0191

Capabilities : -headphone out- DAC resolution : 20-bit ADC resolution : 20-bit 3D enhancement : SigmaTel 3D Enhancement

Current setup Mic gain : +20dB [+20dB] POP path : pre 3D Sim. stereo : off 3D enhancement : off Loudness : off Mono output : MIX Mic select : Mic1 ADC/DAC loopback : off Extended ID : codec=0 rev=1 AMAP DSA=0 SPDIF VRA Extended status : SPCV SPDIF=10/11 VRA PCM front DAC : 48000Hz PCM ADC : 48000Hz SPDIF Control : Consumer PCM Category=0x2 Generation=1 Rate=48kHz

OK this explains all. This codec has no surround outputs. So, 5.1 output isn't really supported.

So my suggestion so far when we have been discussing this inside the GStreamer community is to use 'front' as default device instead of 'default'.

A drawback of "front" is that it doesn't include the software mixing feature. (Dito for "surround*" and "spdif") So far, only "default" PCM has a dmix as it is. If gstream is the only sound system, it'd be fine, though.

That way we will always play(downmix) all channels and nobody 'lose' sound. We can then provide configuration GUI's like Totem do to override this when people have surround capable systems (meaning both capable card and connected speakers). Do this sound like a reasonable approach t you?

It sounds reasonable to me.

Or, you can simply assume number of channels for each preset, i.e. 2ch = default, 4ch = plug:surround40, 5.1ch = plug:surround51, without querying alsa-lib.

Takashi

At Fri, 30 Mar 2007 00:32:16 +0200, Ingo Müller wrote:

Takashi Iwai schrieb:

...

...

So my suggestion so far when we have been discussing this inside the GStreamer community is to use 'front' as default device instead of 'default'.

A drawback of "front" is that it doesn't include the software mixing feature. (Dito for "surround*" and "spdif") So far, only "default" PCM has a dmix as it is. If gstream is the only sound system, it'd be fine, though.

...

That way we will always play(downmix) all channels and nobody 'lose' sound. We can then provide configuration GUI's like Totem do to override this when people have surround capable systems (meaning both capable card and connected speakers). Do this sound like a reasonable approach t you?

It sounds reasonable to me.

Or, you can simply assume number of channels for each preset, i.e. 2ch = default, 4ch = plug:surround40, 5.1ch = plug:surround51, without querying alsa-lib.

Takashi

I'd prefer the "default" device being the default device - that's why it's called like this :-) As the default device is usually a stereo device, only stereo sound should be played there. Surround sound should be played on surround51, surround40, surround71... depending on how many channels the stream has. What these devices do with the sound they receive is not the problem of the application, IMO.

I see your point. Actually, other PCM name was proposed at first, but in the end, it was simply merged to "default" because everyone uses it. We have "front" for the front 2-channel if it really matters.

A question still remains, however: should these outputs be coped with dmix? For example, we can set up relatively easily the dmix + plug version of surround51, too.

One possible problem with plug+dmix'ing surround51 is that this would result in incompatibility with older configuration, and may break the apps using the current config. For example, plug over plug can result in unexpected channel routing. This is rather a bug, but a bit hard to fix, so far.

After that, ALSA or the distribution or the system admin should make sure, that the surroundX devices handle the sound apropriately. I'm sure it is possible to alter the predefined surroundX devices in a way so they upmix/downmix to the amount of channels the concerned sound card actually has. If one is more experienced, he can still overwrite the definitions of these predefined devices according to his suites.

The sound-system management is another missing piece in the whole picture that ALSA currently has. We have a flexible configuration, but it alone doesn't suffice. Currently, we're trying to provide a reasonable "default", which can work for _most_ of users OOTB. But, this isn't apparently enough nowadays. Now the time to consider...

Takashi