Bug#1082772: More info on sound crackling issue
Hello, I've got some additional info to report with my problem. First, as a status update, nothing has significantly changed for me. I'm still getting usually infrequent and light crackling and at times very frequent and heavy crackling. I've not been able to identify what variable is in play here. Second, I have another possible temporary workaround. This is tricky because of the intermittent nature of the problem but it does appear that in addition to restarting the pipewire-pulse process that restarting an individual application suffering from audio crackling can also temporarily resolve the crackling issue though it may take a few restarts in a row to get there. Third, I realized that way I listed the source of the builds for the packages I've experienced the issue with was non-optimal. Here is a less ambiguous report of packages and where they came from: - stable: firefox-esr, vlc, jackd2, linux-image-amd64 - stable-backports: pipewire, telegram-desktop - winehq: wine-devel (Wine project official Debian builds) Considering REAPER, wine-devel, and Proton Experimental are software that is compiled outside of the Debian build system, or in the case of REAPER and Proton Experimental I suspect without any Debian specific build process or helpers at all, I think this demonstrates that the audio clients themselves are not the problem for any Debian specific reason. I also know of another user running Debian 12 that is suffering from the same intermittent crackling issue. His problem showed up about 3 weeks ago but otherwise his description of the issue sounds just like mine: intermittent, sometimes light, sometimes heavy. though he has more luck with getting the problem to stay away by running an older kernel build (linux-image-amd64-22 as I recall). Possibly related, I also know another user that is running Ubuntu 18.06 who said they started experiencing audio crackling also around the same time I did. I checked with them and they are using PulseAudio and not pipewire. On one hand this appears to be kernel related but on the other hand, for myself personally, I am not experiencing any audio issues when applications are using the ALSA interface themselves or when using jackd2. It's all certainly very odd.
Bug#1082772: pipewire: Intermitent light to heavy audio crackling for applications using pipewire-pulse or pipewire-jack
Package: pipewire Version: 1.2.4-1~bpo12+1 Severity: important X-Debbugs-Cc: cardboardaardv...@gmail.com Dear Maintainer, Starting around July or August 2024 I started getting routine but mild crackling out of my speakers. This lasted for several weeks and then went away on it's own. Starting around two weeks ago (approximately September 10, 2024) the crackling returned with a vengence. The most recent symptoms include anything from very mild crackling every few minutes to heavy crackling occuring constantly. Some times the crackling begins immediately upon rebooting my system or restarting pipewire-pulse and some times it can take up to 12 hours for crackling to occur. There is a correlation between system load and how frequently the crackling shows up and how severe the crackling is. During my testing today I used this command to place my system under load resulting in load averages around 40 and most of the CPU time being spent in the kernel: while true; do echo loop; (find /usr -type f | xargs -P 500 -I % -exec cat "%") > /dev/null; sleep 1; done I've experienced this crackling with: * Firefox ESR from apt * VLC from apt * Telegram when playing audio notifications, installed from apt * Foobar2000 running under wine-devel from apt * Skyrim running under Proton experimental from Steam * REAPER with Jack Audio output selected using pipewire-jack as the audio backend The problem does not appear to occur when using REAPER with ALSA selected as the audio backend. As well REAPER using jackd2 from apt does not appear to have this problem. I've been unable to confirm that VLC when using the ALSA backend does not crackle as VLC fails to open the ALSA audio device when I try. In general it has been challenging to find other programs to do more extensive testing because so much stuff now assumes PulseAudio will be available. REAPER in ALSA mode runs itself using realtime scheduling priority. Jackd2 is also running with realtime scheduling priority. As best I can tell pipewire and pipewire-pulse should be running itself with realtime scheduling priority but I don't know how to confirm this is actually happening. REAPER using ALSA and jackd2 delivers reliable audio during my testing even when I experience X GUI pauses exceeding several seconds. REAPER using pulsewire-jack and the other applications using pipewire-pulse will start crackling even when there is no appreciable load on the system. When running the find/xargs load generator the applications using pipewire-pulse and REAPER using pipewire-jack go into extreme levels of crackling to severe distortion. I've used the same media playing inside Firefox, VLC and REAPER to ensure the audio crackling is not present in the source material. As well at this point I'm fairly confident the bug does not originate with the kernel since REAPER using ALSA and jack2 has proven reliable. However I have tested different stable kernel releases and the backports kernel and there appears to be some correlation to kernel releases in the stable branch. Using the backports kernel (6.10 series at this time) does not appear to change the behavior at all compared to the 6.1.0-25-amd64 kernel build from stable. Likewise, using 6.1.0-23-amd64 does not appear to change the behavior. In my testing today using 6.1.0-17-amd64 resulted in much worse audio crackling that the beforementioned kernels. But then also 6.1.0-17-amd64 would have been the kernel I was using in the past well before I ever experienced the audio crackling. I'm pretty sure when I was running 6.1.0-17-amd64 and did not experience the crackling issue I was also using pipewire from backports however I've been unable to confirm this from the apt logs as they do not appear to have timestamps for the log entries. Usually, but not not always, I am able to temporarily resolve the crackling issue by running "systemctl --user restart pipewire-pulse" - specifically, earlier today when the crackling was very bad and very frequent doing the restarts did not help at all. At this moment, about 8 hours later, the audio crackling from Firefox is light and infrequent, and I just performed a restart and it has not resolved the issue. I have previously tried increasing the pipewire quantum to 8192 in an effort to prevent the crackling but it does not appear to have any effect at all. My first change was by running "pw-metadata -n settings 0 clock.quantum 8192" and later I modified the default pipewire.conf to set default.clock.quantum and default.clock.max-quantum to 8192 and that also did not seem to have any effect. I'm not sure what else I can do to test this, issolate the fault, or try to resolve the issue. If you have any thoughts please let me know. This issue is fairly annoying as my workstation's most frequent use case is for playing or editing multimedia. -- System Information: Debian Release: 12.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') A
Bug#874535: vmdebootstrap: BeagleBone Black example is not bootable on BeagleBone Black hardware
Package: vmdebootstrap Version: 1.7-1 Severity: important Dear Maintainer, I am highly interested in using Debian with my BeagleBone Black hardware but have run into an issue with vmdebootstrap: the provided example scripts will run with out error but do not produce a bootable image. I am able to reproduce this problem 100% of the time. Here are the steps I've taken (with logs from the session included below): 1. Execute /usr/share/vmdebootstrap/examples/beagleboneblack.sh with --image and --size options 2. Write the generated image to a microSD card 3. Boot the BBB off the microSD by holding the user button down at power on The serial output of the BBB includes output from uboot so the image is at least partially functional. What I observe is uboot outputting "Staring kernel ..." then a hang for approximiately 1 minute. After this delay it looks like the BBB reboots as the uboot output shows up on the serial port again. What I believe is happening is a watchdog is rebooting the hardware because the kernel has not loaded. What I do not think is the problem is the kernel has booted and is not using the serial device for the console. What I expected to happen is to run the example scripts unmodified and have a BeagleBone Black image that boots into a Debian operating system. At this time I haven't found anything that gets the BBB to boot with the image generated by vmdebootstrap. I can, however, boot the Debian installer but I can not get a bootable install from it either and I can't yet confirm the issues are identical. Here is the output from the session where I created the image and wrote it to a microSD card: tyler@happytime:~/tmp$ /usr/share/vmdebootstrap/examples/beagleboneblack.sh --image bbb.img --size 1G Creating disk image Creating partitions Using bootsize 100mib: 104857600 bytes Creating filesystem ext4 Mounting /dev/mapper/loop0p2 on /tmp/tmpZfQvdh Creating filesystem vfat Mounting /dev/mapper/loop0p1 on /tmp/tmpZfQvdh/boot/ Debootstrapping sid [armhf] Setting up binfmt handler Running debootstrap second stage Give root an empty password Removing udev persistent cd and net rules Enabling systemd-networkd for DHCP Enabling systemctl-resolved for DNS Running customize script /usr/share/vmdebootstrap/examples/beagleboneblack-customise.sh Updating the initramfs Optimizing image for compression Umounting /tmp/tmpZfQvdh/boot/ Umounting /tmp/tmpZfQvdh Changing owner to tyler Cleaning up tyler@happytime:~/tmp$ sudo dd if=bbb.img of=/dev/sdd bs=1M [sudo] password for tyler: 953+1 records in 953+1 records out 10 bytes (1.0 GB, 954 MiB) copied, 53.7612 s, 18.6 MB/s tyler@happytime:~/tmp$ and here is the output from the serial console attached to the BBB hardware showing two boot attempts though no manual reboot was made and no power cycle was performed. U-Boot SPL 2017.07+dfsg1-3 (Aug 04 2017 - 19:56:56) Trying to boot from MMC1 ** First descriptor is NOT a primary desc on 1:1 ** *** Warning - bad CRC, using default environment reading u-boot.img reading u-boot.img U-Boot 2017.07+dfsg1-3 (Aug 04 2017 - 19:56:56 +) CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 ** First descriptor is NOT a primary desc on 1:1 ** *** Warning - bad CRC, using default environment not set. Validating first E-fuse MAC Net: Could not get PHY for cpsw: addr 0 cpsw Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt 755 bytes read in 6 ms (122.1 KiB/s) Loaded env from uEnv.txt Importing environment from mmc0 ... Running uenvcmd ... reading vmlinuz-4.12.0-1-armmp 3864464 bytes read in 251 ms (14.7 MiB/s) reading initrd.img-4.12.0-1-armmp 16194586 bytes read in 1027 ms (15 MiB/s) reading /dtbs/am335x-boneblack.dtb 35788 bytes read in 13 ms (2.6 MiB/s) ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 Using Device Tree in place at 80f8, end 80f8bbcb Starting kernel ... U-Boot SPL 2017.07+dfsg1-3 (Aug 04 2017 - 19:56:56) Trying to boot from MMC1 ** First descriptor is NOT a primary desc on 1:1 ** *** Warning - bad CRC, using default environment reading u-boot.img reading u-boot.img U-Boot 2017.07+dfsg1-3 (Aug 04 2017 - 19:56:56 +) CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 ** First descriptor is NOT a primary desc on 1:1 ** *** Warning - bad CRC, using default environment not set. Validating first E-fuse MAC Net: Could not get PHY for cpsw: addr 0 cpsw Press SPACE to abort autoboot in 2 seconds switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 reading boot.scr ** Unable to read file boot.scr ** read
Bug#762708: nginx-common: Patch for configurable stop schedule and new graceful-stop command in init script
> > Also, jessie ships with systemd by default, and systemd doesn't support > custom commands. So, it's not a good plan to divert the initscript from > the service file. Awesome signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#762708: nginx-common: Patch for configurable stop schedule and new graceful-stop command in init script
> I think that gracefully stopping nginx is a better default the forcibly > stopping the process. I certainly don't - both cases have uses. Please do not force sysadmins to wait for end user behavior *by default*. When I want end users to be able to influence my reboot time I'll specify a specific command. The default should not be to extend reboot time defined by the activity of people external to the system and this is what you have done by converting to graceful shutdown by default. You've reduced the functionality of this patch and decreased the utility of init. Why are you attempting to optimize for reduced command count? Tyler On Oct 8, 2014, at 5:47 AM, Christos Trochalakis wrote: > On Wed, Sep 24, 2014 at 09:21:15AM -0700, Tyler Riddle wrote: >> Package: nginx-common >> Version: 1.6.2-1 >> Severity: wishlist >> Tags: patch >> >> Dear Maintainer, >> >> When clustering nginx behind a load balancer it is useful to take the listen >> socket offline while allowing connected clients to finish their requests >> with out error. The included patch allows for a graceful-shutdown command >> that >> makes this trivial. Both the graceful schedule and the original stop schedule >> can also be defined in /etc/default/nginx for end user customization. >> > > I think that gracefully stopping nginx is a better default the forcibly > stopping the process. So I changed the stop command to do exactly that, > and make the stop schedule configurable. That way we don't have to > introduce a new command at all. > > After your report, I took a closer look to the systemd service file that, > supposdly, did a graceful stop and discovered that was not the case, so > we fixed that regression as well. > > The relevant commits are: > > 8cbf89988 Fix systemd graceful stopping issue > ef90f5ebc initscript: gracefully stop nginx by default > > http://anonscm.debian.org/cgit/collab-maint/nginx.git/log/?h=graceful-stop > > I plan to merge this branch tomorrow, any comments are welcome! signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#762708: nginx-common: Patch for configurable stop schedule and new graceful-stop command in init script
Package: nginx-common
Version: 1.6.2-1
Severity: wishlist
Tags: patch
Dear Maintainer,
When clustering nginx behind a load balancer it is useful to take the listen
socket offline while allowing connected clients to finish their requests
with out error. The included patch allows for a graceful-shutdown command that
makes this trivial. Both the graceful schedule and the original stop schedule
can also be defined in /etc/default/nginx for end user customization.
- BEGIN PATCH ---
diff -Nru nginx-1.6.2/debian/changelog nginx-1.6.2/debian/changelog
--- nginx-1.6.2/debian/changelog2014-09-17 01:20:11.0 -0700
+++ nginx-1.6.2/debian/changelog2014-09-24 08:50:58.0 -0700
@@ -1,3 +1,14 @@
+nginx (1.6.2-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Signal schedule used by stop command in init script is now configurable
+via /etc/defaults/nginx.
+ * Added graceful-stop command to init script which allows a configurable
+schedule to allow connected clients time to finish their request before
+the server goes fully offline.
+
+ -- Tyler Riddle Wed, 24 Sep 2014 08:46:41 -0700
+
nginx (1.6.2-1) unstable; urgency=high
[ Christos Trochalakis ]
diff -Nru nginx-1.6.2/debian/nginx-common.nginx.default
nginx-1.6.2/debian/nginx-common.nginx.default
--- nginx-1.6.2/debian/nginx-common.nginx.default 2014-09-17
01:20:11.0 -0700
+++ nginx-1.6.2/debian/nginx-common.nginx.default 2014-09-24
08:50:58.0 -0700
@@ -3,3 +3,9 @@
# Set the ulimit variable if you need defaults to change.
# Example: ULIMIT="-n 4096"
#ULIMIT="-n 4096"
+
+# Define schedules for quickly and gracefully stopping
+# the server; see the start-stop-daemon --retry documentation
+# for more information
+#STOP_SCHEDULE="TERM/30/KILL/5"
+#GRACEFUL_STOP_SCHEDULE="QUIT/20/TERM/5/KILL/5"
diff -Nru nginx-1.6.2/debian/nginx-common.nginx.init
nginx-1.6.2/debian/nginx-common.nginx.init
--- nginx-1.6.2/debian/nginx-common.nginx.init 2014-09-17 01:20:11.0
-0700
+++ nginx-1.6.2/debian/nginx-common.nginx.init 2014-09-24 08:50:58.0
-0700
@@ -58,8 +58,11 @@
$DAEMON -t $DAEMON_OPTS >/dev/null 2>&1
}
+# See http://nginx.org/en/docs/control.html for documentation
+# on nginx and signal behavior
+
#
-# Function that stops the daemon/service
+# Function that quickly stops the daemon/service
#
do_stop()
{
@@ -68,7 +71,33 @@
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
- start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PID
--name $NAME
+ if [ "$STOP_SCHEDULE" = '' ]; then
+ STOP_SCHEDULE="TERM/30/KILL/5"
+ fi
+
+ start-stop-daemon --stop --quiet --retry="$STOP_SCHEDULE" --pidfile
$PID --name $NAME
+ RETVAL="$?"
+
+ sleep 1
+ return "$RETVAL"
+}
+
+#
+# Function that gives connected clients a chance
+# to finish their request before shutdown
+#
+do_graceful_stop()
+{
+ # Return
+ # 0 if daemon has been stopped
+ # 1 if daemon was already stopped
+ # 2 if daemon could not be stopped
+ # other if a failure occurred
+ if [ "$GRACEFUL_STOP_SCHEDULE" = '' ]; then
+ GRACEFUL_STOP_SCHEDULE="QUIT/20/TERM/5/KILL/5"
+ fi
+
+ start-stop-daemon --stop --quiet --retry="$GRACEFUL_STOP_SCHEDULE"
--pidfile $PID --name $NAME
RETVAL="$?"
sleep 1
@@ -140,6 +169,14 @@
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
+ graceful-stop)
+ [ "$VERBOSE" != no ] && log_daemon_msg "Gracefully stopping
$DESC" "$NAME"
+ do_graceful_stop
+ case "$?" in
+ 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
+ 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
+ esac
+ ;;
restart)
log_daemon_msg "Restarting $DESC" "$NAME"
@@ -201,7 +238,7 @@
log_end_msg $?
;;
*)
- echo "Usage: $NAME
{start|stop|restart|reload|force-reload|status|configtest|rotate|upgrade}" >&2
+ echo "Usage: $NAME
{start|stop|graceful-stop|restart|reload|force-reload|status|configtest|rotate|upgrade}"
>&2
exit 3
;;
esac
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#385077: php5-pgsql: Will not connect to PostgreSQL 8.1
Package: php5-pgsql Version: 5.1.4-0.1 Severity: grave Justification: renders package unusable The package will not connect to PostgreSQL 8.1; the connection fails with the following error: Warning: pg_connect() [function.pg-connect]: Unable to connect to PostgreSQL server: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? However, PostgreSQL is running and listening for connections; the PostgreSQL utilities, such as psql, connect with out trouble. The contents of /var/run/postgresql is: [EMAIL PROTECTED]:/var/run/postgresql$ ls -a .. .. 8.1-main.pid .s.PGSQL.5433 .s.PGSQL.5433.lock [EMAIL PROTECTED]:/var/run/postgresql$ As you can see, the filenames differ by a single number (5432 vs 5433). However, this bug makes the package useless for connecting to version 8.1 of PostgreSQL. System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages php5-pgsql depends on: ii debconf [debconf-2.0]1.5.3 Debian configuration management sy ii libapache2-mod-php5 [phpapi- 5.1.4-0.1 server-side, HTML-embedded scripti ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libpq4 8.1.4-6 PostgreSQL C client library ii php5-common 5.1.4-0.1 Common files for packages built fr php5-pgsql recommends no packages. -- debconf information: php5/extension_pgsql_apache2: true php5/remove_extension: true php5/add_extension: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330845: apache2: httpd.conf does not reference new and proper configuration file
Package: apache2 Version: 2.0.54-5 Severity: minor The httpd.conf file in /etc/apache2 only states that it has been replaced. It should state that it has been replaced by apache2.conf. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages apache2 depends on: ii apache2-mpm-prefork 2.0.54-5 traditional model for Apache2 -- no debconf information
