Re: [pulseaudio-discuss] [gentoo-user] PulseAudio 1.0-r1 + Skype ==> Garbled output sound
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'll test it throughly and > >> tomorrow (today, 29/09) I'll give feedback. > >> Can you reproduce the reported error? I won't file the bug just yet. > > > > Nope -- the mic works just fine for me and a bunch of other people, so I > > suspect a problem on that specific machine. > > Having the same problem using Arch Linux x86_64. Running pulseaudio > 1.0 and skype using lib32-libpulse 0.9.23 seems to be fine, while > skype using lib32-libpulse 1.0 garbles the input. > > Bisecting lib32-libpulse has proven difficult, with me arriving at > seemingly random commits. It appears the issue is not consistently > reproducible. > > So far the earliest commit that reproduced the issue for me seems to > be af18bc8038177a4b83171671daaf771ecf353b8e. > > A colleague running Arch Linux i686 claims he has no issues running > pulseaudio 0.99.4, while sometimes encountering the issue using > pulseaudio 1.0. > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > Tested today pulseaudio-1.0-r1 with skype-2.2.0.35-r1 without mic problems. Had to test with echo123, but it worked, anyways. Emerge pavucontrol and check your devices' profiles. Claudio Roberto França Pereira (a.k.a. Spidey) hardMOB - HTForum - @spideybr Engenharia de Computação - UFES 2006/1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] stream-restore: simple fallback volume table
'Twas brillig, and Tanu Kaskinen at 29/09/11 15:44 did gyre and gimble: > On Thu, 2011-04-21 at 14:40 +0300, Tanu Kaskinen wrote: >> On Thu, 2011-04-21 at 14:31 +0300, Tanu Kaskinen wrote: >>> From: Marc-André Lureau >>> >>> Comment from Tanu Kaskinen: I made a few tweaks, so blame >>> me if the patch contains bugs. >> >> The commit message is a bit short... The purpose of this patch is to >> make it possible to configure stream volumes before pulseaudio is run >> for the first time. This is useful, for example, in embedded products >> where the default volumes have to be sensible already in the first boot. > > Ping? Could this patch be merged? Ooops. Seems this one got lost in the mists of time! Will merge it in soon if Arun doesn't beat me to it. 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
Re: [pulseaudio-discuss] [PATCH 2/3] sink: Add some comments about the rewind handling during stream moves.
Warning bikeshed ahead. 2011/9/29 Tanu Kaskinen : > --- > src/pulsecore/sink.c | 58 > ++ > 1 files changed, 58 insertions(+), 0 deletions(-) > > diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c > index a2642b4..53cab32 100644 > --- a/src/pulsecore/sink.c > +++ b/src/pulsecore/sink.c > @@ -2403,6 +2403,46 @@ int pa_sink_process_msg(pa_msgobject *o, int code, > void *userdata, int64_t offse > pa_usec_t usec = 0; > size_t sink_nbytes, total_nbytes; > > + /* The old sink probably has some audio from this > + * stream in its buffer. We want to "take it back" as > + * much as possible and play it to the new sink. We > + * don't know at this point how much the old sink can > + * rewind. We have to pick something, and that > + * something is the full latency of the old sink here. > + * So we rewind the stream buffer by the sink latency > + * amount, which may be more than what we should > + * rewind. This can result in a chunk of audio being > + * played both to the old sink and the new sink. I'd say that these comments can be a bit wider. Coding Style says about 127 chars. That would be a bit much for a comment block IMHO, but it would be good to conserve some vertical space here. Oh, and thanks for addressing http://www.ohloh.net/p/pulseaudio/factoids/10252254 Maarten ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] osx: don't build the once-test binary on OS X
2011/9/29 Daniel Mack :
> From: Daniel Mack
>
> This patch was already added earlier with commit ID 2f86ba4f, but the
> changes got reverted by commit 3adc43b ("win32: Make once-test work").
That would be my fault.
> However, this still doesn't work on OSX as here, pthread is in general
> available, but the barrier APIs aren't.
Isn't there a way to make once-test work without using bariers? It
think that that's what I have done for the win32 case, or am I smoking
something here?
Maarten
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [gentoo-user] PulseAudio 1.0-r1 + Skype ==> Garbled output sound
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'll test it throughly and >> tomorrow (today, 29/09) I'll give feedback. >> Can you reproduce the reported error? I won't file the bug just yet. > > Nope -- the mic works just fine for me and a bunch of other people, so I > suspect a problem on that specific machine. Having the same problem using Arch Linux x86_64. Running pulseaudio 1.0 and skype using lib32-libpulse 0.9.23 seems to be fine, while skype using lib32-libpulse 1.0 garbles the input. Bisecting lib32-libpulse has proven difficult, with me arriving at seemingly random commits. It appears the issue is not consistently reproducible. So far the earliest commit that reproduced the issue for me seems to be af18bc8038177a4b83171671daaf771ecf353b8e. A colleague running Arch Linux i686 claims he has no issues running pulseaudio 0.99.4, while sometimes encountering the issue using pulseaudio 1.0. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 3/3] memblockq: Improve debuggability by storing a name and a sample spec.
These are not used for anything at this point, but this
makes it easy to add ad-hoc debug prints that show the
memblockq name and to convert between bytes and usecs.
---
src/modules/echo-cancel/module-echo-cancel.c |8
src/modules/module-combine-sink.c|3 ++-
src/modules/module-equalizer-sink.c |4 ++--
src/modules/module-ladspa-sink.c |2 +-
src/modules/module-loopback.c|3 ++-
src/modules/module-virtual-sink.c|2 +-
src/modules/module-virtual-source.c |4 ++--
src/modules/rtp/module-rtp-recv.c|3 ++-
src/modules/rtp/module-rtp-send.c|3 ++-
src/pulse/stream.c |3 ++-
src/pulsecore/memblockq.c| 15 +++
src/pulsecore/memblockq.h| 11 +++
src/pulsecore/play-memchunk.c|2 +-
src/pulsecore/protocol-esound.c |6 --
src/pulsecore/protocol-http.c|3 ++-
src/pulsecore/protocol-native.c | 12 ++--
src/pulsecore/protocol-simple.c |6 --
src/pulsecore/sink-input.c | 24
src/pulsecore/sound-file-stream.c|2 +-
src/pulsecore/source-output.c|6 --
src/tests/memblockq-test.c |7 ++-
21 files changed, 86 insertions(+), 43 deletions(-)
diff --git a/src/modules/echo-cancel/module-echo-cancel.c
b/src/modules/echo-cancel/module-echo-cancel.c
index 6c7828f..7e0dcef 100644
--- a/src/modules/echo-cancel/module-echo-cancel.c
+++ b/src/modules/echo-cancel/module-echo-cancel.c
@@ -1608,10 +1608,10 @@ int pa__init(pa_module*m) {
pa_sink_input_get_silence(u->sink_input, &silence);
-u->source_memblockq = pa_memblockq_new(0, MEMBLOCKQ_MAXLENGTH, 0,
-pa_frame_size(&source_ss), 1, 1, 0, &silence);
-u->sink_memblockq = pa_memblockq_new(0, MEMBLOCKQ_MAXLENGTH, 0,
-pa_frame_size(&sink_ss), 1, 1, 0, &silence);
+u->source_memblockq = pa_memblockq_new("module-echo-cancel
source_memblockq", 0, MEMBLOCKQ_MAXLENGTH, 0,
+&source_ss, 1, 1, 0, &silence);
+u->sink_memblockq = pa_memblockq_new("module-echo-cancel sink_memblockq",
0, MEMBLOCKQ_MAXLENGTH, 0,
+&sink_ss, 1, 1, 0, &silence);
pa_memblock_unref(silence.memblock);
diff --git a/src/modules/module-combine-sink.c
b/src/modules/module-combine-sink.c
index 8bdc5b7..dec2279 100644
--- a/src/modules/module-combine-sink.c
+++ b/src/modules/module-combine-sink.c
@@ -897,10 +897,11 @@ static struct output *output_new(struct userdata *u,
pa_sink *sink) {
o->outq = pa_asyncmsgq_new(0);
o->sink = sink;
o->memblockq = pa_memblockq_new(
+"module-combine-sink output memblockq",
0,
MEMBLOCKQ_MAXLENGTH,
MEMBLOCKQ_MAXLENGTH,
-pa_frame_size(&u->sink->sample_spec),
+&u->sink->sample_spec,
1,
0,
0,
diff --git a/src/modules/module-equalizer-sink.c
b/src/modules/module-equalizer-sink.c
index e0587fe..46bd0d7 100644
--- a/src/modules/module-equalizer-sink.c
+++ b/src/modules/module-equalizer-sink.c
@@ -1207,8 +1207,8 @@ int pa__init(pa_module*m) {
}
u->sink->userdata = u;
-u->input_q = pa_memblockq_new(0, MEMBLOCKQ_MAXLENGTH, 0, fs, 1, 1, 0,
&u->sink->silence);
-u->output_q = pa_memblockq_new(0, MEMBLOCKQ_MAXLENGTH, 0, fs, 1, 1, 0,
NULL);
+u->input_q = pa_memblockq_new("module-equalizer-sink input_q", 0,
MEMBLOCKQ_MAXLENGTH, 0, &ss, 1, 1, 0, &u->sink->silence);
+u->output_q = pa_memblockq_new("module-equalizer-sink output_q", 0,
MEMBLOCKQ_MAXLENGTH, 0, &ss, 1, 1, 0, NULL);
u->output_buffer = NULL;
u->output_buffer_length = 0;
u->output_buffer_max_length = 0;
diff --git a/src/modules/module-ladspa-sink.c b/src/modules/module-ladspa-sink.c
index 7d81e0d..be05715 100644
--- a/src/modules/module-ladspa-sink.c
+++ b/src/modules/module-ladspa-sink.c
@@ -529,7 +529,7 @@ int pa__init(pa_module*m) {
u = pa_xnew0(struct userdata, 1);
u->module = m;
m->userdata = u;
-u->memblockq = pa_memblockq_new(0, MEMBLOCKQ_MAXLENGTH, 0,
pa_frame_size(&ss), 1, 1, 0, NULL);
+u->memblockq = pa_memblockq_new("module-ladspa-sink memblockq", 0,
MEMBLOCKQ_MAXLENGTH, 0, &ss, 1, 1, 0, NULL);
u->max_ladspaport_count = 1; /*to avoid division by zero etc. in pa__done
when failing before this value has been set*/
u->channels = 0;
u->input = NULL;
diff --git a/src/modules/module-loopback.c b/src/modules/module-loopback.c
index 627a16f..5291258 100644
--- a/src/modules/module-loopback.c
+++ b/src/modules/module-loopback.c
@@ -806,10 +806,11 @@ int pa__init(pa_module *m) {
pa_sink_input_get_silence(u->sink_input, &silence);
u->memblockq = pa_memblockq_new(
+"module-loopback memblockq",
0,
[pulseaudio-discuss] [PATCH 2/3] sink: Add some comments about the rewind handling during stream moves.
--- src/pulsecore/sink.c | 58 ++ 1 files changed, 58 insertions(+), 0 deletions(-) diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c index a2642b4..53cab32 100644 --- a/src/pulsecore/sink.c +++ b/src/pulsecore/sink.c @@ -2403,6 +2403,46 @@ int pa_sink_process_msg(pa_msgobject *o, int code, void *userdata, int64_t offse pa_usec_t usec = 0; size_t sink_nbytes, total_nbytes; +/* The old sink probably has some audio from this + * stream in its buffer. We want to "take it back" as + * much as possible and play it to the new sink. We + * don't know at this point how much the old sink can + * rewind. We have to pick something, and that + * something is the full latency of the old sink here. + * So we rewind the stream buffer by the sink latency + * amount, which may be more than what we should + * rewind. This can result in a chunk of audio being + * played both to the old sink and the new sink. + * + * FIXME: Fix this code so that we don't have to make + * guesses about how much the sink will actually be + * able to rewind. If someone comes up with a solution + * for this, something to note is that the part of the + * latency that the old sink couldn't rewind should + * ideally be compensated after the stream has moved + * to the new sink by adding silence. The new sink + * most likely can't start playing the moved stream + * immediately, and that gap should be removed from + * the "compensation silence" (at least at the time of + * writing this, the move finish code will actually + * already take care of dropping the new sink's + * unrewindable latency, so taking into account the + * unrewindable latency of the old sink is the only + * problem). + * + * The render_memblockq contents are discarded, + * because when the sink changes, the format of the + * audio stored in the render_memblockq may change + * too, making the stored audio invalid. FIXME: + * However, the read and write indices are moved back + * the same amount, so if they are not the same now, + * they won't be the same after the rewind either. If + * the write index of the render_memblockq is ahead of + * the read index, then the render_memblockq will feed + * the new sink some silence first, which it shouldn't + * do. The write index should be flushed to be the + * same as the read index. */ + /* Get the latency of the sink */ usec = pa_sink_get_latency_within_thread(s); sink_nbytes = pa_usec_to_bytes(usec, &s->sample_spec); @@ -2456,6 +2496,24 @@ int pa_sink_process_msg(pa_msgobject *o, int code, void *userdata, int64_t offse pa_usec_t usec = 0; size_t nbytes; +/* In the ideal case the new sink would start playing + * the stream immediately. That requires the sink to + * be able to rewind all of its latency, which usually + * isn't possible, so there will probably be some gap + * before the moved stream becomes audible. We then + * have two possibilities: 1) start playing the stream + * from where it is now, or 2) drop the unrewindable + * latency of the sink from the stream. With option 1 + * we won't lose any audio but the stream will have a + * pause. With option 2 we may lose some audio but the + * stream time will be somewhat in sync with the wall + * clock. Lennart seems to have chosen option 2 (one + * of the reasons might have been that option 1 is + * actually much harder to implement), so we drop the + * latency of the new sink from the moved stream and + * hope that the sink will undo most of that in the + * rewind. */ + /* Get the latency of the sink */ usec = pa_sink_get_latency_within_thread(s); nbytes = pa_usec_to_bytes(usec, &s->sample_spec); -- 1.7.6 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 1/3] sink: Move updating the requested latency after the rewind request when finishing a stream move.
---
src/pulsecore/sink.c | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
index 05b08aa..a2642b4 100644
--- a/src/pulsecore/sink.c
+++ b/src/pulsecore/sink.c
@@ -2330,6 +2330,18 @@ int pa_sink_process_msg(pa_msgobject *o, int code, void
*userdata, int64_t offse
* slow start, i.e. need some time to buffer client
* samples before beginning streaming. */
+/* FIXME: Actually rewinding should be requested before
+ * updating the sink requested latency, because updating
+ * the requested latency updates also max_rewind of the
+ * sink. Now consider this: a sink has a 10 s buffer and
+ * nobody has requested anything less. Then a new stream
+ * appears while the sink buffer is full. The new stream
+ * requests e.g. 100 ms latency. That request is forwarded
+ * to the sink, so now max_rewind is 100 ms. When a rewind
+ * is requested, the sink will only rewind 100 ms, and the
+ * new stream will have to wait about 10 seconds before it
+ * becomes audible. */
+
/* In flat volume mode we need to update the volume as
* well */
return o->process_msg(o, PA_SINK_MESSAGE_SET_SHARED_VOLUME, NULL,
0, NULL);
@@ -2440,12 +2452,6 @@ int pa_sink_process_msg(pa_msgobject *o, int code, void
*userdata, int64_t offse
if (i->attach)
i->attach(i);
-if (i->thread_info.requested_sink_latency != (pa_usec_t) -1)
-pa_sink_input_set_requested_latency_within_thread(i,
i->thread_info.requested_sink_latency);
-
-pa_sink_input_update_max_rewind(i, s->thread_info.max_rewind);
-pa_sink_input_update_max_request(i, s->thread_info.max_request);
-
if (i->thread_info.state != PA_SINK_INPUT_CORKED) {
pa_usec_t usec = 0;
size_t nbytes;
@@ -2461,6 +2467,17 @@ int pa_sink_process_msg(pa_msgobject *o, int code, void
*userdata, int64_t offse
pa_sink_request_rewind(s, nbytes);
}
+/* Updating the requested sink latency has to be done
+ * after the sink rewind request, not before, because
+ * otherwise the sink may limit the rewind amount
+ * needlessly. */
+
+if (i->thread_info.requested_sink_latency != (pa_usec_t) -1)
+pa_sink_input_set_requested_latency_within_thread(i,
i->thread_info.requested_sink_latency);
+
+pa_sink_input_update_max_rewind(i, s->thread_info.max_rewind);
+pa_sink_input_update_max_request(i, s->thread_info.max_request);
+
return o->process_msg(o, PA_SINK_MESSAGE_SET_SHARED_VOLUME, NULL,
0, NULL);
}
--
1.7.6
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH 0/3] Results from debugging a rewind problem
module-null-sink has a bug (fix to be posted later) that causes it to use 10 second buffer instead of the intended 2 second buffer. That's actually sort of nice, because that made another bug visible. When moving streams away from the null sink, streams sometimes played silence for a while to the new sink. The culprit turned out to be a bug in rewind handling when a stream moving is finished. The first patch fixes that. The second patch just adds some documentation and FIXME notes - a result of thinking through what really should happen when a stream is moved. The third patch adds some assistance for debugging future bugs. The added memblockq information was successfully used in debugging this rewinding bug. Tanu Kaskinen (3): sink: Move updating the requested latency after the rewind request when finishing a stream move. sink: Add some comments about the rewind handling during stream moves. memblockq: Improve debuggability by storing a name and a sample spec. src/modules/echo-cancel/module-echo-cancel.c |8 +- src/modules/module-combine-sink.c|3 +- src/modules/module-equalizer-sink.c |4 +- src/modules/module-ladspa-sink.c |2 +- src/modules/module-loopback.c|3 +- src/modules/module-virtual-sink.c|2 +- src/modules/module-virtual-source.c |4 +- src/modules/rtp/module-rtp-recv.c|3 +- src/modules/rtp/module-rtp-send.c|3 +- src/pulse/stream.c |3 +- src/pulsecore/memblockq.c| 15 +++- src/pulsecore/memblockq.h| 11 ++- src/pulsecore/play-memchunk.c|2 +- src/pulsecore/protocol-esound.c |6 +- src/pulsecore/protocol-http.c|3 +- src/pulsecore/protocol-native.c | 12 +++- src/pulsecore/protocol-simple.c |6 +- src/pulsecore/sink-input.c | 24 +--- src/pulsecore/sink.c | 87 -- src/pulsecore/sound-file-stream.c|2 +- src/pulsecore/source-output.c|6 +- src/tests/memblockq-test.c |7 ++- 22 files changed, 167 insertions(+), 49 deletions(-) -- 1.7.6 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
> I'm confused how it negotiates with underlying alsa device? Does it > need some changes in alsa driver? E.g. I have an HDMI device, and I > would like to pass a dts-wav file directly down to this device. Are > there some commands like 'gst-launch filesrc location=test.wav ! > pulseaudiosink'? Just to be clear, there's no negotiation with the alsa device for now. I've been pushing for a kernel patch that makes the ELD information available to user-space, and I have some code to read it in pulseaudio. We now have to take the ELD information and set the formats automagically. For now as Arun said you have to set the formats by hand in PulseAudio so that they match the capabilities of your receiver. -Pierre ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] stream-restore: simple fallback volume table
On Thu, 2011-04-21 at 14:40 +0300, Tanu Kaskinen wrote: > On Thu, 2011-04-21 at 14:31 +0300, Tanu Kaskinen wrote: > > From: Marc-André Lureau > > > > Comment from Tanu Kaskinen: I made a few tweaks, so blame > > me if the patch contains bugs. > > The commit message is a bit short... The purpose of this patch is to > make it possible to configure stream volumes before pulseaudio is run > for the first time. This is useful, for example, in embedded products > where the default volumes have to be sensible already in the first boot. Ping? Could this patch be merged? -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] osx: don't build the once-test binary on OS X
From: Daniel Mack
This patch was already added earlier with commit ID 2f86ba4f, but the
changes got reverted by commit 3adc43b ("win32: Make once-test work").
However, this still doesn't work on OSX as here, pthread is in general
available, but the barrier APIs aren't.
---
src/Makefile.am |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 7f547cd..fdb2e99 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -244,7 +244,6 @@ TESTS = \
TESTS_norun = \
mcalign-test \
- once-test \
pacat-simple \
parec-simple \
extended-test \
@@ -262,6 +261,11 @@ TESTS += \
usergroup-test
endif
+if !OS_IS_DARWIN
+TESTS_norun += \
+ once-test
+endif
+
if HAVE_SIGXCPU
TESTS_norun += \
cpulimit-test \
--
1.7.2
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, 2011-09-29 at 16:46 +0800, Lu Guanqun wrote: [...] > Sink #0 > State: IDLE > Name: alsa_output.pci-_00_1b.0.hdmi-stereo > Description: Internal Audio Digital Stereo (HDMI) [...] > Formats: > pcm Looks like you didn't set the supports formats on the receiver (instructions are on the Passthrough page on the wiki). You can also do a pactl set-sink-formats 0 "pcm; dts-iec61937" for now. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 29, 2011 at 04:39:39PM +0800, Arun Raghavan wrote: [...] > So you're in a mode that supports digital output (S/PDIF or HDMI) and > the appropriate formats are set on the sink? If yes, then the output of Which format should I set on the sink to make the passthrough work? > pactl list and gst-launch output with --gst-debug=pulse*:3 while playing > would help. Here's the output just now: (using -v only, I'll use debug level 3 to give more info). Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstDcaParse:dcaparse0.GstPad:sink: caps = audio/x-dts, rate=(int)44100, channels=(int)6, depth=(int)14, endianness=(int)1234, framed=(boolean)false /GstPipeline:pipeline0/GstDcaParse:dcaparse0.GstPad:src: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0.GstGhostPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstTypeFindElement:typefind.GstPad:src: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstTypeFindElement:typefind.GstPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstGhostPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstGhostPad:sink.GstProxyPad:proxypad1: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDcaParse:dcaparse1.GstPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDcaParse:dcaparse1.GstPad:src: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDtsDec:dtsdec0.GstPad:sink: caps = audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)512, frame-size=(int)2048 /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstDecodePad:src0: caps = audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT, GST_AUDIO_CHANNEL_POSITION_LFE > /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2/GstDtsDec:dtsdec0.GstPad:src: caps = audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT, GST_AUDIO_CHANNEL_POSITION_LFE > /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstPulseSink:pulseaudiosink-sink.GstPad:sink: caps = audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)6, rate=(int)44100, channel-positions=(GstAudioChannelPosition)< GST_AUDIO_CHANNEL_POSITION_FRONT_CENTER, GST_AUDIO_CHANNEL_POSITION_FRONT_LEFT, GST_AUDIO_CHANNEL_POSITION_FRONT_RIGHT, GST_AUDIO_CHANNEL_POSITION_REAR_LEFT, GST_AUDIO_CHANNEL_POSITION_REAR_RIGHT, GST_AUDIO_CHANNEL_POSITION_LFE > /GstPipeline:pipeline0/GstPulseAudioSink:pulseaudiosink0/GstDecodeBin2:pulseaudiosink-dbin2.GstDecodePad:src0.GstProxyPad:proxypad5: caps = audio/x-raw-flo
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, 2011-09-29 at 16:32 +0800, Lu Guanqun wrote: > Hi Arun, > > On Thu, Sep 29, 2011 at 04:02:48PM +0800, Arun Raghavan wrote: > [...] > > Take a look at http://pulseaudio.org/wiki/Passthrough -- it gives you > > the basic steps to set things up. I'll try to write up something more > > comprehensive soon. > > That's great. FYI. I've installed the git version of gstreamer. > > > > > The DTS-in-wav case is a bit dicey. In most cases, you should be able to > > get the data out of wavparse, pass it to dcaparse and pass that on to > > pulsesink or pulseaudio directly. > > I'm using this command: > gst-launch filesrc location=test.wav ! wavparse ! dcaparse ! > pulseaudiosink > But this will utilize the dtsdec plugin, and the data is not > passthroughed... So you're in a mode that supports digital output (S/PDIF or HDMI) and the appropriate formats are set on the sink? If yes, then the output of pactl list and gst-launch output with --gst-debug=pulse*:3 while playing would help. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
Hi Arun, On Thu, Sep 29, 2011 at 04:02:48PM +0800, Arun Raghavan wrote: [...] > Take a look at http://pulseaudio.org/wiki/Passthrough -- it gives you > the basic steps to set things up. I'll try to write up something more > comprehensive soon. That's great. FYI. I've installed the git version of gstreamer. > > The DTS-in-wav case is a bit dicey. In most cases, you should be able to > get the data out of wavparse, pass it to dcaparse and pass that on to > pulsesink or pulseaudio directly. I'm using this command: gst-launch filesrc location=test.wav ! wavparse ! dcaparse ! pulseaudiosink But this will utilize the dtsdec plugin, and the data is not passthroughed... > > However, it is possible that the file is made such that it is already > padded to the correct size for IEC958 transmission, which is a case we > do not currently handle. The reason being that pulsesink calls a gst > utility library to perform IEC 61937 payloading, which isn't possible in > these sort of files (no space left for the header). We should probably > just pass this on if the frames are the right size, but at the time, I > deferred this decision to later since I wasn't sure what to do. > > Regards, > Arun > -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
Hi Guanqun, On Thu, 2011-09-29 at 15:52 +0800, Lu Guanqun wrote: > On Thu, Sep 08, 2011 at 02:09:33AM +0800, Arun Raghavan wrote: > [...] > > > 3. To be able to use passthrough, do we still need changes on Gstreamer? > > > Therefore people can simply use something like 'gst-launch xxx'. And > > > how's that status? > > > > The base stuff is in git master, and some of it is en route > > (https://bugzilla.gnome.org/show_bug.cgi?id=657179). > > Hi Arun, > > I've seen that the corresponding patch is already committed in > gst-plugins-good repository. > > Reading the comments from the file: > "It transparently takes care of passing compressed format as-is if the > sink supports it, decoding if necessary, and changes to supported > formats at runtime." > > I'm confused how it negotiates with underlying alsa device? Does it > need some changes in alsa driver? E.g. I have an HDMI device, and I > would like to pass a dts-wav file directly down to this device. Are > there some commands like 'gst-launch filesrc location=test.wav ! > pulseaudiosink'? Take a look at http://pulseaudio.org/wiki/Passthrough -- it gives you the basic steps to set things up. I'll try to write up something more comprehensive soon. The DTS-in-wav case is a bit dicey. In most cases, you should be able to get the data out of wavparse, pass it to dcaparse and pass that on to pulsesink or pulseaudio directly. However, it is possible that the file is made such that it is already padded to the correct size for IEC958 transmission, which is a case we do not currently handle. The reason being that pulsesink calls a gst utility library to perform IEC 61937 payloading, which isn't possible in these sort of files (no space left for the header). We should probably just pass this on if the frames are the right size, but at the time, I deferred this decision to later since I wasn't sure what to do. Regards, Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] ask about passthrough support
On Thu, Sep 08, 2011 at 02:09:33AM +0800, Arun Raghavan wrote: [...] > > 3. To be able to use passthrough, do we still need changes on Gstreamer? > > Therefore people can simply use something like 'gst-launch xxx'. And > > how's that status? > > The base stuff is in git master, and some of it is en route > (https://bugzilla.gnome.org/show_bug.cgi?id=657179). Hi Arun, I've seen that the corresponding patch is already committed in gst-plugins-good repository. Reading the comments from the file: "It transparently takes care of passing compressed format as-is if the sink supports it, decoding if necessary, and changes to supported formats at runtime." I'm confused how it negotiates with underlying alsa device? Does it need some changes in alsa driver? E.g. I have an HDMI device, and I would like to pass a dts-wav file directly down to this device. Are there some commands like 'gst-launch filesrc location=test.wav ! pulseaudiosink'? -- guanqun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
