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