Not able to record properly from thin client

I need to do latency test for my thin client. On my Virtual Desktop I installed Audacity 2.0.3 version. The following are my observations

a) From ‘Sound Recorder’ (not from Audacity, usually available on Windows) I am able to record my own voice. In the recorded signal there is little noise added, some echo, some skips. All together the recorded sample is OK.

b) But when recorded through ‘Audacity’ from thin client the recorded sample is very bad.

  • It has lot of noise added.
  • a small sample of original signal (say 0.5 sec )is recorded in a span of 3 sec (broken in between) with lot of noise added, lot of silence in between.
  • The silence space is gradually increasing between consecutive samples.

c) When I play a ‘Generated Click Track’, I noticed that the gap between two clicks is increasing as proceed. Also only clicks under 15 sec are played for entire 32 sec.

d) When I perform the Latency test by ‘loop-back’ I noticed the following

  • Only clicks under 2 sec (hardly 8 clicks) are being played with lot of delay in between.
  • In the recorded sample hardly I am not able to correlated any sample. There is lot of silence in between the recorded samples. I am not able to distinguish that recorded samples are noise or part of ‘click’.

Setting done in Audacity.

  1. In Edit->Preference->Recording, ‘Latency Correction’ is made to ‘0’. checked ‘Overdub’ playthrough. Unchecked ‘Software Playthrough’
  2. Remaining all settings are default ones.

Here are my questions.

  1. Is any thing to do with the clock frequency of sound card of my remote PC and my thin client?
  2. Any modifications required on sampling frequency?
  3. Do I need more settings in Audacity?
  4. Finally how can I remove noise and record properly and test the latency on my thin client.

V Pavan Kumar.

You were in trouble at a). Skips are a symptom of a system not running fast enough for live audio.
Audacity doesn’t understand delays and will not run over a network.

Could you describe that in more detail.
In terms of computers “A” and “B”, where “A” is the local machine and “B” is the remote machine:
Where is Audacity installed?
Where is your microphone connected?
Where is the audio data written (where is Audacity’s temp folder)?
Where are you saving Audacity projects (if you save them)?
Where are you exporting the recordings to (if you are exporting them)?
Where are your headphones / speakers plugged in for playback?
What sort of network is it?

Audacity needs to be installed on “A” with the sound card on “A”. There is no real support for local and remote machine relationships. If you get it to work as such, it’s as good or bad as it is.


It can work (even if not officially supported) if Audacity is installed on “B” with the sound card on “B” and the microphone plugged into the sound card on “B” and the data is being written to storage in “B” (essentially running as a fat client application), provided that the client hardware is up to the job.

On Linux it is possible (though not particularly easy) if Audacity is installed on “A”, the data written to storage in “A”, with the microphone and sound card connected to “B”, provided that “B” and the network are capable of audio streaming to “A” in real time (via PulseAudio remote streaming). I don’t think that Windows provides this functionality.

Performance is likely to be very bad in most other cases because the network is unlikely to be able to handle on demand real time data transfer well enough.

I agree - I have done that on Windows 7. The recording had several dropouts when I did it on a slow Desktop and none at all on my current reasonably fast laptop.

Simply playing back a track on “B” I had to wait about about five seconds before the local machine received playback sound and the playback was not entirely free of dropouts on either machine (but I made no attempt to find tweaks). This was just Windows Remote Desktop (the version that comes with Windows 7 is supposed to support bi-directional audio).


So that should provide similar functionality as the scenario that I described for Linux (though it was not available prior to Remote Desktop Version 7.0), but it will still be highly dependent on the access speed of the network, which is not likely to be great.