Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #60131 > unrolled thread

Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?)

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?) Andy Simpkins <rattusrattus@debian.org> - 2018-02-03 18:50 +0100
    Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?) Steve McIntyre <steve@einval.com> - 2018-02-03 19:10 +0100
    Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?) Ben Hutchings <ben@decadent.org.uk> - 2018-02-04 01:10 +0100

#60131 — Bug#886782: pulseaudio: Audio playback is slow (sample rate mismatch?)

Control: reassign -1 linux-image-4.9.0-5-amd64
Control: retitle -1 Audio playback is slow over DisplayPort on AMD Tahiti hardware (sample rate mismatch?)
Control: version -1 4.9.65-3+deb9u2

On 15/01/18 23:18, Felipe Sateler wrote:
> On Tue, Jan 9, 2018 at 5:44 PM, Andy Simpkins <rattusrattus@debian.org> wrote:
>> Package: pulseaudio
>> Version: 10.0-1+deb9u1
>> Severity: important
>>
>> Dear Maintainer,
>>
>> Following the upgrade to stretch sound on my system has stopped
>> working correctly.  Instead of normal sounding playback, all audio now
>> plays back slower than it should.
>>
>> This feels like it could be a sample rate issue.  The only speakers on
>> my system are on my monitors and derive their audio over display port.
>> As part of the Squeeze upgrade I am aware that my Graphic Card drivers
>> got changed from the 'non-free ATI drivers to the recommended FLOSS
>> driver so it could be something there...
> 
> Could you try with the trivial resampler? That should rule out the
> resampler as a source of the slowness.
> 
> The driver change sounds a lot more likely to be the cause. Could you
> try booting with the jessie kernel to see if the slowness goes away?
> Also relevant, is the slowness present when playing to any output, or
> only on one (HDMI, internal, etc)?
> 
> Another avenue to try is to set default-fragment-size-msec to some
> very high value, like 250ms.
> 

Hi Again

Sorry for the long time to respond, I needed to get time with someone who knows what they are doing so they can sit with me (many thanks Sledge)

OK so we have tried the following:
1) reverted back to the Jessie Kernel with free drivers, and that does not work with sound through the hdmi display port at all (the OLD fglrx catalyst non-free driver was what I used to use in Jessie 
did however work)

2) tested analogue output (PC motherboard) and sound works correctly.

3) moving back to Stretch, 4.9.X kernel and we have also tested using the Analogue sound port.  this plays output correctly.

4) switching to hdmi / display port and the sound problem returns

5) when we try playback from different applications we get different results.
Playback through VLC is 'bursty': that is sound plays for a fraction of a second, stops, then starts again having skipped some of a track. playback is also SLOW as previously reported, it sounds like 
VLC might be trying to re-sync.

When using Quod Libet the playback is just slow (without the skipping that VLC appears to do to 'resync')

Finally using speaker-test with a 1khz sine output this to my ears also sounds off pitch.

6) setting the resample method to trivial has no obvious effect (audio is still slow)

7) setting default fragment size to 0.25s only changes the 'chunk' of audio duration, playback speed is still slow, and it still pauses and skips before playing the next 'chunk' of audio (using VLC)


Many thanks for your help and suggestions, this is now sounding like a driver issue.  We'll re-assign this to the appropriate linux-image package I'm using and CC the kernel folks too.

Dear kernel folks - sorry, looks like this is your bug (and clearly upstream!).

Cheers

/Andy

[toc] | [next] | [standalone]

#60132

On Sat, Feb 03, 2018 at 05:41:34PM +0000, Andy Simpkins wrote:
>
>Many thanks for your help and suggestions, this is now sounding like
>a driver issue.  We'll re-assign this to the appropriate linux-image
>package I'm using and CC the kernel folks too.
>
>Dear kernel folks - sorry, looks like this is your bug (and clearly
upstream!).

Quickly responding here again - we've just tried the latest kernel
from experimental (4.15.0-rc8) and this still shows the same problem.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Who needs computer imagery when you've got Brian Blessed?

[toc] | [prev] | [next] | [standalone]

#60138

[Multipart message — attachments visible in raw view] — view raw

Control: reassign -1 src:linux 4.9.65-3+deb9u2
Control: found -1 4.15~rc8-1
Control: tag -1 upstream

On Sat, 2018-02-03 at 17:41 +0000, Andy Simpkins wrote:
> Control: reassign -1 linux-image-4.9.0-5-amd64
[...]

Please always assign kernel bugs to the source package, since the set
of binary packages changes over time.

Ben.

-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web