100% CPU on one core when paused

[mythtv@…]

Since 0.24-2 (upgraded from Fedora 12 to 14) pausing during playback causes one core of my 4-core CPU to go to 100% and stay there. Resuming playback and it goes back down to normal (all cores <10%).

Sounds a lot like ticket #6656, but for sure this isn't just caused by cpu speedstep or anything.

It does this on every pause. It never used to do this and I've been using Myth since 2005.

I did also have to make 2 myth config changes when upgrading to Fedora 14: had to change the audio rate to bypass the white-noise-after-seek bug with pulseaudio, and had to change the playback video driver type (I think?) as I'm now using nouveau drivers instead of nvidia binaries.

CPU is Core2 Quad on a modestly loaded workstation.

I did an strace during the pause, will attach shortly.

[mythtv@…]

strace output while paused, showing just the unique part before it repeats 10-20 times a second, same output

[bjoernv@…]

I can confirm this. Some postings suggest to set the environment variable TZ. Others suggest to change the video driver from OpenGL to Qt. Anyway, both suggestions do not help to me. The CPU usage keeps 100% on my quad core CPU in idle mode.

[mythtv@…]

I am using xv-blit renderer. I can't use openGL as the nouveau video drivers suck for GL/3D.

[bugs@…]

Same problem here on Fedora 14 (0.24-fixes, 464fa28373) with closed-source nvidia video driver, VDPAU output and PulseAudio.

I think I can pinpoint the problem to the audio output, specifically to this part of audiooutputbase.cpp:

void AudioOutputBase::OutputAudioLoop(void)
{
    ...

    while (!killaudio)
    {
        if (pauseaudio)
        {
            if (!actually_paused)
            {
                VBAUDIO("OutputAudioLoop: audio paused");
                OutputEvent e(OutputEvent::Paused);
                dispatch(e);
                was_paused = true;
            }

            actually_paused = true;
            audiotime = 0; // mark 'audiotime' as invalid.

            // only send zeros if card doesn't already have at least one
            // fragment of zeros -dag
            WriteAudio(zeros, zero_fragment_size);
            continue;
        }
        else
        {
            ...
        }

By adding

usleep(10000);

after the call to WriteAudio(), the CPU load goes down from 100% to less than 10% when pausing.

[mythtv@…]

That's a decent kludge, but there's got to be a better way than a spinlock/poll-type sleep. Of course, I'll take 10% over 100% anytime :-) Of course, this all used to work perfectly with NO load when paused, so finding out what changed would be best.

I'm using nouveau drivers, xv-blit, pulseaudio. I used to use the binary nvidia drivers, but not since my last fedora upgrade.

[mythtv@…]

My TZ is unset. I have no idea what format it's supposed to be set to? I'll investigate.

[J49137@…]

Not sure if it'll help, but I only get this with PulseAudio?: a few days ago, upgrading to GNOME 3 forced me to switch from ALSA to PA, and then I noticed this happening.

[J49137@…]

Uh, or, thinking about, it could be anything else that got upgraded in switching to GNOME 3 - PulseAudio?'s just been on my mind because of audio problems.

[JYA]

Adding a sleep after WriteAudio? is going to introduce buffer underruns in all audio methods other than Pulse as WriteAudio? is supposed to be blocking.

[James Le Cuirot <chewi@…>]

I'm seeing this with PulseAudio? too. Haven't tried without as I only built that driver. If WriteAudio? isn't blocking when it's supposed to then that's obviously a big clue. I'll try to find some time to check it out but I'm not too familiar with this stuff.

[JYA]

No me too.

Use the ALSA interface along with the pulse interface. On ubuntu it is ALSA:pulse ; with Fedora this may be different

[JYA]

I can't reproduce this in later version of fixes/0.24 nor master