Re: [pulseaudio-discuss] pulsesrc consumes much more CPU than alsasrc
Oh, I tested that on an Atom platform. Is that the cause? -Bin On Mon, 2010-03-15 at 05:12 -0600, Colin Guthrie wrote: Hi Bin, 'Twas brillig, and Bin Gao at 15/03/10 10:28 did gyre and gimble: (resend as plain text) Nice :) It seems both pulseaudio alsa PCM plugin (source) and gstreamer pulsesrc consume much more CPU resource than alsa when working on the same sample (rate, channel and format). I had a rough look at the source code and found they both use the threaded mainloop model. Can we have any chance to optimize for this? $ gst-launch alsasrc device=hw:0,0 ! queue ! audioconvert ! wavenc ! filesink location=test.wav CPU% = 2~3% Trying here I get between 1 and 2% CPU. $ gst-launch pulsesrc ! queue ! audioconvert ! wavenc ! filesink location=test.wav CPU% = 12~14% Here I get about 4% CPU (one process hovered between 1 and 2%, with a second process hovering between 0 and 1% with a third most at 0 and very occasionally at 1% and a fourth always at 0%) So definitely less than optimal but not as striking as your example. (what was interesting to me was that running the first example via pasuspender caused the sinks/source to not unsuspend themselfs when I hit control + C... need to investigate that one). Col ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Fix crash on jack server shutdown
Lennart Poettering wrote: On Tue, 23.03.10 00:36, David Henningsson (launchpad@epost.diwic.se) wrote: What is missing is that the jack loop does not depend on the PA sink to be around resp. the PA IO loop doesn't call into jack when it is dead. If either of that is implemented (and then destruction order matches this) the problem is fixed. Also, what applies to m-jack-sink needs fixing in m-jack-source, too. Good points. I admit to not having checked properly whether pa_sink_unlink and pa_sink_render_full can be called in parallell, I see now that they shouldn't. Calling _unlink() and _render_full() at the same time is actually fine. _unlink() will send a msg to the IO thread to shut down the sink and will synchronously wait for it. _render_full() is called from the IO thread. Since the msg dispatching and the _render_full() are run from the same thread and hence are serialized there is no problem here. Oh, so pa_sink_unlink does synchronize with the IO thread. But then I don't see the new race? What call into pa would be a problem after the sink has been unlinked? It can't be sink rendering, as u-sink-thread_info.state != PA_SINK_RUNNING at that point, so the module will just write silence (and not call into pa). // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
