The end problem is that Pulse/pipewire insists on sending output to a device named pro-audio1. It will give me no other choice.
With another setup, I have had a device named pro-audio, which has worked.
I do not know where it is getting this pro-audio1.
I have seen the name before in the pulseaudio mixer tool, and it has never worked as an output.


I have written my audio conf tool to reconfigure ALSA, pulseaudio, and pipewire.
It seems to work.

For this instance I am using the ALSA DMIX, pulseaudio disabled, pipewire enabled.
My tool invokes the pipewire script at /usr/sbin/pipewire-enable.
I have verified that pipewire daemons are running, and that pulse autostart is disabled, and that pulse client.conf has the autospawn=no.

I have verified that I can run two instances of audacious, playing different songs, and hear them both. That would be the DMIX working.

If I start dragon player, I can see the audio playing using the pulseaudio mixer volume-control tool. However, the output is going to pro-audio1, which is off into some mystery device that does not lead to my headphones.

The pulseaudio mixer control configuration shows two devices (HDMI and Built-in audio).
The HDMI is set to off, as nothing is connected to that.
I set the "Built-in audio" device to "Pro Audio". That is what has worked before. Every other choice is either an input, or some output that is not connected to anything.
But it only gives me pro-audio1 as the only choice in the output-devices screen.

For one brief interval, I had sound come through PulseAudio, but I had to do more work on the audio configure tool, which necessitated running it and testing more.
I do not know what mis-configuration was letting PulseAudio work. It was a mis-configuration because at that time it was supposed to be enabling pipewire.
For what the tool is supposed to do, it has done it correctly (finally).
It uses the Slackware pipewire-enable script if it can.

I had this same problem when I had an audio setup with ALSA redirect through Pulseaudio, which was identical to what is shipped with Slackware. In that case it presented me with three output device choices, only 1 that worked, and 1 that was a bogus device. The third choice is the HDMI output on my audio, which is not connected to anything. That setup had other problems too.

So anyone got any clues as to where pulse/pipe is getting these mystery devices.

There are configure files in /usr/share/pipewire, but I don't think they do anything until they are copied into /etc/pipewire.

I have heard blame aimed at
I don't know how that can detect extra devices just because the pulse and pipewire are configured differently.

In my /proc/asound, I have the following:
card0( pcm0c, pcm0p, pcm1c, pcm1p, pcm2c ), id=SB
card1( pcm3p ), id=HDMI

>> alsmixer
shows 2 devices
HDA ATI SB
HDA ATI HDMI
It has front-mic, rear-mic, and Line inputs (capture devices).
There is an SPIF optical output, which is unused.

pcm0p/info
pcm1p/info
So anyone got any clues as to where pulse/pipe is getting this mystery device,
or how to find out what has happened to the pro-audio output.

The pavucontrol has crashed again. I had tried enabling the HDMI too, because that gives an additional menu to select between them.
I had disabled the built-in, and enabled the HDMI. Then set it back to normal again.
When I tried enabling an HDMI output, the pavucontrol crashed. Now, itt crashes every time I try to restart it.
This has happened before too.

===========
I finally got the pavucontrol to work again.
I forced it to various tab screens, until I found one that would work.
>> pavucontrol --tab=2
This brought up a blank outputs screen. I switched to configuration screen, and then back to outputs screen again, and it was now normal (showing both the HDMI and pro-audio1 outputs).

Hello selfprogrammed,

I had the same problem as you

- server alsa
- plugin pulse audio
- motherboard realtek audio chipset used in /etc/asound.conf
- cpu audio chipset not disabled in bios

Problem:
when i was listening to music with firefox, firefox would start a pulse audio server with the cpu audio chipset.
ffplay and mpv worked fine and used /etc/asound.conf

solution:
-disabled cpu audio chipset in bios.
or
-.....

1 members found this post helpful.

I do not have firefox running during these problems.
I have played music using firefox, while searching music sites, and it has worked.
If you are saying that I can disable the cpu audio chipset in the BIOS, and the Linux sound will still work, then thank you for that information.
I may try that.
However, due to the way this problem manifests, and changes every time I configure the audio differently, it must be something in Linux or Pulse/Pipe.
If it is interacting with something in the BIOS, that would require difficult investigation.
However, again, ALSA has never had a problem. This is entirely a problem with PulseAudio and Pipewire. I don't know how they could interact weirdly with the BIOS, while Audacious is playing music perfectly find through ALSA. It is SDL sound, that uses Pulse, that I need to get working, reliably. And also other programs.

I have had variations on this same problem when the setup was sending ALSA audio through PulseAudio. At least then PulseAudio showed one device that I could use.
Why when ALSA is configured with DMIX, does PulseAudio suddenly not be able to recognize the most useful sound device, but finds useless ones.

1 members found this post helpful.

I have been experimenting, but have been getting mixed results, and taken down false paths.

At this time I have:

1. Had more than one Audacious playing using ALSA, because of DMIX. This has worked reliably for weeks, during all the other testing it has be fully reliable.

2. Have tried Pipewire for weeks, and it would not show any audio device that I could use.

3. I turned off Pipewire and tried PulseAudio.
I verified that the tools did the proper enable/disable.
PulseAudio shows a DIFFERENT failure than Pipewire, HDMI is mostly gone, and the built-in audio has no selections.
ALSA still works, and PulseAudio does not.

4. Dumps of Pipewire and PulseAudio info are mixed.
They do not show any USABLE devices in any listing.

5. pa-info
Shows the devices do exist, and PulseAudio can see them, but that some other program has a file open.

6. Kill every other program that uses audio, and kill timidity.
Kill the audio players
Kill the PulseAudio daemons.
Upon starting Dragon player, it started a PulseAudio daemon, and it seized ALSA. I got output devices in pauvcontrol, and when I selected the analog device everything PulseAudio could play sound.
This is using the SAME config as before, just without any other programs opening files on ALSA.
This is in spite of ALSA DMIX explicitly allowing multiple open files on the output ports.

7. Now Audacious will not work using ALSA, as there is an error trying to open the ALSA pcm device. This is in spite of having DMIX running which explicitly allows multiple simultaneous open streams.
PulseAudio is somehow blocking the normal ALSA traffic.
Even killing the Pulse programs and daemons would not clear this blocking.

This will require writing a patch to PulseAudio.
I suspect at this point, that PulseAudio is sabotaging other access to ALSA, just to ensure that it is the only mixer that can work.

I have the source code, but it is very hard reading, and worse for tracing dataflow.
I have no expectations that anyone has gotten this far into diagnosing the PulseAudio problem before, so I will be alone in doing this.

It is finally beginning to look like it won't be long at all before we can wave bye-bye to Pulse. Pipewire really is chipping away at pulse and only a very few bits are still required, the number of which depends on your pipewire version. If you are involved in digital audio to any depth or having any problems I suggest at least trying to build the newest version of Pipewire you can manage. Slackware Current is on v-3.80 and it's VERY good. Even v-3.79 is a massive improvement over v-3.70.

If you keep a copy of your stock version you can always go back if for any reason "upgradepkg" doesn't work for you going up to a newer version. one of the really thoughtful accommodations in Slackware is that the same command can also downgrade a package to a former version.

1 members found this post helpful.

I tried Pipewire first, but PulseAudio was the first one I had some success on.
They are so close to the same thing. Pipewire seems to be PulseAudio with Video control added, and a rework of its code.
I keep calling it PipeAudio.

PulseAudio has caused more problems, I would like be rid of it, and Pipewire has been promising as a replacement.
But, I have not been able to get it to cooperate.

The supporters talk of how great PulseAudio is supposed to be, and later Pipewire. I have not heard from any of the regular supporters on how to configure either of them to not screw this up.
With all the rules and configuration, you would think that there was some way to make it work with DMIX, without having to modify code.
My having to disable some of the Pulse/Pipe usage, does not sit well and is not the standard configure, so my actions are cursed instead.
Those who are in the same situation as I am, where Pulse/Pipewire screws up an established audio setup, understand.

Now, If I saw any "Latest Changes" from Pipewire, that covered in any way, making Pipewire more compatible with other ALSA programs, and DMIX, then I would jump at using the latest Pipewire. I can follow only one path at a time, and I am stealing time from several other things that really need to get done NOW, to do this as it is. That Pulse/Pipe is again being the PROBLEM, is not improving my attitude towards them.

I need timidity. Substitutes do not provide the same sound.
ALSA and timidity work perfectly together, it is Pulse/Pipe that get weird, even though they should not be affected.
None of the other programs the use ALSA are affected by timidity.

So, for the time being, I must look for the most immediate temp solution, or at least actions that are most certain to gain understanding and progress.
Even if they are ugly solutions.

I will probably have to work up fixes for both PulseAudio and Pipewire.

Thank You for your attention.

A common finding with both PulseAudio and PipeWire is that if your screen is connected to the computer by HDMI or DisplayPort, then the audio device in the screen or graphics card will be detected and set to be the primary audio output device. From the description of your symptoms, this would seem to be a rational explanation.

There is a ton of information about this on the internet, eg: https://wiki.archlinux.org/title/Pul..._configuration

Failing that, the rest of the ArchWiki has a lot of information about PulseAudio and how to configure it, troubleshoot, etc:

https://wiki.archlinux.org/title/Pul...roubleshooting

https://wiki.archlinux.org/title/PulseAudio

Some commands and examples are Arch-specific, but not difficult to translate into Slackware commands.

This may not have been an issue with Slackware 14.2, because perhaps the kernel used by 14.2 did not support that particular piece of hardware.

One question: Are you running a full installation of Slackware?

I have found the problem with PulseAudio by looking through its source code.

PulseAudio has a function "is_card_busy", which if it returns true that audio device is removed from the available devices until an inotify event signals them to look at it again.
The function "is_card_busy" looks at (in my case) "/proc/asound/card0/pcm0p/sub0/status".
If it finds that the status is NOT "closed", then the function returns that it is busy.

This is a BAD assumption because ALSA can handle multiple streams. It is explicit that DMIX can handle multiple open's on its device.

Test steps:
1. I looked at my /proc and saw that "timidity" was owner of the pcm0p, according to "/proc/asound/card0/pcm0p/sub0/status".
2. I started Audacious with output directed to ALSA, and the owner was still timidity. Audacious was playing music clearly and without problem.
3. I killed timidity, and the owner pid of pcm0p was still timidity. I double checked that timidity was actually gone.
So, that ALSA pcm0p owner pid is only set when the open is from a non-open state.
4. When I closed Audacious, THEN the pcm0p/sub0/status changed to "closed".
5. When I started Audacious again, the pcm0p/sub0/status got an owner id of that Audacious.

This PulseAudio test for busy is wholly inadequate in determining if the SINK can actually be used. It cannot cope with ALSA, and was wrong from the conception.
Having timidity running with its SINK being pcm0p does not block any OTHER program, example Audacious.
But if PulseAudio sees that proc status, it will remove pcm0p from the list of available devices.
With ALSA DMIX, that status does not actually indicate that the pcm0p device cannot be used by PulseAudio as a SINK.
This is the cause of much of the problem with PulseAudio vrs ALSA.

The automatic ALSA mixer usage would be the same, but without any explicit config of DMIX.
This is a problem with PulseAudio limiting it's port concept to those which can have only one user.
ALSA is more capable than that, and it is the limited PulseAudio concept of busy that is the problem.

It will take a while to figure a code change.
This cannot be fixed by configuration. There would need to be some PulseAudio setting that skips "is busy". I have not found any.

I am highly suspicious that the PulseAudio camp has known of this for years.
How could they not have found out what was causing the conflict with ALSA. With all the complaints, was there not enough incentive. I found it in a few hours of searching (over two days) and I had never seen that code before.


==== rkelsen
After that reply about how insulted you were that I had problems like this that I was debugging alone, what is this.

During the past several YEARS of trying to fix PulseAudio, I have found multiple how-to PulseAudio on the internet, none of which really gets beyond noting that PulseAudio ties up the whole ALSA device, and that is a great problem. I probably downloaded those months ago, maybe last year.

I do not use HDMI nor DisplayPort.

My Slackware 14.2 installation uses this Audio device more reliably than Slackware 15 because more of the programs are pure ALSA, with fewer PulseAudio programs causing problems.
I could disable PulseAudio and not suffer very much.
I am still using the Slackware 14.2 installation for that work, because it works, with that Audio device.

There are no signs that PulseAudio is missing anything. I customize my installation. That is the whole point of Slackware installation flexibility.
I wrote a Slackware dependency checking tool which can be read about in another thread.

This thread is a follow-on to a previous thread, where we tried to get PulseAudio or Pipewire to work in the Slackware Distribution setup with ALSA redirected to PulseAudio.
It was a failure, as it could not tolerate timidity starting at boot time.
This thread will NOT rehash those conclusions. Everybody had a chance to contribute in that thread.

Insulted? No, I wasn't... but I am now.

"What is this?" It's the solution to your obvious problem... But you clearly don't want to hear it from me.

So, goodbye & good luck. I'll not bother you anymore.

Good work selfprogrammed. This really does show that pulseaudio was programmed with one configuration/distro in mind. I do think there are going to be more examples of this in the code that pulseaudio assumes it is fully in control of everything. I wonder what bugs are being exposed with pulseaudio being emulated through pipewire. Also, because pulseaudio is kind of going away, I'm not so sure how well it is going to be maintained at this point. I am thinking at some point to build a dedicated machine for testing all the audio apis. (pipewire doesn't work correctly in a vm) I want to dig into the pulseaudio code to see once and for all if it is fixable, and that all the audio apis can work together, or what is coming just will make the situation worse. Maybe I can throw timidity on there as a test app.

I haven't had the pulseaudio-grabs-entire-sound-device problem since switching to pipewire. (It's a common thing, if you do any kind of audio work and forget to suspend pulseaudio first.) Hopefully we'll be to the point where pulse goes the way of HAL and other forgotten projects.

2 members found this post helpful.

It should be noted that Pipewire on Slackware v15.0 is only version 0.3.44... is a pretty long way yet from 1.0. On Current as of this month, about 3 days ago actually as of the time of this post to be precise, Pipewire is now version 0.3.80. I have a Current system on one partition of my Main and my daily driver is v15.0. I've built pipewire v 0.3.70 on my daily driver and there is a fairly massive improvement between each revision.

On my systems with v 0.3.80 and including pipewire-alsa, pipewire-pulse, and pipewire-jack everything is finally "just there" and at very decent latency levels (almost an order of magnitude better than pulse measured round-trip) even for very serious DAW work. Even at this beta stage, pulse is thankfully nearly non-existent now. Unfortunately it is still a bit of a mess on stock v15.0, but there is the proverbial light at the end of a too long, too dark tunnel.

4 members found this post helpful.

this is only to know if the problem really comes from pulseaudio and not from alsa 1.2.xx
https://freedesktop.org/software/pul...io-12.2.tar.xz

https://www.freedesktop.org/wiki/Sof...io/Notes/13.0/
release notes
Automatically switch away from unavailable card profiles
"avoid_resampling" also tries to avoid format conversion if the ALSA device supports it

Update on progress:

I patched the pulseaudio code that checks for busy, and also instrumented it to see what it was doing.
PulseAudio bypassed my patched code, as it verified that Control0, and Control1 were accessible, which they were.
There is considerable code in PulseAudio to test those /proc/asound card status, then in the actual test run the logs show that it never executed that code.

At this point, I am getting the feeling that I have done all this before (maybe 5 years ago).

It took most of a day to figure out how to get PulseAudio logs to actually work (it requires defeating autospawn).
But, these cannot be trusted, and you will get logs where pulseaudio did not start, or detected that it was already running.
>> killall pulseaudio
>> pulseaudio --start --log-level=debug --log-target=newfile:/tmp/pas.log -v -v

OR

>> pulseaudio -k --start --log-level=debug --log-target=newfile:/tmp/pas.log -v -v
(not reliable either, as pulseaudio will abort at ANYTHING, like not finding an existing pulseaudio to kill)


I have determined the following:

1. That setting debug and logging in config files does not work.
1a. I set the extra-arguments in /etc/pulse/client.conf, and they were ignored.
1b. I set the --log-level and --log-target in /etc/pulse/daemon.conf, and that was ignored.

2. That audacious and xmms and aplay can all simultaneously play music using ALSA.
How they accomplish this was difficult to determine. Examination of code did not reveal anything different than what PulseAudio used to check devices.

3. If the PulseAudio code was modified to ignore the busy returned by snd_pcm_open, then PulseAudio would shut down at the next ALSA operation, when it got an err return from configuring the hardware. The busy has a real effect and cannot be ignored.

4. I used ALSA test program (ALSA_example__test_pcm.c), that tests ALSA devices with a generated tone.
When given the same devices that I got from the PulseAudio log, it also COULD NOT open those sound devices (they were busy).
These were "hw:0,0", "plughw:0,0", "front:0,0".
These devices all lead ALSA to open /dev/snd/pcmC0D0p, which was busy (by timidity, among others).

5. The device that works is "default". That device does not become busy.
It appears that xmms explicitly uses "default".
I assume that audacious does too, but could not track down how audacious does anything device related, it is a confusing C++ mess.

In my /etc/asound.conf, the "default" device is declared with a slave DMIX.
This was the suggested way to get DMIX to work.

6. By logical determination, the culprit for the busy is the Linux file access, which will "busy" any ordinary sound device that has been opened.
Any mixer, PulseAudio, or any other player, that opens an ALSA sound device, will busy it, and prevent it being opened by any other snd_pcm_open call.
6b. If an ALSA virtual device, that is a front for DMIX, is opened, it will not busy.
There is more verification to be done here, but that requires more examples to work with.

7. Conclusion: The immedidate fault of PulseAudio is that it does not use "default", so the user never gets the one choice that would work the same as XMMS and Audacious.

8. Conclusion: The sound device locking by Linux file access can only be avoided by using ALSA virtual devices, like "default".
The automatic mixer that is available for SOME sound cards, may mask this for those lucky users.
User testimonials that some PulseAudio setup works for them, are useless because of this.

Users with other sound cards, must avoid directly opening any sound device ALSA port, or else it will become "busy", and that will block any other program trying to use ALSA (like timidity blocking PulseAudio, or PulseAudio blocking Audacious).

9. There may be other ways to use DMIX. I have not discovered all the ways to use DMIX.

10. There may be other ways to configure PulseAudio. The PulseAudio card database could be altered to include "default" and other ports.

11. This may also be applicable to Pipewire. However, all my attempts to even find where it opens the sound devices has gone nowhere.
Cannot find a snd_pcm_open in the code, which may likely make it incompatible with any fixes that depend on those characteristics.
Pipewire shows some of the same behavior as PulseAudio, but that is not entirely identical.
My experience with this version Pipewire is that it is currently not much better than PulseAudio (just more opaque).
That they are working on it is promising, and they may find a different or similar solution, or it may also be very sound card dependent in that way that makes user testimonials completely useless.


My plan:
I will try modifying the PulseAudio code to test some more ALSA port names, and if they are found to be accessible, to offer them to the user so they can be selected as the SINK.
"default"
"pulse_default"

Also try the following, as prefix to all tested port names.
For example, "hw:0,0" will also try "pulse_hw:0,0" and "dmix_hw:0,0".
If a more specific port is found to be present and accessible then it will be used instead of the plain port name.

The user will have to declare the port name in asound.conf to make it present.
Thus, in asound.conf, the user can declare a "pulse_default", or a "pulse_hw:0,0" virtual device.
These can be declared to route to DMIX, or to route in other ways. Thus PulseAudio will have a device that will not busy, or a device that it can have entirely to itself.

Please scream, or otherwise comment now, to save time.