On 2010-09-13 13:03, Colin Guthrie wrote: > 'Twas brillig, and David Henningsson at 13/09/10 11:14 did gyre and gimble: >> On 2010-09-04 14:10, Colin Guthrie wrote: >>> I'd be interested as to whether anyone else can repeat this experiment >>> and get similar results. Do you guys get a broken chordtest too (it's on >>> the RedHat bug I mentioned at the beginning of this thread)? >> >> I have now tried to repeat the experiment. The chordtest.sh seems to be >> buggy in itself (the cleanup does not remove the gst-launch, which in >> turn had to be renamed to gst-launch-0.10 here). > > Yeah I have gst-launch-0.10 here too... not quite sure why, I'd have > thought we could ditch the old 0.8 support by now but hey ho. (I don't > follow gst dev super closely) > > I thought that the script trapped ctrl+c and killed any processes > started. It seems to be clean for me. > > Perhaps the problem is that /bin/sh is not actually bash on your system? It is "dash" on Ubuntu systems. > Perhaps just changing the first line to: > > #!/bin/bash would cause it to tidy things up properly? Yes, that worked, thanks. >> Anyway, the results >> were not encouraging - with tsched=0, pavucontrol, and -vvvv to syslog >> on, three tones were heard, then things went quiet - however, pulseaudio >> started to eat more and more memory. Quickly my machine started swapping >> and became unresponsive, so I killed PA. >> Besides that, when I looked at pavucontrol, only the meters of the first >> three were moving, the other ones were silent. My log got filled up with >> "memblockq: pool full" as well. I'm getting the feeling that this >> problem is something different, unrelated to DMA controller hardware. > > Interesting, can't say I noticed this, but I probably wasn't looking > closely enough. > >> My suggestion is that you should commit your proposed patch as it >> improves the situation compared to the current situation. If there are >> additional problems, let's nail them down separately. > > OK, sounds reasonable. Do you think the patch I posted is OK with the > 1330 time? I think it is good enough for now. If it turns out to be too little, we can adjust it later. > I guess it's not super important as if it solves your original problem > that kicked off this whole thread, then that's the main thing!! That PA can handle a stress test is important, but it's a different issue. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic