On 2010-10-13 18:40, o...@iki.fi wrote:
From: Jyri Sarhajyri.sa...@nokia.com
The first patch in the set gives sink implementor a possibility to
synchronize HW and SW volume usage in IO-thread. The remaining patches
implement the synchronization for the alsa-sink and add the necessary
module
Am Mittwoch, den 13.10.2010, 19:40 +0300 schrieb o...@iki.fi:
From: Jyri Sarha jyri.sa...@nokia.com
Signed-off-by: Jyri Sarha jyri.sa...@nokia.com
Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com
It would be great if some native English speakers could take a look at
the following
--- On Thu, 14/10/10, Paul Menzel paulepan...@users.sourceforge.net wrote:
The amount *of* usesc
The number of usecs would be better.
PeterO
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
To use this feature from other frameworks (gstreamer, etc), we will
need a tagged release to #ifdef code related to AC3 passthough for
backwards compatibility. Any idea when that might happen?
(would also be nice to close the gap between git master and meego
versions while we are at
On 2010-10-13 18:40, o...@iki.fi wrote:
From: Jyri Sarhajyri.sa...@nokia.com
...
Thank you for your work! This is the main reason I've been advocating
against enabling flat-volumes by default in Ubuntu, so I'm glad to see
something that addresses the issue.
The basic problem is that we
On 2010-10-13 18:40, o...@iki.fi wrote:
From: Jyri Sarhajyri.sa...@nokia.com
...
...rather than trying to add explicit delays just for the volume sync.
Either that, or some kind of volume ramping. Just curious if you
considered that solution as well?
Ah, only after reading my reply from
On 2010-10-13 18:40, o...@iki.fi wrote:
From: Jyri Sarhajyri.sa...@nokia.com
...
Thank you for your work! This is the main reason I've been advocating
against enabling flat-volumes by default in Ubuntu, so I'm glad to see
something that addresses the issue.
The basic problem is that we
On 2010-10-13 18:40, o...@iki.fi wrote:
From: Jyri Sarhajyri.sa...@nokia.com
...
...rather than trying to add explicit delays just for the volume sync.
Either that, or some kind of volume ramping. Just curious if you
considered that solution as well?
Ah, only after reading my reply from
To use this feature from other frameworks (gstreamer, etc), we will
need a tagged release to #ifdef code related to AC3 passthough for
backwards compatibility. Any idea when that might happen?
(would also be nice to close the gap between git master and meego
versions while we are at
Hi
There's no real way you can extract timing information just by looking
at the data. You either need to parse the frames (what I did for the
BT work) or let the hardware report the number of samples it decoded
and rendered. In both cases, you could find out what the average bit
rate is
'Twas brillig, and Joakim Plate at 14/10/10 13:40 did gyre and gimble:
To use this feature from other frameworks (gstreamer, etc), we will
need a tagged release to #ifdef code related to AC3 passthough for
backwards compatibility. Any idea when that might happen?
(would also be nice to close
'Twas brillig, and PETER ONION at 14/10/10 12:42 did gyre and gimble:
--- On Thu, 14/10/10, Paul Menzel paulepan...@users.sourceforge.net wrote:
The amount *of* usesc
The number of usecs would be better.
I've tweaked the wording in my local application of this patch. I went
for The
Hi,
Review below:
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
+PA_SINK_SYNC_VOLUME = 0x0200U,
+/** The HW volume changes are syncronized with SW volume.
+ * \since X.X.XX */
+
} pa_sink_flags_t;
Can you put 0.9.22 here? If needed I'll do a global
Hi,
Review below:
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index 1108a79..ada5da9 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -1651,8 +1713,15 @@ static
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
From: Jyri Sarha jyri.sa...@nokia.com
Signed-off-by: Jyri Sarha jyri.sa...@nokia.com
Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com
Reviewd-by: Colin Guthrie cguth...@mandriva.org
--
Colin Guthrie
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
From: Jyri Sarha jyri.sa...@nokia.com
Signed-off-by: Jyri Sarha jyri.sa...@nokia.com
Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com
Reviewed-by: Colin Guthrie cguth...@mandriva.org
--
Colin Guthrie
'Twas brillig, and o...@iki.fi at 13/10/10 17:40 did gyre and gimble:
From: Jyri Sarha jyri.sa...@nokia.com
Signed-off-by: Jyri Sarha jyri.sa...@nokia.com
Reviewed-by: Tanu Kaskinen tanu.kaski...@digia.com
Please find attached a revised version of this patch... not sure if this
is the best
There's no real way you can extract timing information just by looking
at the data. You either need to parse the frames (what I did for the
BT work) or let the hardware report the number of samples it decoded
and rendered. In both cases, you could find out what the average bit
rate is and
From: Luke Yelavich luke.yelav...@canonical.com
When building pulseaudio master using gcc 4.5.2 and binutils
2.20.51 plus latest snapshot from 2010-10-14, ld complained about missing
symbols. This patch explicitly links more pulseaudio libraries to satisfy
the linker.
Signed-off-by: Luke
From: Luke Yelavich luke.yelav...@canonical.com
When building pulseaudio stable-queue using gcc 4.5.2 and binutils
2.20.51 plus latest snapshot from 2010-10-14, ld complained about missing
symbols. This patch explicitly links more pulseaudio libraries to satisfy
the linker.
Signed-off-by: Luke
20 matches
Mail list logo
