Discussion:
Basic questions about Linux's sound system
(too old to reply)
Peter Nabbefeld
2017-01-31 06:24:29 UTC
Permalink
Raw Message
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
Leonid Isaev
2017-01-31 06:50:58 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
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
+------------+ +-----------+
| 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
Peter Nabbefeld
2017-01-31 07:40:55 UTC
Permalink
Raw Message
Post by Leonid Isaev
Post by Peter Nabbefeld
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
+------------+ +-----------+
| 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.
Ralf Mardorf
2017-01-31 10:43:55 UTC
Permalink
Raw Message
Hi,

I only replied because your graphic shows "Rosegarden". If you should
use Rosegarden, you should get rid of pulseaudio.

[***@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.

[***@archlinux ~]$ pactree -r pulseaudio
pulseaudio
└─pulseaudio-alsa
├─cinnamon-settings-daemon
│ ├─cinnamon
│ └─cinnamon-control-center
│ └─cinnamon
└─vokoscreen
[***@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.

[***@archlinux ~]$ ls /var/aur3/gnome-settings-daemon-nopulse/
gnome-settings-daemon.install PKGBUILD

Regards,
Ralf
Peter Nabbefeld
2017-01-31 11:41:06 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Hi,
I only replied because your graphic shows "Rosegarden". If you should
use Rosegarden, you should get rid of pulseaudio.
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.
pulseaudio
└─pulseaudio-alsa
├─cinnamon-settings-daemon
│ ├─cinnamon
│ └─cinnamon-control-center
│ └─cinnamon
└─vokoscreen
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.
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
Ralf Mardorf
2017-01-31 12:09:13 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
+-----------+
| 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
Ralf Mardorf
2017-01-31 12:12:36 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by Peter Nabbefeld
+-----------+
| 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.
Peter Nabbefeld
2017-01-31 12:23:02 UTC
Permalink
Raw Message
Post by Ralf Mardorf
Post by Ralf Mardorf
Post by Peter Nabbefeld
+-----------+
| 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.
Ralf Mardorf
2017-01-31 12:43:25 UTC
Permalink
Raw Message
Post by Peter Nabbefeld
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.

[***@archlinux ~]$ pacman -Si pulseaudio | grep Des
Description : A featureful, general-purpose sound server

Regards,
Ralf
Jude DaShiell
2017-01-31 15:29:12 UTC
Permalink
Raw Message
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.
Date: Tue, 31 Jan 2017 05:43:55
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.
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.
pulseaudio
??pulseaudio-alsa
??cinnamon-settings-daemon
? ??cinnamon
? ??cinnamon-control-center
? ??cinnamon
??vokoscreen
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.
gnome-settings-daemon.install PKGBUILD
Regards,
Ralf
--
Ralf Mardorf
2017-01-31 16:10:08 UTC
Permalink
Raw Message
Post by Jude DaShiell
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
Jude DaShiell
2017-01-31 16:38:19 UTC
Permalink
Raw Message
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.
Date: Tue, 31 Jan 2017 11:10:08
Subject: Re: [arch-general] Basic questions about Linux's sound system
Post by Jude DaShiell
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
--
Joakim Hernberg
2017-01-31 18:09:29 UTC
Permalink
Raw Message
On Tue, 31 Jan 2017 11:38:19 -0500 (EST)
Post by Jude DaShiell
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
Loading...