Reported by Darrel Hankerson on the thinlinc-technical list.
> Windows XP and 7 callers using two of the nightly builds usually do
> not get audio. Is there a workaround?
> The 4.1 client works, but it has the slow-audio problem seen on
> some linux callers. The nightly builds solve the problem for linux
> On the single event where audio worked on Windows with a nightly build,
> audio was good. Success was on disable/enable sound in the thinlinc
> client, but this is not a reliable workaround (or is coincidence).
> The error on the session-side is "ALSA...invalid value for card".
Unable to reproduce the issue on our Windows 7 machine, and there are no clues in the attached logs.
I've failed from XP and multiple win7 clients. Is this a server-side issue? We've tested the 4.1 release on Debian stable and Scientific Linux. What's cendio's test environment (e.g., 32-bit win7 on Dell GX755 to 64-bit Redhat...).
Tested every machine in the lab without being able to reproduce this. I was however able to reproduce it on my Windows 7 machine at home.
Henrik seems to be getting this on one of his laptops as well.
From the reports, it seems like most (all?) of the machines are AMD ones. Perhaps this problem only occurs with their sound cards?
I could reproduce this issue on my Dell Vostro machine (Intel Core2):
Connect with audio, open a terminal and play a sound: paplay test.wav
Pulseaudio process takes 100% cpu and hangs the system, a strace of paplay
reports a "connection refused" after a timeout. And the client pa process runs wild. test.wav does not even exists and paplay also reports 'test.wav file not found'.
Killing the running pulseaudio process on the client looses things up and
client got responsive.
If I use task manager on the client to change process priority from HIGH to NORMAL, everything works as it should. paplay works as expected andwhen playing a youtube clip the audio gets jerky after a while.
Regression, so merging with bug 4569.
*** This bug has been marked as a duplicate of bug 4569 ***