How to stream audio from your phone to your laptop with PulseAudio | Hacker News Reader

How to stream audio from your phone to your laptop with PulseAudio

bash-prompt.net

213 pointsmanjana125 comments

Linux audio can be a pain to get setup, but once you've got it setup you can do some pretty cool things. I set something up similar the other day with pulseaudio and a Bluetooth headset. I used it to route the headset channel output on mixxx to the Bluetooth headset and the master output through the speaker output. Sadly, the latency was too much to actually mix and beatmatch properly, but it was a fun exercise and just the fact I could do it was pretty cool.

I wonder if it could work with modern AptX low-latency headsets.

Pulse has latency adjustment so devices can compensate for latency.

When using combine module to output to multiple devices, do drop the sync latency fr the default 10s. Especially if it's a BT device. Turned it fr a nightmarish hell of constantly drifting terrible audio to just working multiple devices output for me.

Latency compensation, not magic latency elimination. The latter is not possible :-)

You can get audio to line up across different outputs when it is being played from a source with a large buffering capability, which is what PulseAudio does well. But when you're trying to get real-time audio to respond to user input (e.g. games, or DJing or playing music), latency compensation just gives you the lowest common denominator, and PulseAudio isn't really any good at guaranteeing low latencies for these use cases anyway. That's why for music production on Linux, you should be using JACK (or directly using ALSA from whatever source app you have, e.g. mixxx or Ardour).

In either case, the Bluetooth issue is inherent to the protocol and codec and technology stack there, and there's no way to fix it. It's really, really hard to do wireless audio with low enough latency for live music, especially on 2.4GHz where you need error correction and retransmits because the band is always so congested. I have a wireless microphone set on 2.4 using proprietary dedicated technology for this, and it still has noticeable latency (though just about usable for karaoke and such, but not ideal), because it has to introduce a fixed latency to allow for a retransmit budget in case of error.

Yes, but you need a different repo [1] for that. The default one supports only SBC, this one adds support for AAC, AptX, AptX-HD, and LDAC. There's third party packages for a myriad of OSes.

[1] https://github.com/EHfive/pulseaudio-modules-bt

Huh, I managed to get AptX working using just a small patch for BlueZ, but I guess that would work too.

aww man, this is so frickin cool. i just set this up, and its amazing. i really needed this for audiobooks. thank you! <3

I use an app called "Voice" [1] on Android for audiobooks. I'm so used to it that any other app or way to consume audiobooks seems below par.

[1] https://github.com/PaulWoitaschek/Voice

That seems interesting. Where do you get your audiobooks from?

My library offers a audiobook service that provides DRM free MP3s.

Not the same person, but I get my audiobooks from Amazon Audible or my local public library.

In the case of Audible, the first listen usually occurs in the Audible app, but eventually I remove the DRM (converting it to mp3) and dump it in my Books folder, which automatically syncs to my phone with SyncThing. I often re-listen to audiobooks a year or two later, and subsequent listens happen in the Voice app. I like having my books stored locally so I can listen to them whenever, and it's also a safeguard if they ever disappear from Audible.

When I check out audiobooks from my library, I do it through the OverDrive program on my Windows computer, which lets you download in mp3 format. It's apparently on the honour system to delete the files once you finish it (which is shocking), but I have to admit that I usually don't. If I ever do re-listen to them, I just check it out from the library again, skipping the download step because I already have the mp3s.

I hadn't considered doing this to save my audible purchases. Going to, now!

Audible + https://hub.docker.com/r/ryanfb/inaudible

I really wish there was a standard way of streaming audio over LANs that worked between devices (like phones, computers, and smart speakers). Bluetooth is such a pain, IMHO.

If you are willing to accept something obscure PulseAudio actually has the best thing. Look into the PulseAudio native module which just let’s you put a speaker on the network as a normal boring sound output that works as if it was connected to your computer.

- Install the zeroconf module on both server and clients.

- Enable the native module on the server and open the port and tell PA to publish an mDNS record.

- See the speaker just appear in your sound options. Play!

Actual instructions if you want to set it up https://blogs.gnome.org/ignatenko/2015/07/31/how-to-set-up-n...

I've done this for years. It works especially well when you have more than one computer, mutually considering eachother their default output.

Playing something in your tmux session on the workstation, but want to go use the laptop in the kitchen? Just move the headphones.

I also use it since I brought the office workstation home, along with barrier (synergy fork), to use one set of peripherals for both of my workstations.

That's pretty cool!

I'd actually like to stream from my Mac or a phone to an Alexa Echo Dot. Bluetooth usually works, but not always, and not needing the devices to be in close proximity would be a bonus.

I tried that and whilst it works for individual outputs, having it playing synchronised with other speakers was not ideal given the timing discrepancies that appeared.

That should be fixable in the same way speaker groups in Google Home work.

Try using module-loopback to add some latency to the sinks and get them in sync.

If it's of any assistance, our (my employer, Linn) Songcast protocol is BSD licensed, and available for high precision uni/multicast networked audio. We use it in the core of our products for multi-room audio.

It is much more network focused than bluetooth though

* https://github.com/openhome

* http://wiki.openhome.org/wiki/Av:Developer:Songcast:Ohm

* http://wiki.openhome.org/wiki/OhMediaDevelopers

Is it possible to stream my phone mic to my laptop with Pulseaudio?

There's also Bluetooth Audio receiver, available in the Windows store for Windows 10 2004 and up, for those who lean that way.

Could probably roll something yourself using Spotify API. Has tempo available as a query https://developer.spotify.com/documentation/web-api/referenc...

This exists. I use it daily & it is awesome. Its called spotifyd: https://github.com/Spotifyd/spotifyd

I don't really understand how this fits in.

Does anybody know, Is it possible to get high-quality two-way audio (e.g. Zoom, Skype) over Bluetooth on Linux?

I believe this is an issue with the Bluetooth codecs. The higher quality codecs use bandwidth dedicated to the mic to also transmit audio signals, and cannot be used for two-way communication. If you actually look at the active codec while just listening to audio, compared to the codec used when also transmitting mic audio back, you will see that they are completely different.

I think you just need to tell Pulse to use a different profile.

https://wiki.archlinux.org/index.php/Bluetooth_headset#Switc...

Pulse already automatically switches the profiles. The issue is that the good codecs are available in the A2DP profile which is sound output only. Pulse will automatically switch back and forth from the HSP profile when an application starts/stops using input from the headset mics, but in HFP you don't have access to the high quality codecs.

Exact same thing happens on Windows and Android and on Apple devices.

The only case where your linked command would be necessary is when depending on your Bluetooth devices & adapters the headset connects and then for some reason registers as HSP instead of A2DP - so you manually switch it back to A2DP to get HQ audio.

I was confused as like you said Bluetooth voice quality is fairly universal.

There is a patch to enable faststream in pulseaudio, but it sounds like very few adapters support it

There's been a massive massive amount of effort being poured into profile support in hopefully the next major PulseAudio release. It should change everything, make it good.

Links? Also, I'm curious if this will also improve pipewire.

https://patchwork.freedesktop.org/patch/361592/

I'm not familiar with pipewire but it sounds like it runs alongside pulse, so should work.

Pipewire is actually the successor to pulse. Its already works as Jack replacement and can do video. Pulse is still in progress.

to answer the q though, this work on bt codecs in Pulse won't directly help PipeWire but the leading the way effect is here: figuring out how to switch codecs & otherwise manage the device (how much bluez (linux's bt daemon) interaction is required, i wonder?).

Can Pipewire do high-quality voice calls (Skype, Zoom) over Bluetooth on Linux?

Bluetooth is currently basically unable to do high quality voice calls.

All the other OSes (MacOS, iOS, Windows, Android) can do high-quality voice calls over Bluetooth, just not Linux, right?

No, the problem is with Bluetooth not Linux.

thanks , yes

i may have been over-expectant; not sure if this is happening in the ultra-cool upcoming v14 release.

https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/1...

I'm on a Mac, but if your hardware/setup suits it this may work. On Chrome/Zoom I set the mic to be from the on-board from the laptop and the sound output to be the bluetooth device. The audio profile then will change for the bluetooth to high-quality instead of the headset profile.

Very neat. I assume this would work work on a cheap Raspberry Pi3 or 4 too, via their Bluetooth and out via its audio jack.

Now I think of it, I seem to remember seeing a project like this to make use of old wooden-box speakers (with a small amp inside too.)

I still don't really understand Linux audio layers and how all this stuff works together, how do I configure it, and so on. Is there some good manual/blogpost/etc that would explain that?

There's the ArchWiki, but overall the Linux audio ecosystem is severely under-documented.

> I still don't really understand Linux audio layers and how all this stuff works together

My simple understanding is that in the Linux audio stack you have the following layers:

- kernel-driver for local sound devices (provides exclusive access, no mixing/multiplexing).

- application-level audio-frameworks/APIs which are device-agnostic (pulse, ALSA, jack), can support, mix and multiplex multiple concurrent streams/applications.

- these different application-level frameworks can have several different back ends (for real HW, BT, virtual devices, network targets, etc, other Linux application-level audio-frameworks. )

(Someone correct me if I’m wrong)

Applications target a framework, but not all target the same, so the frameworks needs to be able to “plug together” so the speak.

This leaves the possibility if the following scenario:

App written for ALSA -> ALSA -> ALSA’s Pulseaudio backend -> PulseAudio -> Real hardware

PulseAudio in particular is very featured, modular and pluggable which is why most desktops Linux distros uses this by default these days.

It supports things like transparent network streaming between various kinds of targets and lets you compose “audio graphs” if need to.

And that’s probably why it was chosen for the experiment in this blog post.

ALSA is (confusingly) two things: a userspace library and API, complete with plug-ins and configurability and even mixing, and also the kernel API that underlies it to talk to the physical hardware.

So a typical chain ends up being legacy app -> ALSA -> PulseAudio -> ALSA -> kernel, because ALSA both frontends PA for legacy ALSA-only apps to use it, and also backends PA to talk to the real hardware.

But ALSA isn't the only backend for PA. For example, Bluetooth audio output will go via BlueZ and into kernel socket APIs instead, since Bluetooth audio is a network protocol, not something handled in the kernel. And then there's FFADO, a userspace driver for FireWire audio devices. And you can put JACK on top of that. And then you can put PulseAudio on top of JACK. Or you can out JACK on top of PulseAudio, but that'd be silly. And PA can go over the network, both from app to a remote PA daemon, and also from PA daemon to PA daemon. And there's also netJACK if you want to put that on a network.

And now PipeWire is replacing JACK and PulseAudio and impersonates their APIs and also ALSA and lets everything talk to everything else.

Basically it's complicated, but also very flexible. In the end though, there is usually one "default" setup that you get if you don't do anything on a typical distro, and that's, these days, apps -> [ALSA ->] PulseAudio -> {ALSA -> kernel, BlueZ -> kernel} for most typical use cases (native PA apps and ALSA apps, local audio and bluetooth backends).

> Or you can out JACK on top of PulseAudio, but that'd be silly

It doesn't give you low latency, but if you don't care about that this is a nice way of using JACK applications without interrupting other applications that might be using PulseAudio; for development it's pretty handy.

A friend want to do real time speech to text of phone calls for a call center client. They want to capture the customer side of audio which is listened by customer care agent. How to build the part to extract stream of audio from this call conversation. Once extracted it would be passed to speech to text streaming API to do inference.

You'd process the audio streams in the call center telephony stack (kamilio, asterisk etc)

Thanks. Isn't there any other options than touching telephony stack

In their SIP client instead? But I agree with the parent, doing it at the PBX level makes more sense.

Anything for the other way around, specifically from Mac to Android? Sort of poor man's wireless headphones.

Interesting.

It should certainly be possible to use a little device driver for MacOS that streams all output in some IP stream format. Then use any web radio client of choice on the android device. Latency will be terrible though.

Search for macos loopback. It is a tool that is part of a collection of tools which might make this possible

Yes! There are a few answers here: https://superuser.com/questions/605445/how-to-stream-my-gnu-... I'm using the top one and it works well for me.

I've done the reverse (connecting to bluetooth speaker) out of the box on Ubuntu. So I'm surprised you'd need to install an extra PulseAudio module.

Perhaps the BT module was already installed? Or do you only need the BT module to handle input, but output works via the kernel's BT stack?

On my ubuntu machine the Bluetooth modules for pulse are installed by default.

Another one of the Linux projects that the cranky contakerous pissy segment of the FOSS world just loves to spit on & hate, PulseAudio.

The FUD keeps coming from within the FOSS world itself. But I keep seeing stuff like this, & thinking, this is such a flexible powerful tokit, pulseaudio- why are so few haters willing or capable of acknowledging that pulse does have serious upsides & vast intermixable capabilities? Maybe it's just me but I feel le Pulse Audio is another one of those epic works that is ceaselessly pointlessly shat upon while no one has anything remotely comparable.

Also though still eager as heck to replace it all & this use case (a frigging awesome ubicomp style use case) with PipeWire. Zeeeerrrooop ccoopppyyyy (to the tune of leroy jenkins).

I think it's a small but very loud minority that hates on systemd, pulseaudio, etc.

Majority of users, like me, never really comment on those two because they do their job so well - they get out of my way and just work.

Not only do they work, but when you need to advanced stuff it's generally easy & works on the first try. Making loopback devices, combining audio streams and/or redirecting streams, all sorts of wacky stuff. The hardest part is finding a good guide on Google that tells you the right commands/configuration options. Same with systemd.

PA at least was full of bugs on arrival ten+ years ago. That's what started the fight. Poor response to criticism fueled it.

In short, don't replace working code with new until it is at least as good. While new stuff needs testing, folks react strongly when it lands on production systems.

That's definitely true as well - some responses by poettering in systemd issues in particular are unnecessarily condescending and very unprofessional.

Also, while systemd and pulseaudio were heavily pushed by many distros, alsa was and still is an option and systemd alternatives exist for those who care that much.

The biggest problem with all the discussions is that 90% of the people don’t know what they are talking about. A lot of people (and I don’t mean you specifically) treat alsa and PulseAudio as interchangeable but they’re at different levels of the stack. Most PulseAudio installs run on top of Alsa and it’s almost always possible to skip the PA layer and output to Alsa directly so long as the applications were built against libasound as well (and you configure PA not to automatically open your Alsa device).

Compared to systemd I feel like most of the issues with pulseaudio circa 2009 were distro or application specific, like the current situation with Wayland. You could run Ubuntu and have PA eat all your RAM and not even work, but switch to Fedora and not have so many problems (performance was still unacceptable on the toaster I used back then, though). Whereas if you dislike how systemd works and Poettering’s often narrow minded approach, using a different systemd based distro probably won’t change your mind.

> using a different systemd based distro probably won’t change your mind

There's plenty of non-systemd based distros. Yes, they're way less popular, but that's because systemd works and does wonders if you know how to use it, compared to that mess of bash scripts inconsistent in quality and across distro implementations that we had before, so users and developers find value in it.

systemd has certainly made my job as a user, sysadmin and developer a whole lot more pleasant.

If you prefer OpenRC or s6, there's distros for you out there. I won't bother supporting them, but you're free to use them.

Granted, you get outcomes such as [1], but if you're fine with that, the choice is there.

1 - https://gitlab.com/postmarketOS/pmaports/-/issues/719

Sorry if I wasn’t clear - I was saying that people who are unsatisfied with systemd vs earlier or current alternatives are usually better off using a distro based on openrc or runit or s6, as you suggest. Not that there is any lack of good alternatives. The point was that the most common complaints about systemd are indeed issues people have with systemd and not with poor packaging or something. This contrasts with pulseaudio where most of the early criticism was caused more by distros doing a poor job with it than the users having fundamental issues with the design of pulseaudio.

What does that pinephone issue have to do with systemd? Sounds more like a bootloader issue (or if not, the kernel lacking a feature) to me.

> The point was that the most common complaints about systemd are indeed issues people have with systemd and not with poor packaging or something. This contrasts with pulseaudio where most of the early criticism was caused more by distros doing a poor job with it than the users having fundamental issues with the design of pulseaudio.

Fair. I think many would contest that and say they indeed had issues with PulseAudio itself, not because you're wrong, but because the understanding as to why PA sucked for many is just not there and never was. I feel systemd is in a similar position. It's not poor distro packaging, bur it is rather a fundamental misunderstanding of what systemd even is.

From most of the complaints I've heard, they fundamentally misunderstand what systemd is even trying to do, there are certainly better ways of doing them, but I feel the debate is not even at the level where there's understanding of systemd and critiquing it.

In a sense, OpenRC is not even a direct competitor.

> What does that pinephone issue have to do with systemd? Sounds more like a bootloader issue (or if not, the kernel lacking a feature) to me.

It's not bootloader related or kernel related. There are other distros for the PinePhone, like Mobian, where suspend works properly. The issue is Alpine's init system can't do the job. systemd can.

> A at least was full of bugs on arrival ten+ years ago. That's what started the fight.

Right, and the criticisms haven't been updated since.

> While new stuff needs testing, folks react strongly when it lands on production systems

How exactly do you test things if you never roll it out to production. Because "at least as good as the old" is a hard metric, especially given that PA solved a bunch of problems the old code never even attempted.

I think Ubuntu had a particularly bad first PA implementation and that did a lot of the damage. But being on repeat for a decade about how it sucks while it no longer does for the vast majority does not make these people look smart, that's for sure.

I haven't heard any complaints about PA in a long time. Sure, if you dig hard enough you could find some, but nothing like the ground swell of ten+ years ago.

I understand it is very hard to roll out something new and bug-free to production. It's quite easy to not bother, however.

I forgot about Pipewire. How is that project going?

Here is a recent update from Christian Schaller on PipeWire [1]. It looks quite promising; it's especially good to see that PipeWire comes with shims implementing the ALSA, PulseAudio, and Jack API, so it should be a drop-in replacement.

[1] https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summ...

PulseAudio sucked when it first came out, then gradually grew enough features and stability to make it worthwhile. The people still hating on it are just too boneheaded to appreciate things like your speakers muting themselves when you plug in headphones.

That said, it's still glitchy at times and can't do low latency properly, and JACK1 is inefficient, and JACK2 has a messy threading model, and none of them can do any-to-any latency compensation, so let's hope it all gets replaced by PipeWire and we solve this mess once and for all.

I think you are right. I started using linux about 6 years ago and I have never really had an issue with pulse audio. I have had loads of headaches trying to get JACK working which really shows me how smooth PA is to use.

I am still wondering if we'll loose all the network capabilities of PA in PipeWire, whereas I don't need its low latency capabilities. Right now, it looks like one will have to install both PA and PW with a bridge between them, which seems a rather bug-prone setup if you ask me.

I've had huge problems with PulseAudio over the last 14 years, but now there are only two left: it randomly hard-hangs a few times a day and it sometimes stops sending audio to a bluetooth speaker (or occasionally to headphones) while acting as if everything is fine. The latter shows up with speakers from two different manufacturers. Everything else I used to hate about Pulse has gotten better: weird audio distortion, clicking & crackling, skipping, messing up the soundcard enough to require reloading modules, getting stuck on mute, jumping to max volume when things were connected - thankfully all gone.

I've had the hang & audio interruption on Mint, openSUSE, an Ubuntu so I'm inclined to think it's something inside Pulse and I've got some hope that those last bits will get fixed. (I am aware that actually playing sound is the first responsibility of a sound system, but I'm being optimistic here.)

Nobody is going to be able to fix that hang unless they know the steps to reproduce. Can you record pulseaudio with rr and capture it happening? Then debugging it should be pretty easy.

Does JACK even have enough information to do any-to-any latency compensation? The only "Linux audio" application that I know of that really does this now is Ardour, and it was only in the last few years that it was implemented.

That's the problem, the JACK design does not allow for it. It's why Ardour is still gimped and can't actually do full latency compensation if you connect a track to more than one sink, because Ardour is built on JACK, and JACK can't handle that, and the non-JACK backends for Ardour are kept at feature parity. (You can work around this with sends instead of connecting track outputs, since Ardour handles those outside of JACK)

JACK in general provides latency information throughout the chain, but it does not add delay lines to compensate latency itself, so the problem is that when you connect one thing to more than one other thing, the latency number becomes ambiguous (a range) and you can't compensate for it any more.

JACK1 isn't inefficient unless you have parallelizable signal pathways. This isn't the common case, though it is also not unusual either.

Some problems are hard and there is no good solution but only solutions that suck less than others. Imo pulseaudio and systemd are in this category. So it's easy for haters to find faults in them.

I mean the module-virtual-surround-sink written 8 years ago [1] doesn't even work properly[2]. Even worse the convolution algorithm is a naive implementation with O(n^2) instead of O(nlog(n))[3]. 8 years later it appears the issues are finally being worked on.[4]

[1] https://lists.freedesktop.org/archives/pulseaudio-discuss/20...

[2] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issue...

[3] https://lists.freedesktop.org/archives/pulseaudio-discuss/20...

[4] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

There's a significant segment of the community that seems to be afraid of anything that fundamentally rethinks an old subsystem, I believe in large part because it forces them to learn new skills and they're been able to get paid rather handsomely thus far with their teenage-learned Unix skills.

It's a form of gatekeeping.

In my house, PulseAudio powers an entire wireless speaker setup, (except the speakers are actual high-quality bookshelfs, rather than say an Echo and I don't have to wiretap my house).

systemd is another project they love to hate despite what came before being an unreadable, inconsistent mess of variable quality shell scripts that came nowhere close to what systemd provides with its declarative services.

To be fair, while systemd really does provide something that SysV init never could, it is hardly without flaws. In the past, it has had several severe security problems (up to and including privilege escalation vulnerabilities) that the developers have not always handled well. It's a "move fast and break things" kind of software, which in the realm of essential operating system components is not a good quality.

I agree on pulseaudio though, my only real gripe with that is documentation.

> I agree on pulseaudio though, my only real gripe with that is documentation.

Yep not great but still better than that confusing mess called asoundrc.

On top of that PulseAudio appeared to be quite buggy at the beginning for quite some amount time, even after distributions started defaulting to it. I have read that most of those issues were actually driver bugs but that did not stop it getting a bad reputation.

I think this bad reputation is also part of the reason why the hate on systemd escalated that much.

To be fair, the root problem is that the Linux kernel sucks at audio, and everything downstream from that suffers. This sits squarely on the heads of Linus and the maintainers.

For goodness sake, they STILL haven't mainlined PREEMPT_RT support after almost what? ... 20 YEARS. (Although they say they're finally going to ... I'll believe it when I see it.).

You need low-latency for audio to not suck. That requires a kernel re-architecture to enable that.

OS X went through a major kernel revamp back in the 10.3/10.4 timeframe in order to stabilize audio latency.

It's not easy.

For all the hate pulse gets, my microphone works more reliably under GNU/Linux than under Windows these days. 2020 is weird, man.

I remain deeply suspicious of second-system-effect "let's replace everything about $THING", but pulse has matured well.

> Another one of the Linux projects that the cranky contakerous pissy segment of the FOSS world just loves to spit on & hate, PulseAudio.

There isn't one single anti-PulseAudio comment in the thread, and yet you start a top comment complaining about them, that you fill with insults (and get approved and upvoted for that). I wonder in which camp truly sit the always 'cranky', 'pissy', 'spiting', 'pointlessly shitting' 'haters'.

I am annoyed by PulseAudio because I don't know how it relates to ALSA.

Every time I made an audio related project on a Raspberry Pi, be it to stream the incoming signal of a USB-mic via ffmpeg/avconv to a server, try to get a ReSpeaker 2-Mics Pi HAT working, stream a MP3 radio stream to a speaker, anything related to sound, I'm always confronted with ALSA as if it were the default audio system on Linux.

But then something doesn't work, and I get referred to PulseAudio, and then I have these two audio systems somehow working together, and I don't know why, but somehow it works, and I'm left clueless about what is going on down there in the OS with all this sound thing.

The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell.

If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement?

At least this rant has pushed me now to seek explanatory YouTube videos on this matter, but I think that I'm not the only one who is confronted with this confusion.

Pulseaudio is a middleman between applications and ALSA. There is no Pulseaudio without ALSA.

EDIT: Forgot OSS can also be the back end as an alternative to ALSA

I highly suggest reading the Arch Wiki page on Pulseaudio. https://wiki.archlinux.org/index.php/PulseAudio

> I'm always confronted with ALSA as if it were the default audio system on Linux.

Because it is as far as the kernel drivers for audio devices are concerned. You have to distinguish between that and the userspace part called libalsa.

> If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement?

Pulseaudio can be seen as a replacement for libalsa while it still talks to the ALSA kernel drivers in usual setups. The fundamental conceptual difference is that pulseaudio is a sound server and libalsa is a library which is directly included into a program.

> The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell.

This is actually the configuration file for libalsa. The pulseaudio stuff in there is configuration for a compatibility plugin shipped with pulseaudio which presents an audio device to the application using libalsa redirecting everything to pulseaudio instead of directly talking to the Kernel. That way applications without native pulseaudio support can still be used without issues while pulseaudio is running.

Won't the quality of the audio over Bluetooth be incredibly compressed, though?

Bluetooth audio generally uses one of two "profiles"; there's A2DP, and generally sounds fine. I've not noticed the compression. A2DP is one-way, audio output only.

There's also HSP, which is two-way (mic+headphones, essentially), and it sounds like a potato.¹

(I have no idea why this is, either. My brother once "solved" the quality issues of HSP by getting a second headset, putting both headsets on his head, putting one in HSP and using the mic from that one, and putting the other in A2DP. It worked fine, aside from it wasn't comfortable and it looked ridiculous. He was on Windows, but I have the same issues in Linux and OS X.)

Short answer is no. I'm not really sure why so many try to hate on bluetooth audio. But don't take my word for it, hear for yourself. You can first read up some on it[0] Then get the needed tools to encode audio into the exact same format that your headphones would see [1]

Hopefully, you have an uncompressed wav file to test with. Unfortunately, the sbcenc command wants the wav in the uncommon big-endian format. Not worries, just do: "ffmpeg -i test.wav test.au" and it will convert it for you. Now feed that .au file into sbcenc:

"sbcenc -B 16 -s 8 -j -b 51 test.au >test.sbc"

That is the default scheme for "bluetooth high quality". Personally I have not found a difference in the sound. Of course note that the audio encoding is adaptive, so if you put on your bluetooth headphones and walk 50 ft away, yea it might sound bad...

[0]: https://en.wikipedia.org/wiki/SBC_(codec)

[1]: https://packages.debian.org/buster/sbc-tools

SBC is also not the only BT codec; BT headphones often offer direct mp3 support so that there is no extra loss in quality

The bluetooth stack on linux only supports SBC due to license issues.

There is a fork of the PulseAudio Bluetooth modules that supports LDAC, AAC, AptX, and AptX-HD. LDAC should be supportable upstream, I think it's coming.

On a side note, LDAC is so laughable. I have to imagine the engineers working on it had a lot of laughs. It has all the "high resolution audio" mumbo jumbo that Sony has marketed to audiophools for decades, and it is hilariously inefficient.

LC3 is the new audio standard for Bluetooth 5.2 and up, but when I read the Bluetooth SIG claims it provides better quality at comparable bitrates to a long list of codecs that ended with "and Opus," I had to laugh and close the tab.

For those that don't know, Opus is pretty much the current gold standard for freely available audio formats that are at least partially designed to operate at the very lowest end of the bitrate spectrum while delivering comprehensible audio; unless LC3 is also using SILK but just under a different name, I'd be extremely shocked to find it actually beats Opus.

"LC3 outperformed Opus at 32 kbps in their tests. But they used an old version (1.1.4) with encoding complexity set to 0."

So yeah, it seems they did one test at a low bitrate with an old encoder and poor settings and proclaimed it "better than Opus".

On that topic, when I get fully set up after my move, I'll have more time to devote to my A2DP Opus mode.

I think it's actually not crazy to decode Opus on Bluetooth chipset DSPs, even all the way up to the maximum bitrates.

One nice thing about this as well is that adding surround sound modes shouldn't be that hard, I think it would be the first surround sound A2DP configuration.

That test is indeed laughable, I read their materials, and it looks like they crippled the Opus encoder, which was already on old release before they used it. Opus 1.3 at an ordinary complexity is doubtless better than LC3, and there are actual encoders and decoders that you can just download and port yourself.

My real problem with BT is how unreliable it is. I'd like to find someone who never had an issue pairing some earphones or headphones and had it working flawlessly every time.

There are many variants of BT audio and they don't all work the way you would expect. It's still not rare to end up with lag if your combination of hardware, software and receivers don't have compatible technologies like aptX.

For me the unreliable and lengthy pairing process is the major pain. Takes out the earbuds, wait at least 10-20s to get them connected, then wait another 10s for the phone to realize it needs to output to the earbuds. More often than I'd like, I have to put back the buds in their case and take them out again to force a reconnection because the phone or one of the buds said it was connected but isn't getting any sound...

And I'm not talking about a cheap Chinese Android phone with a pair of crap $20 earbuds. I'm talking about iPhone 11 Pro with Sony 1000XM3. It's not the equipment, had similar issues with an iPhone 8 and Bose headsets, and with various dongles and computers.

A friend recently thought his new Sony WH-1000XM4 headphones were not working and asked me to have a look. Took me 15 minutes to hook them to Windows properly. Turns out there are multiple devices that appear (but not at the same time) during the pairing process and if you connect to the BLE stack, you don't get the headphone functionality... (what functionality you get is a mystery) and of course, no mention of that in the documentation.

Wireless audio is important enough that we shouldn't have to settle for these subpar experiences. Although BT has made progress on the audio front by providing protocols with lighter overhead and latency, it's still not particularly suited for audio (no high quality transmission, mono/stereo only, no multicast, lengthy connection, ...)

It is what is is, but it's not what it should be.

It’s gotten a lot better recently. But you do have to remember to unpair the last device before trying to use a new device because you can only connect one thing at a time.

In case that wasn't a rhetorical question, I use a Sennheiser 4.50BTNC every day and it works flawlessly, both on my phone and on my Linux computer (through a generic USB adapter).

I've two complaints with the 4.50btnc.

1. Audio quality is not as good as my older same price headphones (3.30 I think), even with noise cancelling turned off. Apparently the 4.40 is better in this regard at the cost of losing the noise cancelling feature.

2. It can connect to two devices at once in a mostly intelligent manner, e.g. your phone and laptop where the laptop is playing music but the phone takes priority for calls or noisy alerts or alarms. But if one of these devices disconnects, its going to interrupt your audio every 2 minutes to say "Disconnected" until you reboot the headphones and connect just your new device(s). This has caused trouble with my Surface Go waking up from sleep, connecting automatically, then going back to sleep and disconnecting, disrupting my music listening.

>My real problem with BT is how unreliable it is. I'd like to find someone who never had an issue pairing some earphones or headphones and had it working flawlessly every time.

The first project I worked on was for elderly care[0], with a fitness tracker we would connect with over Bluetooth Low Energy (BLE). The first things I had done was to request the manufacturer's communication protocol for that device and then abstract that away in a nice library so we could control the tracker with Python functions `tracker.start_ecg()`, etc.

The second part was dealing with all the weird connectivity problems, troubleshoot, and add helpful exception messages for others. Here's an example:

  message = """
      We were unable to connect to the device {}{}{}...
      Bluetooth devices are tricky and even when you do everything
      right, you can still get this exception. Here are a few things
      to consider:

        - Simply retry to connect.

        - Check `rfkill list`: it will tell you whether your device
          is blocked or not. If it is indeed blocked, you can run:
          `\x1b[33mrfkill unblock bluetooth\x1b[0m` to unblock it.

        - Check `hciconfig`: it will tell you whether your device is
          down or up. If it is down, you can raise your device:
          `\x1b[33msudo hciconfig [hci0|hci1] up\x1b[0m`.

        - You can also restart the bluetooth service:
          `\x1b[33msudo service bluetooth restart\x1b[0m`.

        - Calling Bluetooth.connect with the wrong hci_device param
          can result in this exception, too. Check which device is
          active and call the method with that one.

        - Take a deep breath, you'll probably get this often.
  """

[0]: https://twitter.com/jugurthahadjar/status/130349692330808525...

What's the target market for a product that exposes the whole Linux device stack to an end user?

I don't understand your comment. Are you referring to the error message? If yes, that is targeted to the developers using the library that controls the device. i.e: us. The library helps us talk to a device by abstracting away low level details.

If you want to skip the intermediate file and do it all in one go, you can pipe directly to stdout with ffmpeg if you give it sufficient information to make up for the loss of file name hints. I’ve never used sbcenc, but .au defaults to signed 16-bit big endian which you can specify and pipe (so as to skip the intermediate file) as follows:

    ffmpeg -i input.foo -f s16be - | sbcenc ...

EDIT:

gstreamer supports encoding to SBC directly, from whatever input format you have (its sbcenc plugin takes signed 16-bit LE PCM, but it can losslessly convert between audio/video formats on-the-fly):

    gst-launch-1.0 filesrc location=input.foo ! decodebin ! sbcenc ! filesink location=out.sbc

This. I've noticed Bluetooth quality issues, and they are always either

- The source is using low bitrates. SBC is a poor codec, but at the high bitrates (bitpool values) it should be used at it sounds perfectly fine.

- Just shitty hardware/DSP. If your Bluetooth speakers sound different over bluetooth than over line in, then the DSP/DAC processing going on in them is what is screwing up the audio, not the codec.

"High quality" Bluetooth audio codecs are largely a marketing scam to get patent royalties, because it seems that when a standard actually manages to mandate a royalty free codec (a rarity these days!) companies just can't help but try to jam patented nonsense down people's throats anyway. I'm sure some products even deliberately gimp SBC just to make proprietary alternatives sound better.

and of course it doesn’t help that the Bluetooth devices themselves, even so-called high end ones, have speakers/drivers that are just laughably bad.

The protocol and encoding doesn’t really matter, you could feed in 192/32 way and it would still sound bad.

I've been playing around with mopdiy and it's excellent

This is all well and good but I still can't get mono output going out of Ubuntu 202004. The audio stack under most distros is still a weird mess.

I'd like to see someone stream my pulse to my headphones and synthesize that as music. The more amped I am, the more amped the music should be.

Positive reinforcement loop until your heart explodes? Be careful.

I'm confused... I have all my streaming available on my PC via web-browser. Was this created primarily for Linux users?

This article is not about the "streaming" you are thinking about. It is about using your PC as wireless speakers, i.e. streaming your phone audio to your PC.

But again... why would I ever do that? I have access to all my services on my PC directly. I'm not aware of any phone-only streaming services?

What does this have to do with streaming? Obvious use case would be: I am sitting on the couch and want some music played on my speakers.

Option 1: Get up from the couch, go to PC, put the music on, get back to couch. Listen a bit, change my mind, get up again, change track on pc, get back to couch.

Option 2: Have some kind of remote controls for the PC media player on my phone (e.g. mpd). Requires some setup and only for one specific app, but very similar.

Option 3: Use phone as normal and as output select the speakers. People commonly do this with bluetooth speakers (which have their own issues) or you instead use wifi as described in the fine article.

Your whole question is basically "why would anyone want wireless speakers?".

Sadly, there is no good way to stream sound over wifi from my android phone to the rock64 connected to amplifier

You could probably set the device as a DLNA receiver? https://www.raspberry-pi-geek.com/Archive/2014/08/Using-the-...

Edit: https://www.pimusicbox.com/

I have dlna on the rock64 (volumio), the problem is on android side - there are no tools to capture the sound and stream it to dlna.

Custom apps like BubbleUPnP are not satisfying, I want to stream any app sound - chrome, youtube, any

Have shairplay installed on my Linux desktop to accomplish something similar in the iOS playground.

Anyway to do it without bluetooth?

Sure, run a 3.5mm from the phone to the mic port of any motherboard

I rue the day they remove audio jacks from desktop motherboards. Presumably to improve water resistance.

I’m using shairport-sync for that.

Reply on news.ycombinator.com