pulseaudio issueshttps://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues2021-04-20T07:16:16Zhttps://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/378No audio with A2DP playback to Rocketfish headphones2021-04-20T07:16:16ZBugzilla Migration UserNo audio with A2DP playback to Rocketfish headphones## Submitted by David Highley
Assigned to **pul..@..op.org**
**[Link to original bug (#60623)](https://bugs.freedesktop.org/show_bug.cgi?id=60623)**
## Description
Also submitted to Fedora bugzilla, [Bug 882594](https://bugs.freed...## Submitted by David Highley
Assigned to **pul..@..op.org**
**[Link to original bug (#60623)](https://bugs.freedesktop.org/show_bug.cgi?id=60623)**
## Description
Also submitted to Fedora bugzilla, [Bug 882594](https://bugs.freedesktop.org/show_bug.cgi?id=882594).
Description of problem:
Streaming audio via A2DP bluetooth profile is low quality to headphones.
Version-Release number of selected component (if applicable):
How reproducible:
Everytime
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
I have had an open bug report on this since Fedora 16, [Bug 787405](https://bugs.freedesktop.org/show_bug.cgi?id=787405). The bluetooth stack seems to be working now in Fedora 17 but the audio quality for streaming is poor. In the sound options I was only able to get audio to work for the telephony mode. If I switched to A2DP then I received no audio. I have tested this on Fedora 17 and Fedora 18. I use the same headphones with my cellphone and have good quality audio. For more information see the reference bug report. Purchased a USB 4.0 Bluetooth adapter to see if it would work better than the SOC motherboard but nothing changed. Headphones are Rocketfish and work great with Android phones.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/138Replace dummy modules with a list of deprecated module aliases in the module ...2018-07-30T09:57:58ZBugzilla Migration UserReplace dummy modules with a list of deprecated module aliases in the module loading code## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#60146)](https://bugs.freedesktop.org/show_bug.cgi?id=60146)**
## Description
Sometimes we want to rename modules. That's no reason to ...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#60146)](https://bugs.freedesktop.org/show_bug.cgi?id=60146)**
## Description
Sometimes we want to rename modules. That's no reason to break user configuration. We have handled this sometimes by keeping a compatibility module that loads the new module, and sometimes we have simply broken configuration compatibility. Dummy modules take up compilation time and add clutter the source tree. I propose a lighter-weight solution: maintain a simple list of deprecated module aliases in the module loading code. If configuration contains a module that is on the list, the module loading code issues a warning and loads the modern version of the module.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/32network playback choppy for some clients when streaming via mDNS tunnel2019-10-26T12:21:38ZBugzilla Migration Usernetwork playback choppy for some clients when streaming via mDNS tunnel## Submitted by jro..@..re.net
Assigned to **pul..@..op.org**
**[Link to original bug (#59267)](https://bugs.freedesktop.org/show_bug.cgi?id=59267)**
## Description
The problem occurs for some clients and not others, and goes away...## Submitted by jro..@..re.net
Assigned to **pul..@..op.org**
**[Link to original bug (#59267)](https://bugs.freedesktop.org/show_bug.cgi?id=59267)**
## Description
The problem occurs for some clients and not others, and goes away entirely if a direct connection is used (by setting PULSE_SERVER or pax11publish). This happens primarily iceweasel (firefox).
I found that if I switch the sink back and forth between the local and remote server I can eventually get the choppiness to go away. If I pause the audio at the source the choppiness returns.
ohsix on the #pulseaudio channel suggested I look at the sink latency with "pacmd list-sinks". In either case, either when playback is good or when choppy, the "current latency" reported by the remote sink is absurdly high. For instance:
current latency: 5515241.32 ms
I can guarantee I'm not actually seeing a 1.5 hour latency. (Maybe this is a red herring, but if it is it probably indicates a bug in it's own right.)
Please let me know if there's any further information I can provide.
The local and remote servers are both version 2.0-6 from Debian wheezy.
Thanks for the help, and for such a great piece of software.Russell TreleavenRussell Treleavenhttps://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/466pulseaudio[19858]: [alsa-sink] memblock.c: Assertion 'pa_atomic_load(&(b)->_r...2018-07-30T10:30:02ZBugzilla Migration Userpulseaudio[19858]: [alsa-sink] memblock.c: Assertion 'pa_atomic_load(&(b)->_ref) > 0' failed at pulsecore/memblock.c:590, function pa_memblock_unref(). Aborting.## Submitted by John Schmitt
Assigned to **pul..@..op.org**
**[Link to original bug (#59115)](https://bugs.freedesktop.org/show_bug.cgi?id=59115)**
## Description
Created attachment 72663
pulseaudio extracted from /var/log/message...## Submitted by John Schmitt
Assigned to **pul..@..op.org**
**[Link to original bug (#59115)](https://bugs.freedesktop.org/show_bug.cgi?id=59115)**
## Description
Created attachment 72663
pulseaudio extracted from /var/log/messages for the time that pulseaudio ran with log-level=4
About once a day pulseaudio crashes with that message. The machine is usually idle when this happens except for skype.
$ rpm -qa | grep -i pulse
wine-pulseaudio-1.5.13-1.fc17.x86_64
pulseaudio-module-gconf-1.1-9.fc17.x86_64
pulseaudio-1.1-9.fc17.x86_64
pulseaudio-libs-1.1-9.fc17.i686
wine-pulseaudio-1.5.13-1.fc17.i686
alsa-plugins-pulseaudio-1.0.26-1.fc17.x86_64
kde-settings-pulseaudio-4.8-19.fc17.noarch
gvncpulse-0.5.1-4.fc17.x86_64
pulseaudio-libs-glib2-1.1-9.fc17.x86_64
pulseaudio-module-x11-1.1-9.fc17.x86_64
pulseaudio-module-zeroconf-1.1-9.fc17.x86_64
pulseaudio-libs-1.1-9.fc17.x86_64
pulseaudio-utils-1.1-9.fc17.x86_64
Steps to Reproduce:
Install skype leave it running
use a USB headset (Logitch G35) as well as speakers on-board sound
run xfce4-mixer and pavucontrol, leave them running
Actual results:
pulseaudio[19858]: [alsa-sink] memblock.c: Assertion 'pa_atomic_load(&(b)->_ref) > 0' failed at pulsecore/memblock.c:590, function pa_memblock_unref(). Aborting.
$ cat ~/.pulse/daemon.conf
log-level = 4
; default-fragment-size-msec = 1
; default-sample-rate = 48000
; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0
**Attachment 72663**, "pulseaudio extracted from /var/log/messages for the time that pulseaudio ran with log-level=4":
[pulse.out](/uploads/387daa6d79da1785b71dc4e0361cf12f/pulse.out)https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/499X11 bell event dropped in Xfce and other non-Gnome desktops2018-07-30T10:32:49ZBugzilla Migration UserX11 bell event dropped in Xfce and other non-Gnome desktops## Submitted by PMouse
Assigned to **pul..@..op.org**
**[Link to original bug (#58930)](https://bugs.freedesktop.org/show_bug.cgi?id=58930)**
## Description
When running Xfce (or any other non-GNOME-based desktop), the X11 bell ev...## Submitted by PMouse
Assigned to **pul..@..op.org**
**[Link to original bug (#58930)](https://bugs.freedesktop.org/show_bug.cgi?id=58930)**
## Description
When running Xfce (or any other non-GNOME-based desktop), the X11 bell event generated by XTerm and some terminal emulators does not produce any audible sound; it is lost, dropped, or ignored somewhere.
Steps to Reproduce:
1. Install xterm
2. Start xterm
3. type 'echo ^G' `<ENTER>`
4. Or, install the 'xkbbell' utility and run it, or run xbiff, irssi, or any program that makes a bell/beep. (Hell, even firefox makes this beep if you search for a word that doesn't exist on the page.)
Please see https://bugzilla.redhat.com/show_bug.cgi?id=607393 for (the very long) history.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/483Implement opus audio compression2018-07-30T10:31:17ZBugzilla Migration UserImplement opus audio compression## Submitted by Jonas Heinrich
Assigned to **pul..@..op.org**
**[Link to original bug (#56993)](https://bugs.freedesktop.org/show_bug.cgi?id=56993)**
## Description
Hello,
I would like to see audio compression for streaming audio ...## Submitted by Jonas Heinrich
Assigned to **pul..@..op.org**
**[Link to original bug (#56993)](https://bugs.freedesktop.org/show_bug.cgi?id=56993)**
## Description
Hello,
I would like to see audio compression for streaming audio in the network. Especially the new codec Opus could be usefull, because it's very fast (low-latency) and efficent (good sound quality with low bitrates).
Such a feature would allow me to stream audio via wifi, what currently doesn't work with a normal tcp.sink.
Best regards,
Jonashttps://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/498Distortion when kaffeine is playing2018-07-30T10:32:43ZBugzilla Migration UserDistortion when kaffeine is playing## Submitted by Frederik Himpe
Assigned to **pul..@..op.org**
**[Link to original bug (#56893)](https://bugs.freedesktop.org/show_bug.cgi?id=56893)**
## Description
Created attachment 69776
pulseaudio log
Quite often, sound sudde...## Submitted by Frederik Himpe
Assigned to **pul..@..op.org**
**[Link to original bug (#56893)](https://bugs.freedesktop.org/show_bug.cgi?id=56893)**
## Description
Created attachment 69776
pulseaudio log
Quite often, sound suddenly starts to become totally distorted on my system. This happens quite often (but not always) when I'm watching DVB-T television with Kaffeine and pidgin IM client plays a notification sound for an incoming message.
The attached log contains a complete pulseaudio session where this bug is occuring. In the beginning kaffeine is playing fine, but near then suddenly the sound becomes distorted, and then I shut down pulseaudio.
I also attach a recording of the distorted sound coming through the speakers, made with my phone.
**Attachment 69776**, "pulseaudio log":
[pulse.log](/uploads/29a3bf343f186dcad6db8a108b676133/pulse.log)https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/487playback of an audio file in mplayer2 with ao=pulse does not finish2018-07-30T10:31:39ZBugzilla Migration Userplayback of an audio file in mplayer2 with ao=pulse does not finish## Submitted by pur..@..kr.net
Assigned to **pul..@..op.org**
**[Link to original bug (#56577)](https://bugs.freedesktop.org/show_bug.cgi?id=56577)**
## Description
After switching mplayer2 config from ao=alsa to ao=pulse, sometim...## Submitted by pur..@..kr.net
Assigned to **pul..@..op.org**
**[Link to original bug (#56577)](https://bugs.freedesktop.org/show_bug.cgi?id=56577)**
## Description
After switching mplayer2 config from ao=alsa to ao=pulse, sometimes playback of an audio file would stop at the end of file, without ever ending or going to next track. Manually seeking forward or back unfreezes it but it happens all the time.
pulseaudio version: 2.0-6
mplayer2 version: 2.0-554-gf63dbad-1+b1
Packages are from debian sid amd64https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/536channels aren't separated after switching between speakers and headphone (som...2018-07-30T10:37:29ZBugzilla Migration Userchannels aren't separated after switching between speakers and headphone (sometimes)## Submitted by alex
Assigned to **pul..@..op.org**
**[Link to original bug (#55438)](https://bugs.freedesktop.org/show_bug.cgi?id=55438)**
## Description
Symptoms:
-music sounds strange
-playing front-left (gnome) is also heard o...## Submitted by alex
Assigned to **pul..@..op.org**
**[Link to original bug (#55438)](https://bugs.freedesktop.org/show_bug.cgi?id=55438)**
## Description
Symptoms:
-music sounds strange
-playing front-left (gnome) is also heard on the right headphone speaker and the other way around
Reproduction (speakers are connected, also the headphone):
1. plug out headphones, the sound should be hearable from the speakers
2. listen to music some time
3. plug in headphones
Now this problem appears sometimes (with the headphone, the speakers still operate fine). The problem can't be solved by restarting pulseaudio.
The weirdest thing is that the problem disappears after a while.
Sorry that I don't have more information. I hope you can reproduce the problem.
my conclusion:
It seems as if the left and the right channel are mixed to a distorted mono sound.
But this seems only to happen in headphones. Most probably it is a fault in the headphone detection (the headphone itself is new and works fine) or a hardware problem (broken driver?)
Technical data:
pulseaudio: git, build date: 22.9.2012
distro: archlinux
mainboard: GA-MA785GT-UD3H
Related bugs (seems so):
https://bugs.freedesktop.org/show_bug.cgi?id=53206https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/31Dre Beats cause major hang ups2019-02-01T18:30:04ZBugzilla Migration UserDre Beats cause major hang ups## Submitted by John C
Assigned to **pul..@..op.org**
**[Link to original bug (#55401)](https://bugs.freedesktop.org/show_bug.cgi?id=55401)**
## Description
I have an HP Envy 3040nr:
http://www.newegg.com/Product/Product.aspx?Item...## Submitted by John C
Assigned to **pul..@..op.org**
**[Link to original bug (#55401)](https://bugs.freedesktop.org/show_bug.cgi?id=55401)**
## Description
I have an HP Envy 3040nr:
http://www.newegg.com/Product/Product.aspx?Item=N82E16834158219
It has Dre "Beats" speaker. I do not know if they are the cause of the issue, but this computer suffer sever hang ups after log in.
Gnome-shell gdm cannot activate on this computer unless I use a workaround.
This happens with Arch, Ubuntu, Mint, and Fedora.
My workaround is to add "blacklist snd-usb-audio" to /etc/modprobe.d/alsa-base.conf
Without using this workaround, the computer borders on unsuable. The sound applets refuse to even work.
I was unsure under which category to put this.
My OS: Arch Linux x64https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/207Assertion '!s->thread_info.rewind_requested' failed at pulsecore/sink.c:1271,...2019-11-27T18:34:12ZBugzilla Migration UserAssertion '!s->thread_info.rewind_requested' failed at pulsecore/sink.c:1271, function pa_sink_render_into_full(). Aborting.## Submitted by Matthijs Kooijman
Assigned to **pul..@..op.org**
**[Link to original bug (#54881)](https://bugs.freedesktop.org/show_bug.cgi?id=54881)**
## Description
Created attachment 67112
pulseaudio -vv output
This assertion...## Submitted by Matthijs Kooijman
Assigned to **pul..@..op.org**
**[Link to original bug (#54881)](https://bugs.freedesktop.org/show_bug.cgi?id=54881)**
## Description
Created attachment 67112
pulseaudio -vv output
This assertion occured when playing an audio stream and starting pavucontrol halfway through the stream. I happened to have pulseaudio running with -vv, so I'm attaching that log output. I unfortunately don't have a stacktrace, nor have I succeeded in reproducing this particular assert.
This assertion was observed running pulseaudio 2.0 from Debian (2.0-3).
Here's the tail of the log:
D: [pulseaudio] protocol-native.c: Client pavucontrol changes volume of sink input 'A Night Like This' by 'Caro Emerald'.
D: [alsa-sink] alsa-sink.c: Requested to rewind 384000 bytes.
D: [alsa-sink] alsa-sink.c: Limited to 3584 bytes.
D: [alsa-sink] alsa-sink.c: before: 896
D: [alsa-sink] alsa-sink.c: after: 896
D: [alsa-sink] alsa-sink.c: Rewound 3584 bytes.
D: [alsa-sink] sink.c: Processing rewind...
D: [alsa-sink] sink-input.c: Have to rewind 3584 bytes on render memblockq.
D: [alsa-sink] module-equalizer-sink.c: Rewind callback!
D: [alsa-sink] sink-input.c: Have to rewind 3584 bytes on render memblockq.
D: [alsa-sink] source.c: Processing rewind...
I: [pulseaudio] module-stream-restore.c: Storing volume/mute/device for stream sink-input-by-media-role:music.
I: [alsa-sink] alsa-sink.c: Underrun!
I: [alsa-sink] alsa-sink.c: Increasing minimal latency to 1.00 ms
D: [alsa-sink] alsa-sink.c: Latency set to 1.00ms
D: [alsa-sink] alsa-sink.c: hwbuf_unused=383808
D: [alsa-sink] alsa-sink.c: setting avail_min=95977
D: [alsa-sink] alsa-sink.c: Requesting rewind due to latency change.
D: [alsa-sink] alsa-sink.c: Latency set to 1.00ms
D: [alsa-sink] alsa-sink.c: hwbuf_unused=383808
D: [alsa-sink] alsa-sink.c: setting avail_min=95977
D: [alsa-sink] alsa-sink.c: Latency set to 1.00ms
D: [alsa-sink] alsa-sink.c: hwbuf_unused=383808
D: [alsa-sink] alsa-sink.c: setting avail_min=95977
D: [alsa-sink] alsa-sink.c: Latency set to 1.00ms
D: [alsa-sink] alsa-sink.c: hwbuf_unused=383808
D: [alsa-sink] alsa-sink.c: setting avail_min=95977
E: [alsa-sink] sink.c: Assertion '!s->thread_info.rewind_requested' failed at pulsecore/sink.c:1271, function pa_sink_render_into_full(). Aborting.
**Attachment 67112**, "pulseaudio -vv output":
[pulse.log](/uploads/f75b41ebad7d10644de579d255f5028d/pulse.log)https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/18[cleanup] sync_input_volumes_within_thread() has unnecessary code duplication2023-08-10T09:42:15ZBugzilla Migration User[cleanup] sync_input_volumes_within_thread() has unnecessary code duplication## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54252)](https://bugs.freedesktop.org/show_bug.cgi?id=54252)**
## Description
This is sync_input_volumes_within_thread():
static void ...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54252)](https://bugs.freedesktop.org/show_bug.cgi?id=54252)**
## Description
This is sync_input_volumes_within_thread():
static void sync_input_volumes_within_thread(pa_sink *s) {
pa_sink_input *i;
void *state = NULL;
pa_sink_assert_ref(s);
pa_sink_assert_io_context(s);
PA_HASHMAP_FOREACH(i, s->thread_info.inputs, state) {
if (pa_cvolume_equal(&i->thread_info.soft_volume, &i->soft_volume))
continue;
i->thread_info.soft_volume = i->soft_volume;
pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
}
}
And this is the PA_SINK_INPUT_MESSAGE_SET_SOFT_VOLUME handler:
case PA_SINK_INPUT_MESSAGE_SET_SOFT_VOLUME:
if (!pa_cvolume_equal(&i->thread_info.soft_volume, &i->soft_volume)) {
i->thread_info.soft_volume = i->soft_volume;
pa_sink_input_request_rewind(i, 0, TRUE, FALSE, FALSE);
}
return 0;
Instead of duplicating the code in the SET_SOFT_VOLUME handler, sync_input_volumes_within_thread() should call i->process_msg(PA_SINK_INPUT_MESSAGE_SET_SOFT_VOLUME).https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/65protocol-esound, protocol-simple: Rewind after underrun can be too large2018-07-30T09:38:13ZBugzilla Migration Userprotocol-esound, protocol-simple: Rewind after underrun can be too large## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54251)](https://bugs.freedesktop.org/show_bug.cgi?id=54251)**
## Description
Rewinding after an underrun should be done like this:
pa...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54251)](https://bugs.freedesktop.org/show_bug.cgi?id=54251)**
## Description
Rewinding after an underrun should be done like this:
pa_sink_input_request_rewind(s->sink_input, (size_t) (s->sink_input->thread_info.underrun_for == (uint64_t) -1 ? 0 : s->sink_input->thread_info.underrun_for), FALSE, TRUE, FALSE);
(The example is from protocol-native.c.)
That ensures that the received data won't overwrite valid data in case the underrun was so short that the sink still has data left from time before the underrun started.
protocol-esound.c currently does this:
pa_sink_input_request_rewind(c->sink_input, 0, FALSE, TRUE, FALSE);
Giving zero as the rewind amount means that a full rewind will be done, regardless of whether valid data might get overwritten. If valid data gets overwritten, there will be a skip in the audio.
protocol-simple.c has the same bug.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/219[cleanup] When creating a new sink input, the core could request a rewind2018-07-30T10:07:38ZBugzilla Migration User[cleanup] When creating a new sink input, the core could request a rewind## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54243)](https://bugs.freedesktop.org/show_bug.cgi?id=54243)**
## Description
Comment in the PA_SINK_MESSAGE_ADD_INPUT handler in sink....## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54243)](https://bugs.freedesktop.org/show_bug.cgi?id=54243)**
## Description
Comment in the PA_SINK_MESSAGE_ADD_INPUT handler in sink.c:
/* We don't rewind here automatically. This is left to the
* sink input implementor because some sink inputs need a
* slow start, i.e. need some time to buffer client
* samples before beginning streaming. */
Not doing the rewind automatically has led to a situation where every filter sink (and some other sink input implementations, like module-sine) has this sink input state change callback:
static void sink_input_state_change_cb(pa_sink_input *i, pa_sink_input_state_t state) {
struct userdata *u;
pa_sink_input_assert_ref(i);
pa_assert_se(u = i->userdata);
pa_log_debug("Sink input %d state %d", i->index, state);
/* If we are added for the first time, ask for a rewinding so that
* we are heard right-away. */
if (PA_SINK_INPUT_IS_LINKED(state) &&
i->thread_info.state == PA_SINK_INPUT_INIT) {
pa_log_debug("Requesting rewind due to state change.");
pa_sink_input_request_rewind(i, 0, FALSE, TRUE, TRUE);
}
}
Repeating that in every filter sink shouldn't be needed. The core could request the rewind itself, without pushing the responsibility to the sink input implementors. Avoiding the rewind when it's not needed is only an optimization. In my opinion the optimization is good to have, but it could be implemented by having a sink input flag that says that this input "needs a slow start".https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/368Rewinding when moving streams isn't done in an optimal way2018-07-30T10:21:08ZBugzilla Migration UserRewinding when moving streams isn't done in an optimal way## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54182)](https://bugs.freedesktop.org/show_bug.cgi?id=54182)**
## Description
Code in the PA_SINK_MESSAGE_START_MOVE handler in sink.c:...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54182)](https://bugs.freedesktop.org/show_bug.cgi?id=54182)**
## Description
Code in the PA_SINK_MESSAGE_START_MOVE handler in sink.c:
if (i->thread_info.state != PA_SINK_INPUT_CORKED) {
pa_usec_t usec = 0;
size_t sink_nbytes, total_nbytes;
/* The old sink probably has some audio from this
* stream in its buffer. We want to "take it back" as
* much as possible and play it to the new sink. We
* don't know at this point how much the old sink can
* rewind. We have to pick something, and that
* something is the full latency of the old sink here.
* So we rewind the stream buffer by the sink latency
* amount, which may be more than what we should
* rewind. This can result in a chunk of audio being
* played both to the old sink and the new sink.
*
* FIXME: Fix this code so that we don't have to make
* guesses about how much the sink will actually be
* able to rewind. If someone comes up with a solution
* for this, something to note is that the part of the
* latency that the old sink couldn't rewind should
* ideally be compensated after the stream has moved
* to the new sink by adding silence. The new sink
* most likely can't start playing the moved stream
* immediately, and that gap should be removed from
* the "compensation silence" (at least at the time of
* writing this, the move finish code will actually
* already take care of dropping the new sink's
* unrewindable latency, so taking into account the
* unrewindable latency of the old sink is the only
* problem).
*
* The render_memblockq contents are discarded,
* because when the sink changes, the format of the
* audio stored in the render_memblockq may change
* too, making the stored audio invalid. FIXME:
* However, the read and write indices are moved back
* the same amount, so if they are not the same now,
* they won't be the same after the rewind either. If
* the write index of the render_memblockq is ahead of
* the read index, then the render_memblockq will feed
* the new sink some silence first, which it shouldn't
* do. The write index should be flushed to be the
* same as the read index. */
/* Get the latency of the sink */
usec = pa_sink_get_latency_within_thread(s);
sink_nbytes = pa_usec_to_bytes(usec, &s->sample_spec);
total_nbytes = sink_nbytes + pa_memblockq_get_length(i->thread_info.render_memblockq);
if (total_nbytes > 0) {
i->thread_info.rewrite_nbytes = i->thread_info.resampler ? pa_resampler_request(i->thread_info.resampler, total_nbytes) : total_nbytes;
i->thread_info.rewrite_flush = TRUE;
pa_sink_input_process_rewind(i, sink_nbytes);
}
}
Code in the PA_SINK_MESSAGE_FINISH_MOVE handler in sink.c:
if (i->thread_info.state != PA_SINK_INPUT_CORKED) {
pa_usec_t usec = 0;
size_t nbytes;
/* In the ideal case the new sink would start playing
* the stream immediately. That requires the sink to
* be able to rewind all of its latency, which usually
* isn't possible, so there will probably be some gap
* before the moved stream becomes audible. We then
* have two possibilities: 1) start playing the stream
* from where it is now, or 2) drop the unrewindable
* latency of the sink from the stream. With option 1
* we won't lose any audio but the stream will have a
* pause. With option 2 we may lose some audio but the
* stream time will be somewhat in sync with the wall
* clock. Lennart seems to have chosen option 2 (one
* of the reasons might have been that option 1 is
* actually much harder to implement), so we drop the
* latency of the new sink from the moved stream and
* hope that the sink will undo most of that in the
* rewind. */
/* Get the latency of the sink */
usec = pa_sink_get_latency_within_thread(s);
nbytes = pa_usec_to_bytes(usec, &s->sample_spec);
if (nbytes > 0)
pa_sink_input_drop(i, nbytes);
pa_log_debug("Requesting rewind due to finished move");
pa_sink_request_rewind(s, nbytes);
}
So, there are two problems in the move start phase: the sink input is rewound more than it should be, and there may be unnecessary silence left in the render_memblockq.
It can be argued that the move finish phase is ok, but I think it would be better not to lose any audio.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/469[cleanup] When lowering sink latency, the core could request a rewind2018-07-30T10:30:11ZBugzilla Migration User[cleanup] When lowering sink latency, the core could request a rewind## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54006)](https://bugs.freedesktop.org/show_bug.cgi?id=54006)**
## Description
If a sink supports dynamic latency and the latency is adj...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#54006)](https://bugs.freedesktop.org/show_bug.cgi?id=54006)**
## Description
If a sink supports dynamic latency and the latency is adjusted downwards, there needs to be a rewind to ensure that the sink buffer doesn't contain more data than what is allowed by the new latency. This is because rewind requests can't be larger than the configured latency, and if there's more data than that in the buffer, a later rewind request may end up being too small.
The responsibility for issuing the rewind request is currently on the sink implementor. I don't think that's necessary, so I think it would be better to issue the rewind request in the core code.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/55resampler leftover buffer is not taken into account when rewinding2018-07-30T09:37:30ZBugzilla Migration Userresampler leftover buffer is not taken into account when rewinding## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#53911)](https://bugs.freedesktop.org/show_bug.cgi?id=53911)**
## Description
The resampler leftover buffer can contain data from a sin...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#53911)](https://bugs.freedesktop.org/show_bug.cgi?id=53911)**
## Description
The resampler leftover buffer can contain data from a sink input, data which has been popped from the sink input implementor but not yet pushed to the render_memblockq. That data is not currently taken into account when rewinding. When doing a rewind that affects the resampler, the leftover data is discarded, and that is not compensated in any way, which means that the data is completely lost and there's a skip in the audio.
In practice the leftover buffer is rarely used and even if it is used, it will contain a minimal amount of data, so the user-visible effect of this bug is minor.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/261Distorted sound with time-based scheduling (tsched=1 for module-udev-detect)2020-02-07T05:29:02ZBugzilla Migration UserDistorted sound with time-based scheduling (tsched=1 for module-udev-detect)## Submitted by David Lynam
Assigned to **pul..@..op.org**
**[Link to original bug (#53892)](https://bugs.freedesktop.org/show_bug.cgi?id=53892)**
## Description
Created attachment 65902
PA alsa sink log.
Using PulseAudio (with a...## Submitted by David Lynam
Assigned to **pul..@..op.org**
**[Link to original bug (#53892)](https://bugs.freedesktop.org/show_bug.cgi?id=53892)**
## Description
Created attachment 65902
PA alsa sink log.
Using PulseAudio (with a null sink and loopback) as the audio input for ffmpeg causes severe distortion in the output after 20-40 seconds of encoding. This occurs in any case, i.e. while recording video (x11grab) or simply dumping to a .wav file.
The ability to record/stream should be equivalent to Xsplit/FFsplit on Windows: the latter uses ffmpeg and is mostly smooth.
Additional info:
Linux 3.4.8-1-ARCH #1 SMP PREEMPT
pulseaudio 2.1-1
alsa-lib 1.0.25-1
alsa-utils 1.0.25-3
ffmpeg 1:0.11.1-1 and N-43565-gaec9390
pavucontrol 1.0-1
The same problem is experienced by at least one other person: http://www.linuxquestions.org/questions/linux-software-2/pulse-audio-module-loopback-distortion-942066/
Steps to reproduce:
Set up a null sink and loopback monitor of sound card output to the sink. Run ffmpeg (-i alsa -f pulse) and use pavucontrol to direct the monitor of the null sink to ffmpeg.
Open the output file or view the stream (if streaming); around 30 seconds into the video, sound will suddenly contain loud glitches, distortions and increases/decreases in speed and pitch.
Workaround:
Modifying /etc/pulse/default.pa to re-enable interrupt-based scheduling (load-module module-udev-detect tsched=0) seems to alleviate the distortion problem but also increases CPU consumption and makes sound unusable in Wine.
Variables which have been tinkered with to no avail:
(PA) real-time priority
(PA) high priority
(PA/ffmpeg) sampling rate
(pavucontrol) muting different inputs, outputs, removing microphone/USB headset
(ffmpeg) building from git
(ffmpeg) changing audio encoding, trying every thread value from 0-6 (6-core CPU)
**Attachment 65902**, "PA alsa sink log.":
[everything.log_alsa-sink](/uploads/76a59a0b577a314d67c100405a41d17c/everything.log_alsa-sink)https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/146Channels are swapped when mixing two stereo streams2018-07-30T09:58:51ZBugzilla Migration UserChannels are swapped when mixing two stereo streams## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#53206)](https://bugs.freedesktop.org/show_bug.cgi?id=53206)**
## Description
I played two songs (stereo audio) simultaneously, one wit...## Submitted by Tanu Kaskinen `@tanuk`
Assigned to **pul..@..op.org**
**[Link to original bug (#53206)](https://bugs.freedesktop.org/show_bug.cgi?id=53206)**
## Description
I played two songs (stereo audio) simultaneously, one with the left channel muted and one with the right channel muted. I listened with headphones, and the one that should have played to the left ear played to the right ear and vice versa. One of the songs was shorter than the other, and when the shorter one ended, the longer song jumped from the right ear to the left ear.
The symptoms suggest that the mixing code is broken: it swaps channels. With two streams active the channels are the wrong way around, but with only one stream the channels are right.https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/519unrecognized tv tuner card causes distorted sound2018-07-30T10:35:08ZBugzilla Migration Userunrecognized tv tuner card causes distorted sound## Submitted by alex
Assigned to **pul..@..op.org**
**[Link to original bug (#53021)](https://bugs.freedesktop.org/show_bug.cgi?id=53021)**
## Description
the sound is distorted after I installed an old tv tuner card (sadly I don'...## Submitted by alex
Assigned to **pul..@..op.org**
**[Link to original bug (#53021)](https://bugs.freedesktop.org/show_bug.cgi?id=53021)**
## Description
the sound is distorted after I installed an old tv tuner card (sadly I don't the model). It is from an acer apire e380.
I get an error message when I boot:
Unknown header type 7f. Ignore device
You don't have noise until you play a sound.
My theory is that if device information and block devices in /dev are inconsistent the bug appears