Re: [pulseaudio-discuss] [PATCH] Implement Fortemedia SMA processing.
'Twas brillig, and Alban Browaeys at 14/01/11 20:56 did gyre and gimble: Le jeudi 06 janvier 2011 à 10:30 +, 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 pra...@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 silence. 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 surprised :p). Anyway, suggestions for fully automating this solution would be appreciated. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC] Dynamic reconfiguration of sampling rate
'Twas brillig, and pl bossart at 05/01/11 17:15 did gyre and gimble: Happy New Year, During a set of long-haul flights and long waits in airports, I tried to address one of the recurring concerns listed on this mailing list, namely the somewhat high CPU usage due to resampling. An excellent way to spend such time! In most cases people will listen to music at 44.1kHz. watch movies at 48kHz, or start a voice call at 8 or 16kHz. Running the sinks/sources at a fixed default frequency isn't going to be optimal for all cases. To work-around this limitation, I introduced a new callback for sinks and sources which can be called to reconfigure the sampling rate. It works fine on my laptop. However there are a number of limitations on which I'd like to have comments before moving forward: - first the change is only possible when the sinks/sources are suspended. I made this conscious decision to avoid glitches. PulseAudio runs as a daemon, in most cases the sinks/sources are suspended when the user want to hear something. That seems like a sensible limitation. Avoiding the glitches is obviously got to be top of the list. - I decided to have a per-sink/source implementation, and to make the feature optional. In the case of Bluetooth or other network protocols, tearing down the link and reconfiguring it may be too long. This reconfiguration is nearly immediate for a regular ALSA sink Yeah, doing it server wide makes no sense IMO. The default-sample-rate configure option predates our mixer profile logic and really (IMO) somehow be wrapped up into card profiles or sink/source ports anyway, but I digress. - To avoid quality issues, I limited the sinks to two frequencies, 44.1 or 48kHz. If we allowed for lower sampling rates, it'd be a problem if additional sink-inputs/source-outputs are created at a later stage with a higher sampling rate. This means that for a phone call or voice memo you would still see a resampling, but it should be lighter with integer instead of fractional ratios. While I see the logic behind it, it'll likely not placate all those people who want dynamic rate switching. Perhaps this will need to be extended at some point but perhaps it's a sensible starting off point. I'm thinking more of even larger frequencies rather than lower ones (although the practical usefulness could obviously be debated endlessly) - Some work would be needed to prevent system alerts from reconfiguring the sampling rate, but this is a different policy-related problem. Yeah, this could be easily enough done with some kind of proplist entry implemented in e.g. libcanberra and honoured by PA. - the sinks/sources only get suspended after a 5s timeout. This seems too high for sinks/sources that can be reconfigured quickly. It may make sense to have different values for the timeout, and make them dependent on the configuration latency. Or perhaps the OK to change rate logic could work when the sink is either IDLE || SUSPENDED ? That way the suspend timeout wouldn't really matter. Just a thought. Please review the code, give it a try and let me know if you think this is a useful feature to add. Not had a chance to review/try the code yet, but I think it's a sensible feature to add overall. One thing I think would be very interesting here would be cards that support hardware mixing. With these cards, would it be possible to open a stream for each of the different rates we want to use? Then when we deal with the mixing, we mix all the like-rated inputs together and send those separately to their matched device-stream? That is likely the best use of such hardware and the best implementation of support for multiple rates, but it's possibly not worth thinking about immediately due to the fact that this h/w is likely in a minority. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of various rate adjustment patches
The branch is up at https://github.com/mkbosmans/pulseaudio/compare/master...rate-adjustment ready for merging, as far a I am concerned. I'm still not entirely sure whether the change of https://github.com/mkbosmans/pulseaudio/commit/72b90ea8ac53e23862284991a2ce355de250f585 is correct, but it seems to avoid unnecessary rewinds for me. I've tested module-loopback by playing to a null-sink and looping its monitor to the real alsa sink. This showed good behaviour, but may be the algorithm I used for module-rtp-recv should also be used here. Does anyone has a better suggestion for a setup to test module-loopback? null-sink and alsa have very stable latencies, so its no good test for module-loopback. Maarten 2011/1/15 Maarten Bosmans mkbosm...@gmail.com: 2011/1/15 Colin Guthrie gm...@colin.guthr.ie: Hi, I know people (i.e. Maarten) are discussing and proposing various rate adjustment patches just now. Not quite got a grasp on whether any of them are ready for merging so if/when they are, please just poke me. Col The patches I sent to the list were mainly to illustrate the ideas I was discussing. I am trying to make a coherent set out of them. Things remaining are: - smoothing of the estimated (real) sample rate in module-rtp-recv. I'm tryng to find a balance between very good runtime behaviour and keeping the algorithm not too complicated. - module-loopback. I just need to setup a loopback and start some testing. I would have expected that module-tunnel also needs sample rate adjustments, but it appears it does not. Is that correct? module-echo-cancel also seems to do sample rate adjustments. But it seems that it is not completely implemented yet (there are commented lines), so unless the author of that module explains what de desired behaviour is, I'll just leave that. I'll try to make a patch set and send them to the list for (hopefully) final review. Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
