[pulseaudio-discuss] [PATCH] fix two warnings in utils/padsp.c

2011-10-18 Thread Lu Guanqun 
  CC libpulsedsp_la-padsp.lo
utils/padsp.c:1524:5: warning: no previous prototype for '__open_2' 
[-Wmissing-prototypes]
utils/padsp.c:2560:5: warning: no previous prototype for '__open64_2' 
[-Wmissing-prototypes]
---
 src/utils/padsp.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/utils/padsp.c b/src/utils/padsp.c
index a8bc8d2..414ebe4 100644
--- a/src/utils/padsp.c
+++ b/src/utils/padsp.c
@@ -64,6 +64,9 @@
 #undef open
 #undef open64
 
+int __open_2(const char *filename, int flags);
+int __open64_2(const char *filename, int flags);
+
 typedef enum {
 FD_INFO_MIXER,
 FD_INFO_STREAM,

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] ask about passthrough support

2011-09-29 Thread Lu Guanqun 
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

Re: [pulseaudio-discuss] ask about passthrough support

2011-09-29 Thread Lu Guanqun 
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-float,

Re: [pulseaudio-discuss] Routing questions of module-switch-on-connect, module-device-manager and device profiles

2011-09-27 Thread Lu Guanqun 
On Wed, Sep 21, 2011 at 02:16:23PM +0800, David Henningsson wrote:
[...]
 In a later version of these patches I have removed this functionality 
 from m-s-on-c and put it into a separate module. I haven't posted that 
 here yet as I didn't think it would be much reason to do so before 1.0 
 is released.

Hi David,

Do you have a separate git tree which tracks your latest developement on
this jack detection stuff? If there's one, that'll be great.

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Reply-to (was: How does pulseaudio find the new default sink/source when current one is unlinked?)

2011-09-21 Thread Lu Guanqun 
On Wed, Sep 21, 2011 at 02:09:01PM +0800, David Henningsson wrote:
 On 09/21/2011 05:21 AM, Lu Guanqun wrote:
  On Tue, Sep 20, 2011 at 08:32:39PM +0800, Colin Guthrie wrote:
  [...]
  See the blog post I pointed to my reply on the other thread.
 
  Hi Col,
 
  This might not be related to this thread, but can I request you to
  change the behaviour of this mailing list a bit? Generally what this
  mailing list does is to reply to the list directly without the replier
  been CC-ed. However, in this way, if they don't check this mailing list
  regularly, they might miss some mails. Is it possible to change it to
  default Cc the person?
 
 Being in the same situation for another list: AFAIK, this is not 
 possible to set globally. You can choose to have the mailinglist or the 
 original sender as being the default to reply to, whereas having the 
 original sender will lead to people mistakenly responding in private. 
 This is IMO worse than people mistakenly not cc:ing in the original poster.
 
 I think it is up to everyone to be disciplined enough to use Reply All 
 instead of Reply in their e-mail reader.

Yes, it's better for everyone to use Reply to All, but there's some
extra effort.

What makes think the behaviour might be changed is when I check the
email header, there's a line below:
Reply-To: General PulseAudio Discussion 
pulseaudio-discuss@lists.freedesktop.org
Thus, the mail client will try to reply to this address first. I'm
asking is it possible to remove this line.
[I'm not familiar with email processing system, so that might be wrong...]

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Reply-to

2011-09-21 Thread Lu Guanqun 
On Wed, Sep 21, 2011 at 03:57:29PM +0800, Colin Guthrie wrote:
[...]
 That and we're also a community. We want people who have received help
 and advice from us in the past to help pass information and tips on to
 others. Myself and a few of the other core folks try very hard to reply
 to people seeking help on the list and I think it's important to
 encourage everyone who follows it to do the same and spread the burden.

You and other guys are doing a pretty good job to make it happen.
Appreciated.

 
 
 So tricking people into following the list has IMO many benefits which
 go beyond simple convenience for the end recipient.

I like your idea of tricking people to read the mailing list. :) I'll
make my polling more frequently.

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Reply-to

2011-09-21 Thread Lu Guanqun 
On Wed, Sep 21, 2011 at 04:41:24PM +0800, Maarten Bosmans wrote:
 Huh? I clicked on reply-all (in gmail) on Guanqun's message and it put
 Colin in the CC. How is that possible?
 
 2011/9/21 Lu Guanqun guanqun...@intel.com:
  So tricking people into following the list has IMO many benefits which
  go beyond simple convenience for the end recipient.
 
  I like your idea of tricking people to read the mailing list. :) I'll
  make my polling more frequently.
 
 It sound like you're not subscribed, but reading the list archives
 regularly. How about just subscribing to the list? If you don't want
 to use your work mail address, use a webmail service.

Hi Maarten,

I've subscribed, but I've filtered this mailing list to one specific
folder, if I'm not CC-ed, the mail will not be in my main inbox, thus I
have to poll this folder to read what's up in the mailing list.

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Muting while changing ports

2011-09-21 Thread Lu Guanqun 
On Thu, Sep 22, 2011 at 08:55:04AM +0800, Lu Guanqun wrote:
 On Wed, Sep 21, 2011 at 10:16:52PM +0800, Tanu Kaskinen wrote:
  On Wed, 2011-09-21 at 17:08 +0300, David Henningsson wrote:
   On 09/21/2011 02:22 PM, Tanu Kaskinen wrote:
Hi,
   
There exists audio hardware that produces annoying noise (snap, crackle,
pop) when changing the alsa mixer settings, unless hw mute is used
during the mixer changes. I'm planning to fix this by using hw mute
during path activation, if the path provides hw mute. If anyone has
objections or other comments, the best time to publish them would be
now :)
   
   Does not sound like anything I would like to enable by default - e g, 
   what if hw mute introduces a click, and changing the volume does not?
  
  If you think that such hardware is likely to exist, then I guess I'll
  have to make this configurable, and disable it by default. The path
  configuration files would get a new option for the [General] section:
  mute-during-activation = yes/no. Does that sound ok to you?
 
 I have the same concern with David, but as it's configurable, I'm OK
 with it.

Hi Tanu,

Sorry to send it again, but as a second thought, isn't the annoying
noise a bug of underlying driver? I once met with a poorly written
driver that causes lots of unpleasant noises (though not in mixer
changing operation).

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Does pulseaudo provide API to set the active port of a sink/source?

2011-09-20 Thread Lu Guanqun 
On Tue, Sep 20, 2011 at 03:07:49PM +0800, Lin, Mengdong wrote:
 I want to switch to the loud speaker/mike (hand-free) during a phone call 
 without unplugging my wired headset. And the wired-headset and speaker/mike 
 are two ports of the ALSA sink/source on my platform.
 
 Does PA provide an API that can to set the active port on a sink/source?
 I only found the API to set sink/source pa_context_set_default_sink but no 
 API to set the port.

Check PROTOCOL file gives me back:

~
### v16, implemented by = 0.9.15

new messages:

PA_COMMAND_SET_SINK_PORT
PA_COMMAND_SET_SOURCE_PORT
~

And the corresponding pa_context_set_sink_port_by_index is possibly what
you want.

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] How does pulseaudio find the new default sink/source when current one is unlinked?

2011-09-20 Thread Lu Guanqun 
On Tue, Sep 20, 2011 at 08:32:39PM +0800, Colin Guthrie wrote:
[...]
 See the blog post I pointed to my reply on the other thread.

Hi Col,

This might not be related to this thread, but can I request you to
change the behaviour of this mailing list a bit? Generally what this
mailing list does is to reply to the list directly without the replier
been CC-ed. However, in this way, if they don't check this mailing list
regularly, they might miss some mails. Is it possible to change it to
default Cc the person?

-- 
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

2011-09-08 Thread Lu Guanqun 
On Thu, Sep 08, 2011 at 02:19:41AM +0800, Arun Raghavan wrote:
 On Wed, 2011-09-07 at 11:09 -0700, Arun Raghavan wrote:
  On Wed, 2011-09-07 at 14:20 +0800, Lu Guanqun wrote:
   Hi Arun,
   
   I have several things unclear about passthrough support:
  
  I'm talking about this work at Linux Plumbers' Conference on Friday. If
  videos are available, I'll link to them -- hopefully that should make
  the motivation clear.
 
 Oh, phew, no video -- I'm still happy to answer any questions you
 have. :)

Thanks Arun for your info. At least there'll be slides published?

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 1/2] module-switch-on-connect: Don't switch to a monitoring source

2011-08-24 Thread Lu Guanqun 
Hi David,

On Wed, Aug 24, 2011 at 08:01:00PM +0800, David Henningsson wrote:
 Buglink: http://bugs.launchpad.net/bugs/831675

Opening the above link gives me back nothing...

~
Lost something?

There’s no page with this address in Launchpad.

Check that you entered the address correctly, or search for it: 
~

 Signed-off-by: David Henningsson david.hennings...@canonical.com
 ---
  src/modules/module-switch-on-connect.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/src/modules/module-switch-on-connect.c 
 b/src/modules/module-switch-on-connect.c
 index b121fd9..b1570b1 100644
 --- a/src/modules/module-switch-on-connect.c
 +++ b/src/modules/module-switch-on-connect.c
 @@ -29,6 +29,7 @@
  #include pulsecore/core.h
  #include pulsecore/sink-input.h
  #include pulsecore/source-output.h
 +#include pulsecore/source.h
  #include pulsecore/modargs.h
  #include pulsecore/log.h
  #include pulsecore/namereg.h
 @@ -113,6 +114,10 @@ static pa_hook_result_t source_put_hook_callback(pa_core 
 *c, pa_source *source,
  if (c-state != PA_CORE_RUNNING)
  return PA_HOOK_OK;
  
 +/* Don't switch to a monitoring source */
 +if (source-monitor_of)
 +return PA_HOOK_OK;
 +
  /* Don't switch to any internal devices */
  if ((s = pa_proplist_gets(source-proplist, PA_PROP_DEVICE_BUS))) {
  if (pa_streq(s, pci))
 -- 
 1.7.5.4
 
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH] pacat: make pacat respond to cork/uncork events

2011-08-23 Thread Lu Guanqun 
Pacat remembers the number of cork requests, and then cork/uncork the stream
accordingly.

With this change, it makes below test script work correctly:

pacat -p --property=media.role=music long-sound 
sleep 2
pacat -p --property=media.role=phone short-sound
wait

Signed-off-by: Lu Guanqun guanqun...@intel.com
---
 src/utils/pacat.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/src/utils/pacat.c b/src/utils/pacat.c
index f687402..2568db5 100644
--- a/src/utils/pacat.c
+++ b/src/utils/pacat.c
@@ -91,6 +91,8 @@ static int32_t latency_msec = 0, process_time_msec = 0;
 static pa_bool_t raw = TRUE;
 static int file_format = -1;
 
+static int cork_requests = 0;
+
 /* A shortcut for terminating the application */
 static void quit(int ret) {
 pa_assert(mainloop_api);
@@ -408,6 +410,15 @@ static void stream_event_callback(pa_stream *s, const char 
*name, pa_proplist *p
 
 t = pa_proplist_to_string_sep(pl, , );
 pa_log(Got event '%s', properties '%s', name, t);
+
+if (pa_streq(name, PA_STREAM_EVENT_REQUEST_CORK)) {
+cork_requests++;
+pa_operation_unref(pa_stream_cork(s, !!cork_requests, NULL, NULL));
+} else if (pa_streq(name, PA_STREAM_EVENT_REQUEST_UNCORK)) {
+cork_requests--;
+pa_operation_unref(pa_stream_cork(s, !!cork_requests, NULL, NULL));
+}
+
 pa_xfree(t);
 }
 

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] pacat: make pacat respond to cork/uncork events

2011-08-23 Thread Lu Guanqun 
Hi Col,

On Tue, Aug 23, 2011 at 04:22:48PM +0800, Colin Guthrie wrote:
 'Twas brillig, and Lu Guanqun at 23/08/11 07:18 did gyre and gimble:
  Pacat remembers the number of cork requests, and then cork/uncork the stream
  accordingly.
  
  With this change, it makes below test script work correctly:
  
  pacat -p --property=media.role=music long-sound 
  sleep 2
  pacat -p --property=media.role=phone short-sound
  wait
 
 
 
 Interesting, this is likely good as a test bed/example.

Thanks. I was trying module-cork-music-on-phone and came up with this
little script. :)

 
 That said, I'm not sure we should be sending the operations every time.
 
 Perhaps we should only send a cork req when the count moves form 0-1
 and an uncork when the count moves from 1-0?

At my first attempt, I'm only doing something like below:

diff --git a/src/utils/pacat.c b/src/utils/pacat.c
index f687402..41817ff 100644
--- a/src/utils/pacat.c
+++ b/src/utils/pacat.c
@@ -408,6 +410,12 @@ static void stream_event_callback(pa_stream *s, const char 
*name, pa_proplist *p
 
 t = pa_proplist_to_string_sep(pl, , );
 pa_log(Got event '%s', properties '%s', name, t);
+
+if (pa_streq(name, PA_STREAM_EVENT_REQUEST_CORK))
+pa_operation_unref(pa_stream_cork(s, 1, NULL, NULL));
+else if (pa_streq(name, PA_STREAM_EVENT_REQUEST_UNCORK))
+pa_operation_unref(pa_stream_cork(s, 0, NULL, NULL));
+
 pa_xfree(t);
 }
 
But I read the mailing list and once someone said it's better for client
to remember how many cork requests it receives and only uncork it when
it reaches zero. That's why I changed to the current style.

Do you think my original code is better for this case?

 
 We may at some point have to change the semantics at the server side to
 deal with the start_corked issue, and thus this is likely more robust in
 those circumstances.

It should. However for 'pacat', it doesn't set START_CORKED flag, so I'm
afraid there's no such problem for 'pacat'.

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH] pacat: make pacat respond to cork/uncork events

2011-08-23 Thread Lu Guanqun 
On Tue, Aug 23, 2011 at 05:00:58PM +0800, Colin Guthrie wrote:
 Yes, the latest code is better but what I was meaning was something like:
 
 diff --git a/src/utils/pacat.c b/src/utils/pacat.c
 index f687402..2568db5 100644
 --- a/src/utils/pacat.c
 +++ b/src/utils/pacat.c
 @@ -91,6 +91,8 @@ static int32_t latency_msec = 0, process_time_msec = 0;
  static pa_bool_t raw = TRUE;
  static int file_format = -1;
 
 +static int cork_requests = 0;
 +
  /* A shortcut for terminating the application */
  static void quit(int ret) {
  pa_assert(mainloop_api);
 @@ -408,6 +410,15 @@ static void stream_event_callback(pa_stream *s,
 const char *name, pa_proplist *p
 
  t = pa_proplist_to_string_sep(pl, , );
  pa_log(Got event '%s', properties '%s', name, t);
 +
 +if (pa_streq(name, PA_STREAM_EVENT_REQUEST_CORK)) {
 +if (!cork_requests)
 +pa_operation_unref(pa_stream_cork(s, 1, NULL, NULL));
 +cork_requests++;
 +} else if (pa_streq(name, PA_STREAM_EVENT_REQUEST_UNCORK)) {
 +cork_requests--;
 +if (!cork_requests)
 +  pa_operation_unref(pa_stream_cork(s, 0, NULL, NULL));
 +}
 +
  pa_xfree(t);
  }
 
 
 
 (not a real patch!)
 
 
 This way the actual operation is only sent at the transition of 0-1 and
 not 1-2 etc. (and the opposite, it will only be sent when doing 1-0
 and not from 2-1).
 
 I think this makes sense, but other opinions are welcomed too.

I see your point of only doing the corking at 0-1 and vice versa.

 
  We may at some point have to change the semantics at the server side to
  deal with the start_corked issue, and thus this is likely more robust in
  those circumstances.

BTW: Which semantics are we trying to change to? I may not have the
context here...

  
  It should. However for 'pacat', it doesn't set START_CORKED flag, so I'm
  afraid there's no such problem for 'pacat'.
 
 Aye, but gstreamer does... so the problem is real and thus any example
 code should probably follow the best practice principles - now we only
 need to decide what best practice really is :p
 
 Col

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] How's the integration of UCM into pulseaudio?

2011-08-21 Thread Lu Guanqun 
I searched the list and found Jorge Eduardo Candelaria is doing the
work. Loop in for more info...

On Fri, Aug 19, 2011 at 02:06:32PM +0800, Lu Guanqun wrote:
 Hi list,
 
 I'm curious what's the status of integration of UCM? Are there any
 plans, roadmap or patches are ready and they haven't got into git
 master?
 
 Any comments are welcomed.
 
 Thanks!
 -- 
 guanqun
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] How's the integration of UCM into pulseaudio?

2011-08-19 Thread Lu Guanqun 
Hi list,

I'm curious what's the status of integration of UCM? Are there any
plans, roadmap or patches are ready and they haven't got into git
master?

Any comments are welcomed.

Thanks!
-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/2] memblock: use built-in function

2011-08-14 Thread Lu Guanqun 
Signed-off-by: Lu Guanqun guanqun...@intel.com
---
 src/pulsecore/memblock.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/pulsecore/memblock.c b/src/pulsecore/memblock.c
index 332fcb7..409c65e 100644
--- a/src/pulsecore/memblock.c
+++ b/src/pulsecore/memblock.c
@@ -229,7 +229,7 @@ static pa_memblock *memblock_new_appended(pa_mempool *p, 
size_t length) {
 /* If -1 is passed as length we choose the size for the caller. */
 
 if (length == (size_t) -1)
-length = p-block_size - PA_ALIGN(sizeof(pa_memblock));
+length = pa_mempool_block_size_max(p);
 
 b = pa_xmalloc(PA_ALIGN(sizeof(pa_memblock)) + length);
 PA_REFCNT_INIT(b);

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Need help to reduce delay with USB, mic using pulseaudio

2011-08-11 Thread Lu Guanqun 
Hi Ashwani,

On Thu, Aug 11, 2011 at 11:02:41PM +0800, Pierre-Louis Bossart wrote:
  I am attaching the pulseaudio usb mic delay log.
  When I am running gst-launch-0.10 ! pulsesrc ! pulsesink on pandaboard
  getting around 2-3 sec. on the fly audio delay.
  
  Please suggest how to resolve this problem.
 
 Use module-loopback and play with the latency parameters.

In case you don't know what the latency parameters are, on the
gst-launch line, you can append these parameters: e.g.

gst-launch-0.10 pulsesrc buffer-time= latency-time= !
pulsesink buffer-time= latency-time=

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] Need help to reduce delay with USB, mic using pulseaudio

2011-08-11 Thread Lu Guanqun 
On Fri, Aug 12, 2011 at 12:07:18AM +0800, Colin Guthrie wrote:
 'Twas brillig, and Lu Guanqun at 11/08/11 17:20 did gyre and gimble:
  Hi Ashwani,
  
  On Thu, Aug 11, 2011 at 11:02:41PM +0800, Pierre-Louis Bossart wrote:
  I am attaching the pulseaudio usb mic delay log.
  When I am running gst-launch-0.10 ! pulsesrc ! pulsesink on pandaboard
  getting around 2-3 sec. on the fly audio delay.
 
  Please suggest how to resolve this problem.
 
  Use module-loopback and play with the latency parameters.
  
  In case you don't know what the latency parameters are, on the
  gst-launch line, you can append these parameters: e.g.
  
  gst-launch-0.10 pulsesrc buffer-time= latency-time= !
  pulsesink buffer-time= latency-time=
  
 
 I suspect Pierre was referring to the latency_usec param on module-loopback.

Waiting Pierre to clarify. ;)

I once played with the buffer time and latency time on gstreamer, it
could reduce the delay to some extent.

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] long delay after paplay -s somehost foo.wav

2011-08-10 Thread Lu Guanqun 
Hi,

On Wed, Aug 10, 2011 at 09:47:47PM +0800, Paul Fox wrote:
 colin wrote:
   'Twas brillig, and Paul Fox at 08/08/11 15:21 did gyre and gimble:
  ...
but this:
paplay -s server one.wav
paplay -s server two.wav
will result in a delay of over 2 seconds between one and two. 
  ...
   
   This is likely related to the drain. In order to be 100% sure that the
   data is no longer needed (as it may be needed by rewind buffers) we have
   to wait.
   
   There are a few bug reports about this kind of thing in e.g. the simple
   protocol, but I'm not sure we can solve it 100% in all cases.
 
 thanks.  i found this: http://www.pulseaudio.org/ticket/866
 
 it certainly sounds like a fix will be a long time coming.  it feels
 to me that there should be a way for a stream to be started with a
 different contract, i.e., i will never rewind this stream.  please
 deliver the data on a best-effort basis.  i don't require
 acknowledgement of the last byte. i.e., exactly the conditions needed
 by most real-world uses of pa_play.
 
   The 2s delay is likely related to the amount of audio that is buffered
   by default.
 
 i've modified the pacat-simple.c example to let me play with the
 pa_buffer_attr passed to pa_simple_new, but can't seem to find a
 combination that avoids the 2s wait.

I did some experiment to set the tsched buffer size down a little bit
and for me the wait time becomes smaller. This makes sense since the
total buffer becomes smaller and the time to wait it to be drained is
smaller.

As this parameter is not exported via module-udev-detect, so you have to
use this hack method instead:

pacmd
 list-modules
[find the module index of your alsa card]
 unload-module the-above-index-you-find
 load-module module-alsa-card device_id=0 name=pci-_00_1b.0
card_name=alsa_card.pci-_00_1b.0 namereg_fail=false tsched=yes
ignore_dB=no sync_volume=yes
card_properties=module-udev-detect.discovered=1
tsched_buffer_size=some-number

[note the parameter here may differ from yours, but you can get it from
list-modules above, see the arguments part]

Change the tsched_buffer_size to some number smaller. How to decide the
number? Before you unload this module, invoke list-sinks and check this
property: device.buffering.buffer_size. You may need to try half the
number again and again to see how it fixes your problem.

The cons of this action is you gets poor power consumption, the wakeup
gets more and if it's too small, more chances of underrun. Be cautious.
It's more like a tuning thing. You can take a try.

 
 removing the call to pa_simple_drain(), however, and (hack alert!)
 substituting usleep(10) seems to do the trick, for me.  i do get
 a click between played files, though, so i'm not done.
 
 paul
 
   
   Col
   
   -- 
   
   Colin Guthrie
   gmane(at)colin.guthr.ie
   http://colin.guthr.ie/
 
 =-
  paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 62.4 degrees)
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 1/2] thread-posix: remove duplicate code for setting thread name

2011-08-10 Thread Lu Guanqun 
According to the principle of DRY (don't repeat yourself), remove the code for
setting thread name in thread-posix.c.

Signed-off-by: Lu Guanqun guanqun...@intel.com
---
 src/pulsecore/thread-posix.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
index 3f4ae5c..81ae98d 100644
--- a/src/pulsecore/thread-posix.c
+++ b/src/pulsecore/thread-posix.c
@@ -65,15 +65,19 @@ static void thread_free_cb(void *p) {
 
 PA_STATIC_TLS_DECLARE(current_thread, thread_free_cb);
 
+static void pa_thread_set_name_raw(const char *name) {
+#ifdef __linux__
+prctl(PR_SET_NAME, name);
+#elif defined(HAVE_PTHREAD_SETNAME_NP)  defined(OS_IS_DARWIN)
+pthread_setname_np(name);
+#endif
+}
+
 static void* internal_thread_func(void *userdata) {
 pa_thread *t = userdata;
 pa_assert(t);
 
-#ifdef __linux__
-prctl(PR_SET_NAME, t-name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP)  defined(OS_IS_DARWIN)
-pthread_setname_np(t-name);
-#endif
+pa_thread_set_name_raw(t-name);
 
 t-id = pthread_self();
 
@@ -175,11 +179,7 @@ void pa_thread_set_name(pa_thread *t, const char *name) {
 pa_xfree(t-name);
 t-name = pa_xstrdup(name);
 
-#ifdef __linux__
-prctl(PR_SET_NAME, name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP)  defined(OS_IS_DARWIN)
-pthread_setname_np(name);
-#endif
+pa_thread_set_name_raw(name);
 }
 
 const char *pa_thread_get_name(pa_thread *t) {

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH 2/2] sample-util: use built-in function

2011-08-10 Thread Lu Guanqun 
use built-in function pa_frame_aligned().

Signed-off-by: Lu Guanqun guanqun...@intel.com
---
 src/pulsecore/sample-util.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/pulsecore/sample-util.c b/src/pulsecore/sample-util.c
index 8a13495..16ec4ad 100644
--- a/src/pulsecore/sample-util.c
+++ b/src/pulsecore/sample-util.c
@@ -734,7 +734,7 @@ void pa_volume_memchunk(
 
 pa_assert(c);
 pa_assert(spec);
-pa_assert(c-length % pa_frame_size(spec) == 0);
+pa_assert(pa_frame_aligned(c-length, spec));
 pa_assert(volume);
 
 if (pa_memblock_is_silence(c-memblock))

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] [PATCH v2] thread-posix: remove duplicate code for setting thread name

2011-08-10 Thread Lu Guanqun 
According to the principle of DRY (don't repeat yourself), remove the code for
setting thread name in thread-posix.c.

Signed-off-by: Lu Guanqun guanqun...@intel.com
---
 src/pulsecore/thread-posix.c |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/pulsecore/thread-posix.c b/src/pulsecore/thread-posix.c
index 3f4ae5c..9a8c51b 100644
--- a/src/pulsecore/thread-posix.c
+++ b/src/pulsecore/thread-posix.c
@@ -65,15 +65,19 @@ static void thread_free_cb(void *p) {
 
 PA_STATIC_TLS_DECLARE(current_thread, thread_free_cb);
 
+static void set_thread_name(const char *name) {
+#ifdef __linux__
+prctl(PR_SET_NAME, name);
+#elif defined(HAVE_PTHREAD_SETNAME_NP)  defined(OS_IS_DARWIN)
+pthread_setname_np(name);
+#endif
+}
+
 static void* internal_thread_func(void *userdata) {
 pa_thread *t = userdata;
 pa_assert(t);
 
-#ifdef __linux__
-prctl(PR_SET_NAME, t-name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP)  defined(OS_IS_DARWIN)
-pthread_setname_np(t-name);
-#endif
+set_thread_name(t-name);
 
 t-id = pthread_self();
 
@@ -175,11 +179,7 @@ void pa_thread_set_name(pa_thread *t, const char *name) {
 pa_xfree(t-name);
 t-name = pa_xstrdup(name);
 
-#ifdef __linux__
-prctl(PR_SET_NAME, name);
-#elif defined(HAVE_PTHREAD_SETNAME_NP)  defined(OS_IS_DARWIN)
-pthread_setname_np(name);
-#endif
+set_thread_name(name);
 }
 
 const char *pa_thread_get_name(pa_thread *t) {

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 04/25] printout pthread id number in pulseaudio log

2011-08-08 Thread Lu Guanqun 
On Sat, Aug 06, 2011 at 07:10:16PM +0800, Colin Guthrie wrote:
 'Twas brillig, and Pierre-Louis Bossart at 05/08/11 16:24 did gyre and
 gimble:
  there're multiple pthreads in pulseuadio, which makes reading a bit
  confuse.
  this patch can print each pthread's id.
  
  Wouldn't it be easier to understand if the thread name was used? We
  typically rely on thread names to understand what goes on with
  ftrace/pytimechart, I would think this is similar here. I would rather see a
  log with alsa-sink rather than PID 6779, it'd also make log comparison
  and analysis easier.
 
 Yup I agree (in an ideal world we'd name the thread by sink index too...
 (i.e. alsa-sink 0)

Hi Col,

Do you think it's better to invoke pa_thread_new(alsa-sink 0, func, u)
or adding another index after the plain name? (e.g.
pa_thread_new(alsa-sink, index, func, u))

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] [PATCH 04/25] printout pthread id number in pulseaudio log

2011-08-07 Thread Lu Guanqun 
On Fri, Aug 05, 2011 at 10:24:17PM +0800, Pierre-Louis Bossart wrote:
  there're multiple pthreads in pulseuadio, which makes reading a bit
  confuse.
  this patch can print each pthread's id.
 
 Wouldn't it be easier to understand if the thread name was used? We
 typically rely on thread names to understand what goes on with
 ftrace/pytimechart, I would think this is similar here. I would rather see a
 log with alsa-sink rather than PID 6779, it'd also make log comparison
 and analysis easier.
 -Pierre

How about the patch something like below? :) It displays the thread name
instead of thread id.

 
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
From 25659dfbd3fa8a77bd9d015235817595a2fe1ac1 Mon Sep 17 00:00:00 2001
From: Lu Guanqun guanqun...@intel.com
Date: Mon, 8 Aug 2011 10:24:13 +0800
Subject: [PATCH] log: add thread name

This patch displays thread name in the log, that would be more descriptive.
It improves Xingchao (xingchao.w...@intel.com)'s patch which shows thread id.

Signed-off-by: Lu Guanqun guanqun...@intel.com
---
 src/pulsecore/log.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/pulsecore/log.c b/src/pulsecore/log.c
index 1303814..a5a9162 100644
--- a/src/pulsecore/log.c
+++ b/src/pulsecore/log.c
@@ -302,9 +302,9 @@ void pa_log_levelv_meta(
 pa_vsnprintf(text, sizeof(text), format, ap);
 
 if ((_flags  PA_LOG_PRINT_META)  file  line  0  func)
-pa_snprintf(location, sizeof(location), [%s:%i %s()] , file, line, 
func);
+pa_snprintf(location, sizeof(location), [%s][%s:%i %s()] , 
pa_thread_get_name(pa_thread_self()), file, line, func);
 else if ((_flags  (PA_LOG_PRINT_META|PA_LOG_PRINT_FILE))  file)
-pa_snprintf(location, sizeof(location), %s: , 
pa_path_get_filename(file));
+pa_snprintf(location, sizeof(location), [%s]%s: , 
pa_thread_get_name(pa_thread_self()), pa_path_get_filename(file));
 else
 location[0] = 0;
 
-- 
1.7.6

___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] how's fighting rewind going?

2011-06-17 Thread Lu Guanqun 
On Fri, Jun 17, 2011 at 03:43:53PM +0800, David Henningsson wrote:
 On 2011-06-17 09:13, Lu Guanqun wrote:
  Hi David,
 
  On Fri, Jun 17, 2011 at 02:31:41PM +0800, David Henningsson wrote:
  On 2011-06-17 02:21, Lu Guanqun wrote:
  Hi David,
 
  How's your fighting rewind going?
 
  Now, I find there's a rewind flood in my environment, and it's doing a
  rewrite rewind all the times. At the time of rewinding, the write index
  is less than the read index.
 
  Do you have any idea what's going on? I'm only seeing this when I'm
  viewing an 1080p MP4 file.
 
  Thanks!
 
  Hi Lu,
 
  My patches has been optimisations so far, which means that it's reducing
  the amount of rewinds rather than eliminating them. With a slow enough
  computer (for Intel, the Atom comes to mind), or lots of other things to
  do for that computer (such as viewing an 1080p file?), the rewind flood
  thing can still happen.
 
  Oh, man, you totally got me. :) I'm playing 1080p on an Atom based machine.
  I find the rewind flood on this platform. For 480p video, it works quite
  fine.
 
 
  What client are you using to connect to PulseAudio? For gstreamer based
  clients, my gstreamer patch was first applied upstream, then reverted
  for reasons I don't fully understand. Applying it is likely to help
  against rewinds. See bug https://bugzilla.gnome.org/show_bug.cgi?id=641072
 
  Yes, I used gstreamer clients. FYI. The two patches on pulesaudio are
  already applied.  However, no matter when I applied the gstreamer patch,
  the rewind flood still can be seen.
 
  As you said, you're doing optimizations. Is there a way to fully solve
  this issue, or this is just a mission impossible per your understanding?
 
 Nothing is impossible, the impossible just takes slightly longer to fix :-)

Definitely. :)

 
 Lately I've been thinking that we should implement some kind of 
 ratelimit to rewinding as well. Something like; if we've done 10 rewinds 
 during the latest second, block rewinds for the upcoming second. That 
 would give a hickup (likely temporary silence), but not complete 
 brokenness.
 In combination with the existing patches, I believe that would give 
 sufficient protection. I haven't figured out, however, what would be the 
 right numbers for a particular machine.
 
 The best thing you can do for now, however, is to make sure the client 
 sends large packets. I e, rather one packet per second with one second 
 of sample data in it, than a hundred packets with 10 ms of sample data 
 in it.

Thanks for the idea, let me try on this direction.
BTW: is smaller packet the root cause of infinite rewrite rewind? Could
you elaborate the overall process in a little more detail? It makes me
think it's due to the wrong corporation between pulseaudio and gstreamer
client.

 
 
 -- 
 David Henningsson, Canonical Ltd.
 http://launchpad.net/~diwic

-- 
guanqun
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss