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
