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
