alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Raymond Yau <superquad.vortex2@gmail.com>
To: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Maarten Lankhorst <m.b.lankhorst@gmail.com>,
	Takashi Iwai <tiwai@suse.de>
Subject: Re: [PATCH] Alsa-plugins: Pulse: Fix snd_pcm_avail returning 0 in some cases
Date: Fri, 29 Apr 2011 10:32:10 +0800	[thread overview]
Message-ID: <BANLkTimq_7_YZFEK0BH4xcRMF=KQw9nwtA@mail.gmail.com> (raw)
In-Reply-To: <4DB67BD3.7090706@canonical.com>

On 2011-04-20 12:09, Maarten Lankhorst wrote:
>* Hi David,
*>*
*>* Op 20-04-11 09:33, David Henningsson schreef:
*>>* On 2011-04-19 18:12, Maarten Lankhorst wrote:
*>>>* Hi all,
*>>>*
*>>>* For wine I was investigating a bug with pulseaudio, it seems
*>>>* alsa-plugins' pulse driver ignores underruns.


*If you follow the instruction in
http://colin.guthr.ie/2010/09/compiling-and-running-pulseaudio-from-git/

to run a more advanced client application and define DEBUG_TIMING in
alsa-sink.c

you can test it with

aplay -Dpulse --period-time=10000 any.wav

and

aplay -Dhw:0,0 --period-time=10000 any.wav

The period time "10ms" which work with "hw:0,0", may not work with
"pulse" any more
since PA server is expecting the sound card to run accurately at 5ms
period time**

aplay -Dpulse -v --period-time=10000 any.wav
Playing WAVE 'any.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
  stream       : PLAYBACK

  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22050
  period_size  : 441

  period_time  : 10000
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 441
  period_event : 0
  start_threshold  : 1323
  stop_threshold   : 1323
  silence_threshold: 0
  silence_size : 0

  boundary     : 1387266048



D: alsa-sink.c: Wrote 928 bytes (of possible 928 bytes)
D: alsa-sink.c: avail: 63804
D: alsa-sink.c: 9.82 ms left to play; inc threshold = 0.00 ms; dec
threshold = 100.00 ms

D: alsa-sink.c: Buffer time: 10 ms; Sleep time: 4 ms; Process time: 5 ms
D: alsa-sink.c: avail: 63868
D: alsa-sink.c: 9.46 ms left to play; inc threshold = 0.00 ms; dec
threshold = 100.00 ms
D: alsa-sink.c: Buffer time: 10 ms; Sleep time: 4 ms; Process time: 5 ms

D: alsa-sink.c: avail: 63900
D: alsa-sink.c: 9.27 ms left to play; inc threshold = 0.00 ms; dec
threshold = 100.00 ms
*


when using aplay to play those audio which are not the default sample
rate/ channels of PA server
such as 48000Hz and mono (e.g. /usr/share/sounds/alsa/*.wav"

5ms seem not enough for resampling/enable logging

underrun occur (avail 66552 > buffer size 65536) and PA server abort

D: alsa-sink.c: 9.46 ms left to play; inc threshold = 0.00 ms; dec
threshold = 100.00 ms
D: alsa-sink.c: Buffer time: 10 ms; Sleep time: 4 ms; Process time: 5 ms
D: alsa-sink.c: avail: 64288
D: alsa-sink.c: 7.07 ms left to play; inc threshold = 0.00 ms; dec
threshold = 100.00 ms
D: alsa-sink.c: Wrote 516 bytes (of possible 516 bytes)
D: alsa-sink.c: avail: 66552
Trace/breakpoint trap



*>>*
*>>* Hmm, doesn't wine come with a native pulse driver these days?
*>* Nope, but distros patch in a buggy winepulse driver, wine is working on
*>* rearchitecting its driver model, so that a pulseaudio driver might be
*>* added after that, but the current winepulse driver was a bad
*>* copy/replace job of the wrong sound driver. :)

*winepulse is almost useless if it does not support mixer and midi

> My main point is that the underrun is often obsolete when the message

> reached the application, because more data has already been written,
> therefore reporting it to the app does more harm than good.
> At least until the underrun callback (and PA protocol) supports sending

> the position of underrun, together with the underrun message. If we had
> that position, we could compare that with the current write pointer to
> determine whether the underrun is actually obsolete or not.

Refer to the output in "Running a Client Application"
If seem that underrun is unavoidable , as you should notice that
"paplay -vv" also get "Stream underrun" at the end

it is not granunette that snd_pcm_close() must be called after
snd_pcm_drain() or snd_pcm_drop()

src/paplay -vv /usr/share/sounds/ia_ora-startup.wav
Opening a playback stream with sample specification 's16le 2ch
22050Hz' and channel map 'front-left,front-right'.
Connection established.

Stream successfully created.
Buffer metrics: maxlength=4194304, tlength=176400, prebuf=174640, minreq=1764
Using sample spec 's16le 2ch 22050Hz', channel map 'front-left,front-right'.
Connected to device alsa_output.pci-0000_00_1b.0.analog-stereo (0, not
suspended).

Stream started.
Stream underrun.
Playback stream drained.: 1007045 usec.
Draining connection to server.
*
*

      parent reply	other threads:[~2011-04-29  2:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-21 13:22 [PATCH] Alsa-plugins: Pulse: Fix snd_pcm_avail returning 0 in some cases David Henningsson
2011-04-21 23:25 ` Raymond Yau
2011-04-26  8:01   ` David Henningsson
2011-04-26 14:39     ` Takashi Iwai
2011-05-07  3:18       ` Raymond Yau
2011-04-27  1:00     ` Raymond Yau
2011-04-29  2:32     ` Raymond Yau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTimq_7_YZFEK0BH4xcRMF=KQw9nwtA@mail.gmail.com' \
    --to=superquad.vortex2@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=m.b.lankhorst@gmail.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).