On Mon, 2011-10-10 at 22:28 +0300, Rémi Denis-Courmont wrote:
> Le lundi 10 octobre 2011 21:31:30 Pierre-Louis Bossart, vous avez écrit :
> > I don't have time to waste for threads like these.
>
> Oh yeah. Sorry that I spend much of the free time I had in the past few
> months
> fixing our code
In Reply to: Mark Brown
> On Fri, Oct 07, 2011 at 07:21:44PM +0200, Paul Menzel wrote:
>
> > I am not sure. 4 W power consumption of a sound chip sounds quite a lot
> > to me. Additionally as written above please try a newer version.
>
> That's many orders of magnitude more than is sane unless
> If the RT prio stuff is working the way it should, there shouldn't be
> underruns (on the Pulse/ALSA side, not the client side) even if the
> system load is high.
I have never seen any issues when the processing is done inside the
real-time thread (voice integration in Meego).
The issue is that
On 10/10/2011 05:40 PM, Pierre-Louis Bossart wrote:
So the question is whether the logic in Pierre's patch makes sense.
I don't know the answer. Anyway, here's one argument why the current
logic is not good: I believe some applications really are sensitive to
latency - to the point that it's bet
Le lundi 10 octobre 2011 19:57:03 Arun Raghavan, vous avez écrit :
> You could pick the most conservative of your formats and then adjust
> after connecting using pa_stream_set_buffer_attr().
Hmm OK. But what's most conservative here? There is over an order of magnitude
between float32 7.1 at 192
Le lundi 10 octobre 2011 21:31:30 Pierre-Louis Bossart, vous avez écrit :
> I don't have time to waste for threads like these.
Oh yeah. Sorry that I spend much of the free time I had in the past few months
fixing our code (good), adapting to PulseAudio new requirements (not very
good) or working
> Do you even read the emails before you press
> the reply button?
I don't have time to waste for threads like these.
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudi
Le lundi 10 octobre 2011 20:44:58 Pierre-Louis Bossart, vous avez écrit :
> > Yeah? I never said there were formats with variable bit rate. I said I
> > don't
> > know the format, hence the bit rate, until after the buffer attributes
> > have
> > already been transmitted.
>
> If you know the sampl
> Yeah? I never said there were formats with variable bit rate. I said I
> don't
> know the format, hence the bit rate, until after the buffer attributes
> have
> already been transmitted.
If you know the sampling frequency and the number of channels, you know the
bitrate for PCM and all IEC forma
On Mon, 2011-10-10 at 19:24 +0300, Rémi Denis-Courmont wrote:
> Le lundi 10 octobre 2011 18:35:02 Pierre-Louis Bossart, vous avez écrit :
> > > Whether passing multiple format infos to negotiate digital passthrough,
> > > or
> > > setting one of the PA_STREAM_FIX_* flags on a record stream, I'm a b
Le lundi 10 octobre 2011 18:35:02 Pierre-Louis Bossart, vous avez écrit :
> > Whether passing multiple format infos to negotiate digital passthrough,
> > or
> > setting one of the PA_STREAM_FIX_* flags on a record stream, I'm a bit
> > puzzled
> > how the buffering attributes are supposed to work.
> So the question is whether the logic in Pierre's patch makes sense.
>
> I don't know the answer. Anyway, here's one argument why the current
> logic is not good: I believe some applications really are sensitive to
> latency - to the point that it's better to have occasional drop-outs
> than to r
> Whether passing multiple format infos to negotiate digital passthrough,
> or
> setting one of the PA_STREAM_FIX_* flags on a record stream, I'm a bit
> puzzled
> how the buffering attributes are supposed to work.
>
> Most of the values are expressed in bytes. How should the application
> negotia
On Fri, Oct 07, 2011 at 07:21:44PM +0200, Paul Menzel wrote:
> I am not sure. 4 W power consumption of a sound chip sounds quite a lot
> to me. Additionally as written above please try a newer version.
That's many orders of magnitude more than is sane unless there's very
loud sound coming out of
Am 10.10.2011 11:06, schrieb Maarten Bosmans:
2011/10/10 Julius:
Am 09.10.2011 21:49, schrieb Maarten Bosmans:
2011/10/9 Julius:
hi,
i would like to redirect the output from totem to line-in and use line-in
as
input for teamspeak3 to "send" mp3's.
Wow, two more or less the same questions on
On Mon, 2011-10-10 at 12:28 +0200, Maarten Bosmans wrote:
> ---
So as I understand it, this forces a dependency on Python 2.6 or above.
I'm fine with this, but does anyone else have any objections?
-- Arun
___
pulseaudio-discuss mailing list
pulseaudio
---
src/utils/qpaeq | 43 ---
1 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/src/utils/qpaeq b/src/utils/qpaeq
index a8a9fda..951e70f 100755
--- a/src/utils/qpaeq
+++ b/src/utils/qpaeq
@@ -22,12 +22,11 @@ try:
from PyQt4 import QtGui
On Mon, Oct 10, 2011 at 01:01:00PM +0300, Matti J. Aaltonen wrote:
> On 10/07/2011 03:49 PM, ext Mark Brown wrote:
> >What I said was that the entire audio system should be one card.
> I didn't read it that way,but OK... Just one more comment/question:
> I would have thought that to achieve as fi
Package: pulseaudio
Version: 1.0-4
Severity: normal
X-Debbugs-CC: pulseaudio-discuss@lists.freedesktop.org
2011/10/10 Maarten Bosmans :
> 2011/10/9 Paul Menzel :
>> Package: pulseaudio
>> Version: 1.0-4
>> Severity: normal
>> X-Debbugs-CC: pulseaudio-discuss@lists.freedesktop.org
>>
>>
>> Dear Pul
2011/10/10 Julius :
> Am 09.10.2011 21:49, schrieb Maarten Bosmans:
>>
>> 2011/10/9 Julius:
>>>
>>> hi,
>>>
>>> i would like to redirect the output from totem to line-in and use line-in
>>> as
>>> input for teamspeak3 to "send" mp3's.
>>
>> Wow, two more or less the same questions on the same day.
Am 09.10.2011 21:49, schrieb Maarten Bosmans:
2011/10/9 Julius:
hi,
i would like to redirect the output from totem to line-in and use line-in as
input for teamspeak3 to "send" mp3's.
Wow, two more or less the same questions on the same day.
currently ive set ts3 to get the input from "monito
2011/10/9 Paul Menzel :
> Package: pulseaudio
> Version: 1.0-4
> Severity: normal
> X-Debbugs-CC: pulseaudio-discuss@lists.freedesktop.org
>
>
> Dear PulseAudio Debian packagers and upstream PA folks,
>
>
> the Debian init script `/etc/init.d/pulseaudio` [1] currently prints a
> warning when PA is
2011/10/6 Xavier Bestel :
> On Thu, 2011-10-06 at 13:49 +0200, Maarten Bosmans wrote:
>> 2011/10/6 Xavier Bestel :
>> [...] I made a mistake, that wasn't paman I was talking about but another
>> > tool, with a little icon sitting in the systray to quickly select one of
>> > the available zeroconf s
Hi,
[I'm just concerned that Taylor is not on the PA mailing list so we need
to keep them CC'ed. Dylan is registered but CC'ing for completeness :)
This message just quotes Pierre-Louis's mail in full below (which is
certainly worth reading!)
This is my only comment]
'Twas brillig, and Pierre-
On Sun, Oct 9, 2011 at 7:36 PM, Arun Raghavan wrote:
> On Thu, 2011-10-06 at 21:14 -0700, Dylan Reid wrote:
> > > Obviously we're somewhat biased here, but I think it would
> > be prudent of
> > > you to revisit some of the previous results. Pierre has done
> > a l
hi,
i would like to redirect the output from totem to line-in and use
line-in as input for teamspeak3 to "send" mp3's.
currently ive set ts3 to get the input from "monitor of internal
audio..." - this works, but this also means that when persons talk in
the room it gets echoed back.
how do yo
Package: pulseaudio
Version: 1.0-4
Severity: normal
X-Debbugs-CC: pulseaudio-discuss@lists.freedesktop.org
Dear PulseAudio Debian packagers and upstream PA folks,
the Debian init script `/etc/init.d/pulseaudio` [1] currently prints a
warning when PA is configured in non-system mode.
PU
On 29 September 2011 20:09, Spidey / Claudio wrote:
> On Thu, Sep 29, 2011 at 15:57, Jan Steffens wrote:
>>
>> On Thu, Sep 29, 2011 at 8:19 AM, Arun Raghavan
>> wrote:
>> > On Thu, 2011-09-29 at 02:56 -0300, Spidey / Claudio wrote:
>> > [...]
>> >> My bad, hadn't synced yet before that post. I'l
On 10/07/2011 03:33 PM, ext Mark Brown wrote:
On Fri, Oct 07, 2011 at 03:21:33PM +0300, Matti J. Aaltonen wrote:
by the DAC codec. Now to have on output for the analog radio the amplifier
should be handled as a separate audio card, right? And then the
No. When I said this should all be a sing
On 10/07/2011 01:31 PM, ext Mark Brown wrote:
On Fri, Oct 07, 2011 at 10:24:40AM +0300, Matti J. Aaltonen wrote:
But then I don't get why the radio should be able to say when the
[analog] "stream" starts and stops (and what do you actually mean by
that?). Isn't it possible in the above scenario
Hi!
Note that alsa support is not compiled in because the alsa-lib is quite
old (1.0.16).
As I know the version of alsa-lib and the version of alsa in kernel
must match.
I'm trying to avoid using alsa (if it is possible) because of the
previous reasons.
This device is a cash register on buses
Otherwise you get an "invalid argument" error from pa_stream_new later.
---
src/utils/pacat.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/utils/pacat.c b/src/utils/pacat.c
index 3be1f6c..3c8e3c7 100644
--- a/src/utils/pacat.c
+++ b/src/utils/pacat.c
@@ -1103,6
Without this fix, pacat won't start up, because it is unable to set the stream
name.
---
src/pulse/utf8.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/pulse/utf8.c b/src/pulse/utf8.c
index fe7bcd2..773a1f8 100644
--- a/src/pulse/utf8.c
+++ b/src/pulse/utf8.c
These two are the result of helping someone on IRC this weekend getting pulse
to run on an OpenWRT device.
If compiled without iconv support, pacat gives an unclear "invalid argument"
error.
The first patch addresses the local<->utf8 conversion when iconv is not
available. The pa_locale_to_utf8
Hi!
Please check my previous reply.
On Mon, 10 Oct 2011 08:24:35 +0530, Arun Raghavan wrote:
On Sat, 2011-10-08 at 15:52 +0200, krisztian.koc...@optimaster.eu
wrote:
Sorry, here are the attachments.
Original Message
Subject: Re: Bluetooth Headset Problem
Date: Sat, 08 Oct 20
35 matches
Mail list logo
