Live data from Hacker News

PipeWire: The Linux audio/video bus

lwn.net

151–160 of 203 posts

Re: PipeWire: The Linux audio/video bus

#151
post #98
post #48

> Second, D-Bus was replaced as the IPC protocol. Instead, a native fully asynchronous protocol that was inspired by Wayland — without the XML serialization part — was implemented over Unix-domain sockets. Taymans wanted a protocol that is simple and hard-realtime safe. I'm surprised to read this; I was under the impression that D-Bus was the de jure path forward for interprocess communication like this. That's not t…

Well, D-Bus was originally designed to solve the problem of... a message bus. So you can pass messages down the bus and multiple consumers can see it, you can call "into" other bus services as a kind of RPC, etc. Even today, there's no real alternative, natively-built solution to the message bus problem for Linux. There have been various proposals to solve this directly in Linux (e.g. multicast AF_UNIX, bus1, k-dbus)…

> The biggest is multicast; as far as I know there's just no good way to write a message once and have it appear atomically for N listeners, without D-Bus...

I once wrote a proof of concept that uses the file system to do this. Basically, writers write their message as a file to a directory that readers watch via inotify. When done in a RAM based file system like tmpfs, you need not even touch the disk. There are security and permission snags that I hadn't thought of and it may be difficult if not totally infeasible to work in production, but yeah... the file system is pretty much the traditional one-to-many communication channel.

Re: PipeWire: The Linux audio/video bus

#153

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

If you use Arch Linux, it's really easy to just drop this right in from official packages as a replacement for Pulse/ALSA [0] and start using it. I've been running it for about a month and everything seems to work exactly as I expect it to. I honestly notice no difference other than the pulse audio input/output picker extension I had been using seems confused now (the native GNOME sound control panel applet works jus…

Thanks for this, I was wondering if a future Arch update would just auto install this and I would be left wondering what happened when it broke. I am going to remember your post here and try to upgrade to it soon!

Re: PipeWire: The Linux audio/video bus

#154
post #85
post #58

Earlier quoted context omitted.

That's a very old wiki page with decades old workaround for decade old issues. I'm not saying you are wrong, but if you take this impression solely from that wiki page you are likely mislead. Afaik this always works and did for many years - but I might be wrong and always only lucky with all the systems where I tested it?

I think you've hit one of the most painful topics of ALSA: Its documentation.

Yes, you can do an incredible amount of very useful stuff with ALSA and it's asoundrc files.

Sadly that logic is quite opaque, poorly documented, and produces mysterious error messages or, worse, no error at all.

Re: PipeWire: The Linux audio/video bus

#155

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

What in particular do you want/ expect from AVRCP here?

I can't tell, but it sounds like the two things it might do for me are:

1. Allow my software stack to remember and restore levels on a hardware device, so maybe my big on-ear headset is super loud compared to the cheap earbuds I use, lets have the software notice they're different and put the hardware output levels back where they were on each device when it sees them. This avoids the device (which presumably is battery powered) needing to correctly remember how it was set up. I would like this.

2. Try to avoid noise from analogue amplifier stages in the headset by only using as much amplification as is strictly needed for current volume settings, which in turn involves guessing how linear (or not) that amplifier's performance is, or makes my level controls needlessly coarse. I don't want this, I'll put up with it but mostly by finding settings where it's not too annoying and swearing every time it trips up.

Re: PipeWire: The Linux audio/video bus

#156
post #146

Everybody had trouble with PulseAudio, even people who liked it in principle. LP wasn't joking about breaking sound: things did break, many, many times for many, many people, for years. And, almost always the only information readily available about what went wrong was just sound no longer coming out, or going in. And, almost always the reliable fix was to delete PA. But it really was often a consequence of something…

For the vast majority of audio needs Rust is portable enough to cover x86, ARM, MIPS-based platforms. Probably 99% of users that need this kind audio/video multiplexing.

Re: PipeWire: The Linux audio/video bus

#157
post #67
post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

The ALSA interface can actually refer to two different things: 1. The ALSA kernel interface 2. The interface provided by libasound2 The former is basically the device files living in /dev/snd, this interface is hardware dependent and whether you can or cannot send multiple streams to the sound card all depends on the actual underlying hardware and driver support. The later is actually a shared library that when linke…

I've found https://www.volkerschatz.com/noise/alsa.html to be a good overview of ALSA's architecture (though many of the things mentioned, like ogg123, are no longer in common use).

Re: PipeWire: The Linux audio/video bus

#158
post #120

Earlier quoted context omitted.

Same what FreeBSD has done: keep developing Open Source OSS. One implementation going non-free doesn't affect other implementations of the same API.

Didn't they do that by developing ALSA OSS emulation? That is effectively another implementation of the same API.

Libalsa is there in FreeBSD ports, but it's only for backward compatibility with Linux, and it's only userspace parts. The kernel implements OSS API.

Re: PipeWire: The Linux audio/video bus

#159
post #55
post #45

Earlier quoted context omitted.

Trivia: Some sound cards (eg pas16) showed up as multiple devices using OSS too and you could output pcm audio to 2 simultaneously.

Trivia, FreeBSD looked at Alsa and decided they were using a rewrite as an excuse to not fix OSS and so they dug in and fixed OSS so it worked.

You know how some people say C thinks every computer is just a fancier PDP-11 ?

OSS thinks every computer's audio playback devices are just fancier CT Soundblasters.

If you've got a typical generic PC with Intel HDA or AC'97 (or indeed, an actual PCI Soundblaster) and what you'd like to have happen is that you can run your VoIP software, and listen to MP3s and also have new mails go "bing!" then "all the world is a Soundblaster 16" is close enough.

But if you've got a USB headset you plug in to take those VoIP calls, and a pair of bluetooth earbuds for listening to music, but you want new mail noises on speakers - you will start to struggle. These things aren't enough like a Soundblaster, neither in terms of how they're actually working nor in terms of how you expect to use them.

PulseAudio does a much better job there, because it's the right shape, and now it seems PipeWire is a better shape for modern environments where it's not necessarily OK for the software that plays smooth jazz from the Internet to be technically capable of listening in on your video conference calls.

Re: PipeWire: The Linux audio/video bus

#160

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Did you get 2—way (in & out) 16khz Bluetooth to work? Am I right that this isn't possible?

I believe when the HFP profile is used and mSBC is supported, then mSBC is used for both the input and output.
Post reply on HN