Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[Software] pulseaudio bursts of static and sound dropouts

Graphical Environments, Managers, Multimedia & Desktop questions.
Post Reply
Message
Author
FeralUrchin
Posts: 5
Joined: 2022-11-17 06:55

[Software] pulseaudio bursts of static and sound dropouts

#1 Post by FeralUrchin »

Hardware: AMD 8150 (8 core 64-bit); 16GB RAM; multi terabytes of storage. Software: Debian Bullseye 5.10.149-2 (10-22-2022); cinnamon desktop, pulseaudio 14.2-2, totem 3.38.0-2. Primary use: as video creation and editing workstation.

Symptoms:
1) When totem plays an MP4 file, episodically a balloon appears in the system tray with the message "Volume set at xx%". This percentage corresponds to the audio volume set manually in QasMixer. These messages appear randomly even though the QasMixer volume has not been changed since boot time, and always show the same unchanged audio volume percentage. For instance, if at boot time QasMixer audio volume is observed to be set at 28%, all subsequent notifications in the system tray report 28% volume. These balloon notifications are accompanied by a loud burst of static. These notifications and static appear non-reproduceably in my experience 0 to 4 times during playback of a 9 minute MP4 file. I can detect no circumstance in pulseaudio configuration or system particulars that explain or control these bursts of static. They occur even though there has been no manual audio volume change in QasMixer. QasMixer File/Settings allows me to kill the balloons notifications but not the concommittant bursts of static.

2) When totem plays an MP4 file, episodically the sound drops out, sometimes repeatedly and for several seconds. Again I can discern no environmental conditions which influence this behavior.

Attempted Fix (failed): set flat-volumes=no in /etc/pulse/daemon.conf. This was recommended in a somewhat similar pulseaudio post to prevent pulseaudio automatic volume changes.

Ultimate Fix (successful): The only way I have found to prevent these two show-stopping symptoms above is to prevent pulseaudio from running at all by 1) mv-ing /usr/bin/pulseaudio to /usr/bin/<expletive>audio, and either a) killing the running daemon or b) rebooting. Only when pulseaudio is not running and cannot be made to run will totem reliably and satisfactorily playback the MP4 file.
NOTE: totem functions normally (presumably using ALSA) if its attempted connection to the pulseaudio server fails.

Comment:
I'm aware that pulseaudio is a dependency of cinnamon (i.e. cannot be removed without also removing cinnamon), and that firefox and librewolf seem to require pulseaudio in order to produce sound. However, the egregious show-stopping problems caused by pulseaudio are far, far worse than any benefit offered by allowing pulseaudio to run on my video-creation-and-editing workstation. I'm also aware that pulseaudio has been around for many years. I don't doubt that its developers were bright people with good reasons for implementing a sound server as middleware to pure ALSA usage. Howver, I feel justified in observing that pulseaudio has aged without maturing due to its very serious lingering problems. Many others have written posts identifying difficulties in using it. In my opinion its presence in the Debian release should be felt as an embarrassment both to Debian and to the pulseaudio developers. Until recently it was possible to prevent pulseaudio from running by setting autospawn=no in /etc/pulse/client.conf. This user control has been taken away, pulseaudio is automatically started (and thereby shoved up all our noses) while making reliably pleasant playback of av files impossible.

I have three recommendations 1) remove pulseaudio from the Debian distribution altogether, or at a minimum make it possible to prevent it from starting, as before, by setting autospawn=no in /etc/pulse/client.conf (or similarly effective means to prevent, system-wide, pulseaudio from running; 2) require all sound-application developers to follow the totem developers' example; i.e. use ALSA when pulseaudio is unavailable; 3) investigate how the serious errors in judgment involved--in 1) the decision to include pulseaudio in Debian at all, and 2) force its initiation at boot time unconditionally--were possible. These circumstances, in my opinion, expose a major failure in Debian governance. In conclusion, many of us developers have found ALSA to be entirely satisfactory and we much prefer not being defeated in its use by middleware getting in our way.

tynman
Posts: 131
Joined: 2016-05-03 19:48
Location: British Columbia, Canada
Been thanked: 1 time

Re: [Software] pulseaudio bursts of static and sound dropouts

#2 Post by tynman »

I share your frustration with Pulseaudio, and I haven't used it for years. (I'm not a huge fan of alsa either - I find it very obtuse to configure - but it definitely works (for me) day in and day out.

One point though. Pulseaudio is not a default part of Debian. So I think your comments about Pulseaudio being an embarrassment to Debian, etc are unfair.

FeralUrchin
Posts: 5
Joined: 2022-11-17 06:55

Re: [Software] pulseaudio bursts of static and sound dropouts

#3 Post by FeralUrchin »

Thanks very much for your response. I'm glad to see additional confirmation that I'm not alone in being frustrated with pulseaudio. As to its inclusion in Debian, the Debian 11.1 release ISO includes Cinnamon (which seems to have pulseaudio as a dependency), pulseaudio itself, mechanisms within the kernel for unconditionally starting, stopping and restarting pulseaudio, and finally a recent disabling of users' ability to prevent pulseaudio from running (i.e. the autospawn option in /etc/pulse/client.conf). It's for these reasons that I blame Debian for the egregious mess pulseaudio creates for users of the Debian 11.1 distribution. As I see it, Debian 11.1 / Cinnamon should not require pulseaudio to be installed, and if installed should enable the user easily to block pulseaudio execution, and should expect audio developers to write code falling back to ALSA if pulseaudio is unavailable (i.e. should behave in this respect like totem and not like Firefox, Librewolf etc that simply fail to produce sound if pulseaudio is unavailable.

Thank you again for your response.

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 times

Re: [Software] pulseaudio bursts of static and sound dropouts

#4 Post by sunrat »

You should be able to mask PulseAudio from starting by masking its systemd service.
If it was universally as bad as you seem to be experiencing, it certainly wouldn't be installed as default for most desktop environments. You should check log files and journalctl for error messages.

I have used PA over a few releases of Debian, using KDE Plasma desktop, and have no serious issues with it. Currently I run JACK as default audio server on my desktop with PulseAudio running into it via PA to JACK sink module. My notebook runs default PulseAudio and again, no issues.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

User avatar
NorthEast
Posts: 349
Joined: 2018-11-18 04:35
Has thanked: 12 times
Been thanked: 30 times

Re: [Software] pulseaudio bursts of static and sound dropouts

#5 Post by NorthEast »

Debian looks like it's moving to pipewire in any case:
https://wiki.debian.org/PipeWire#Debian ... 2FUnstable

Personally I've had no trouble with pulseaudio on numerous machines. Reasonable testing of pulseaudio involves controlling for a number of possible confounding variables, which include the computer, the applications and the user. Sample size n=1 has issues.

FeralUrchin
Posts: 5
Joined: 2022-11-17 06:55

Re: [Software] pulseaudio bursts of static and sound dropouts

#6 Post by FeralUrchin »

Thanks to both tynman and NorthEast for their thoughtful responses. I'm going to rant a little bit below, and absolutely none of it is directed toward the two of you.

I now confess to being somewhat unforthcoming in deliberately neglecting to mention that I have written a video editor, editAV, beginning about a decade ago, which immediately ran afoul of pulseaudio. For me a central challenge in writing software that plays both video and audio streams--is to keep them synchronized. In other words--to ensure that during playback movement of lips and musical instruments is accurately timed to the sounds they produce. editAV contains code that meticulously maintains synchronization providing pulseaudio is not running. Pulseaudio entirely destroyed video-audio synchrony by introducing several seconds latency in the audio during playback. I quickly learned, around ten years ago, to set autospawn=no in /etc/pulse/client.conf to prevent pulseaudio from running. Everything was wonderful until recently when the geniuses at Debian removed this simple means of preventing pulseaudio from running. In desperation I recently added pulseaudio support to editAV in which editAV falls back to ALSA if connection to pulseaudio fails.

I chose not to mention this before because in the past when I used my own product (editAV) as an example of the mischief caused by pulseaudio, the self-styled "support team" at Mint jumped down my throat blaming me for any problems I might be experiencing, and at the same time denying that such problems could possibly be experienced by anyone else. So instead I mentioned problems I was experiencing with a pure up-to-date Debian distribution; i.e. with totem vs pulseaudio instead of editAV vs pulseaudio. [I have today discovered that identical problems exist with mplayer also.] So, with totem and mplayer being made dysfunctional by pulseaudio--again in a pure up-to-date Debian 11.1 environment--I feel safe in admitting that my own product is similarly made dysfunctional by pulseaudio. When I hide the pulseaudio binary (e.g. by changing its name) from the kernel and its allies, all these programs function normally.

In a further attempt to convince anyone reading this of my bonafides, I will attest that I have worked as both a system- and application-level software developer for well over half a century. Inexplicably I still seem to be of a somewhat sound body and mind at 81 years. I have worked both as a contractor and permanent employee at Microsoft, where I earned a reputation as a "moderately heavy-hitter". I have contributed a number of open source projects to sourceforge targeting both Microsoft and Linux platforms. One of them, a photo editor and archive manager (cim and manageImages) was downloaded over 1,000 times in a single day. Another provided a front-end DML tool for MSDE thereby offering users a copy of MS SQL Server for free (I'm proud to say that this contribution cost MS around a million dollars in gross revenue). I also uploaded an earlier version of editAV, which was downloaded several thousand times.

Be aware also that I'm not alone in being frustrated by pulseaudio. User complaints are easy to find in various forums. In one of them, an exasperated user asked "Who is willing to put up with this garbage?" Doubtless my views on pulseaudio would be more moderate had someone explained to me what real-world problem it solved or what valuable service it performs. In my ignorance of any benefit provided by a server/middleware program that destructively intervenes between me and ALSA, I'm happy to continue fulminating.

As I see it, ALSA works perfectly fine as is. Interposition of a "sound server" between it and developers is a solution in search of a problem. Furthermore, preventing users and developers from disabling its execution reflects noteworthy ignorance and arrogance on the part--not only of pulseaudio's developers--but also on the part of those who govern the Debian distribution. Lastly, the quality of the pulseaudio product--after ten or more years since its introduction--is just appalling given its lingering problems and dissatisfied users.

Debian, of course, will continue to hide behind its hardened rampart, "community support". The pulseaudio (and pipewire) developers will likewise make themselves scarce from any developer criticism. And those users who maintain a "see no evil, speak no evil, hear no evil" outlook toward the concept of a "sound server" are like mindlessly contented Germans in 1933. To all these I offer my testament and benediction: "F***k you all."

Post Reply