Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-27 Thread xing wang 
Hi tanuk,

Let me quote piece of your post:
Are there any real problems with this rewinding, like the beginning of
the stream disappearing, or an audible drop-out in the audio? The sink
buffer has to be always rewound when a new stream is created, because
initially the sink buffer contains silence. That silence has to be
overwritten with the stream data, so that there's no unnecessary latency
due to waiting for the silence to be played.

If the buffer_size is bigger enough, such as 2s, at the beginning of
stream starting playback, there's only silence, right? For music
playing, it maybe accetable for user.But for
video playing, this obvious delay makes Video/Audio out of sync.

I am not sure whether catch your point clearly.

--xingchao

2011/5/26 xing wang wangxingchao2...@gmail.com:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 10:42 did gyre and gimble:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?

 Thank you Colin, let me have a try.

 Of course it's probably sensible to just run the whole stable-queue
 branch. That's generally what I do in my distro packages... just apply
 all stable queue patches on top of the official release. A 0.9.23
 release will likely go out soon (if I can nail Lennart down!) based on
 this branch.

 Hi Colin, i think my release had include David's patchset.  I see
 there're three patches about Fast rewind, here's the link:
 http://gstreamer-devel.966125.n4.nabble.com/Fighting-rewinds-pulseaudio-crash-update-td3248107.html.

 The delay issue met based on my release build could not be fixed with
 David's patch.
 But i think it's quite like Ccrma's description in post rewind and
 underrun issues on start of playback.  If change the buffer size to
 smaller value, the delay becomes short. I am not sure whether alsa is
 playing silence data or just didnot start playback.

 Thanks
 --xingchao


 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@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread xing wang 
Hi baeksan,

Accidently I see your post about Pulseaudio rewind issue, that's quite
same with mine.
The background is, with timer-based feature enabled, i use default
2000ms  of tsched_size, when playback begins
there's rewind operation because of application's request latency very
low,so the final buffer size will be a small value after calculation.
then there will be nearly 3 seconds before hear the real sound. Maybe
alsa is playing silence data or didnot start to playback operations.

From your log i see the buffer_size/period_size is not too big, so do
you have try with a big tsched_size value(such as 2 second). if we
have same result, that's maybe Pulseaudio's bug about the rewind operations.

--xingchao




=
From baeksan at ccrma.stanford.edu  Sun May  1 00:38:34 2011
From: baeksan at ccrma.stanford.edu (Baek Chang)
Date: Sat, 30 Apr 2011 15:38:34 -0700
Subject: [pulseaudio-discuss] rewind and underrun issues on start of playback
Message-ID: banlktikq1u6duzzikgfqgs0ofm2mkc5...@mail.gmail.com

Hi,

I'm seeing some issue with underruns/rewinds occurring on the beginning of
every sink input playback.
I see rewind requests on alsa sink of 9600 bytes.  The alsa driver is
configured with the following buffer sizes

I: sink.c: device.buffering.buffer_size = 9600
I: sink.c: device.buffering.fragment_size = 4800

So it seems like one buffer size is always being rewinded on the beginning
of playback.
Is there a way to prevent these rewinds/underruns when starting playback?
 after the stream has started, there is no issue with audio dropouts or
underruns, just on the beginning.

If i log the data that gets sent to alsa, from pulseaudio or in the alsa
driver, i do see the beginning being dropped as well.

please see attached logs using both tshed=0 and tsched=1.

any help with this?
thanks!

I: client.c: Created 0 Native client (UNIX socket client)
D: protocol-native.c: Protocol version: remote 19, local 19
I: protocol-native.c: Got credentials: uid=0 gid=0 success=1
D: protocol-native.c: SHM possible: yes
D: protocol-native.c: Negotiated SHM: no
D: memblockq.c: memblockq requested: maxlength=33554432, tlength=0, base=4,
prebuf=0, minreq=1 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=33554432, tlength=33554432,
base=4, prebuf=0, minreq=4 maxrewind=0
I: sink-input.c: Created input 0 /usr/palm/sounds/notification.wav on
pcm_output with sample spec s16le 2ch 44100Hz and channel map
front-left,front-right
I: sink-input.c: media.format = WAV (Microsoft)
I: sink-input.c: media.name = /usr/palm/sounds/notification.wav
I: sink-input.c: application.name = pacat
I: sink-input.c: native-protocol.peer = UNIX socket client
I: sink-input.c: native-protocol.version = 19
I: sink-input.c: application.process.id = 4474
I: sink-input.c: application.process.user = root
I: sink-input.c: application.process.host = PalmDevice
I: sink-input.c: application.process.binary = pacat
I: sink-input.c: application.language = C
I: sink-input.c: application.process.machine_id = PalmDevice
I: protocol-native.c: Requested tlength=2000.00 ms, minreq=20.00 ms
D: protocol-native.c: Traditional mode enabled, modifying sink usec only for
compat with minreq.
D: memblockq.c: memblockq requested: maxlength=4194304, tlength=352800,
base=4, prebuf=349276, minreq=3528 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=352800,
base=4, prebuf=349276, minreq=3528 maxrewind=0
I: protocol-native.c: Final latency 2054.42 ms = 1960.00 ms + 2*20.00 ms +
54.42 ms
D: protocol-native.c: Requesting rewind due to end of underrun.
D: alsa-sink.c: Requested to rewind 9600 bytes.
D: alsa-sink.c: Limited to 9344 bytes.
D: alsa-sink.c: before: 2336
D: alsa-sink.c: after: 2336
D: alsa-sink.c: Rewound 9344 bytes.
D: sink.c: Processing rewind...
D: sink-input.c: Have to rewind 9344 bytes on render memblockq.
D: source.c: Processing rewind...
D: protocol-native.c: Underrun on '/usr/palm/sounds/notification.wav', 0
bytes in queue.
D: alsa-sink.c: Requested to rewind 9600 bytes.
D: alsa-sink.c: Limited to 9344 bytes.
D: alsa-sink.c: before: 2336
D: alsa-sink.c: after: 2336
D: alsa-sink.c: Rewound 9344 bytes.
D: sink.c: Processing rewind...
D: source.c: Processing rewind...
D: core.c: Hmm, no streams around, trying to vacuum.
I: sink-input.c: Freeing input 0 /usr/palm/sounds/notification.wav
I: client.c: Freed 0 pacat
I: protocol-native.c: Connection died.

-- 
-baeksanchang
-- next part --
An HTML attachment was scrubbed...
URL: 
https://tango.0pointer.de/pipermail/pulseaudio-discuss/attachments/20110430/97c1f9a4/attachment-0001.htm
-- next part --
root at PalmDevice:/media/internal# pulseaudio -
D: core-rtclock.c: Timer slack is set to 50 us.
D: core-util.c: setpriority() worked.
I: core-util.c: Successfully gained nice level -4.
I: main.c: Found user 'pulse' (UID 31) and

Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread xing wang 
2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?

Thank you Colin, let me have a try.

--xingchao

 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@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] rewind and underrun issues on start of playback

2011-05-26 Thread xing wang 
2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 10:42 did gyre and gimble:
 2011/5/26 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 26/05/11 09:09 did gyre and gimble:
 I: main.c: This is PulseAudio 0.9.22

 Just as a very small aside, David did some work on Fighting Rewinds
 recently.

 Just search the stable-queue git log for Fighting rewinds...

 These may already be included in your build, but if not it's perhaps
 worth grabbing those patches?

 Thank you Colin, let me have a try.

 Of course it's probably sensible to just run the whole stable-queue
 branch. That's generally what I do in my distro packages... just apply
 all stable queue patches on top of the official release. A 0.9.23
 release will likely go out soon (if I can nail Lennart down!) based on
 this branch.

Hi Colin, i think my release had include David's patchset.  I see
there're three patches about Fast rewind, here's the link:
http://gstreamer-devel.966125.n4.nabble.com/Fighting-rewinds-pulseaudio-crash-update-td3248107.html.

The delay issue met based on my release build could not be fixed with
David's patch.
But i think it's quite like Ccrma's description in post rewind and
underrun issues on start of playback.  If change the buffer size to
smaller value, the delay becomes short. I am not sure whether alsa is
playing silence data or just didnot start playback.

Thanks
--xingchao


 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@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] ask about the assumption of min volume and max volume got from ALSA

2011-05-25 Thread xing wang 
Hi Colin,

Would you please give some comments about Guanqun's patch?
We're working on Pulseaudio and meet some bugs, i think we will run
faster with community's help.

thanks
--xingchao

2011/5/25 Lu Guanqun guanqun...@intel.com:
 Hi,

 This patch needs a little more love. :)
 No one cared?

 On Wed, May 25, 2011 at 02:17:18PM +0800, Lu Guanqun wrote:
 Hi list,

 I may not have the background on this issue, but from the code, it seems
 the code assumes min_volume and max_volume should be non negative. Is
 this the right assumption we should take? What about some drivers
 exposes that min_volume is -126 and max_volume is 0? Should we fix the
 driver or generalize pulseaudio code to tolerate these issues?

 If we allow min_volume could be less than zero, and how about the below
 patch in your point of view? Could you have a review of the below patch?
 If that's OK, I can send a standalone patch for it.

 From 1f5c8fa0e80d9fe2e3d56133afa8fe9a5dbe6693 Mon Sep 17 00:00:00 2001
 From: Lu Guanqun guanqun...@intel.com
 Date: Wed, 25 May 2011 14:12:52 +0800
 Subject: [PATCH] fix the assumption that volume is always positive

 Add a variable to track whether the actual volume is set or not.
 Suppose this:
       min volume: -126        max volume: 0
 then when user wants to set some constant volume to -10, it would fail.

 Signed-off-by: Lu Guanqun guanqun...@intel.com
 ---
  src/modules/alsa/alsa-mixer.c |    6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

 diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
 index 1bd709a..23651b0 100644
 --- a/src/modules/alsa/alsa-mixer.c
 +++ b/src/modules/alsa/alsa-mixer.c
 @@ -1123,6 +1123,7 @@ static int element_set_constant_volume(pa_alsa_element 
 *e, snd_mixer_t *m) {
      snd_mixer_selem_id_t *sid = NULL;
      int r = 0;
      long volume = -1;
 +    int volume_set = 0;

      pa_assert(m);
      pa_assert(e);
 @@ -1136,6 +1137,7 @@ static int element_set_constant_volume(pa_alsa_element 
 *e, snd_mixer_t *m) {
      switch (e-volume_use) {
          case PA_ALSA_VOLUME_OFF:
              volume = e-min_volume;
 +            volume_set = 1;
              break;

          case PA_ALSA_VOLUME_ZERO:
 @@ -1143,18 +1145,20 @@ static int 
 element_set_constant_volume(pa_alsa_element *e, snd_mixer_t *m) {
                  long dB = 0;

                  volume = decibel_fix_get_step(e-db_fix, dB, +1);
 +                volume_set = 1;
              }
              break;

          case PA_ALSA_VOLUME_CONSTANT:
              volume = e-constant_volume;
 +            volume_set = 1;
              break;

          default:
              pa_assert_not_reached();
      }

 -    if (volume = 0) {
 +    if (volume_set) {
          if (e-direction == PA_ALSA_DIRECTION_OUTPUT)
              r = snd_mixer_selem_set_playback_volume_all(me, volume);
          else
 --
 1.7.2.3

 --
 guanqun
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

 --
 guanqun
 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] several seconds delay while playing video with timer-based audio scheduling enabled

2011-05-06 Thread xing wang 
2011/5/5 Arun Raghavan arun.ragha...@collabora.co.uk:
 On Thu, 2011-05-05 at 23:37 -0400, xing wang wrote:
 2011/5/5 xing wang wangxingchao2...@gmail.com:
  2011/5/5 Colin Guthrie gm...@colin.guthr.ie:
  'Twas brillig, and xing wang at 05/05/11 10:24 did gyre and gimble:
  Hi community,
 
  I met a weird issue when playing video on Meego Platform.
  if turn on timer-based audio scheduling, there's nearly seconds voice
  delay during playing video.
  The abnormal phenomenon disappeared after turn it off.
 
  I use 2.6.37 kernel and 0.9.22 pulseaudio version. As suggestions
  (http://0pointer.de/blog/projects/pulse-glitch-free.html)
  the pulseaudio's glitch-free works on newest Alsa/Kernel/Pulseaudio,
  newest everything.
 
  After some google search, there's no obvious finding about similar
  issues. Meanwhile i guess the official release of glitch-free
  must be verified about tsched feature, so it's not a bug but a usage
  mistake,such as some config file wrong for my platform.
 
  So if anyone had meet same issue or could you provide some
  suggestions, that would be appreciated much.
 
  What video player is being used? It is perhaps making some really dumb
  assumptions about things and thus breaking (and using too much power too!)
 
  It's Meego default player meego-qml-launcher.

 Maybe wrong here. Qml-launcher is only one app launcher, the exact app name 
 is
 meego-app-video, it's one QML based application.

 What hardware are you trying this on, btw?

For Intel Moorestown Platform.

 -- Arun

 ___
 pulseaudio-discuss mailing list
 pulseaudio-discuss@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

[pulseaudio-discuss] several seconds delay while playing video with timer-based audio scheduling enabled

2011-05-05 Thread xing wang 
Hi community,

I met a weird issue when playing video on Meego Platform.
if turn on timer-based audio scheduling, there's nearly seconds voice
delay during playing video.
The abnormal phenomenon disappeared after turn it off.

I use 2.6.37 kernel and 0.9.22 pulseaudio version. As suggestions
(http://0pointer.de/blog/projects/pulse-glitch-free.html)
the pulseaudio's glitch-free works on newest Alsa/Kernel/Pulseaudio,
newest everything.

After some google search, there's no obvious finding about similar
issues. Meanwhile i guess the official release of glitch-free
must be verified about tsched feature, so it's not a bug but a usage
mistake,such as some config file wrong for my platform.

So if anyone had meet same issue or could you provide some
suggestions, that would be appreciated much.

--thanks
xingchao
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] several seconds delay while playing video with timer-based audio scheduling enabled

2011-05-05 Thread xing wang 
2011/5/5 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 05/05/11 10:24 did gyre and gimble:
 Hi community,

 I met a weird issue when playing video on Meego Platform.
 if turn on timer-based audio scheduling, there's nearly seconds voice
 delay during playing video.
 The abnormal phenomenon disappeared after turn it off.

 I use 2.6.37 kernel and 0.9.22 pulseaudio version. As suggestions
 (http://0pointer.de/blog/projects/pulse-glitch-free.html)
 the pulseaudio's glitch-free works on newest Alsa/Kernel/Pulseaudio,
 newest everything.

 After some google search, there's no obvious finding about similar
 issues. Meanwhile i guess the official release of glitch-free
 must be verified about tsched feature, so it's not a bug but a usage
 mistake,such as some config file wrong for my platform.

 So if anyone had meet same issue or could you provide some
 suggestions, that would be appreciated much.

 What video player is being used? It is perhaps making some really dumb
 assumptions about things and thus breaking (and using too much power too!)

It's Meego default player meego-qml-launcher.


 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@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] several seconds delay while playing video with timer-based audio scheduling enabled

2011-05-05 Thread xing wang 
2011/5/5 xing wang wangxingchao2...@gmail.com:
 2011/5/5 Colin Guthrie gm...@colin.guthr.ie:
 'Twas brillig, and xing wang at 05/05/11 10:24 did gyre and gimble:
 Hi community,

 I met a weird issue when playing video on Meego Platform.
 if turn on timer-based audio scheduling, there's nearly seconds voice
 delay during playing video.
 The abnormal phenomenon disappeared after turn it off.

 I use 2.6.37 kernel and 0.9.22 pulseaudio version. As suggestions
 (http://0pointer.de/blog/projects/pulse-glitch-free.html)
 the pulseaudio's glitch-free works on newest Alsa/Kernel/Pulseaudio,
 newest everything.

 After some google search, there's no obvious finding about similar
 issues. Meanwhile i guess the official release of glitch-free
 must be verified about tsched feature, so it's not a bug but a usage
 mistake,such as some config file wrong for my platform.

 So if anyone had meet same issue or could you provide some
 suggestions, that would be appreciated much.

 What video player is being used? It is perhaps making some really dumb
 assumptions about things and thus breaking (and using too much power too!)

 It's Meego default player meego-qml-launcher.

Maybe wrong here. Qml-launcher is only one app launcher, the exact app name is
meego-app-video, it's one QML based application.

--xingchao


 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@mail.0pointer.de
 https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss