Re: [pulseaudio-discuss] [PATCH] module-jack-sink/source: Set fixed latency correctly on creation
On 03/25/2012 12:59 PM, Maarten Lankhorst wrote:
250 ms default fixed latency won't work well for some applications like wine.
Thanks for the patch. It seems reasonable to set the sink's latency to
match jack's latency, but jack_port_get_total_latency is deprecated and
therefore causes a compiler warning.
Would it make more sense to use jack_port_get_latency_range and
pa_sink_set_latency_range? Or maybe set the fixed latency to match the
min or max value of jack's latency range?
Signed-off-by: Maarten Lankhorstm.b.lankho...@gmail.com
---
diff --git a/src/modules/jack/module-jack-sink.c
b/src/modules/jack/module-jack-sink.c
index ba4ea95..4270b15 100644
--- a/src/modules/jack/module-jack-sink.c
+++ b/src/modules/jack/module-jack-sink.c
@@ -296,6 +296,8 @@ int pa__init(pa_module*m) {
unsigned i;
const char **ports = NULL, **p;
pa_sink_new_data data;
+jack_nframes_t l;
+size_t n;
pa_assert(m);
@@ -443,6 +445,9 @@ int pa__init(pa_module*m) {
}
}
+l = jack_port_get_total_latency(u-client, u-port[0]);
+n = l * pa_frame_size(u-sink-sample_spec);
+pa_sink_set_fixed_latency(u-sink,
pa_bytes_to_usec(n,u-sink-sample_spec));
pa_sink_put(u-sink);
if (ports)
diff --git a/src/modules/jack/module-jack-source.c
b/src/modules/jack/module-jack-source.c
index 13109f3..a1ec9f6 100644
--- a/src/modules/jack/module-jack-source.c
+++ b/src/modules/jack/module-jack-source.c
@@ -249,6 +249,8 @@ int pa__init(pa_module*m) {
unsigned i;
const char **ports = NULL, **p;
pa_source_new_data data;
+jack_nframes_t l;
+size_t n;
pa_assert(m);
@@ -388,6 +390,9 @@ int pa__init(pa_module*m) {
}
+l = jack_port_get_total_latency(u-client, u-port[0]);
+n = l * pa_frame_size(u-source-sample_spec);
+pa_source_set_fixed_latency(u-source,
pa_bytes_to_usec(n,u-source-sample_spec));
pa_source_put(u-source);
if (ports)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Trying to update translations
On 03/23/2012 05:02 PM, Rémi Denis-Courmont wrote: ...and this brokenness is the rule, not the exception. (And in the example above one can wonder why a translation was made in the first place.) In some cases these do not even fit their format strings. Btw, I have seen some crashes in pa_log_level_meta lately, I wonder if this is related? Normally, gettext ignores fuzzy translations at run-time. I think they are not even compiled into the binary translation file, though I have not checked. Thanks for the information. Then we are not as bad off as I first feared. However, that means I don't have an explanation as of why PulseAudio sometimes crashes in pa_log_level_meta :-/ -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] module-jack-sink/source: Set fixed latency correctly on creation
Hey David, Op 26-03-12 11:30, David Henningsson schreef: On 03/25/2012 12:59 PM, Maarten Lankhorst wrote: 250 ms default fixed latency won't work well for some applications like wine. Thanks for the patch. It seems reasonable to set the sink's latency to match jack's latency, but jack_port_get_total_latency is deprecated and therefore causes a compiler warning. Would it make more sense to use jack_port_get_latency_range and pa_sink_set_latency_range? Or maybe set the fixed latency to match the min or max value of jack's latency range? Yes I'm adding a call to a deprecated function, but that function is already used if you look at the code. Because PA_SOURCE_MESSAGE_GET_LATENCY and PA_SINK_MESSAGE_GET_LATENCY both use that call, I felt it made the most sense just to use that call directly instead of changing it even more. Latency in general seems to be a bit of a headache with jack though, how should the case where you have multiple ports with differing latency requirements be handled? ~Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] sink: Prevent filter sink cycles
While looking at bug 44397,
https://bugs.freedesktop.org/show_bug.cgi?id=44397
Gnome's volume control somehow wanted to create a filter sink cycle. I'm
attaching a patch to prevent this, which seems to have worked (at least
there is no crash!), but before I push it:
Is there any reason, any use case, where we actually would want a cycle?
I can't think of any, but just wanted another thought in case I missed
anything.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
From c89b41abebddcb1775b75a37739c6d8d6d681b08 Mon Sep 17 00:00:00 2001
From: David Henningsson david.hennings...@canonical.com
Date: Fri, 23 Mar 2012 13:06:27 +0100
Subject: [PATCH] sink: Prevent filter sink cycles
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=44397
Signed-off-by: David Henningsson david.hennings...@canonical.com
---
src/pulsecore/sink-input.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/pulsecore/sink-input.c b/src/pulsecore/sink-input.c
index b8412bd..a8aeda6 100644
--- a/src/pulsecore/sink-input.c
+++ b/src/pulsecore/sink-input.c
@@ -1383,6 +1383,15 @@ pa_bool_t pa_sink_input_may_move(pa_sink_input *i) {
return TRUE;
}
+static pa_bool_t find_filter_sink_input(pa_sink_input *target, pa_sink *s) {
+while (s s-input_to_master) {
+if (s-input_to_master == target)
+return TRUE;
+s = s-input_to_master-origin_sink;
+}
+return FALSE;
+}
+
/* Called from main context */
pa_bool_t pa_sink_input_may_move_to(pa_sink_input *i, pa_sink *dest) {
pa_sink_input_assert_ref(i);
@@ -1396,6 +1405,12 @@ pa_bool_t pa_sink_input_may_move_to(pa_sink_input *i, pa_sink *dest) {
if (!pa_sink_input_may_move(i))
return FALSE;
+/* Make sure we're not creating a filter sink cycle */
+if (find_filter_sink_input(i, dest)) {
+pa_log_debug(Can't connect input to %s, as that would create a cycle., dest-name);
+return FALSE;
+}
+
if (pa_idxset_size(dest-inputs) = PA_MAX_INPUTS_PER_SINK) {
pa_log_warn(Failed to move sink input: too many inputs per sink.);
return FALSE;
--
1.7.9.1
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] module-jack-sink/source: Set fixed latency correctly on creation
On 03/26/2012 11:54 AM, Maarten Lankhorst wrote: Hey David, Op 26-03-12 11:30, David Henningsson schreef: On 03/25/2012 12:59 PM, Maarten Lankhorst wrote: 250 ms default fixed latency won't work well for some applications like wine. Thanks for the patch. It seems reasonable to set the sink's latency to match jack's latency, but jack_port_get_total_latency is deprecated and therefore causes a compiler warning. Would it make more sense to use jack_port_get_latency_range and pa_sink_set_latency_range? Or maybe set the fixed latency to match the min or max value of jack's latency range? Yes I'm adding a call to a deprecated function, but that function is already used if you look at the code. Because PA_SOURCE_MESSAGE_GET_LATENCY and PA_SINK_MESSAGE_GET_LATENCY both use that call, I felt it made the most sense just to use that call directly instead of changing it even more. Right, but I want to fix those warnings, rather than adding more of them. (And I believe I'm not the only one who cares about trying to keep the build warning-free when possible.) Would it be possible for you to look deeper into this issue, to figure out if there is a correct way to do the same thing but using a non-deprecated API? Latency in general seems to be a bit of a headache with jack though, how should the case where you have multiple ports with differing latency requirements be handled? Not sure what you mean here. If you refer to JACK's concepts of ports, I guess Jack will take that into account when it returns the latency to us? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa-mixer: Fix element channel masks array size.
Valid channel id range is from 0 to SND_MIXER_SCHN_LAST,
inclusive, so the array size has to be
SND_MIXER_SCHN_LAST + 1.
---
src/modules/alsa/alsa-mixer.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.h b/src/modules/alsa/alsa-mixer.h
index cc2dfc3..ee7221c 100644
--- a/src/modules/alsa/alsa-mixer.h
+++ b/src/modules/alsa/alsa-mixer.h
@@ -145,7 +145,7 @@ struct pa_alsa_element {
long volume_limit; /* -1 for no configured limit */
double min_dB, max_dB;
-pa_channel_position_mask_t masks[SND_MIXER_SCHN_LAST][2];
+pa_channel_position_mask_t masks[SND_MIXER_SCHN_LAST + 1][2];
unsigned n_channels;
pa_channel_position_mask_t merged_mask;
--
1.7.8
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Release planning
So, how can I get a release candidate from Git? What URL should I probe? There is no branch named 2.0 or like. Sorry, I am not familiar with your terminology *happen off* the master branch. On 19.02.12 18:59, Arun Raghavan wrote: Hey folks, In order to make things a bit more regular, we've decided to adopt a periodic release schedule. I've jotted down our World Domin ... err, I mean ... Release Plan on the wiki: http://pulseaudio.org/wiki/ReleasePlanning ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: Fix element channel masks array size.
On 03/26/2012 01:35 PM, Tanu Kaskinen wrote:
Valid channel id range is from 0 to SND_MIXER_SCHN_LAST,
inclusive, so the array size has to be
SND_MIXER_SCHN_LAST + 1.
This looks correct. A quick grep for SND_MIXER_SCHN_LAST shows similar
arrays in alsa-sink and alsa-source, and also, that my subset
elimination goes up to SND_MIXER_SCHN_LAST exclusive. Maybe that should
be changed at the same time?
---
src/modules/alsa/alsa-mixer.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.h b/src/modules/alsa/alsa-mixer.h
index cc2dfc3..ee7221c 100644
--- a/src/modules/alsa/alsa-mixer.h
+++ b/src/modules/alsa/alsa-mixer.h
@@ -145,7 +145,7 @@ struct pa_alsa_element {
long volume_limit; /* -1 for no configured limit */
double min_dB, max_dB;
-pa_channel_position_mask_t masks[SND_MIXER_SCHN_LAST][2];
+pa_channel_position_mask_t masks[SND_MIXER_SCHN_LAST + 1][2];
unsigned n_channels;
pa_channel_position_mask_t merged_mask;
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] dbus: Add an assertion to get rid of a warning from Coverity.
Coverity thinks that sample can be NULL when it's
dereferenced after this line. Adding an assertion doesn't
hurt here (in my opinion), and that should get rid of the
warning.
---
src/modules/dbus/iface-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/modules/dbus/iface-core.c b/src/modules/dbus/iface-core.c
index 58abcb9..97a46a5 100644
--- a/src/modules/dbus/iface-core.c
+++ b/src/modules/dbus/iface-core.c
@@ -1401,7 +1401,7 @@ static void handle_upload_sample(DBusConnection *conn,
DBusMessage *msg, void *u
goto finish;
}
-sample = pa_idxset_get_by_index(c-core-scache, idx);
+pa_assert_se(sample = pa_idxset_get_by_index(c-core-scache, idx));
if (n_volume_entries 0) {
sample-volume.channels = n_channels;
--
1.7.8
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: Fix element channel masks array size.
On Mon, 2012-03-26 at 13:44 +0200, David Henningsson wrote: On 03/26/2012 01:35 PM, Tanu Kaskinen wrote: Valid channel id range is from 0 to SND_MIXER_SCHN_LAST, inclusive, so the array size has to be SND_MIXER_SCHN_LAST + 1. This looks correct. A quick grep for SND_MIXER_SCHN_LAST shows similar arrays in alsa-sink and alsa-source, and also, that my subset elimination goes up to SND_MIXER_SCHN_LAST exclusive. Maybe that should be changed at the same time? Good spot! It seems that those arrays are unused, though, but maybe it still makes sense to remove them in the same commit. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Release planning
On Mon, 2012-03-26 at 14:42 +0300, Roman Beslik wrote: So, how can I get a release candidate from Git? What URL should I probe? We've uploaded one RC already. Details at: http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-March/012986.html There is no branch named 2.0 or like. Sorry, I am not familiar with your terminology *happen off* the master branch. That just means we'll be making a release from the top of the master branch itself once it's ready for release. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Release planning
On Mon, 2012-03-26 at 14:42 +0300, Roman Beslik wrote: So, how can I get a release candidate from Git? What URL should I probe? There is no branch named 2.0 or like. Sorry, I am not familiar with your terminology *happen off* the master branch. The phrase means that there won't be a separate branch for 2.0. When the code is ready, the release will be made from a commit in the master branch. For an official release candidates we use tags. The only RC so far for 2.0 uses tag name v1.99.1. So check that out. If you want to test the release candidate, and getting the code straight from git is ok, I guess testing the latest stuff in the master branch would be slightly more useful than v1.99.1. Today is supposed to be the release day. Is it going to happen? As for the non-fixed release blocker bugs that I've flagged as such myself, [1] has at least a preliminary patch from David (Arun said he'd have a look at it also today), and [2] should be removed from the blocker list (I didn't have the time to finish it after all, and it's not a critical issue). [1] https://bugs.freedesktop.org/show_bug.cgi?id=44397 [2] https://bugs.freedesktop.org/show_bug.cgi?id=45817 -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Release planning
'Twas brillig, and Tanu Kaskinen at 26/03/12 13:32 did gyre and gimble: On Mon, 2012-03-26 at 14:42 +0300, Roman Beslik wrote: So, how can I get a release candidate from Git? What URL should I probe? There is no branch named 2.0 or like. Sorry, I am not familiar with your terminology *happen off* the master branch. The phrase means that there won't be a separate branch for 2.0. When the code is ready, the release will be made from a commit in the master branch. For an official release candidates we use tags. The only RC so far for 2.0 uses tag name v1.99.1. So check that out. If you want to test the release candidate, and getting the code straight from git is ok, I guess testing the latest stuff in the master branch would be slightly more useful than v1.99.1. Today is supposed to be the release day. Is it going to happen? As for the non-fixed release blocker bugs that I've flagged as such myself, [1] has at least a preliminary patch from David (Arun said he'd have a look at it also today), and [2] should be removed from the blocker list (I didn't have the time to finish it after all, and it's not a critical issue). [1] https://bugs.freedesktop.org/show_bug.cgi?id=44397 [2] https://bugs.freedesktop.org/show_bug.cgi?id=45817 I'd propose we do another tarball tomorrow and then release on Friday or Monday if no further issues crop up. 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Missing channels on Terratec 6Fire USB
Hi, I'm trying to install the Terratec 6Fire USB audio device. It's an external audio device with several analog in output channels. The alsa-driver is running and I can play analog stereo music or movies on pulseaudio based players. I can output digital sound (ac3 or dts) on spdif via optical with vlc and mplayer. But I can't output analog multichannel sound from flac files or movies. Although alsamixer can access all 6 analog output channels, pulseaudio does not see then. I'm running Pulseaudio on Fedora 16. Currently I'm slighty lost, as I'm not sure if this is a driver, an alsa or an pulseaudio problem and how to troubleshoot this. Any help would be appreciated. Regards, Robert [root@localhost alsa]# aplay -L default Default sysdefault:CARD=Intel HDA Intel, STAC92xx Analog Default Audio Device front:CARD=Intel,DEV=0 HDA Intel, STAC92xx Analog Front speakers surround40:CARD=Intel,DEV=0 HDA Intel, STAC92xx Analog 4.0 Surround output to Front and Rear speakers surround41:CARD=Intel,DEV=0 HDA Intel, STAC92xx Analog 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=Intel,DEV=0 HDA Intel, STAC92xx Analog 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=Intel,DEV=0 HDA Intel, STAC92xx Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers surround71:CARD=Intel,DEV=0 HDA Intel, STAC92xx Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers sysdefault:CARD=DMX6FireUSB TerraTec DMX6FireUSB, DMX 6Fire USB Analog Default Audio Device [root@localhost alsa]# [root@localhost pulse]# aplay -l Liste der Hardware-Geräte (PLAYBACK) Karte 0: Intel [HDA Intel], Gerät 0: STAC92xx Analog [STAC92xx Analog] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 1: DMX6FireUSB [TerraTec DMX6FireUSB], Gerät 0: 6fire Analog [DMX 6Fire USB Analog] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 Karte 1: DMX6FireUSB [TerraTec DMX6FireUSB], Gerät 1: 6fire Digital Out [DMX 6Fire USB Digital Playback] Sub-Geräte: 1/1 Sub-Gerät #0: subdevice #0 [root@localhost pulse]# ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] GSoC Proposal: Configurable maximum volume for sinks and sources
On Sun, 2012-03-25 at 16:45 +0200, Matěj Laitl wrote:
Hi Tanu and pulseaudio-discuss,
I'd like to participate as a student in GSoC 2012 working on PulseAudio.
Among
suggested ideas I've chosen Configurable maximum volume for sinks and
sources,
below is a very draft of my proposal.
Excellent!
I'd be very grateful for any comments, suggestions, pointed-out omissions and
general questions that may arise. I've also thought about extending the
proposal a bit to add code to deal with stereo microphones where one channel
is inverted (supposedly common problem) -- but I've heard on #pulseadio this
is already being worked on. What do you think?
IIRC, if someone is working on this, it's David Henningsson. My
impression is, though, that there's no implementation work done yet. So,
hopefully David can give a status update. Probably this microphone fix
would be a fine extra project for the summer. Do you have this
microphone problem yourself?
Note, however, that there's another extra job that you'd preferably do
before starting with the volume things (or at least before starting to
extend the client API), which reduces the probability of running out of
stuff to do. One of the project ideas is a configuration system. There
was a discussion between me, Colin and Arun, and we thought that it
would be really good if the volume limit feature could use the
configuration system's client API as the client interface. Since the
configuration system doesn't exist, designing the client API for it
would have to be part of the volume limit project. The API probably can
be quite simple, since all it has to do is to provide means for getting
and setting configuration values and for subscribing to updates. You
wouldn't have to implement the whole configuration infrastructure, only
as much as is needed to make the limit configuration to work. We should
update the idea page to reflect this...
BTW, as you obviously have found #pulseaudio, what's your nick?
Introduction
===
Recent PulseAudio versions gained an ability to amplify signal of inputs and
outputs in software. While this is often needed for low-amplitude signals,
software amplification can cause negative effects such as clipping and should
be
avoided if possible. Sometimes, even without amplification, outputs may be
able
to produce sound that is unacceptably loud. In both situations user should be
able to set volume limit to prevent her ears and/or equipment from discomfort
or even damage. Many portable audio players are able to do this, this project
is about supporting volume limits in PulseAudio.
Project goals
===
What will be implemented in PulseAudio in this project:
* support for enforcing volume limits in [TODO: ALSA-based?] Sources and
Sinks; the limits can be
changed on-the-fly
* support for persisting volume limits across PulseAudio restarts
* user-friendly GUI to configure volume limits by extending KDE's KMix or
PulseAudio's pavucontrol. [TODO: I would love to make both, but it's hard to
estimate how much time it will take]
Implementation
=
[this section is based on my rather incomplete understanding of the code;
please correct me where I'm wrong]
PulseAudio's architecture is based on modules that can provide Sources (audio
inputs), Sinks (audio outputs), networking protocols and more. Sinks are
represented with a C struct pa_source defined in pulsecore/sink.h; Sources
use
analogous structure pa_sink. Modules then implement Sources and Sinks by
setting various callbacks in the structs to their functions and filling
fields
with their data.
[TODO: this project should focus on ALSA, right?] Relevant for this project
is
the module-alsa-card (which shares Sink and Source code with
module-alsa-sink,
module-alsa-source) that implements Sinks Sources atop of the most
prevalent
Linux sound system, ALSA. For the first iteration, the module(s) will be made
to accept volume_limit parameter that will be enforced in
{sink,source}_set_volume_cb() (TODO: this seems to only work for
hardware
volumes?)
It should be possible to set limits for any devices, not only for alsa
devices. There may be need to adapt the backend modules to the changes,
but the focus should be in working with sinks, sources and device
ports[1] in general, not with some specific backend. The set_volume_cb
functions indeed only work with hardware volumes, so they aren't really
the right place to do the limit enforcement.
Volume handling is pretty complex in Pulseaudio, so getting a good
picture of the whole volume system will probably take some time. Here's
one hint: you'll want to apply the limit to reference_volume. That's the
volume that you see in KMix.
I wrote in the wiki that the project would start with making it possible
to configure the limits with module arguments, but actually I don't
think that is a very important feature in the end. You can do that if
you start with
[pulseaudio-discuss] [PATCH v2] module-jack-sink/source: Set fixed latency correctly on creation
Changes since v1:
Use max value of jack_port_get_latency_range to calculate the latency
and squash compiler warnings cased by using jack_port_get_total_latency
Modifying latency only works inside a callback, and for hardware the
latency is generally fixed on jack, so just take the max value.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
diff --git a/src/modules/jack/module-jack-sink.c
b/src/modules/jack/module-jack-sink.c
index ba4ea95..017fbf6 100644
--- a/src/modules/jack/module-jack-sink.c
+++ b/src/modules/jack/module-jack-sink.c
@@ -168,10 +168,12 @@ static int sink_process_msg(pa_msgobject *o, int code,
void *data, int64_t offse
case PA_SINK_MESSAGE_GET_LATENCY: {
jack_nframes_t l, ft, d;
+jack_latency_range_t r;
size_t n;
/* This is the worst-case latency */
-l = jack_port_get_total_latency(u-client, u-port[0]) +
u-frames_in_buffer;
+jack_port_get_latency_range(u-port[0], JackPlaybackLatency, r);
+l = r.max + u-frames_in_buffer;
if (u-saved_frame_time_valid) {
/* Adjust the worst case latency by the time that
@@ -296,6 +298,8 @@ int pa__init(pa_module*m) {
unsigned i;
const char **ports = NULL, **p;
pa_sink_new_data data;
+jack_latency_range_t r;
+size_t n;
pa_assert(m);
@@ -443,6 +447,9 @@ int pa__init(pa_module*m) {
}
}
+jack_port_get_latency_range(u-port[0], JackPlaybackLatency, r);
+n = r.max * pa_frame_size(u-sink-sample_spec);
+pa_sink_set_fixed_latency(u-sink, pa_bytes_to_usec(n,
u-sink-sample_spec));
pa_sink_put(u-sink);
if (ports)
diff --git a/src/modules/jack/module-jack-source.c
b/src/modules/jack/module-jack-source.c
index 13109f3..cf62882 100644
--- a/src/modules/jack/module-jack-source.c
+++ b/src/modules/jack/module-jack-source.c
@@ -124,11 +124,13 @@ static int source_process_msg(pa_msgobject *o, int code,
void *data, int64_t off
return 0;
case PA_SOURCE_MESSAGE_GET_LATENCY: {
+jack_latency_range_t r;
jack_nframes_t l, ft, d;
size_t n;
/* This is the worst-case latency */
-l = jack_port_get_total_latency(u-client, u-port[0]);
+jack_port_get_latency_range(u-port[0], JackCaptureLatency, r);
+l = r.max;
if (u-saved_frame_time_valid) {
/* Adjust the worst case latency by the time that
@@ -249,6 +251,8 @@ int pa__init(pa_module*m) {
unsigned i;
const char **ports = NULL, **p;
pa_source_new_data data;
+jack_latency_range_t r;
+size_t n;
pa_assert(m);
@@ -388,6 +392,9 @@ int pa__init(pa_module*m) {
}
+jack_port_get_latency_range(u-port[0], JackCaptureLatency, r);
+n = r.max * pa_frame_size(u-source-sample_spec);
+pa_source_set_fixed_latency(u-source, pa_bytes_to_usec(n,
u-source-sample_spec));
pa_source_put(u-source);
if (ports)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] My attempt to reduce latency with pacat and tvtime
I use tvtime (an open source TV application) to watch TV on my Fedora 16
system. As some of you may know forwarding audio from the sound card
built into the TV tuner card to the primary sound card is not done by
tvtime. There are various ways of forwarding the audio including SoX,
module-loopback, etc. but I've had the best luck (least latency) using
pacat in a manner similar to what this webpage describes:
http://thelinuxexperiment.com/guinea-pigs/tyler-b/fix-pulseaudio-loopback-delay/
But with a change that I've made to pacat that I'd like to share in case
it's helpful.
The web page above describes using two instances of pacat with a pipe:
pacat -r ... | pacat -p ...
to forward the audio. I've found that this works quite well for a
while, but gradually the latency increases. If for some reason the
pacat processes are temporarily suspended and then resumed (ctrl-Z
followed by bg, for example) the latency increases drastically.
I've found that the increased latency is due to audio queuing up on the
input to the play instance of pacat (the pacat on the right side of the
| shown above). The extra queued up audio never gets consumed because
audio is being produced by the record instance of pacat (the pacat on
the left side of the | shown above) at the same rate it is consumed by
the play instance of pacat. So I experimented with ways of discarding
the queued up audio that did not interfere with the sound quality too
much.
Each time stdin_callback() is called by the play instance of pacat to
get audio from the input pa_stream_writable_size() is called to see how
many bytes the sink can take. This limits the amount of data that can
be read from stdin.
Each read of stdin is either full (precisely the number of bytes
requested is returned) or partial (less than the number of bytes
requested is returned). I've found the if a large number of full reads
occur in a row that it's likely there latency due to extra audio queued
up in the input. When this happens I've modified pacat to read as much
as 64 KiB more than what pa_stream_writable_size() requested, but then
discard the extra data read.
I suspect that there may be a more elegant solution at a different layer
in the code. At the very least the change should be made optional so
that it does not break pacat when playing a file instead of reading from
a pipe:
pacapt -p ... audio.raw
But if there is interest I can add a command line option so that the
change is not always in effect.
--
| Steven Elliott | http://selliott.org | sellio...@austin.rr.com |
--- src/utils/pacat.c.orig 2012-03-24 10:13:10.382540053 -0500
+++ src/utils/pacat.c 2012-03-24 22:51:41.350164538 -0500
@@ -51,6 +51,10 @@
#define CLEAR_LINE \x1B[K
+#define DRAIN_THRESHOLD 100
+
+#define DRAIN_BYTES 65536
+
static enum { RECORD, PLAYBACK } mode = PLAYBACK;
static pa_context *context = NULL;
@@ -501,8 +505,9 @@
/* New data on STDIN **/
static void stdin_callback(pa_mainloop_api*a, pa_io_event *e, int fd, pa_io_event_flags_t f, void *userdata) {
-size_t l, w = 0;
+size_t l, l_extra, w = 0;
ssize_t r;
+static int full_reads; // Consecutive full reads (all bytes read).
pa_assert(a == mainloop_api);
pa_assert(e);
@@ -516,9 +521,10 @@
if (!stream || pa_stream_get_state(stream) != PA_STREAM_READY || !(l = w = pa_stream_writable_size(stream)))
l = 4096;
-buffer = pa_xmalloc(l);
+l_extra = (full_reads DRAIN_THRESHOLD) ? (l + DRAIN_BYTES) : l;
+buffer = pa_xmalloc(l_extra);
-if ((r = read(fd, buffer, l)) = 0) {
+if ((r = read(fd, buffer, l_extra)) = 0) {
if (r == 0) {
if (verbose)
pa_log(_(Got EOF.));
@@ -535,8 +541,27 @@
return;
}
-buffer_length = (uint32_t) r;
-buffer_index = 0;
+if ((size_t) r == l_extra) {
+full_reads++;
+}
+else {
+full_reads = 0;
+}
+
+if ((size_t) r l) {
+// The read exceeds the writeable size. Find the end of the buffer
+// that is aligned on a 4 byte boundary.
+// TODO: Determine the alignment bytes rather than assuming 4.
+buffer_index = (~3) (r - l);
+buffer_length = (size_t) r - buffer_index;
+if (buffer_length l)
+{
+buffer_length = l;
+}
+} else {
+buffer_length = (uint32_t) r;
+buffer_index = 0;
+}
if (w)
do_stream_write(w);
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
