[pulseaudio-discuss] [PATCH] Implement Fortemedia SMA processing.
gmane at colin.guthr.ie
Sat Jan 15 05:45:08 PST 2011
'Twas brillig, and Alban Browaeys at 14/01/11 20:56 did gyre and gimble:
> Le jeudi 06 janvier 2011 à 10:30 +0000, Colin Guthrie a écrit :
>> Hi Alban,
>> 'Twas brillig, and Alban Browaeys at 06/01/11 00:32 did gyre and gimble:
>>> From 853a4d96bf2624ef30f86cf4819382949d039c87 Mon Sep 17 00:00:00 2001
>>> From: Alban Browaeys <prahal at yahoo.com>
>>> Date: Wed, 5 Jan 2011 17:13:04 +0100
>>> Subject: [PATCH] Implement Fortemedia SMA processing.
>>> Those small array microphones returns two channels of opposite
>>> phase thus the default remap in pulseaudio doing the sum output
>> Many thanks for this patch, it's very interesting, especially as I've
>> been helping a couple folk with mics that appear to be 180 deg OOP
>> recently (although this could be an unrelated issue, see:
>> https://qa.mandriva.com/show_bug.cgi?id=55930 and
>> http://blog.moncef-mechri.com/?p=124 to see if you think this is a
>> similar issue)
> Most likely yes . Acer uses fortemedia in quite many of its models (I
> have an acer ferrari one 200).
>> Can you explain how to use the module and what users need to do to make
>> it work?
> Currently one have to explicitely add:
> load-module module-fmaudiosma
> to /etc/pulse/default.pa
> restart pulse. (or one could use pacmd to load the module).
> Then I uses gnome-control-center 3 sound panel and in input tab select
> "FMAudio SMA Source <name of input stereo>"
> Same could be achieved via pavucontrol.
> That s it. I hope it could be improved. Ie for example the choice does
> not remains through sessions. That is the most annoying issue at this
> stage. Any requests (and clues as to how to implement them) welcomed !
I think in that case we need to find a way to enable this automatically,
rather than add this module which requires manual activation.
Personally I'd prefer to make it work at the ALSA level so that all
higher level things (PA included), but if that is not possible (which I
doubt) then I'd say we need to have some way to detect this and
compensate for it automatically.
Perhaps by some udev tags or such like which is then read and processed
within the mixer profile logic? Open to suggestions here.
FWIW, I'm still not 100% sure if this is caused by the use of front:0
and whether it would be avoided by using hw:0 (I'd be surprised if a
wider problem in pure-alsa was still completely unresolved, but not that
Anyway, suggestions for fully automating this solution would be appreciated.
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss