Channel map API patches: to be 3.7 or not to be?

Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

Hi,

does anyone have concern if I push the current channel map API patches
(in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
i.e. for inclusion to 3.7 kernel?

I don't worry too much about the kernel API.  This can be refactored
later.  But the kernel ABI must retain, so we won't change in an
incompatible way any longer once after it's merged to the upstream.

So, if anyone sees a flaw in the kernel ABI definition using control
elements, let me know.

(But note that the API can't be perfect for all generic purposes.
 It's designed to be "good enough" for a big lack for multi-channel
 streaming.  Of course, this doesn't discourage to use the API for any
 other purposes.)


thanks,

Takashi

Re: Channel map API patches: to be 3.7 or not to be?

[Raymond Yau]

2012-9-11 上午1:43 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
>
> Hi,
>
> does anyone have concern if I push the current channel map API patches
> (in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
> i.e. for inclusion to 3.7 kernel?
>
> I don't worry too much about the kernel API.  This can be refactored
> later.  But the kernel ABI must retain, so we won't change in an
> incompatible way any longer once after it's merged to the upstream.
>
> So, if anyone sees a flaw in the kernel ABI definition using control
> elements, let me know.
>
> (But note that the API can't be perfect for all generic purposes.
>  It's designed to be "good enough" for a big lack for multi-channel
>  streaming.  Of course, this doesn't discourage to use the API for any
>  other purposes.)
>

How about the channel map of the usb mono playback device and those sound
card which can pan mono to stereo speakers and headphone?

Pulseaudio developer has just changed the downmixing method

The mono playback is not left anymore

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/416190
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Tue, 11 Sep 2012 16:10:43 +0800,
Raymond Yau wrote:
> 
> 2012-9-11 上午1:43 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
> >
> > Hi,
> >
> > does anyone have concern if I push the current channel map API patches
> > (in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
> > i.e. for inclusion to 3.7 kernel?
> >
> > I don't worry too much about the kernel API.  This can be refactored
> > later.  But the kernel ABI must retain, so we won't change in an
> > incompatible way any longer once after it's merged to the upstream.
> >
> > So, if anyone sees a flaw in the kernel ABI definition using control
> > elements, let me know.
> >
> > (But note that the API can't be perfect for all generic purposes.
> >  It's designed to be "good enough" for a big lack for multi-channel
> >  streaming.  Of course, this doesn't discourage to use the API for any
> >  other purposes.)
> >
> 
> How about the channel map of the usb mono playback device and those sound
> card which can pan mono to stereo speakers and headphone?

If the device specifies which speaker position the mono channel is
for, then you can map it properly.  Unless it's really specified by
the device, the mono stream is UNKNOWN position in general.

> Pulseaudio developer has just changed the downmixing method
> 
> The mono playback is not left anymore
> 
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/416190


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Tue, 11 Sep 2012 10:22:23 +0200,
Takashi Iwai wrote:
> 
> At Tue, 11 Sep 2012 16:10:43 +0800,
> Raymond Yau wrote:
> > 
> > 2012-9-11 上午1:43 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
> > >
> > > Hi,
> > >
> > > does anyone have concern if I push the current channel map API patches
> > > (in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
> > > i.e. for inclusion to 3.7 kernel?
> > >
> > > I don't worry too much about the kernel API.  This can be refactored
> > > later.  But the kernel ABI must retain, so we won't change in an
> > > incompatible way any longer once after it's merged to the upstream.
> > >
> > > So, if anyone sees a flaw in the kernel ABI definition using control
> > > elements, let me know.
> > >
> > > (But note that the API can't be perfect for all generic purposes.
> > >  It's designed to be "good enough" for a big lack for multi-channel
> > >  streaming.  Of course, this doesn't discourage to use the API for any
> > >  other purposes.)
> > >
> > 
> > How about the channel map of the usb mono playback device and those sound
> > card which can pan mono to stereo speakers and headphone?
> 
> If the device specifies which speaker position the mono channel is
> for, then you can map it properly.  Unless it's really specified by
> the device, the mono stream is UNKNOWN position in general.

BTW, this reminds me of an open question:
  is it useful to add SND_CHMAP_MONO, or is it just redundant?

It's nothing but indicating a mono channel without any channel
position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
SND_CHMAP_MONO would give a clear sign of mono streams while
SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Channel map API patches: to be 3.7 or not to be?

[Clemens Ladisch]

Takashi Iwai wrote:
> BTW, this reminds me of an open question:
>   is it useful to add SND_CHMAP_MONO, or is it just redundant?
>
> It's nothing but indicating a mono channel without any channel
> position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
> SND_CHMAP_MONO would give a clear sign of mono streams while
> SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.

What would it be used for?

Labeling surround channels is necessary for reordering them or for doing
up/downmixing.  A "mono" channel, however, does not appear to have any
semantic difference from a single "unknown" channel.


Regards,
Clemens

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Tue, 11 Sep 2012 14:19:49 +0200,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > BTW, this reminds me of an open question:
> >   is it useful to add SND_CHMAP_MONO, or is it just redundant?
> >
> > It's nothing but indicating a mono channel without any channel
> > position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
> > SND_CHMAP_MONO would give a clear sign of mono streams while
> > SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.
> 
> What would it be used for?
> 
> Labeling surround channels is necessary for reordering them or for doing
> up/downmixing.  A "mono" channel, however, does not appear to have any
> semantic difference from a single "unknown" channel.

Right, that's the current status.  OTOH, labeling it as "mono" makes
clear that it's an unaligned mono stream. i.e. it shows the purpose of 
the stream by itself.

Well, I'm not for introducing yet another definition.  Just stumbled
on it, and would like to know opinions from others.


thanks,

Takashi

Re: Channel map API patches: to be 3.7 or not to be?

[Raymond Yau]

2012-9-11 下午8:14 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
>
> At Tue, 11 Sep 2012 10:22:23 +0200,
> Takashi Iwai wrote:
> >
> > At Tue, 11 Sep 2012 16:10:43 +0800,
> > Raymond Yau wrote:
> > >
> > > 2012-9-11 上午1:43 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
> > > >
> > > > Hi,
> > > >
> > > > does anyone have concern if I push the current channel map API
patches
> > > > (in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
> > > > i.e. for inclusion to 3.7 kernel?
> > > >
> > > > I don't worry too much about the kernel API.  This can be refactored
> > > > later.  But the kernel ABI must retain, so we won't change in an
> > > > incompatible way any longer once after it's merged to the upstream.
> > > >
> > > > So, if anyone sees a flaw in the kernel ABI definition using control
> > > > elements, let me know.
> > > >
> > > > (But note that the API can't be perfect for all generic purposes.
> > > >  It's designed to be "good enough" for a big lack for multi-channel
> > > >  streaming.  Of course, this doesn't discourage to use the API for
any
> > > >  other purposes.)
> > > >
> > >
> > > How about the channel map of the usb mono playback device and those
sound
> > > card which can pan mono to stereo speakers and headphone?
> >
> > If the device specifies which speaker position the mono channel is
> > for, then you can map it properly.  Unless it's really specified by
> > the device, the mono stream is UNKNOWN position in general.
>
> BTW, this reminds me of an open question:
>   is it useful to add SND_CHMAP_MONO, or is it just redundant?
>
> It's nothing but indicating a mono channel without any channel
> position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
> SND_CHMAP_MONO would give a clear sign of mono streams while
> SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.
>
>

How about those sound card which use multi plugin for multi channels (e.g.
emu10k1 , c0106 and cs4630) as they can also provide a rear or clfe device
for independent stereo playback ?

It seem the branch still miss the patch for au88x0 and ymfpci which need to
check the sdac bit of ac97 codec for adding the 4 channels map

Most of 2.1 external speaker set only have green jack and those creative
4.1 fps have green and black jacks where the volume of subwoofer is
controlled by the volume knob of the subwoofer

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1047543

However some of those 2.1 internal speaker in notebook may need stereo
channel map (e.g. stac920x hda codec using mono widget)

Some notebook (e.g. acer aspire 4930g) hda codec) may need a special
channel map for the internal 2.1 speaker but a stereo channel map for the
external 2.1 speaker and some Asus laptops have propertiary jack for the
external subwoofer

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=786c51f9168cfd2d49250c6e5e60035cbb2fd5a1

Does those 3stack-6ch laptop/desktop have those 5.1 channel map before the
input jack retasked as output?

If yes, does the retasking is performed automatically by the set channel
map function?

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-unstable.git;a=commit;h=9c9a5175e65b2667001e6a3b6dedddebeee82aa2
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Wed, 12 Sep 2012 09:35:20 +0800,
Raymond Yau wrote:
> 
> 2012-9-11 下午8:14 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
> >
> > At Tue, 11 Sep 2012 10:22:23 +0200,
> > Takashi Iwai wrote:
> > >
> > > At Tue, 11 Sep 2012 16:10:43 +0800,
> > > Raymond Yau wrote:
> > > >
> > > > 2012-9-11 上午1:43 於 "Takashi Iwai" <tiwai@suse.de> 寫道：
> > > > >
> > > > > Hi,
> > > > >
> > > > > does anyone have concern if I push the current channel map API
> patches
> > > > > (in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
> > > > > i.e. for inclusion to 3.7 kernel?
> > > > >
> > > > > I don't worry too much about the kernel API.  This can be refactored
> > > > > later.  But the kernel ABI must retain, so we won't change in an
> > > > > incompatible way any longer once after it's merged to the upstream.
> > > > >
> > > > > So, if anyone sees a flaw in the kernel ABI definition using control
> > > > > elements, let me know.
> > > > >
> > > > > (But note that the API can't be perfect for all generic purposes.
> > > > >  It's designed to be "good enough" for a big lack for multi-channel
> > > > >  streaming.  Of course, this doesn't discourage to use the API for
> any
> > > > >  other purposes.)
> > > > >
> > > >
> > > > How about the channel map of the usb mono playback device and those
> sound
> > > > card which can pan mono to stereo speakers and headphone?
> > >
> > > If the device specifies which speaker position the mono channel is
> > > for, then you can map it properly.  Unless it's really specified by
> > > the device, the mono stream is UNKNOWN position in general.
> >
> > BTW, this reminds me of an open question:
> >   is it useful to add SND_CHMAP_MONO, or is it just redundant?
> >
> > It's nothing but indicating a mono channel without any channel
> > position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
> > SND_CHMAP_MONO would give a clear sign of mono streams while
> > SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.
> >
> >
> 
> How about those sound card which use multi plugin for multi channels (e.g.
> emu10k1 , c0106 and cs4630) as they can also provide a rear or clfe device
> for independent stereo playback ?

The case of emu10k1 is a bit difficult, as the routing is completely
dynamic and determined in alsa-lib plugin.  So, my plan for this case
is to provide the chmap override in the alsa-lib config definition for
emu10k1 surrounds.

In other cases, the PCM stream is mostly bound with certain channels,
and multi plugin can combine all these chmaps.  ctxfi already provides
independent stereo streams like RL/RR, combined via multi plugin for
4.0 or 5.1.

> It seem the branch still miss the patch for au88x0 and ymfpci which need to
> check the sdac bit of ac97 codec for adding the 4 channels map

Feel free to send a patch.

> Most of 2.1 external speaker set only have green jack and those creative
> 4.1 fps have green and black jacks where the volume of subwoofer is
> controlled by the volume knob of the subwoofer
> 
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1047543
> 
> However some of those 2.1 internal speaker in notebook may need stereo
> channel map (e.g. stac920x hda codec using mono widget)
> 
> Some notebook (e.g. acer aspire 4930g) hda codec) may need a special
> channel map for the internal 2.1 speaker but a stereo channel map for the
> external 2.1 speaker and some Asus laptops have propertiary jack for the
> external subwoofer
> 
> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=786c51f9168cfd2d49250c6e5e60035cbb2fd5a1

The _only_ interest for now is how to map the channels for
multi-channel streams, and whether the API proposal can cover it or
not.  When the hardware binds a boost speaker internally, it's not
what applications care.  It's nothing but a driver setup.

So, the only interesting topic in the above would be the proper 2.1
mapping (i.e. the lack of FC channel) for ASUS laptops.  And this case
doesn't conflict with the API proposal.

> Does those 3stack-6ch laptop/desktop have those 5.1 channel map before the
> input jack retasked as output?

It depends on the driver implementation.  API doesn't restrict the
behavior.  I myself suppose the query could be static in such a case
while get/set should reflect to the current jack state.

> If yes, does the retasking is performed automatically by the set channel
> map function?
> 
> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-unstable.git;a=commit;h=9c9a5175e65b2667001e6a3b6dedddebeee82aa2

The operation is allowed in theory, feel free to implement.
But I don't think we'd need it.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Tue, 11 Sep 2012 14:24:09 +0200,
Takashi Iwai wrote:
> 
> At Tue, 11 Sep 2012 14:19:49 +0200,
> Clemens Ladisch wrote:
> > 
> > Takashi Iwai wrote:
> > > BTW, this reminds me of an open question:
> > >   is it useful to add SND_CHMAP_MONO, or is it just redundant?
> > >
> > > It's nothing but indicating a mono channel without any channel
> > > position, so I supposed SND_CHMAP_UNKNOWN being sufficient.  OTOH,
> > > SND_CHMAP_MONO would give a clear sign of mono streams while
> > > SND_CHMAP_UNKNOWN could be used for any other exceptional purposes.
> > 
> > What would it be used for?
> > 
> > Labeling surround channels is necessary for reordering them or for doing
> > up/downmixing.  A "mono" channel, however, does not appear to have any
> > semantic difference from a single "unknown" channel.
> 
> Right, that's the current status.  OTOH, labeling it as "mono" makes
> clear that it's an unaligned mono stream. i.e. it shows the purpose of 
> the stream by itself.

Looking at PulseAudio and gstreamer codes, they seem to have explicit
MONO channel definition.

typedef enum pa_channel_position {
    PA_CHANNEL_POSITION_INVALID = -1,
    PA_CHANNEL_POSITION_MONO = 0,
    ....

typedef enum {
  GST_AUDIO_CHANNEL_POSITION_INVALID = -1,

  /* Main front speakers. Mono and left/right are mututally exclusive! */
  GST_AUDIO_CHANNEL_POSITION_FRONT_MONO,
  ....

So, defining MONO seems rather standard.  Now I'm inclined to define
SND_CHMAP_MONO...


Takashi

Re: Channel map API patches: to be 3.7 or not to be?

[Clemens Ladisch]

Takashi Iwai wrote:
>> Clemens Ladisch wrote:
>>> Takashi Iwai wrote:
>>>>   is it useful to add SND_CHMAP_MONO, or is it just redundant?
>>>
>>> What would it be used for?
>
> Looking at PulseAudio and gstreamer codes, they seem to have explicit
> MONO channel definition.
> [...]
> So, defining MONO seems rather standard.  Now I'm inclined to define
> SND_CHMAP_MONO...

Okay; if they want it, they can get it ...


Regards,
Clemens

Re: [alsa-devel] Channel map API patches: to be 3.7 or not to be?

[Tanu Kaskinen]

On Wed, 2012-09-12 at 18:32 +0200, Clemens Ladisch wrote:
> Takashi Iwai wrote:
> >> Clemens Ladisch wrote:
> >>> Takashi Iwai wrote:
> >>>>   is it useful to add SND_CHMAP_MONO, or is it just redundant?
> >>>
> >>> What would it be used for?
> >
> > Looking at PulseAudio and gstreamer codes, they seem to have explicit
> > MONO channel definition.
> > [...]
> > So, defining MONO seems rather standard.  Now I'm inclined to define
> > SND_CHMAP_MONO...
> 
> Okay; if they want it, they can get it ...

Speaking as a PulseAudio developer, "wanting" is a bit strong word. I
initially wanted it, but I don't anymore think that it's necessary. I
don't think it will do any harm either, though...

-- 
Tanu

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Mon, 10 Sep 2012 19:43:33 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> does anyone have concern if I push the current channel map API patches
> (in sound-unstable git tree topic/tlv-chmap branch) for linux-next,
> i.e. for inclusion to 3.7 kernel?
> 
> I don't worry too much about the kernel API.  This can be refactored
> later.  But the kernel ABI must retain, so we won't change in an
> incompatible way any longer once after it's merged to the upstream.
> 
> So, if anyone sees a flaw in the kernel ABI definition using control
> elements, let me know.
> 
> (But note that the API can't be perfect for all generic purposes.
>  It's designed to be "good enough" for a big lack for multi-channel
>  streaming.  Of course, this doesn't discourage to use the API for any
>  other purposes.)

FYI, as I haven't got any big NO-NO, now the topic branch for chmap is
merged to for-next branch.  I'm going to merge user-space side,
alsa-lib and alsa-utils patches.


Takashi

Re: Channel map API patches: to be 3.7 or not to be?

[Raymond Yau]

> > How about those sound card which use multi plugin for multi channels
(e.g.
> > emu10k1 , c0106 and cs4630) as they can also provide a rear or clfe
device
> > for independent stereo playback ?
>
> The case of emu10k1 is a bit difficult, as the routing is completely
> dynamic and determined in alsa-lib plugin.  So, my plan for this case
> is to provide the chmap override in the alsa-lib config definition for
> emu10k1 surrounds.
>
But the routing of device 0 "hw" is not as same as front device since the
driver pan the output to both front and rear jacks (upmixing).

Does all pcm devices support channel map ?

How about those 16 channels multichannel playback and capture devices ?

card 0: Live [SB Live! Platinum [CT4760P]], device 2: emu10k1 efx
[Multichannel Capture/PT Playback]
  Subdevices: 8/8

card 0: Live [SB Live! Platinum [CT4760P]], device 3: emu10k1 [Multichannel
Playback]
  Subdevices: 1/1

**** List of CAPTURE Hardware Devices ****

card 0: Live [SB Live! Platinum [CT4760P]], device 2: emu10k1 efx
[Multichannel Capture/PT Playback]
  Subdevices: 1/1

BTW. It seem that the patch for USB audio is still missing as some USB card
support 5.1/7.1

Re: Channel map API patches: to be 3.7 or not to be?

[Takashi Iwai]

At Mon, 17 Sep 2012 18:46:32 +0800,
Raymond Yau wrote:
> 
> > > How about those sound card which use multi plugin for multi channels
> (e.g.
> > > emu10k1 , c0106 and cs4630) as they can also provide a rear or clfe
> device
> > > for independent stereo playback ?
> >
> > The case of emu10k1 is a bit difficult, as the routing is completely
> > dynamic and determined in alsa-lib plugin.  So, my plan for this case
> > is to provide the chmap override in the alsa-lib config definition for
> > emu10k1 surrounds.
> >
> But the routing of device 0 "hw" is not as same as front device since the
> driver pan the output to both front and rear jacks (upmixing).

The hw device doesn't provide any map.  It's only for "front", "rear"
whatever in strict channel position definitions.

> Does all pcm devices support channel map ?

No.  The channel map is an optional feature.

> How about those 16 channels multichannel playback and capture devices ?
> 
> card 0: Live [SB Live! Platinum [CT4760P]], device 2: emu10k1 efx
> [Multichannel Capture/PT Playback]
>   Subdevices: 8/8
> 
> card 0: Live [SB Live! Platinum [CT4760P]], device 3: emu10k1 [Multichannel
> Playback]
>   Subdevices: 1/1
>
> **** List of CAPTURE Hardware Devices ****
> 
> card 0: Live [SB Live! Platinum [CT4760P]], device 2: emu10k1 efx
> [Multichannel Capture/PT Playback]
>   Subdevices: 1/1

Such devices are not supported.  If any, they can be mapped using
DRIVER_SPEC flag.


> BTW. It seem that the patch for USB audio is still missing as some USB card
> support 5.1/7.1

Feel free to submit a patch :)


Takashi