[pulseaudio-tickets] [Bug 47390] New: module-null-sink keeps low latency when not needed

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47390

             Bug #: 47390
           Summary: module-null-sink keeps low latency when not needed
    Classification: Unclassified
           Product: PulseAudio
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: modules
        AssignedTo: pulseaudio-bugs at lists.freedesktop.org
        ReportedBy: tanuk at iki.fi
         QAContact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net


Copied from
http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-January/012729.html

Sean McNamara writes:

"Hi all,

First, my environment:

* 2nd-gen Nehalem quad core dedicated server
* Debian Testing (x86_64)
* PulseAudio 1.1 (tarball from website)
* OpenVZ container

Relevant PulseAudio settings:
* speex-float-2
* NO physical soundcard; just module-null-sink
* Flat-volumes enabled
* Default latency: 100 ms

Use case: Basically I'm looking for an inexpensive (CPU-wise) software
mixer for two streams on the local box, with as low latency as I can
get without making the CPU usage too high... in other words, a
pareto-optimal setup or as close as I can get.

"Stream A" is Mumble client with playback and capture streams (native
PA protocol over shm). "Stream B" is a gst-launch pipeline with only a
capture stream, using pulsesrc. All capture and playback streams are
taken out against one module-null-sink and its monitor, the default
sink and source respectively.

Defective behavior:

1. Start PulseAudio and observe CPU usage. PA daemon is using 0% CPU
because of module-suspend-on-idle.
2. Start Stream B and observe CPU usage. PA daemon and client are both
using 8% CPU according to top.
3. Start Stream A and observe CPU usage. Stream A client is configured
to request a latency of 10 ms. PA daemon and each client jump to 25%
cpu usage apiece.
4. Kill Stream A process with a SIGTERM, then wait a few seconds and
observe CPU usage. PA daemon and Stream B are still using 25% CPU
apiece.

Expected results:
(1) When Stream A is killed, PA will realize that its
lowest-requested-latency client has disconnected, and it will tell the
remaining client(s) to go back to either the default latency, or the
next highest requested latency in the chain.
(2) On Step 3 of the defective behavior steps, the CPU usage of Stream
B should not increase. It should be possible to have one client
causing a lot of CPU activity due to a low latency request, while
allowing a client that doesn't need low latency to send buffers in
larger, more infrequent chunks for better efficiency.

My understanding is that time-based scheduling is designed to handle
both (1) and (2) of the expected results. I haven't tested this
particular setup with a hardware module-alsa-sink on a local box, but
I have a PA daemon locally with an uptime of several weeks that is
only using 0.5% CPU while playing a Rhythmbox stream, and this daemon
has had clients of all kinds of different latencies (Adobe Flash,
Mumble, etc) connect to it over time.

So my conclusion is that either
(A) time-based scheduling isn't implemented for module-null-sink, or
(B) there is some bug causing this strange behavior.

In case (A), would it be possible, even in principle, to implement it?
In case (B), is this a bug that anyone can look into? Can provide as
much additional info as required.

Maybe there's some other third possibility, but I'm just not expecting
this kind of behavior out of PA. I thought all the tsched work was to
help to juggle latency-intensive streams simultaneously with
high-latency streams without impacting the latter's CPU usage?

Thanks,

Sean"

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.