So, what's the current status of everything?

[Linux-SWAT]

Looks like sndio may be a way to have a clean audio:

Hyperbola - Todo: sndio migration

www.hyperbola.info

And the extra bonus: kicks out pulseaudio.

 

[Letalis Sonus]

Looks like sndio may be a way to have a clean audio:

One of the main reasons PulseAudio is being used is the ability to configure Bluetooth audio devices on the fly, if it doesn't support that we could just as well go back to full ALSA.

 

[Linux-SWAT]

Why shouldn't it be possible ?

BlueALSA: Bluetooth-Audio using ALSA (not PulseAudio)

Yesterday I did get a new little Bluetooth-Speaker, but without AUX - I rechecked some Bluetooth-Commands. But could never connect, because the Pi missed the protocol A2DP - which was only available with PulseAudio as Bluetooth-Module So I used my 2nd OrangePi One with USB-Bluetooth-Dongle and ma...

forum.armbian.com

 

[levi]

Plus I'll note I don't have any of the issues listed on that link. My audio hardware does sometimes crap out and it takes a second to reconnect which usually hits once or twice per album but I recall it does similar using ALSA, and it certainly never does any of the bullshit they talk about there. I can see reasons to distrust pulseaudio, most of them beginning with some slight against the sayer by a certain LP, but lying about the project I'm using to make me use another doesn't work for me.

 

[rygD]

Haven't had a new update in a while.

The prototypes have gone out, and they are starting to be received and worked with. That is pretty big news, imo.

 

[EvilDragon]

Why shouldn't it be possible ?

BlueALSA: Bluetooth-Audio using ALSA (not PulseAudio)

Yesterday I did get a new little Bluetooth-Speaker, but without AUX - I rechecked some Bluetooth-Commands. But could never connect, because the Pi missed the protocol A2DP - which was only available with PulseAudio as Bluetooth-Module So I used my 2nd OrangePi One with USB-Bluetooth-Dongle and ma...

forum.armbian.com

Seem to be a lot of fiddling around for the end user.
It looks like you need to choose the alsa audio device each time you want to play audio to speaker / headphone / bluetooth.
With Pulseaudio, you can redirect the stream on-the-fly, which is a huge advantage.

 

[Linux-SWAT]

and it certainly never does any of the bullshit they talk about there.

You should not talk like a troll about these people who are very respectful of the free software movement. Shame on you.

 

[rygD]

I think some of us are trying to avoid pulse and friends.

 

[Linux-SWAT]

Seem to be a lot of fiddling around for the end user.
It looks like you need to choose the alsa audio device each time you want to play audio to speaker / headphone / bluetooth.
With Pulseaudio, you can redirect the stream on-the-fly, which is a huge advantage.

Seems only a user-space tweaking, at least it's worth investigating.

Post automatically merged: Dec 29, 2019

I think some of us are trying to avoid pulse and friends.

We have to keep opensource open, and free software free.

 

[Letalis Sonus]

Seems only a user-space tweaking, at least it's worth investigating.

It does not provide any sort of dynamic configuration. You can't just change environment variables of programs that are already running and changes to ALSA's configuration files requires restarting all applications that are using it. I wouldn't be surprise if losing connection to the Bluetooth device would break audio entirely just because the sound device becomes unavailable, ALSA just isn't designed to handle these kind of things.

 

[EvilDragon]

Yes, I don't think dynamically switching around audio streams will work with ALSA.
To my knowledge, you have to stop and restart the stream to switch the output device,

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.

 

[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.