[alsa-devel] Channel map API patches: to be 3.7 or not to be?
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
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
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
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
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
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
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
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
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=786c51f...
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;...
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=786c51f...
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;...
The operation is allowed in theory, feel free to implement. But I don't think we'd need it.
Takashi
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
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
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
participants (3)
-
Clemens Ladisch -
Raymond Yau -
Takashi Iwai