1

After recent upgrade of Skype for Linux to 8.18.06 I hhave noticed deteriorating quality of sound playback. When calling to other Skype users they do not complain on the quality of sound coming from my side.

The Web version of Skype that runs in Google Chrome, or Chromium browsers does not seem to have this problem.

A thread on Skype Community forum dedicated to this problem has two possible solutions.

Solution 1

This solution seems to be taken from a blog post "Changes to Skype and issues in sound quality" at mikw623t.worpress.com.

As root in /etc/pulse/daemon.conf

Add a line 

default-fragment-size-msec = 5

Then as a non-privileged user restart the PulseAudio daemon using the commands

pulseaudio -k 
pulseaudio --start

This seems to correct the problem.

Solution 2

Start Skype as

env PULSE_LATENCY_MSEC=90 skypeforlinux

Question

Solution 1 seems more attractive because it is a "fix once and forget" solution. However this solution is not specific to Skype and will affect other tasks that use the PulseAudio daemon. Are there any downsides of solution 1? What exactly is going on here?

Configuration details

I am seeing this on a notebook with Intel Haswell-ULT HD Audio Controller, running Linux 4.4 series kernel.

I have also observed similar issues on an Intel Atom D2700 system with Intel NM10/ICH7 HD Audio controller running 3.19 series kernel.

Improve this question
2
  • You know that Microsoft bought Skype, right? The proper solution might be to find a platform which is not "developed" by Microsoft.
    – tripleee
    Commented Mar 21, 2018 at 6:23
  • @tripleee Yes, I have deployed Apache Openmeetings already in 2011 as an alternative to Skype. Yet I am sure we can figure out the mechanism that is causing problems with audio on Skype.
    – Dima Chubarov
    Commented Mar 21, 2018 at 7:18

1 Answer 1

Reset to default
1

The manpage of pulse-daemon.conf says:

DEFAULT FRAGMENT SETTINGS
       Some hardware drivers require the hardware playback buffer to be subdivided into several  frag‐
       ments.  It  is possible to change these buffer metrics for machines with high scheduling laten‐
       cies. Not all possible values that may be configured here are available in  all  hardware.  The
       driver  will find the nearest setting supported. Modern drivers that support timer-based sched‐
       uling ignore these options.

       default-fragments= The default number of fragments. Defaults to 4.

       default-fragment-size-msec=The duration of a single fragment. Defaults to 25ms (i.e. the  total
       buffer is thus 100ms long).
Improve this answer
1
  • I am not sure I fully understand this. Usually to compensate for latency we increase buffer size, but here the solutions seems to be in shrinking the fragment size and thus the buffer size. Could you please explain.
    – Dima Chubarov
    Commented Mar 21, 2018 at 4:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .