Re: [alsa-devel] How to define card specific pcm devices?
2012-8-17 下午10:51 於 "Tanu Kaskinen" tanu.kaskinen@digia.com 寫道：
Ping?
If card specific pcm definitions are not possible, would it be acceptable to have a generic "front_left:CARD" or "first_channel:CARD" pcm, which would transform "front:CARD" or "hw:CARD" into a mono device?
As pulseaudio server use SND_PCM_NO_AUTO_CHANNEL which diable channel conversion, this left channel device only work with other alsa applications except pulseaudio when your sound card does not support mono.
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=ff4af902cf4ac07...
the solution is to change the mixing in pulseaudio by using left channel for this mic and those stereo mic with inverted phase , and average for mono playback device . stereo mic and line-in
how about the 4 channel mic?
-- Tanu
On Fri, 2012-08-10 at 14:25 +0300, Tanu Kaskinen wrote:
Hi,
I'm writing UCM configuration for RX-51 (Nokia N900), and I have a problem: "hw:RX51" can't be opened in mono mode, but there's only one integrated mono microphone, and its audio is routed to the left input channel. Applications will get only silence in the right channel when they use "hw:RX51".
The best solution that I have come up is to define a pcm that converts "hw:RX51" into a mono device. The problem is that I don't know how exactly to do that. I guess the route plugin can be used for that:
pcm.rx51_mono_from_left { type route slave.pcm hw:RX51 slave.channels 2 ttable.0.0 1 }
I tried putting that definition in /usr/share/alsa/cards/RX-51.conf (and also RX51.conf, since it's not entirely clear to me when the dash should be omitted). I have this in the UCM configuration:
Value { CapturePCM "rx51_mono_from_left" CaptureChannels "1" }
This is printed to the PulseAudio log:
(alsa-lib)pcm.c: Unknown PCM rx51_mono_from_left
So the rx51_mono_from_left definition is not loaded. I'm not terribly surprised: I guess the card configuration files are loaded only when necessary, and when PulseAudio tries to open "rx51_mono_from_left", alsa-lib can't really know that it's somehow related to the RX-51 card.
How should I solve this?
On Sat, 2012-08-18 at 09:26 +0800, Raymond Yau wrote:
2012-8-17 下午10:51 於 "Tanu Kaskinen" tanu.kaskinen@digia.com 寫道：
Ping?
If card specific pcm definitions are not possible, would it be acceptable to have a generic "front_left:CARD" or "first_channel:CARD" pcm, which would transform "front:CARD" or "hw:CARD" into a mono device?
As pulseaudio server use SND_PCM_NO_AUTO_CHANNEL which diable channel conversion, this left channel device only work with other alsa applications except pulseaudio when your sound card does not support mono.
So are you suggesting that Alsa doesn't need any changes, because all other applications allow automatic channel conversion, and therefore this is a PulseAudio specific problem and should be fixed in PulseAudio?
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=ff4af902cf4ac07...
the solution is to change the mixing in pulseaudio by using left channel for this mic and those stereo mic with inverted phase , and average for mono playback device . stereo mic and line-in
Sure this can be fixed in PulseAudio with card specific configuration, but if at all possible, I want to avoid card specific configuration in PulseAudio. I believe one of the main points of UCM is to avoid hardware specific configuration in applications using Alsa.
This could be solved also by stating in the UCM configuration that only the left channel of the stereo device contains useful data. This would avoid having card specific configuration in applications, but handling that information adds more complexity in applications. Having a proper mono device in Alsa would avoid any changes in applications.
how about the 4 channel mic?
What about it? The discussion stopped when I asked what should be the name for the device. I asked whether "4channelinput" would be good, but got no answers. At PulseAudio side we figured that "hw" works well enough in practice, so there was not much pressure for me to keep the discussion alive.
how about the 4 channel mic?
What about it? The discussion stopped when I asked what should be the name for the device. I asked whether "4channelinput" would be good, but got no answers. At PulseAudio side we figured that "hw" works well enough in practice
http://www.rrfx.net/2009/11/ps3-eye-4-channel-audio-tests-on-ubuntu.html
the geometry of the microphone array is an important factor for how to perform downmixing to mono as there are delay between the four mics and the channel map of mic array is different from the channel map of surround speakers
2012-8-18 下午12:09 於 "Tanu Kaskinen" tanuk@iki.fi 寫道：
On Sat, 2012-08-18 at 09:26 +0800, Raymond Yau wrote:
2012-8-17 下午10:51 於 "Tanu Kaskinen" tanu.kaskinen@digia.com 寫道：
Ping?
If card specific pcm definitions are not possible, would it be acceptable to have a generic "front_left:CARD" or "first_channel:CARD" pcm, which would transform "front:CARD" or "hw:CARD" into a mono
device?
As pulseaudio server use SND_PCM_NO_AUTO_CHANNEL which diable channel conversion, this left channel device only work with other alsa
applications
except pulseaudio when your sound card does not support mono.
So are you suggesting that Alsa doesn't need any changes, because all other applications allow automatic channel conversion, and therefore this is a PulseAudio specific problem and should be fixed in PulseAudio?
strictly speaking your mic is not a true stereo mic and the channel map is [left, null] instead of the normal map [left,right] of line-in or stereo mic
the channel map for those stereo mic which have out of phase left and right channel is either [left,-left] or [-right,right]
some stereo mic may has [null,right]
On Wed, 2012-08-29 at 09:44 +0800, Raymond Yau wrote:
strictly speaking your mic is not a true stereo mic and the channel map is [left, null] instead of the normal map [left,right] of line-in or stereo mic
I think specifying the channel map like you suggest would be a good solution. Supporting it would require some extra work in PulseAudio, but I think PulseAudio will anyway have to be extended to query the channel map information from UCM.
Now the problem is that UCM doesn't provide the channel map information at all. Should the channel map be provided in the device "Value" section? Like this:
SectionDevice."my-mono-mic" {
...
Value { # Does this value become redundant if # the "CaptureChannelMap" value is added? CaptureChannels "2"
# Channel names match the constants in # Takashi's proposed channel map API CaptureChannelMap "FL, NA" }
}
Opinions? (Liam added to CC - am I right in that you should be CC'd in all UCM related discussions?)
participants (2)
-
Raymond Yau -
Tanu Kaskinen