[pulseaudio-discuss] Soft CPU time limit exhausted, terminating. (WAS using PA with multiple sound cards)

Mark Greenwood fatgerman at ntlworld.com
Fri Mar 27 15:41:21 PDT 2009


On Sunday 22 March 2009 12:02:58 Colin Guthrie wrote:
> 'Twas brillig, and Mark Greenwood at 21/03/09 23:45 did gyre and gimble:
> > High CPU usage problem:
> > 
> > Machine one: Use paprefs to enable 'Enable network access to local
> > sound devices' 'Allow other machines on the LAN to discover local
> > sound devices' 'Don't require authentication'
> > 
> > Machine two: Use paprefs to enable 'Make discoverable network sound
> > devices available locally'
> > 
> > As before, start Amarok playing some music. Use pavucontrol to Move
> > Stream to the USB sound device on machine one (actually it doesn't
> > matter, any device on machine one will do. I don't even need the USB
> > device plugged in).
> > 
> > Audio starts playing out of machine one. CPU usage (run 'top') on
> > both machines rises and rises. Machine one is very low-powered and on
> > there the CPU usage reaches 99% and pulseaudio quits.
> 
> I thought I could replicate this earlier today, as pulse CPU did go very 
> high for a while with network sinks, and it fell away when I unticked 
> the boxes in paprefs. But I can't replicate now I try to sit down and 
> look at it :s
> 
> That said, one end of my loop is 0.9.10 so not sure how valid a test 
> this is. I'll try and upgrade the other side shortly.
> 
> > This is the best thing about Linux when it works. I'm starting to
> > think I'm going mad; (I can't be the only one using the network
> > stuff, surely? Why has nobody else reported this?)
> 
> To be fair there are probably not a huge number of people using 0.9.14. 
> Quite a lot of distros stuck with 0.9.10 and are only shipping 0.9.14/15 
> in the next round of releases which are coming up now.
> 
> And of those using the newer versions, only a small subset will use 
> networking. So it's not surprising that you're the only one reporting 
> this... you're a pioneer! Be proud! :p
> 
> 
> 
> To debug further, it would be good to run pulseaudio manually on each 
> machine via -vvv args and see if anything is printed when the CPU goes 
> skyward.
> 
> Col
> 

OK I've run pulseaudio -vvvv on both end of my network. The logs are big so rather than pollute the list I've uploaded the ends of each of them to here

http://homepage.ntlworld.com/fatgerman/local_end.txt		-  log from the end which is discovering network sinks
http://homepage.ntlworld.com/fatgerman/remote_end.txt	-  log from the network sink

In summary, as soon as I open pavucontrol the remote end is giving lots of

D: protocol-native.c: Requesting rewind due to end of underrun.                                                                 
.. and then, later
D: sink-input.c: Requesting rewind due to corking                                                                               
D: module-suspend-on-idle.c: Sink alsa_output.pci_1106_3059_sound_card_0_alsa_playback_0 becomes idle.                          
I: module-suspend-on-idle.c: Source alsa_input.pci_1106_3059_sound_card_0_alsa_capture_0 idle for too long, suspending ...      
I: module-alsa-source.c: Device suspended...                                                                                    
I: module-suspend-on-idle.c: Sink alsa_output.pci_1106_3059_sound_card_0_alsa_playback_0 idle for too long, suspending ...      
I: module-alsa-sink.c: Device suspended...                                                                                      
I: module-stream-restore.c: Synced.                                                                                             
D: module-hal-detect.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded                                                                                                                            
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded                                                                                                                           
Soft CPU time limit exhausted, terminating.                                                                                     
E: cpulimit.c: Received request to terminate due to CPU overload.                                                               

The local end gives:
D: module-tunnel.c: Stream created.                                                                                                                                                 
D: module-tunnel.c: Stream created.                                                                                                                                                 
D: module-tunnel.c: Server reports playback started.                                                                                                                                
I: module-tunnel.c: Server signalled buffer overrun/underrun.                                                                                                                       
D: module-tunnel.c: Server reports playback started.                                                                                                                                
I: module-tunnel.c: Server signalled buffer overrun/underrun.                                                                                                                       
.. repeatedly ..
and eventually
W: module-tunnel.c: Stream died. 

How can I proceed with further debugging? The problem is getting worse, I have been able to play some audio before, but now I can't even open pavucontrol let alone get as far as moving audio onto the network sink. I'm passing tsched=0 to module_hal_detect on the local end, because I get very choppy playback otherwise (broken sound driver I think).

(On the other hand, the RTP issue seems to have gone, or at least only seems to happen the first time I move a source to the RTP sink)

Thanks,

Mark



More information about the pulseaudio-discuss mailing list