Re: [pulseaudio-discuss] Frequent trivially-reproducible client hangs with stable-queue PA
On 22 Feb 2010, Paul Menzel stated: Am Montag, den 22.02.2010, 18:50 + schrieb Nix: Ever since I started using PA 0.9.21 (and possibly before: it's been long enough that my memory has faded), lots of applications have started hanging hard when fast-forwarded/rewound. This includes MPD and every single video player I own capable of fullscreen playback. As you might imagine, having to stop PA playing back sound and forcing all my video and music players not to use PA renders it... less useful than it might be, and the constant need to pay attention to ALSA volume levels makes PA's otherwise admirable ALSA volume-level frotzing annoying as well. (I'd use the ALSA-PA plugin, but as reported earlier, this doesn't work either, stuttering like crazy and frequently locking up. It may be that the ALSA plugin lockup is a special case of this one.) [~] Is there anything in the log files [1]? I forgot they existed (my default assumption where anything running as a user is concerned: I keep forgetting about the LOG_USER facility). ... no, not a line. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Frequent trivially-reproducible client hangs with stable-queue PA
well. (I'd use the ALSA-PA plugin, but as reported earlier, this doesn't work either, stuttering like crazy and frequently locking up. Even with this patch? http://launchpadlibrarian.net/37640450/0001-pulse-Fix-buffer-pointer-issues-improves-recovering-.patch // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Invalid dB data from drivers
Heya, just wanted to point everybody to this new canned response type note I just added to the wiki: http://pulseaudio.org/wiki/BadDecibel I wrote a little tool that can be used to track invalid dB data exposed by ALSA drivers. Incorrect dB data usually means that playing a stream in PA while another one is already playing might result in a volume change of the first one, that should not happen. As it appears a lot of USB hw has issues with the dB information. Anyway, I though you might find that page and the tool useful, especially if you maintain PA in other distributions and want to know what to do with bug reports about issues like the one I pointed out above. Did this tool go almost unnoticed, at least on this list? Thanks! I'm sure it'll come in handy when we triage some of the bugs in Ubuntu. Perhaps it could be something for the hardware testing suite, both in Ubuntu (i e checkbox), and its counterparts in other distributions? Now if only I could get some spare time, so I could play with it and package it...and optimally, I also need to get a soundcard with bad dB information from somewhere... Have fun, I've always enjoyed sine waves. ;-) // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Invalid dB data from drivers
'Twas brillig, and David Henningsson at 23/02/10 22:24 did gyre and gimble: Heya, just wanted to point everybody to this new canned response type note I just added to the wiki: http://pulseaudio.org/wiki/BadDecibel I wrote a little tool that can be used to track invalid dB data exposed by ALSA drivers. Incorrect dB data usually means that playing a stream in PA while another one is already playing might result in a volume change of the first one, that should not happen. As it appears a lot of USB hw has issues with the dB information. Anyway, I though you might find that page and the tool useful, especially if you maintain PA in other distributions and want to know what to do with bug reports about issues like the one I pointed out above. Did this tool go almost unnoticed, at least on this list? I guess most of us have been following the interesting and very long thread on this topic over at: http://thread.gmane.org/gmane.linux.alsa.devel/70545 :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Frequent trivially-reproducible client hangs with stable-queue PA
On 23 Feb 2010, David Henningsson said: well. (I'd use the ALSA-PA plugin, but as reported earlier, this doesn't work either, stuttering like crazy and frequently locking up. Even with this patch? http://launchpadlibrarian.net/37640450/0001-pulse-Fix-buffer-pointer-issues-improves-recovering-.patch Yes, that's installed. Most of the failures above happen only when the PulseAudio native libraries are used. (I've turned the ALSA plugin off because it stutters and hangs too much to be usable.) I just tried totem. It doesn't hang, but the audio stutters insanely, and after a couple of fast-forwards/rewinds, nothing is audible but stuttering. I've tried to record it, but parec has no man page and it is not obvious how to use it, e.g.: n...@mutilate 33 /home/nix% parec --device=Monitor of Internal Audio Analog Stereo --file-format=flac --record --verbose foo.flac Failed to open audio file. -- wtf? I'm recording! Audio file? Maybe --file-format is the *input* format, though I'd expect it to be an output format to allow transcoding. Let's try dropping the file format and just trying to record in whatever format parec wants to: n...@mutilate 34 /home/nix% parec --device=Monitor of Internal Audio Analog Stereo --record --verbose foo Opening a recording stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'. Connection established. Stream error: Invalid argument No good :( Hm, I wonder if the totem stuttering may be related to this intermittent problem: Feb 23 23:09:57 mutilate err: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Feb 23 23:09:57 mutilate err: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Feb 23 23:09:57 mutilate err: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value min_avail. Feb 23 23:11:16 mutilate warning: ratelimit.c: 58 events suppressed Feb 23 23:14:24 mutilate warning: ratelimit.c: 76 events suppressed (a bug new in 2.6.32, apparently: I first saw that message a day after upgrading.) Maybe this whole thing is a 2.6.32 kernel bug... I'll try rebooting into 2.6.31 shortly... ... no, no such luck. The log messages above are not correlated with the stuttering nor the hangs. They don't seem to happen (as much?) with 2.6.31, but both the totem/alsa-plugin stuttering and the xine/mplayer hangs continue with that kernel. It's amazing how annoying this bug is. A good thing I don't use GNOME, or I suspect the event sounds would be causing random app hangs across the whole desktop. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
