Ticket #1193 (closed defect: wontfix)

Opened 9 years ago

Last modified 9 years ago

Severe performance problems with Pulseaudio

Reported by: mjr@… Owned by: john_lee
Priority: high Milestone:
Component: Host Software Version: 2007.2
Severity: normal Keywords:
Cc: buglog@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Pulseaudio's behavior on my Neo has annoyed me for a while, and now I got around
to poking it a bit, with not much results but some. The visible issue is that
eg. when playing music with openmoko-mediaplayer, the pulseaudio server hogs up
25-30% of the CPU, which is enough to cause serious skipping of the audio (at
least my sample ogg tracks from Harvey Danger,
http://www.harveydanger.com/downloads/ ). This with no other clients playing
anything, of course, so no mixing required, just pushing bits from buffer to
sound driver.

ogg123, not going through pulseaudio, plays the same tracks quite well at around
80% CPU. Pulseaudio behavior is the same whether I use native ALSA or OSS sinks.

I straced pulseaudio a bit while playing music. Obviously, the strace emphasized
the skipping severely and quite possibly isn't useful for diagnosis due to
altering a lot of the timing, but some stuff was still going through.

Anyway, the thing that caught my eye was that between each write to the audio
device there were 16 pairs of alternating calls:
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0

I presumed this to be threading-related, but apparently pulseaudio doesn't do
threads after all. Then I presumed it to be rabid syncing with the shared memory
area the client uses to communicate with it, but it seems to persist with
--disable-shm (as does the CPU hogging, whether it's related or not). Now I just
presume pulseaudio is on crack.

One should hopefully be able to have a decent mediaplayer experience without
waiting for GTA-02 in order to have more CPU to feed to the relentless
pulseaudio. Hopefully it's easily fixable to consume sane amounts of CPU
regardless.)

Change History

comment:1 Changed 9 years ago by abraxa@…

I'm lead to assume that this is due to lack of proper atomic ops support on the
SOC - http://0pointer.de/blog/projects/atomic-rt.html has more on that.

I didn't get around yet to try the suggested workaround, help would be
appreciated.

comment:2 Changed 9 years ago by roh

  • Owner changed from buglog@… to openmoko-devel

comment:3 Changed 9 years ago by peepsalot

Not sure if this is the same issue, but I have a freerunner, and have attempted to play some media with openmoko-mediaplayer2. The audio constantly pops and crackles. Even the touchscreen tap sounds have crackles and pops at times.

Pulseaudio appears to use about 22-24% CPU when playing an mp3, and media player uses about 25%
So while there is still about 50% unused CPU, the audio quality is still unbearable.

I'm no expert at linux audio, but it seems to me that running at 50% CPU should not cause skipping.
Is there maybe an audio buffer that could be increased to help with this issue?

comment:4 Changed 9 years ago by hedora

comment:5 Changed 9 years ago by goldie

I have this problem too. After 10 maybe 12 hours (no matter if I listen to music or not) I have this annoying pops and crackles. If I restart the pulseaudio/freerunner, this problem goes away - but not for a long time.

comment:6 Changed 9 years ago by john_lee

  • Status changed from new to accepted
  • Owner changed from openmoko-devel to john_lee
  • HasPatchForReview unset

comment:7 Changed 9 years ago by john_lee

  • Status changed from accepted to closed
  • Resolution set to wontfix

switched om-mediaplayer2 to alsa as a workaround (#1614).

Note: See TracTickets for help on using tickets.