Bug 1282285

This bug has been open now for 2 months with zero movement.  Is there anything I can do to help out here?  I'm willing to troubleshoot, I just have no idea what to do next.

I'm pretty sure that this is an alsa problem. The driver probably configures the wrong samplerate or maybe it needs a tweak for this particular hardware.

Exactly the same here.
Trying with newest version of Debian 8 and SuSE 42.1.

The headset plays too fast with a short gap every second. Regardless which connection is used. Directly via USB-Cable, or via BT-Dongle. Both with the same result.

It plays the correct speed when connected via Bluetooth to Android devices.
Connected at Windows PC it pays also without any spot.

(In reply to Wim Taymans from comment #2)
> I'm pretty sure that this is an alsa problem. The driver probably configures
> the wrong samplerate or maybe it needs a tweak for this particular hardware.

Ok, so I've got the same question; what can I do to help troubleshoot this?  Guys, I'm willing to be your eyes and hands here, but these eyes and hands need a brain to direct them. :)

Hi. I've had the same problem.
Here is workaround that helped me:

In file

/etc/pulse/daemon.conf

replace
---
;default-sample-rate = 44100

|
v

with
---
default-sample-rate = 48000

And then reload pulseaudio

pulseaudio -k

Just tried this, and it appears to work here as well.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I see this with the Jabra Evolve 65 headset as well in Fedora 30.

The workaround above to set the sample rate to:

default-sample-rate = 48000

in the default pulse config works for me, but how can we make this DTRT by default?

pulseaudio-12.2-3.fc30.x86_64
alsa-lib-1.1.9-1.fc30.x86_64
$ uname -r
5.1.6-300.fc30.x86_64

The device reports those supported sample rates:

        bSamFreqType            5 Discrete
        tSamFreq[ 0]         8000
        tSamFreq[ 1]        16000
        tSamFreq[ 2]        32000
        tSamFreq[ 3]        44100
        tSamFreq[ 4]        48000

Could you check all rates with the 'speaker-test' utility through the native ALSA device (like 'spaker-test -D plughw:J65 -f 44100')?

Do you mean -r or -f ?  I hear "pink noise" with all selected frequencies with either -r or -f.


$ speaker-test -D plughw:J65 -r 44100

speaker-test 1.1.9

Playback device is plughw:J65
Stream parameters are 44100Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 44100Hz (requested 44100Hz)
Buffer size range from 90 to 262144
Period size range from 45 to 131072
Using max buffer size 262144
Periods = 4
was set period_size = 65536
was set buffer_size = 262144
 0 - Front Left
Time per period = 2.740062


$ speaker-test -D plughw:J65 -f 44100

speaker-test 1.1.9

Playback device is plughw:J65
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 96 to 262144
Period size range from 48 to 131072
Using max buffer size 262144
Periods = 4
was set period_size = 65536
was set buffer_size = 262144
 0 - Front Left
Time per period = 2.745972

does this help?

Sorry, -r is the correct option, of course. If the problematic rate works with the direct ALSA interface, you may try to simulate stream parameters (buffers) like PA uses and use '-b -p -P' arguments for speaker-test to force them. The actual streaming parameters are in /proc/asound/card#/pcm0p/sub0 directory.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.