[arch-general] Basic questions about Linux's sound system
Hello, semms I'm missing some basic parts of the sound system. I've been told, ALSA is for the hardware, pulseaudio is for the infrastructure, and bluez provides for virtual bluetooth devices, so I understand it should look like this (ASCII graphics, please use monospaced font for viewing): +------------+ +-----------+ | Rosegarden | | Totem | +------------+ +-----------+ +-----------------+ | Jack | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Pulseaudio (PA) | +--------------------+---+-------------------------+ | ALSA | | Bluez | +--------------------+ +-------------------------+ This would imply, that ALSA cannot "see" Bluetooth devices, but that seems not to be the fact, so there's probably a misconfiguration on my laptop. There's a bridge (bluez-alsa-git) in the AUR, but I haven't installed it, so why can ALSA see my headset? I'm asking this because of problems with HSP/HDP profile with my headset - if I've "coupled" the modules the wrong way, they'll probably block each other's functionality - especially, if ALSA and pulseaudio try to use the Bluez device at the same time ... Kind regards Peter
On Tue, Jan 31, 2017 at 07:24:29AM +0100, Peter Nabbefeld wrote:
Hello,
semms I'm missing some basic parts of the sound system. I've been told, ALSA is for the hardware, pulseaudio is for the infrastructure, and bluez provides for virtual bluetooth devices, so I understand it should look like this (ASCII graphics, please use monospaced font for viewing):
+------------+ +-----------+ | Rosegarden | | Totem | +------------+ +-----------+ +-----------------+ | Jack | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Pulseaudio (PA) | +--------------------+---+-------------------------+ | ALSA | | Bluez | +--------------------+ +-------------------------+
This would imply, that ALSA cannot "see" Bluetooth devices, but that seems not to be the fact, so there's probably a misconfiguration on my laptop. There's a bridge (bluez-alsa-git) in the AUR, but I haven't installed it, so why can ALSA see my headset?
ALSA "sees" audio devices as reported by the kernel. If the kernel / udev registers your bluetooth headset as an audio device, you should be able to control it through ALSA. This is similar to USB network adapters, for example. Cheers, -- Leonid Isaev
Am 31.01.2017 um 07:50 schrieb Leonid Isaev:
On Tue, Jan 31, 2017 at 07:24:29AM +0100, Peter Nabbefeld wrote:
Hello,
semms I'm missing some basic parts of the sound system. I've been told, ALSA is for the hardware, pulseaudio is for the infrastructure, and bluez provides for virtual bluetooth devices, so I understand it should look like this (ASCII graphics, please use monospaced font for viewing):
+------------+ +-----------+ | Rosegarden | | Totem | +------------+ +-----------+ +-----------------+ | Jack | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Pulseaudio (PA) | +--------------------+---+-------------------------+ | ALSA | | Bluez | +--------------------+ +-------------------------+
This would imply, that ALSA cannot "see" Bluetooth devices, but that seems not to be the fact, so there's probably a misconfiguration on my laptop. There's a bridge (bluez-alsa-git) in the AUR, but I haven't installed it, so why can ALSA see my headset?
ALSA "sees" audio devices as reported by the kernel. If the kernel / udev registers your bluetooth headset as an audio device, you should be able to control it through ALSA. This is similar to USB network adapters, for example.
Cheers,
Thank You! :) Kind regards P.
Hi, I only replied because your graphic shows "Rosegarden". If you should use Rosegarden, you should get rid of pulseaudio. [rocketmouse@archlinux ~]$ pacman -Qi rosegarden | grep Dep Depends On : liblrdf dssi fftw lirc perl qt5-tools shared-mime-info liblo>=0.28 Optional Deps : lilypond: notation display Pulseaudio is not good for this kind of task. ALSA is the only thing required for sound, since it's the layer with the audio drivers. Pulseaudio needs ALSA, but ALSA doesn't need pulseaudio. The people responsible for pulseaudio made a lot of noise when pulseaudio didn't work correctly with ALSA, while ALSA on it's own worked. It's a "consortium" of coders who cause a lot of trouble, not only with pulseaudio. Soundservers such as pulseaudio or jackd provide some comfort. For the desktop I just use the bell (beep of the PC speaker) and an audio interface for webradio, videos and things like this. Only for audio productions I'm using a sound server, jackd. You only need crappy sound servers such as pulseaudio for software that is bad programmed, AFAIK it's skype or if you want to listen to webradio and recycle bin crackles at the same time, without using ALSA's dmix. AFAIK pulseaudio allows you to play a video and a media player at the same time using different sample rates. In short, without some kind of "patch bay" only one app could use a single audio device. A sound server provides the comfort to connect several apps to a single audio device. From my audio engineer's point of view, everybody who uses pulseaudio either makes something fundamentally wrong or is a lazy android who wants to listen to several sound sources at the same time, without configuring plain ALSA to do it. I doubt that many humans seriously like to listen to several sound sources at the same time. For audio productions OTOH it makes sense to have a virtual patch bay that is real-time capable and in addition easily allows to chose sample rate and frames, so jackd makes sense for such a task, but even in this context using pulseaudio still would be counter-productive. IMO pulseaudio is good for absolutely nothing, but just could be the cause for serious issues. I installed a dummy package, just in case pulseaudio should be a hard dependency for software, that actually doesn't need it, because I don't want to rebuild those packages without the pulseaudio requirement. [rocketmouse@archlinux ~]$ pactree -r pulseaudio pulseaudio └─pulseaudio-alsa ├─cinnamon-settings-daemon │ ├─cinnamon │ └─cinnamon-control-center │ └─cinnamon └─vokoscreen [rocketmouse@archlinux ~]$ pacman -Qi pulseaudio | head -12 Name : pulseaudio Version : 2013.08.18-1 Description : Dummy package Architecture : any URL : None Licenses : None Groups : None Provides : pulseaudio Depends On : None Optional Deps : None Required By : pulseaudio-alsa Optional For : fluidsynth phonon-qt4 phonon-qt5 speech-dispatcher It's to funny, I never used cinnamon and never used vokoscreen,so I could remove them. However, in the past I used some software with a hard dependency to pulseaudio without having pulseaudio installed. Much likely cinnamon and vokoscreen will work without pulseaudio, too. The old AUR once provided gnome-settings-daemon-nopulse. [rocketmouse@archlinux ~]$ ls /var/aur3/gnome-settings-daemon-nopulse/ gnome-settings-daemon.install PKGBUILD Regards, Ralf
Am 31.01.2017 um 11:43 schrieb Ralf Mardorf:
Hi,
I only replied because your graphic shows "Rosegarden". If you should use Rosegarden, you should get rid of pulseaudio.
[rocketmouse@archlinux ~]$ pacman -Qi rosegarden | grep Dep Depends On : liblrdf dssi fftw lirc perl qt5-tools shared-mime-info liblo>=0.28 Optional Deps : lilypond: notation display
Pulseaudio is not good for this kind of task.
ALSA is the only thing required for sound, since it's the layer with the audio drivers. Pulseaudio needs ALSA, but ALSA doesn't need pulseaudio. The people responsible for pulseaudio made a lot of noise when pulseaudio didn't work correctly with ALSA, while ALSA on it's own worked. It's a "consortium" of coders who cause a lot of trouble, not only with pulseaudio. Soundservers such as pulseaudio or jackd provide some comfort. For the desktop I just use the bell (beep of the PC speaker) and an audio interface for webradio, videos and things like this. Only for audio productions I'm using a sound server, jackd. You only need crappy sound servers such as pulseaudio for software that is bad programmed, AFAIK it's skype or if you want to listen to webradio and recycle bin crackles at the same time, without using ALSA's dmix. AFAIK pulseaudio allows you to play a video and a media player at the same time using different sample rates. In short, without some kind of "patch bay" only one app could use a single audio device. A sound server provides the comfort to connect several apps to a single audio device. From my audio engineer's point of view, everybody who uses pulseaudio either makes something fundamentally wrong or is a lazy android who wants to listen to several sound sources at the same time, without configuring plain ALSA to do it. I doubt that many humans seriously like to listen to several sound sources at the same time. For audio productions OTOH it makes sense to have a virtual patch bay that is real-time capable and in addition easily allows to chose sample rate and frames, so jackd makes sense for such a task, but even in this context using pulseaudio still would be counter-productive.
IMO pulseaudio is good for absolutely nothing, but just could be the cause for serious issues.
I installed a dummy package, just in case pulseaudio should be a hard dependency for software, that actually doesn't need it, because I don't want to rebuild those packages without the pulseaudio requirement.
[rocketmouse@archlinux ~]$ pactree -r pulseaudio pulseaudio └─pulseaudio-alsa ├─cinnamon-settings-daemon │ ├─cinnamon │ └─cinnamon-control-center │ └─cinnamon └─vokoscreen [rocketmouse@archlinux ~]$ pacman -Qi pulseaudio | head -12 Name : pulseaudio Version : 2013.08.18-1 Description : Dummy package Architecture : any URL : None Licenses : None Groups : None Provides : pulseaudio Depends On : None Optional Deps : None Required By : pulseaudio-alsa Optional For : fluidsynth phonon-qt4 phonon-qt5 speech-dispatcher
It's to funny, I never used cinnamon and never used vokoscreen,so I could remove them. However, in the past I used some software with a hard dependency to pulseaudio without having pulseaudio installed. Much likely cinnamon and vokoscreen will work without pulseaudio, too. The old AUR once provided gnome-settings-daemon-nopulse.
[rocketmouse@archlinux ~]$ ls /var/aur3/gnome-settings-daemon-nopulse/ gnome-settings-daemon.install PKGBUILD
Regards, Ralf
Thank You Ralf, now as I understand Pulseaudio ist also a sound server, I've changed my overview to this - hopefully this time it's correct: +-----------+ | Totem | +------------+ +-----------+ +-----------------+ | Rosegarden | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Jack | Pulseaudio (PA) | +------------+-------------------------------------+ | ALSA - Bluez | +--------------------------------------------------+ As I need Jack for Rosegarden (though I'd not really need Rosegarden, just playing a little bit around for interest in it as an application), I'd next look which programs use PA to find out, if it is needed by any important piece of software, so I could probably remove it. However, I'll need bluez-alsa then to get my headset working, because bluez > 5 doesn't support that anymore (probably even dependent on PA). Kind regards Peter
On Tue, 31 Jan 2017 12:41:06 +0100, Peter Nabbefeld wrote:
+-----------+ | Totem | +------------+ +-----------+ +-----------------+ | Rosegarden | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Jack | Pulseaudio (PA) | +------------+-------------------------------------+ | ALSA - Bluez | +--------------------------------------------------+
Hi, I can't comment "Bluez", I don't know how this works. Anyway, it's Still incorrect, since only one sound server could grab the audio device, the other sound sever needs to use the sound server connected to ALSA. +-------------+ | Application | +-------------+ +-------------------+ | Application | | One sound server | +----------------------------------------+ | Another Soundserver connects with ALSA | +------------+---------------------------+ | ALSA connects software and hardware | +----------------------------------------+ | Hardware | +----------------------------------------+ That's simplified, but in this context IMO good enough. Regards, Ralf
On Tue, 31 Jan 2017 13:09:13 +0100, Ralf Mardorf wrote:
On Tue, 31 Jan 2017 12:41:06 +0100, Peter Nabbefeld wrote:
+-----------+ | Totem | +------------+ +-----------+ +-----------------+ | Rosegarden | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Jack | Pulseaudio (PA) | +------------+-------------------------------------+ | ALSA - Bluez | +--------------------------------------------------+
Hi,
I can't comment "Bluez", I don't know how this works. Anyway, it's Still incorrect, since only one sound server could grab the audio device, the other sound sever needs to use the sound server connected to ALSA.
+-------------+ | Application | +-------------+ +-------------------+ | Application | | One sound server | +----------------------------------------+ | Another Soundserver connects with ALSA | +------------+---------------------------+ | ALSA connects software and hardware | +----------------------------------------+ | Hardware | +----------------------------------------+
That's simplified, but in this context IMO good enough.
Regards, Ralf
PS: One sound server not necessarily needs to use the other, if you stop one sound sever, before only using the other sound sever, but if you use both at the same time, one sound server has direct ALSA access, the other doesn't have.
Am 31.01.2017 um 13:12 schrieb Ralf Mardorf:
On Tue, 31 Jan 2017 13:09:13 +0100, Ralf Mardorf wrote:
On Tue, 31 Jan 2017 12:41:06 +0100, Peter Nabbefeld wrote:
+-----------+ | Totem | +------------+ +-----------+ +-----------------+ | Rosegarden | | GStreamer | | Appl. using PA | +------------+---+-----------+---+-----------------+ | Jack | Pulseaudio (PA) | +------------+-------------------------------------+ | ALSA - Bluez | +--------------------------------------------------+
Hi,
I can't comment "Bluez", I don't know how this works. Anyway, it's Still incorrect, since only one sound server could grab the audio device, the other sound sever needs to use the sound server connected to ALSA.
+-------------+ | Application | +-------------+ +-------------------+ | Application | | One sound server | +----------------------------------------+ | Another Soundserver connects with ALSA | +------------+---------------------------+ | ALSA connects software and hardware | +----------------------------------------+ | Hardware | +----------------------------------------+
That's simplified, but in this context IMO good enough.
Regards, Ralf
PS: One sound server not necessarily needs to use the other, if you stop one sound sever, before only using the other sound sever, but if you use both at the same time, one sound server has direct ALSA access, the other doesn't have.
Yes, that's what the configuration should do (automatic switching of servers), which I copied from the wiki. I've only not been aware of that pulseaudio is a sound server, too. Thank You for pointing this out! Regards P.
On Tue, 31 Jan 2017 13:23:02 +0100, Peter Nabbefeld wrote:
Yes, that's what the configuration should do (automatic switching of servers), which I copied from the wiki. I've only not been aware of that pulseaudio is a sound server, too.
Thank You for pointing this out!
You are welcome! It's a good idea to turn off pulseaudio when using Rosegarden with Jack. [rocketmouse@archlinux ~]$ pacman -Si pulseaudio | grep Des Description : A featureful, general-purpose sound server Regards, Ralf
The consortium is freedesktop.org and it also made wifi-menu. However, in terms of pulseaudio I think in many instances it's more trouble than helpful. For one thing, the terminology in the software is alien to alsa and sometimes pulseaudio gets confused and I have to use a script to correct the sound output over here that handles alsa and straightens my configuration out. People using orca have had and have issues with pulseaudio too. On Tue, 31 Jan 2017, Ralf Mardorf wrote:
Date: Tue, 31 Jan 2017 05:43:55 From: Ralf Mardorf <silver.bullet@zoho.com> Reply-To: General Discussion about Arch Linux <arch-general@archlinux.org> To: arch-general@archlinux.org Subject: Re: [arch-general] Basic questions about Linux's sound system
Hi,
I only replied because your graphic shows "Rosegarden". If you should use Rosegarden, you should get rid of pulseaudio.
[rocketmouse@archlinux ~]$ pacman -Qi rosegarden | grep Dep Depends On : liblrdf dssi fftw lirc perl qt5-tools shared-mime-info liblo>=0.28 Optional Deps : lilypond: notation display
Pulseaudio is not good for this kind of task.
ALSA is the only thing required for sound, since it's the layer with the audio drivers. Pulseaudio needs ALSA, but ALSA doesn't need pulseaudio. The people responsible for pulseaudio made a lot of noise when pulseaudio didn't work correctly with ALSA, while ALSA on it's own worked. It's a "consortium" of coders who cause a lot of trouble, not only with pulseaudio. Soundservers such as pulseaudio or jackd provide some comfort. For the desktop I just use the bell (beep of the PC speaker) and an audio interface for webradio, videos and things like this. Only for audio productions I'm using a sound server, jackd. You only need crappy sound servers such as pulseaudio for software that is bad programmed, AFAIK it's skype or if you want to listen to webradio and recycle bin crackles at the same time, without using ALSA's dmix. AFAIK pulseaudio allows you to play a video and a media player at the same time using different sample rates. In short, without some kind of "patch bay" only one app could use a single audio device. A sound server provides the comfort to connect several apps to a single audio device. From my audio engineer's point of view, everybody who uses pulseaudio either makes something fundamentally wrong or is a lazy android who wants to listen to several sound sources at the same time, without configuring plain ALSA to do it. I doubt that many humans seriously like to listen to several sound sources at the same time. For audio productions OTOH it makes sense to have a virtual patch bay that is real-time capable and in addition easily allows to chose sample rate and frames, so jackd makes sense for such a task, but even in this context using pulseaudio still would be counter-productive.
IMO pulseaudio is good for absolutely nothing, but just could be the cause for serious issues.
I installed a dummy package, just in case pulseaudio should be a hard dependency for software, that actually doesn't need it, because I don't want to rebuild those packages without the pulseaudio requirement.
[rocketmouse@archlinux ~]$ pactree -r pulseaudio pulseaudio ??pulseaudio-alsa ??cinnamon-settings-daemon ? ??cinnamon ? ??cinnamon-control-center ? ??cinnamon ??vokoscreen [rocketmouse@archlinux ~]$ pacman -Qi pulseaudio | head -12 Name : pulseaudio Version : 2013.08.18-1 Description : Dummy package Architecture : any URL : None Licenses : None Groups : None Provides : pulseaudio Depends On : None Optional Deps : None Required By : pulseaudio-alsa Optional For : fluidsynth phonon-qt4 phonon-qt5 speech-dispatcher
It's to funny, I never used cinnamon and never used vokoscreen,so I could remove them. However, in the past I used some software with a hard dependency to pulseaudio without having pulseaudio installed. Much likely cinnamon and vokoscreen will work without pulseaudio, too. The old AUR once provided gnome-settings-daemon-nopulse.
[rocketmouse@archlinux ~]$ ls /var/aur3/gnome-settings-daemon-nopulse/ gnome-settings-daemon.install PKGBUILD
Regards, Ralf
--
On Tue, 31 Jan 2017 10:29:12 -0500 (EST), Jude DaShiell wrote:
The consortium is freedesktop.org
No, I was thinking about 2 very selfish coders with very contemptuous, bad manners, one is a "special" friend of Linus Torvalds, IOW Mr. Torvalds is very upset, the other coder mainly responsible for pulseaudio, didn't behave better, when pulseaudio failed. Both follow a "fix your software, when my software is buggy, to make my software work" attitude. They might have contributed good things to Linux, but live often is easier without some of their programming. However, this is the wrong place to wake up this discussion again. I only chime in, because I guess it's important to recommend against pulseaudio, when a user mentions to use Rosegarden or similar real-time audio related software. Regards, Ralf
It helps when screen reading or speech synthesis is real time or as near to real time as possible. Thanks for putting this information out since I could use one set of speakers for speech and another set I have connected for other audio when I can figure out how to get it correctly configured until you replied, I didn't even know this was possible. On Tue, 31 Jan 2017, Ralf Mardorf wrote:
Date: Tue, 31 Jan 2017 11:10:08 From: Ralf Mardorf <silver.bullet@zoho.com> Reply-To: General Discussion about Arch Linux <arch-general@archlinux.org> To: arch-general@archlinux.org Subject: Re: [arch-general] Basic questions about Linux's sound system
On Tue, 31 Jan 2017 10:29:12 -0500 (EST), Jude DaShiell wrote:
The consortium is freedesktop.org
No, I was thinking about 2 very selfish coders with very contemptuous, bad manners, one is a "special" friend of Linus Torvalds, IOW Mr. Torvalds is very upset, the other coder mainly responsible for pulseaudio, didn't behave better, when pulseaudio failed. Both follow a "fix your software, when my software is buggy, to make my software work" attitude. They might have contributed good things to Linux, but live often is easier without some of their programming. However, this is the wrong place to wake up this discussion again. I only chime in, because I guess it's important to recommend against pulseaudio, when a user mentions to use Rosegarden or similar real-time audio related software.
Regards, Ralf
--
On Tue, 31 Jan 2017 11:38:19 -0500 (EST) Jude DaShiell <jdashiel@panix.com> wrote:
It helps when screen reading or speech synthesis is real time or as near to real time as possible. Thanks for putting this information out since I could use one set of speakers for speech and another set I have connected for other audio when I can figure out how to get it correctly configured until you replied, I didn't even know this was possible.
My 2 cents ;) I'll skip the anti PA stuff, but note that it's possibly not the best to use in conjunction with JACK, as it's not intended for low latency audio, and the pulse to jack bridge seems to occasionally cause xruns on my systems. That said it seems to work more or less well. Personally I kept it off my systems for many years, but have lately started caving in ;) On my desktop I run it on a separate card to the one that I use for jack, and I have a mixer which i use to control output level from the 2 cards. PA is used for all the desktop audio, and jack for my reaper (daw) work in wine. On the laptop I mostly use 2 cards too, so same scenario, but I also have it setup so that I can bring up a bridge so the desktop audio (PA) will go to jack instead of the builtin card. I can also run jack on the builtin and let PA connect to it. I even know of a few people that run PA on the alsa loopback device, and then use alsa_in/out or zita-a2jbridge to connect the loopback to jack :) -- Joakim
participants (5)
-
Joakim Hernberg
-
Jude DaShiell
-
Leonid Isaev
-
Peter Nabbefeld
-
Ralf Mardorf