So, what's the current status of everything?

[Linux-SWAT]

Maybe ALSA can hold some kind of dummy buffer, allowing to route the stream on the fly with the help of some script/zenity/whatever ?

 

[elvissteinjr]

Every linked packages needs to be rebuild. There will likely be broken packages.

Isn't this the elephant in the room? Can't use the Debian repos for any application using Pulse then. I thought the point was to stay close to mainline and existing distros? Somebody will have to maintain that stuff.

 

[EvilDragon]

Rebuilding every package doesn't make sense, as not everything not compiled with NEON support or other optimizations would slow the system down noticeably.

We have our own repos and could do that with selected packages if need be.

But the again, there's not much to be maintained: If all that's needed is a recompile with different compiler options, this could be done automatically by a build server.

 

[Wrath Of Khan]

So current status is... we are pretty damn close. After ed has had a nice christmas break we can put him back to work 24/7... ok 24/6 or 24/5 or 24/1? Ok. 8/5...

 

[AndiTheBest]

Pulseaudio also will be important as it supports echo cancelation, for the phone function.

 

[levi]

Most applications including in my experience mplayer and deadbeef (not sure about vlc yet) can be configured to use different audio sinks, including alsa and pulseaudio. No rebuild required, just a configuration swap.

 

[netcat]

.. and we are totally happy to receive units with buggy software, its just the hardware that must work... plz confirm.

 

[Linux-SWAT]

Pulseaudio also will be important as it supports echo cancelation, for the phone function.

Here also we can avoid pulseaudio:

GitHub - voice-engine/ec: Echo Canceller, part of Voice Engine project

Echo Canceller, part of Voice Engine project. Contribute to voice-engine/ec development by creating an account on GitHub.

github.com

 

[wismerhill]

If, like me, you only have basic audio playback needs, you can use apulse to "force" programs that only support pulseaudio (like recent firefox) to send their audio stream directly to alsa, without the need for an actual pulse daemon.

 

[Letalis Sonus]

you can use apulse to "force" programs that only support pulseaudio (like recent firefox) to send their audio stream directly to alsa, without the need for an actual pulse daemon.

...which has some serious compatibility issues with certain Pulse-only applications that it was not specifically developed for.

Firefox does still support ALSA, you just need to perform some about:config magic to get it working again. It was never removed, but the newer sandboxing mechanisms simply lacked the required whitelisting entries for certain ALSA components. It should still work out of the box if you do not configure dmix, e.g. because you've got a sound card with a proper hardware mixer that accepts multiple audio streams. Firefox already has some whitelist entries for ALSA built-in like libasound.so, but things like dmix and LADSPA plugins need to be manually added to the whitelist.

 

[Linux-SWAT]

There's no magic in having a pulse-free system.
I use that everyday without any problem as only ~20 packages have to be replaced in Slackware, which officially and cleverly provides the alternative :
ftp://ftp.osuosl.org/pub/slackware/slackware-current/extra/pure-alsa-system/

And Firefox needed zero tweaking.

 

[Grench]

The way that I understand the differences, though:

ALSA has a fairly simple model.

Audio stream a \
Audio stream b  \
Audio stream c   >  ALSA = Single Output Stream
Audio stream d  /
Audio stream e /

All input streams are bitrate adjusted to match a singular output stream that can then be volume adjusted and output to one or more output devices. To have more than one output stream effectively requires multiple instances of ALSA. For most use cases this is real easy to understand and use as a the single 'user' wants to have effectively the same things locked in the same position for a singular output stream even if it is to be output to multiple destinations (headphones, speakers, bluetooth). This model makes it near impossible to have two audio sources pipe their individual output to three different outputs at different levels or presence/absence. It does not lend itself well to the concept of two audio players with one sending audio to the headphone jack, the other sending audio to the bluetooth headset and the combined - and balanced - outputs blended through the device speakers.


Pulse has a more mixer like model.

Audio stream a \                 / Output stream a
Audio stream b  \               /  Output stream b
Audio stream c   >  Pulse <   Output stream c
Audio stream d  /               \  Output stream d
Audio stream e /                 \ Output stream e

All input streams can be selectively level and bitrate adjusted and mixed and sent to any/some/all selected outputs at the output bitrate and volume parameters. This gets complicated quickly and is why pro audio mixing boards are big, expensive, can have hundreds of knobs and buttons just to control a dozen inputs (mics, instruments, audio tracks, etc) and outputs (house speakers, each musician's in ear monitor mix, surrounds, etc). This model makes it possible to have two audio sources pipe their individual output to three different outputs at different levels or presence/absence. It lends itself well to the concept of two audio players with one sending audio to the headphone jack, the other sending audio to the bluetooth headset and the combined - and balanced - outputs blended through the device speakers.

ALSA is superior in 'just make it work' for 'simple cases', which are the most common case.
Pulse is superior in 'give me control over how much of each input channel goes to each output channel', which is the mixing board use case.

And thus we have a holy war of ALSA vs Pulse.

 

[Djoga'Ro]

You don't know JACK! ;P

 

[Linux-SWAT]

And now we have sndio:

sndio

 

[Letalis Sonus]

ALSA has a fairly simple model.

And yet you managed to get it all wrong, all you did was explain how the dmix plugin mixes its streams. You can do pretty much everything you can do with Pulse with ALSA as well, the big difference is that you cannot configure it dynamically. This includes routing an audio stream to multiple output devices or mixing several input devices into a single output stream. Once a single process has started to load and initialize libasound you are locked onto the currently configured setup, the routing of the audio streams becomes fixed. At least as far as ALSA is concerned, you may still include plugins into your ALSA config that reroute audio streams to seperate processes that can reroute them dynamically, which is exactly what Pulse does to support ALSA-only applications. This is actually one of the things I never understood: You could basically use this approach to do only the dynamic rerouting of everything, gaining the big advantage of Pulse without many of its drawbacks.

The big difference between ALSA and other sound server solutions is that ALSA is not a sound server to begin with, it manages everything through its client library libasound. The dmix plugin only works because AFAIK it sort of provides a cross-process singleton implementation, the very first process that initializes libasound for outputting audio will parse the ALSA config and create a dmix instance as commanded by that configuration, all following processes will simply hook into the already existing dmix interface provided by the first process. Once that one exits, another running process takes over.

The whole routing process is actually the one where ALSA is by far the most powerful of them all, because you can really fully configure it. You can fully control at which point the resampling happens, it is not part of the routing itself. It is only forced upon you if you leave the ALSA domain: E.g.: The LADSPA interface to include sound effects into the audio streams within the ALSA configuration is fixed to use float samples, but that is pretty much a LADSPA limitation.

 

[erico]

@Grench is doing so much on ankther thread i read it anctiously... put please a video on usage if possible. Be mearcifull. Id love to see it going.

 

[Grench]

And yet you managed to get it all wrong, all you did was explain how the dmix plugin mixes its streams.

All of it?

You can do pretty much everything you can do with Pulse with ALSA as well, the big difference is that you cannot configure it dynamically. This includes routing an audio stream to multiple output devices or mixing several input devices into a single output stream. Once a single process has started to load and initialize libasound you are locked onto the currently configured setup, the routing of the audio streams becomes fixed. At least as far as ALSA is concerned,

As per my example above, that you restated here, ALSA cannot dynamically shift and mix audio to multiple independent output channels on the fly where Pulse can. So, I didn't get it all wrong - in fact, you just restated my main point. ALSA works favorably for the simple case where you have multiple Input channels with the intent to combine them into a single (or stereo) output channel with a singular program on one or more output channels.

Pulse is far more complicated because it -does more-. It allows for each input source and output channel to be handled fully independently, much more like a pro mixer console. This makes it annoying to use if all you want to do is the simple example where ALSA excels.

you may still include plugins into your ALSA config that reroute audio streams to seperate processes that can reroute them dynamically, which is exactly what Pulse does to support ALSA-only applications. This is actually one of the things I never understood: You could basically use this approach to do only the dynamic rerouting of everything, gaining the big advantage of Pulse without many of its drawbacks.

At the point where you have had to add plugins and tweaks and special cases to ALSA to make it do some of what Pulse does, you have made ALSA more complicated than Pulse is.

The big difference between ALSA and other sound server solutions is that ALSA is not a sound server to begin with, it manages everything through its client library libasound. The dmix plugin only works because AFAIK it sort of provides a cross-process singleton implementation, the very first process that initializes libasound for outputting audio will parse the ALSA config and create a dmix instance as commanded by that configuration, all following processes will simply hook into the already existing dmix interface provided by the first process. Once that one exits, another running process takes over.

Again, restating my point that ALSA is great for -simple- routing of sound sources into a singular program (sound engineer not software engineer version of that term) that is then output over one or more channels. If you want a differential program for each channel, that is where you need Pulse.

The whole routing process is actually the one where ALSA is by far the most powerful of them all, because you can really fully configure it. You can fully control at which point the resampling happens, it is not part of the routing itself. It is only forced upon you if you leave the ALSA domain: E.g.: The LADSPA interface to include sound effects into the audio streams within the ALSA configuration is fixed to use float samples, but that is pretty much a LADSPA limitation.

At which point you need to manually edit the configuration files associated with ALSA or run plugins to do that for you - which often wind up running multiple instances of ALSA in order to cope with the multiple processes that need to be done resulting in more overhead.

Frankly, I'm not a big fan of either - at least not the offered stock configuration interfaces for them. Give me a full screen graphical mixing board interfaces with input channels on the left and output channels listed as columns across the top and an individual select knob that I can turn up/down for adding/removing each source to/from each output channel. Ganged stereo maybe, but I'd rather control balance by the source-output layer anyway. ALSA can't do this without running stacked instances and a whole lot of plugins. Pulse can do it, but I've yet to see an interface for it that isn't a pile of steaming garbage.

The reason why Pulse might be better on the Pyra is that the hardware has the ability to truly, and independently, feed separate outputs to headphone jack, speakers, bluetooth audio and maybe even sound over the HDMI - all in stereo - maybe more over the HDMI (7.1?). If there is enough CPU (which there might not be if video is running too), the Pyra could theoretically play one song through the headphone jack, a separate song through a set of Bluetooth headphones, be playing a game on-screen with it's audio coming out through the speakers AND send a movie through the HDMI port with it's own soundtrack playing back over the TV. That is a minimum of eight output channels (stereo). ALSA can get to there, barely, with plugins and running multiple instances. Now feed 25% volume of each of the other three soundtracks into each of the others (mixing) while maintaining the dominant signal associated with the channel output (monitor mixing). ALSA simply cannot do it. That is where Pulse shines - which is an admitted niche case.

Post automatically merged: Dec 30, 2019

@Grench is doing so much on ankther thread i read it anctiously... put please a video on usage if possible. Be mearcifull. Id love to see it going.

I don't do videos. At this point there isn't much to see but a screen full of log messages I don't understand. Working on that.

 

[theredbaron]

I am probably the lowest common denominator of potential Prya buyers, at least for the next few years while things settle down. I know a little about linux, I do run it as my main OS, however I an not a power user by any stretch. GUI if I can at all help it kind of person. Just work as a handyman, and the only "coding" I know is what little shell scripting I have picked up (I can change pcmanfm's wallpaper: ) ).

Now this is a very dumb end users experience, on an old version of Ubuntu. (9.04 I believe)...

However, the alsa v pulse argument is something I do know about, as when I started using linux, Ubuntu used Alsa. And I wanted Bluetooth headphones. I hated it. Damnation, the amount of work I needed to do to get Bluetooth audio working sucked so much. It maybe something alot of you here can do easy, but for me it was hell.

Then I heard about this shitty audio backend that was trying to replace Alsa. I installed it, and pavucontrol, and it just worked, and beautifully. I could have, and did have, me listening to something with Bluetooth, my brother listening to something else with a usb sound card, and the speakers playing the audio for the movie my other brother was watching as we went down the road.

Pulse was, for dumb users like me, a god send. Even someone as ignorant as me could do magic with it. It may have lots of issue surrounding it, but for extending the reach of a product to dumb users, its amazing. Kinda like systemd, but that's a whole nother can of worms .

So, while you can go to just alsa, and there are good reasons to do it, if you can get pulse to work, I believe it would be a good idea. If nothing else, it would make the dumber end users able to wield its power more handily, leaving it at least seemingly a better product then with alsa and some scripts.

But again, just the thoughts of the lowest common denominator here. I don't know what 'is' possible.

Sent from my H3123 using Tapatalk

 

[rv6502-2]

And you have to do that in the program, ALSA itself can't do that... which is the reason I think there's no real way around pulse.

For a phone-capable handheld switching dynamically between BT headset, speakers and analog headphones is gonna be pretty important.
Same for the audio input.

I already use that feature every day on both my desktop and GPD Win.

On the GPD Win when I turn on my BT headset it automatically switches audio from the builtin speakers over to the Bluetooth headset.

On the desktop I got it set to simultaneous outputs so I can have
the HDMI monitor,
a set of speakers in the other room (soldering desk / workbench) with the line-out motherboard port,
and the bluetooth headset all at once playing the same audio.

Sometimes my kid wants to watch something so I redirect VLC or my game to the BT headset directly and her show to the HDMI directly, notifications still broadcast on all simultaneous.

It's all a few clicks in `pavucontrol` and `paprefs`.

I got BT on right now and it's using between 1.7% to 2% CPU usage playing music with the simultaneous output to all 3 sound devices (BT, HDMI, line-out).
If I disconnect the BT headset it drops to 1.3% CPU usage (HDMI + line out)
If I switch chromium to play directly to the HDMI port rather than "simultaneous output" it drops to 0.7% CPU usage.

(That's percentage of ONE core/thread. Not total system available CPU power. So one app can take 3200% CPU time if there's 32 CPUs)

It's right there at the bottom.

Memory usage is at 18MB resident (13MB shared) with all these outputs going and connected apps, and browser playing audio.
And it takes no CPU time at all when nothing is playing.

At least on x86 PulseAudio works fantastic now.
It's not like it was in 2004, 15 years ago.

 

[ible]

i find the hate targeted towards the main author behind Pulseaudio (and/or systemd) a bit stupid. it's linux; you can make your own version of things if you want. if it doesn't catch on as well as you'd like it to, maybe it doesn't solve everyone's problems as well as you thought it did, but you shouldn't be ticked off with the other person's work.

(but good for you anyways; it's amazing to be able to accomplish a project. of course, i am referring to the people who make their own projects and don't just criticize people from the sidelines. )

(also, pulseaudio works for my requirements just fine.)