61–70 of 136 posts
> ALSA is the core layer of the Linux audio stack. It provides low-level audio hardware control, including drivers for sound cards and basic audio functionality. > ... > Ulike PuleAudio and JACK, PipeWire does not require ALSA on a system, in fact if ALSA is installed the output of ALSA is very likely pushed through PipeWire I don't get this part. If ALSA represents the kernel level hardware drivers for audio, how do…
Earlier quoted context omitted.
Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.
My understanding is that pipewire finally unifies JACK and Pulseaudio. You no longer have to decide if you want a general audio setup or a low-latency one, there's a single audio server now that does everything well. So from that list the unification is now: - JACK and Pulseaudio are both replaced by pipewire - OSS is long gone, ALSA is now the only low-level interface - ESD, NAS, ClanLib, xine, portaudio, allegro an…
In practice, OSS and Jack still stick around, as do portaudio, libao and others.
Earlier quoted context omitted.
Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.
My understanding is that pipewire finally unifies JACK and Pulseaudio. You no longer have to decide if you want a general audio setup or a low-latency one, there's a single audio server now that does everything well. So from that list the unification is now: - JACK and Pulseaudio are both replaced by pipewire - OSS is long gone, ALSA is now the only low-level interface - ESD, NAS, ClanLib, xine, portaudio, allegro an…
I hear many complaining (even here) about "the mess" of linux audio. First, in the article, [1] shows in one single diagram where the complexity is coming from; the audio system has to handle a good deal of different hardware on many different systems and also provide extra functionality for multiplexing, network features, wireless headsets and their codecs, etc. All this: open source. Second: linux is the only platf…
PulseAudio constantly stands out as the most common frustration in all of Linux. systemd is pretty frustrating too, but it's only frustrating the 1% of the time when it breaks (because it means your whole system is broken), whereas the 70% of the time PulseAudio doesn't work, it's more mildly infuriating.
For anything except a single audio in and single audio out, I would not bet on a beginner-to-intermediate ever getting it working, and PulseAudio is probably the main reason I in 2024 cannot recommend Linux on the desktop for non-engineers.
Earlier quoted context omitted.
For me it's been nothing but problems. The primary reason is I'm probably doing things that (almost) nobody else is doing but I assume both countless people are and it should be working fine. Once I hook up some midi devices, want things to be recorded, run a synthesizer stack through pw-jack, expect the midi clock to go down the USB bus, etc, all kinds of interesting behavior starts happening. It even completely loc…
It would be helpful if folks on here who say "works for me"/"doesn't work for me" would indicate which flavour/version of Linux they use. Some distros don't have the latest pipewire stack, and you're left to fend for yourself, having to follow some incomplete or poorly written blog post to side-step what your distro does and put pipewire on top. Me: Ubuntu 24.04 LTS, and happily using carla, ardour, lmms and a bunch…
I have a counter-request: It's really frustrating when people are like "It just works! I had no problem! It's so easy!" in response to someone who has clearly struggled to get things working. It'd be like someone telling you they just had a car crash from a mechanical failure and you responding "Well I didn't! I drove home just fine!"
Instead, if you're going to respond at all, something like "I'm sorry, don't give up. I hope you figure it out" would be nice.
Here's my background 1. I have to modify my audio settings every time I start a call in Teams on Linux because it keeps losing my audio device. 2. In my audio settings UI, half the time I switch my devices the speaker test doesn't work. 3. In my audio settings UI, whenever I switch my mic I hear myself. The mic feedback only disappears 30 seconds after I close the settings UI. 4. My work headsets have a robotic sound…
every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire
I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing devices running multi-tasking OS'es on application processors, in my opinion.
Current issues this article does not address that actually constitute large parts of the "mess" of Linux Audio:
- channel mapping that is not transparent nor clearly assigned anywhere in userspace. (aka, why does my computer insist that my multi-input pro-audio interface is a surround-sound interface? I don't WANT high-pass-filters on the primary L/R pair of channels. I am not USING a subwoofer. WTF)
- the lack of a STANDARD for channel-mapping, vs the Alsa config standards, /etc/asound.conf etc.
- the lack of friendly nomenclature on hardware inputs/outputs for DAW software, whether on the ALSA layer, or some sound-server layer. (not to mention that ALSA calls an 8-channel audio-interface "4 stereo devices")
- probably more, but I can't remember. My current audio production systems have the DAW software directly opening an ALSA device. I cannot listen to audio elsewhere until I quit my DAW. This works and I can set my latency as low as the hardware will allow it.
this is the thing: more than about 10ms latency is unacceptable for audio recording in the multitrack fashion, as one does.
Earlier quoted context omitted.
1. Is a known Problem with Teams
Yeah, teams definitely shares in the blame there. That one hurts more and I blame both microsoft and linux.
Here's my background 1. I have to modify my audio settings every time I start a call in Teams on Linux because it keeps losing my audio device. 2. In my audio settings UI, half the time I switch my devices the speaker test doesn't work. 3. In my audio settings UI, whenever I switch my mic I hear myself. The mic feedback only disappears 30 seconds after I close the settings UI. 4. My work headsets have a robotic sound…
That would be your headset being in headset mode. I'm on Debian Testing, and I'm finally able to exit headset mode and use a high quality audio codec instead. I hope that's the direction Linux is heading.