www.cendio.com

Bug 4802

Summary: No sound with nightly builds on Windows 7
Product: ThinLinc Reporter: Karl Mikaelsson <derfian@cendio.se>
Component: SoundAssignee: Pierre Ossman <ossman@cendio.se>
Status: CLOSED DUPLICATE QA Contact: Bugzilla mail exporter <bugzilla-qa@cendio.se>
Severity: Normal    
Priority: P2 CC: hankedr@auburn.edu, hean01@cendio.se
Version: trunk   
Target Milestone: 4.1.1   
Hardware: PC   
OS: Unknown   
Acceptance Criteria:

Description From cendio 2013-09-10 09:30:02
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
> callers.  
> 
> 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".
------- Comment #2 From cendio 2013-09-10 16:58:52 -------
Unable to reproduce the issue on our Windows 7 machine, and there are no clues
in the attached logs.
------- Comment #3 From 2013-09-11 14:12:20 -------
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...).
------- Comment #4 From cendio 2013-09-16 13:38:30 -------
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.
------- Comment #5 From cendio 2013-09-16 13:43:18 -------
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?
------- Comment #6 From cendio 2013-09-16 16:09:54 -------
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.
------- Comment #7 From cendio 2013-09-18 12:39:12 -------
Regression, so merging with bug 4569.

*** This bug has been marked as a duplicate of bug 4569 ***