161–170 of 203 posts
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.…
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 see…
There's some work on getting AVRCP absolute volume implemented here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/46...
I believe your first point should automatically work once this is implemented. Pipewire seems to already support remembering the volume per bluetooth device (though it's just the software volume that's being remembered right now).
I'm currently trying pipewire on openSUSE Tumbleweed. I'm very impressed with it so far. (After realizing it was broken, because I didn't have the pipewire-alsa package installed => No audio devices) The pulse drop-in worked flawlessly out of the box. I'd had some isssues with the jack drop-in libraries tho. (metalic voice, basically not useable) To fix this, I had to change the sample rate in /etc/pipewire/pipewire.…
Earlier quoted context omitted.
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.
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.
Sounds on linux is a shitshow.
I wanted to give this a spin, but it’s seemingly not packaged in a meaningful way on Ubuntu yet. That is, there is no pipewire-pulse, pipewire-jack, etc. Oh well. Maybe next version?
> 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)…
> Well, D-Bus was originally designed to solve the problem of... a message bus.
I guess no one has ever told me what the "message bus problem" actually is. I get sending messages -- a very useful way of structuring computation, but why do I want a message _bus_?
I get wanting service discovery, but don't see why that means a bus. I get wanting RPC, but don't see why that means a bus.
Heck, I don't even know what "have it appear atomically for N listeners" means if you have less than N CPUs or the listeners are scheduled separately. Or why that's a good thing. Did you just mean globally consistent ordering of all messages?
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.
Nah, another audio daemon is not what Linux needs IMO. This should be merged into the kernel, especially since process isolation is one of the stated goals. Running hard realtime stuff in a user space that is designed to not provide useful guarantees related to hard deadlines is brave, but ultimately somewhat foolish. I know that there are arguments against having high quality audio rate resampling inside the kernel…
So every VST/Virtual instrument in a DAW or for live performance should be running in the kernel? Because that's definitely a fresh take.
Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which…
> extremely low latency How low is "extremely low", especially compared to JACK that I'm currently using when doing music production?