On Mon, Apr 05, 2010 at 02:23:50PM -0500, pl bossart wrote:
Ideally we should enforce a stronger smoothing on the time estimation,
there's no reason why such variations should occur. I forced the
smoothing history to 20s, maybe there's a better way to do this.
FWIW a lot of impleementations
On Wed, May 12, 2010 at 08:50:42AM -0500, pl bossart wrote:
This might be almost equivalent to the timer approach in terms of # of
wakeups, however the timer can be reprogrammed on-the-fly whereas
periods can only be changed by closing and reopening the device. You
can also adjust the timer
On Fri, Jul 16, 2010 at 11:41:33AM -0500, pl bossart wrote:
Well right now there are several projects (outside of my own) going on
in this field, but there does seem to be a little bit of disparity with
upstream people.
One project specifically is coming from the ALSA side and will get
On Thu, Jul 22, 2010 at 12:33:01PM +0100, Colin Guthrie wrote:
'Twas brillig, and priyanka sharma at 22/07/10 12:18 did gyre and gimble:
I need some help in understanding the amount of effort required to port
Pulse Audio to Android. Any help in this regard would be of great use to us.
As
On Wed, Aug 25, 2010 at 07:47:18AM +, Kim Therkelsen wrote:
Do you think it would be possible and a good idea to make the DSP as a kernel
module instead?
I want the DSP module to be usable in different linux distributions - also
those that do not use PulseAudio by default.
No, DSP
On Fri, Aug 27, 2010 at 08:49:16AM +, Kim Therkelsen wrote:
[Please fix your MUA to word wrap within paragraphs, it makes your
messages vastly more legible.]
No, DSP in kernel will never be accepted upstream. ALSA supports doing
DSP at the application layer, though PulseAudio bypasses
On Wed, Aug 25, 2010 at 03:49:44PM +0100, Colin Guthrie wrote:
'Twas brillig, and pl bossart at 25/08/10 14:31 did gyre and gimble:
For jack sensing, we'd need a module that traps input events. ALSA
sends an input event when the headphone jack is inserted. This is
what's used in Meego (the
On Tue, Nov 16, 2010 at 09:41:38PM -0800, Baek Chang wrote:
Well say the client/user had a legitimate reason to switch the sampling rate
(for example, low power usage or hw limitations for certain applications
where it has to be a fixed sampling rate). Would it be possible to suspend
all
On Wed, Dec 01, 2010 at 03:09:10PM +, Colin Guthrie wrote:
wouldn't hurt anyway... that said, WTF is the diffrence between a front
and rear mic physically on a laptop? Do they *really* make laptops with
two mics on them for this purpose? (from the names I'd have to expect a
yes answer
is digital (which
is possible) then it is vastly better to do the amplification in the
boost stage as you've discarded data in the ADC with the signal at the
low level it was at.
so perhaps best to leave that until UCM
can just tell us without probing).
After having spoken to Mark Brown at Plumber's, he
On Tue, Jan 18, 2011 at 12:16:33PM +, Colin Guthrie wrote:
'Twas brillig, and Mark Brown at 18/01/11 11:51 did gyre and gimble:
If you play a new message notification over a movie then if the
notification is an MP3 at 44.1kHz and the movie is at 48kHz you need SRC
as well as mixing
On Wed, Jan 19, 2011 at 10:23:44AM -0600, pl bossart wrote:
So I'm not sure we can idle@0s as a general rule, but as I have very
limited test hardware (namely my laptop and couple other machine which
aren't really meant for testing!), I can't really say this with any
degree of confidence.
On Tue, Apr 12, 2011 at 02:14:04PM -0500, pl bossart wrote:
Jack detect does not use the ALSA kernel subsystem but does instead
use the input subsystem for jack status. It makes sense to create a
new module so we can then use jack detect for non ALSA sound devices.
I'm a bit lost here.
On Wed, Apr 27, 2011 at 05:07:44PM +0200, David Henningsson wrote:
Adding Marga and Liam, not cutting text as a result.
On 2011-04-27 16:55, David Henningsson wrote:
So I'll do some testing then grab it at some point (tho' need to spend
some time reviewing Margarita's work before next week
On Wed, Apr 27, 2011 at 08:29:34PM +0200, David Henningsson wrote:
On 2011-04-27 20:06, Mark Brown wrote:
You're not really supposed to use alsaucm directly except for testing
and developing new configurations,
That's reason enough to have a man page and some documentation, if you
ask me
On Wed, Apr 27, 2011 at 08:04:06PM +0100, Liam Girdwood wrote:
On Wed, 2011-04-27 at 20:29 +0200, David Henningsson wrote:
The patches basically provide the ability to :-
1) Store UCM verb and devices configuration in proplists.
2) Allow pulseaudio to change the UCM usecase verb and device.
On Tue, May 03, 2011 at 11:09:56AM -0700, Baek Chang wrote:
I think you are correct in that there is an alsa bug. It seems that
pulseaudio 0.9.14 didn't exhibit this bug in the driver, but pulseaudio
0.9.22 does.
It seems like the rewind is causing the driver to not have data in its first
hw
On Fri, May 13, 2011 at 10:11:55PM +0200, David Henningsson wrote:
We want to maximise quality while avoiding digital distortion, that's
basically the problem in a nutshell. We're assuming (sometimes
incorrectly; but that's our best guess) that this golden spot will be
achieved with
On Thu, May 26, 2011 at 01:07:33PM +0200, David Henningsson wrote:
On 2011-05-19 18:44, Jorge Eduardo Candelaria wrote:
+typedef enum pa_jack_event {
+PA_JACK_HEADPHONES,
+PA_JACK_HEADSET,
I'm a little hesitant to whether we should have one headset or whether
that should be
19 matches
Mail list logo
