* Channel map API patches: to be 3.7 or not to be? @ 2012-09-10 17:43 Takashi Iwai 2012-09-11 8:10 ` Raymond Yau 2012-09-17 9:39 ` Takashi Iwai 0 siblings, 2 replies; 14+ messages in thread From: Takashi Iwai @ 2012-09-10 17:43 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-10 17:43 Channel map API patches: to be 3.7 or not to be? Takashi Iwai @ 2012-09-11 8:10 ` Raymond Yau 2012-09-11 8:22 ` Takashi Iwai 2012-09-17 9:39 ` Takashi Iwai 1 sibling, 1 reply; 14+ messages in thread From: Raymond Yau @ 2012-09-11 8:10 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-11 8:10 ` Raymond Yau @ 2012-09-11 8:22 ` Takashi Iwai 2012-09-11 12:14 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2012-09-11 8:22 UTC (permalink / raw) To: Raymond Yau; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-11 8:22 ` Takashi Iwai @ 2012-09-11 12:14 ` Takashi Iwai 2012-09-11 12:19 ` Clemens Ladisch 2012-09-12 1:35 ` Raymond Yau 0 siblings, 2 replies; 14+ messages in thread From: Takashi Iwai @ 2012-09-11 12:14 UTC (permalink / raw) To: Raymond Yau; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-11 12:14 ` Takashi Iwai @ 2012-09-11 12:19 ` Clemens Ladisch 2012-09-11 12:24 ` Takashi Iwai 2012-09-12 1:35 ` Raymond Yau 1 sibling, 1 reply; 14+ messages in thread From: Clemens Ladisch @ 2012-09-11 12:19 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-11 12:19 ` Clemens Ladisch @ 2012-09-11 12:24 ` Takashi Iwai 2012-09-12 16:03 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2012-09-11 12:24 UTC (permalink / raw) To: Clemens Ladisch; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-11 12:24 ` Takashi Iwai @ 2012-09-12 16:03 ` Takashi Iwai 2012-09-12 16:32 ` Clemens Ladisch 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2012-09-12 16:03 UTC (permalink / raw) To: Clemens Ladisch; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-12 16:03 ` Takashi Iwai @ 2012-09-12 16:32 ` Clemens Ladisch 2012-09-12 17:20 ` [alsa-devel] " Tanu Kaskinen 0 siblings, 1 reply; 14+ messages in thread From: Clemens Ladisch @ 2012-09-12 16:32 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [alsa-devel] Channel map API patches: to be 3.7 or not to be? 2012-09-12 16:32 ` Clemens Ladisch @ 2012-09-12 17:20 ` Tanu Kaskinen 0 siblings, 0 replies; 14+ messages in thread From: Tanu Kaskinen @ 2012-09-12 17:20 UTC (permalink / raw) To: Clemens Ladisch; +Cc: Takashi Iwai, alsa-devel, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-11 12:14 ` Takashi Iwai 2012-09-11 12:19 ` Clemens Ladisch @ 2012-09-12 1:35 ` Raymond Yau 2012-09-12 6:21 ` Takashi Iwai 1 sibling, 1 reply; 14+ messages in thread From: Raymond Yau @ 2012-09-12 1:35 UTC (permalink / raw) To: Takashi Iwai Cc: lukasz.wojnilowicz, ALSA Development Mailing List, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-12 1:35 ` Raymond Yau @ 2012-09-12 6:21 ` Takashi Iwai 2012-09-17 10:46 ` Raymond Yau 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2012-09-12 6:21 UTC (permalink / raw) To: Raymond Yau Cc: lukasz.wojnilowicz, ALSA Development Mailing List, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-12 6:21 ` Takashi Iwai @ 2012-09-17 10:46 ` Raymond Yau 2012-09-17 10:49 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Raymond Yau @ 2012-09-17 10:46 UTC (permalink / raw) To: Takashi Iwai Cc: lukasz.wojnilowicz, ALSA Development Mailing List, pulseaudio-discuss > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-17 10:46 ` Raymond Yau @ 2012-09-17 10:49 ` Takashi Iwai 0 siblings, 0 replies; 14+ messages in thread From: Takashi Iwai @ 2012-09-17 10:49 UTC (permalink / raw) To: Raymond Yau Cc: lukasz.wojnilowicz, ALSA Development Mailing List, pulseaudio-discuss 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Channel map API patches: to be 3.7 or not to be? 2012-09-10 17:43 Channel map API patches: to be 3.7 or not to be? Takashi Iwai 2012-09-11 8:10 ` Raymond Yau @ 2012-09-17 9:39 ` Takashi Iwai 1 sibling, 0 replies; 14+ messages in thread From: Takashi Iwai @ 2012-09-17 9:39 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-09-17 10:49 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-10 17:43 Channel map API patches: to be 3.7 or not to be? Takashi Iwai 2012-09-11 8:10 ` Raymond Yau 2012-09-11 8:22 ` Takashi Iwai 2012-09-11 12:14 ` Takashi Iwai 2012-09-11 12:19 ` Clemens Ladisch 2012-09-11 12:24 ` Takashi Iwai 2012-09-12 16:03 ` Takashi Iwai 2012-09-12 16:32 ` Clemens Ladisch 2012-09-12 17:20 ` [alsa-devel] " Tanu Kaskinen 2012-09-12 1:35 ` Raymond Yau 2012-09-12 6:21 ` Takashi Iwai 2012-09-17 10:46 ` Raymond Yau 2012-09-17 10:49 ` Takashi Iwai 2012-09-17 9:39 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.