You are not logged in.

#1 2015-10-03 16:09:35

hhh
Meep!
Registered: 2015-09-17
Posts: 10,582
Website

PulseAudio vs. Alsa

I think we might have less sound issues reported if we use alsa by default and move pulseaudio installation to a menu entry or bl-welcome. Thoughts?

Offline

#2 2015-10-03 16:16:49

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 1,285

Re: PulseAudio vs. Alsa

Doesn't Skype - and other apps - require pulseaudio now?

Might be better to stick with the Debian defaults and have a tutorial thread for removing pulse and installing alsa.

Last edited by PackRat (2015-10-03 16:35:35)


You must unlearn what you have learned.
    -- yoda

Offline

#3 2015-10-03 16:20:32

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

I'm not sure if it will result it less issues per say but I am much better at troubleshooting pure alsa setups. Seems to me like PA just adds another layer to try and deal with when something does go wrong. I also noticed I am having intermittent issues with volti icon disappearing from tint2 as well. I looked at ~/.xsession-errors and it showed nothing. Sound will continue to work, the icon just disappears periodically.

I feel like we really need some scripting in bl-welcome to help people set their sound up. Like parse the output of aplay -l and let people select their cards. If we can come up with a way to assist them in setting it up, it should cut down on the number of help requests.

Offline

#4 2015-10-03 17:53:19

expat2be
Member
From: Las Vegas
Registered: 2015-09-29
Posts: 28
Website

Re: PulseAudio vs. Alsa

While it has never really been much of an issue for me, the audio failure in a VMware installation of BL RC1 "might" have been related to PulseAudio.

Audio distros KXStudio and AVLinux do not use PulseAudio but Ubuntu Studio does.


Radio Jukebox | USB Multiboot Collections | HomeNet Wi-Fi Media Server | Compact Linux Directory | Mobile Web Sites

-- One of those curious distrohopping crunchbangers since the good ole early days back in 2008 --

Offline

#5 2015-10-03 21:38:12

Head_on_a_Stick
Member
From: London
Registered: 2015-09-29
Posts: 8,759
Website

Re: PulseAudio vs. Alsa

PackRat wrote:

Doesn't Skype - and other apps - require pulseaudio now?

^ This.

It's very easy to do without PA if your system only has one soundcard and you don't use USB cards or headsets or multimedia outputs.

For all the other situations, PA makes things very simple to set up.

IMO, the problem in BL at the moment is that a poor mixer is being used for volti.

I would recommend changing the default mixer to pavucontrol as this will reliably set the default output device with a simple and understandable GUI.

I outlined the method here:
http://crunchbang.org/forums/viewtopic. … 53#p435553

Just offering to install PA via the Welcome script risks alienating the type of user who won't even read the script and then wonders why their HDMI output doesn't work properly (or those who choose to extend their system's audio capabilities post-installation).

expat2be wrote:

Audio distros KXStudio and AVLinux do not use PulseAudio

They use JACK instead.


“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.

Forum Rules   •   How to report a problem   •   Software that rocks

Offline

#6 2015-10-03 21:42:18

hhh
Meep!
Registered: 2015-09-17
Posts: 10,582
Website

Re: PulseAudio vs. Alsa

Head_on_a_Stick wrote:

I would recommend changing the default mixer to pavucontrol as this will reliably set the default output device with a simple and understandable GUI.

This is how it's currently set up on GitHub, although the push barely missed the RC1.

Offline

#7 2015-10-03 22:01:52

MrDowntempo
Member
Registered: 2015-09-30
Posts: 20

Re: PulseAudio vs. Alsa

hhh wrote:
Head_on_a_Stick wrote:

I would recommend changing the default mixer to pavucontrol as this will reliably set the default output device with a simple and understandable GUI.

This is how it's currently set up on GitHub, although the push barely missed the RC1.

Oh thank goodness! I was glad I could figure that out on my own, but it's a big deal. I'm glad it's becoming default.

Offline

#8 2015-10-04 00:38:22

MsMattie
Member
Registered: 2015-09-29
Posts: 98

Re: PulseAudio vs. Alsa

I've had at least one audio issue with BL installed from a usb iso. So, is replacing volti with pavucontrol as simple as just using Synaptic to uninstall volti, and then installing pavucontrol? Or, would it be more involved than that?


...
Linux in the backwoods of the Rocky Mountains...

Offline

#9 2015-10-04 01:17:37

hhh
Meep!
Registered: 2015-09-17
Posts: 10,582
Website

Re: PulseAudio vs. Alsa

MsMattie wrote:

So, is replacing volti with pavucontrol as simple as just using Synaptic to uninstall volti, and then installing pavucontrol?

Simpler, pavucontrol is already installed. Right-click the volti systray icon>Preferences>Mixer>uncheck "Use internal mixer", in the External Mixer field manually enter 'pavucontrol' w/out quotes and click the Close button. Now when you right-click the icon>"Show mixer" it opens pavucontrol (also Super+v).

Offline

#10 2015-10-04 03:33:19

MsMattie
Member
Registered: 2015-09-29
Posts: 98

Re: PulseAudio vs. Alsa

Thank you for the help. It worked with one modification...I had to browse to /usr/bin/pavuconrol to get to the full location in the box. It also worked when I just went to alsamixer. And this also solved the problem of having the audio muted every single time I started the laptop. Now the unmute setting holds on each startup. So thanks. It very importantly allows me to listen to my Downton Abbey Christmas music collection.

I also put Skype on and it works right off with these changes. I just followed the terminal commands at debian.org for the Skype install. So, I can now also talk with my chums.

Strangely, when I right click on the little speaker icon in the upper right > Preferences > it still shows Volti just as it did previously. And there is no option up here to go o the volume control, I must use Super > V to do that. But it works so I will leave well enough alone. This Volti seems to have some Borg element which refuses to surrender the machine, but that is another story.

thanks again...


...
Linux in the backwoods of the Rocky Mountains...

Offline

#11 2015-10-05 02:39:47

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 7,337
Website

Re: PulseAudio vs. Alsa

tknomanzr wrote:

I feel like we really need some scripting in bl-welcome to help people set their sound up. Like parse the output of aplay -l and let people select their cards.

Let's have a think about this. If people can suggest the right algorithm, I'll have a go at implementing it.

Tend to agree with PackRat and Head_on_a_Stick that we might be better off sticking with the Debian CrunchBang default, and providing some support for people who want to change - as with systemd.

Last edited by johnraff (2015-10-14 08:58:54)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#12 2015-10-05 08:43:12

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

I think the output of aplay -l would be what you were looking for. For instance here is mine:

**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: CA0132 Analog [CA0132 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 1: CA0132 Digital [CA0132 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

A separate menu entry per card listing perhaps?

That being said, sound worked out of the box with this hardware and PA, which was quite suprising to me. I expected to have issues considering dmesg was showing an error related to ctefx.bin. I am thinking that is Creative's DSP extensions, which I would never use, though.

These two files may be of interest. Sorry about the length but perhaps someone who has done something with them in a PA enviroment may come across them and give some pointers. They come from /etc/pulseuadio.
The first if default.pa

#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

# This startup script is used only if PulseAudio is started per-user
# (i.e. not in system mode)

.nofail

### Load something into the sample cache
#load-sample-lazy x11-bell /usr/share/sounds/freedesktop/stereo/bell.oga
#load-sample-lazy pulse-hotplug /usr/share/sounds/freedesktop/stereo/device-added.oga
#load-sample-lazy pulse-coldplug /usr/share/sounds/freedesktop/stereo/device-added.oga
#load-sample-lazy pulse-access /usr/share/sounds/freedesktop/stereo/message.oga

.fail

### Automatically restore the volume of streams and devices
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore

### Automatically augment property information from .desktop files
### stored in /usr/share/application
load-module module-augment-properties

### Should be after module-*-restore but before module-*-detect
load-module module-switch-on-port-available

### Load audio drivers statically
### (it's probably better to not load these drivers manually, but instead
### use module-udev-detect -- see below -- for doing this automatically)
#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0
#load-module module-oss device="/dev/dsp" sink_name=output source_name=input
#load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=input
#load-module module-null-sink
#load-module module-pipe-sink

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev support)
load-module module-detect
.endif

### Automatically connect sink and source if JACK server is present
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif

### Automatically load driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif

### Load several protocols
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix

### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp
#load-module module-native-protocol-tcp
#load-module module-zeroconf-publish

### Load the RTP receiver module (also configured via paprefs, see above)
#load-module module-rtp-recv

### Load the RTP sender module (also configured via paprefs, see above)
#load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"
#load-module module-rtp-send source=rtp.monitor

### Load additional modules from GConf settings. This can be configured with the paprefs tool.
### Please keep in mind that the modules configured by paprefs might conflict with manually
### loaded modules.
.ifexists module-gconf.so
.nofail
load-module module-gconf
.fail
.endif

### Automatically restore the default sink/source when changed by the user
### during runtime
### NOTE: This should be loaded as early as possible so that subsequent modules
### that look up the default sink/source get the right value
load-module module-default-device-restore

### Automatically move streams to the default sink if the sink they are
### connected to dies, similar for sources
load-module module-rescue-streams

### Make sure we always have a sink around, even if it is a null sink.
load-module module-always-sink

### Honour intended role device property
load-module module-intended-roles

### Automatically suspend sinks/sources that become idle for too long
load-module module-suspend-on-idle

### If autoexit on idle is enabled we want to make sure we only quit
### when no local session needs us anymore.
.ifexists module-console-kit.so
load-module module-console-kit
.endif
.ifexists module-systemd-login.so
load-module module-systemd-login
.endif

### Enable positioned event sounds
load-module module-position-event-sounds

### Cork music/video streams when a phone stream is active
load-module module-role-cork

### Modules to allow autoloading of filters (such as echo cancellation)
### on demand. module-filter-heuristics tries to determine what filters
### make sense, and module-filter-apply does the heavy-lifting of
### loading modules and rerouting streams.
load-module module-filter-heuristics
load-module module-filter-apply

# X11 modules should not be started from default.pa so that one daemon
# can be shared by multiple sessions.

### Load X11 bell module
#load-module module-x11-bell sample=x11-bell

### Register ourselves in the X11 session manager
#load-module module-x11-xsmp

### Publish connection data in the X11 root window
#.ifexists module-x11-publish.so
#.nofail
#load-module module-x11-publish
#.fail
#.endif

### Make some devices default
#set-default-sink output
#set-default-source input

It looks to be responsible for setting uo the sinks via auto-detect but does contain an entry for manually specifying a sound sink.
the second is client.conf

# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB

; auto-connect-localhost = no
; auto-connect-display = no

In a pure alsa environment, I was just setting stuff up in /etc/asound.conf with the correct card settings, based off of aplay -l. This would set the settings up on a system-wide basis. On a per user basis, you would use ~/.asoundrc. Anyway, here's the relevant info from the Alsa Project:
Asoundrc

Offline

#13 2015-10-05 08:52:45

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

Anyway, my thinking is, play a test tone in terminal and ask user if they can hear it. If yes, then no further action needed. If no, then post output of aplay -l to list the cards and ask the user to select one. Once selected, enter the relevant changes into either /etc/asound.conf or default.pa, then test again til the user hears sound and drops out of the loop.

Last edited by tknomanzr (2015-10-05 08:53:06)

Offline

#14 2015-10-05 08:56:37

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 7,337
Website

Re: PulseAudio vs. Alsa

^thanks. Lets have a play with it. If we get really deep into config settings it might be something better handled by the interfaces alredy existing, but if it's a simple choice between two cards (that often seems to be the case) it might be worth doing.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#15 2015-10-05 09:17:10

brontosaurusrex
Middle Office
Registered: 2015-09-29
Posts: 2,107
Website

Re: PulseAudio vs. Alsa

You could use speaker-test (part of alsa-utils), example (of how to limit the length);
https://github.com/brontosaurusrex/post … epspeakers

Offline

#16 2015-10-05 13:17:37

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

Yeah, you are probably looking at Analog, Digital, and one or more HDMI choices. If you set it up in /etc/asound.conf and it does not interfere with the normal operation of PA, then that is the way to go most likely. Chances are I have a sample config sitting around somewhere. It is really about getting that default state set right, then pavucontrol should do the rest for folks.

Offline

#17 2015-10-05 13:32:46

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

I was considering the approach to this a bit more and was wondering if it might not be wise to set the sound config up as a separate script, called bl-sound-config, say. This could then be used as a troubleshooting tool. If no sound cards list on the aplay -l portion, then you know it's a hardware issue, if they do and you have no sound, it's a configuration issue. You could then tie this script back into bl-welcome if you chose.

Offline

#18 2015-10-05 13:41:39

damo
....moderator....
Registered: 2015-08-20
Posts: 6,336

Re: PulseAudio vs. Alsa

tknomanzr wrote:

I was considering the approach to this a bit more and was wondering if it might not be wise to set the sound config up as a separate script, called bl-sound-config, say. This could then be used as a troubleshooting tool. If no sound cards list on the aplay -l portion, then you know it's a hardware issue, if they do and you have no sound, it's a configuration issue. You could then tie this script back into bl-welcome if you chose.

Or have it as a menu entry so it could be used by those who need it: "System -> Sound Configuration"?


Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#19 2015-10-05 13:43:23

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

Yeah or possibly even both. Bl-welcome is nice but no guarantee people will actually use it. Nor do I think having to run through the entire script, when all you really want to do is run the sound config, would be strictly necessary.

Offline

#20 2015-10-05 13:58:10

expat2be
Member
From: Las Vegas
Registered: 2015-09-29
Posts: 28
Website

Re: PulseAudio vs. Alsa

tknomanzr wrote:

I think the output of aplay -l would be what you were looking for.

aplay may help debug sound problems in some cases but it had no relevancy to lack of sound in my VMplayer install of BL RC1. On the same day, I set up BL RC1 and Ubuntu Mate 15.10 Beta2. The aplay -l output was identical for both and yet the sound from Ubuntu Mate worked while BL RC1 audio failed.

One suggestion that I got was to change settings in VLC preference to change audio output from PulseAudio to Alsa or direct hardware. Unfortunately, this had no noticeable effect and when I ran alsamixer in a user terminal session it still showed PulseAudio as the sound source.


Radio Jukebox | USB Multiboot Collections | HomeNet Wi-Fi Media Server | Compact Linux Directory | Mobile Web Sites

-- One of those curious distrohopping crunchbangers since the good ole early days back in 2008 --

Offline

#21 2015-10-05 15:19:58

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

I'm not sure I understand this comment. Your hardware is virtualized in VMware or any other virtual machine for that matter. It has no bearing on actual hardware discussions. If you hardware works yet does not in a virtual machine, then that has to do with the configuration of your virtual machine. If your hardware does not work, then you can hardly expect it to also work in a virtual machine.

Offline

#22 2015-10-05 15:32:19

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

Actually, let me revisit this. Here is the relevant portion from the Alsa Project:

A typical asoundrc starts with a 'PCM hw type'. This gives an ALSA application the ability to start a virtual soundcard (plugin, or slave) by a given name. Without this, the soundcard(s)/devices(s) must be accessed with names like hw:0,0 or default. For example:
aplay -D hw:0,0 test.wav
or with ecasound
ecasound -i test.wav -o alsa,hw:0,0
The numbers after hw: stand for the soundcard number and device number. This can get confusing as some sound "cards" are better represented by calling them sound "devices", for example USB sounddevices. However they are still "cards" in the sense that they have a specific driver controlling a specific piece of hardware. They also correspond to the index shown in
/proc/asound/cards
As with most arrays the first item usually starts at 0 not 1. This is true for the way pcm devices (physical I/O channels) are represented in ALSA. Starting at pcm0c (capture), pcm0p (playback).
We use subdevices mainly for hardware which can mix several streams together. It is impractical to have 32 devices with exactly the same capabilities. The subdevices can be opened without a specific address, so the first free subdevice is opened. Also, we temporarily use subdevices for hardware with a lot of streams (I/O connectors) — for example MIDI. There are several limits given by used minor numbers (8 PCM devices per card, 8 MIDI devices per card etc.).
For example, to access the first device on the first soundcard/device, you would use
hw:0,0
to access the first device on the second soundcard/device, you would use
hw:1,0
to access the second device on the third soundcard/device, you would use
hw:2,1

I assume aplay -l is simply going in and reading the data as populated by the kernel in /proc/asound/cards. What I know for sure happens is that Alsa binds to the first listing in that array that it sees oftentimes, which will end up not being a sensible default. We have no control of the order in which hardware vendors list their card output strings, so we need a way to assist the user in setting up sensible default.

Just out of curiosity, have you checked which kernel version Ubunto Mate is using? Are you sure what you are experiencing is not a hardware related issue? I have no idea what your hardware looks like. What is the output of aplay -l? Do you see cards listed there? If not then Im willing to bet your hardware is not set up correctly.

Last edited by tknomanzr (2015-10-05 15:33:57)

Offline

#23 2015-10-05 16:02:45

expat2be
Member
From: Las Vegas
Registered: 2015-09-29
Posts: 28
Website

Re: PulseAudio vs. Alsa

tknomanzr wrote:

I'm not sure I understand this comment. Your hardware is virtualized in VMware or any other virtual machine for that matter. It has no bearing on actual hardware discussions. If you hardware works yet does not in a virtual machine, then that has to do with the configuration of your virtual machine. If your hardware does not work, then you can hardly expect it to also work in a virtual machine.

That is disputed by the evidence. A USB BL "live session" on the same Lenovo notebook has working audio. A VMware session configured identically for both an "installed" Ubuntu Mate and a BunsenLabs distro yields different audio results. VM Ubuntu Mate audio works. VM BL audio fails.

Last edited by expat2be (2015-10-05 18:07:32)


Radio Jukebox | USB Multiboot Collections | HomeNet Wi-Fi Media Server | Compact Linux Directory | Mobile Web Sites

-- One of those curious distrohopping crunchbangers since the good ole early days back in 2008 --

Offline

#24 2015-10-05 19:39:10

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

I went with a fresh install on my laptop, in which a pure alsa setup always needs manual intervention to get running correctly. I just had a feeling that this was getting overly complicated. Sound worked out of the box, for the first time ever on this hardware. However, volti is throwing an error, the output of which is posted below, when trying to access its preferences:

volti
Traceback (most recent call last):
  File "/usr/lib/volti/volti/menu.py", line 52, in show_preferences
    self.main.preferences.open()
  File "/usr/lib/volti/volti/preferences.py", line 90, in open
    _PREFERENCES = Preferences(self.main)
  File "/usr/lib/volti/volti/preferences.py", line 60, in __init__
    self.read_file()
  File "/usr/lib/volti/volti/preferences.py", line 67, in read_file
    PREFS["control"] = self.cp.get(self.section, "control").strip()
  File "/usr/lib/python2.7/ConfigParser.py", line 618, in get
    raise NoOptionError(option, section)
ConfigParser.NoOptionError: No option 'control' in section: 'card-1'

I am not sure if an issue needs to be raised on git for this or not.
I then installed volumeicon-alsa and it appears to work out of the box.
However, if there are any further issues, then we could consider adding /etc/asound.conf with something like the following:

If the PulseAudio plugin for alsalibs is installed all applications with support for the ALSA API should be able to access 
a PulseAudio server. You need version 1.0.12 or newer of the ALSA packages for the PulseAudio plugin to be included.

To activate the driver edit /etc/asound.conf or ~/.asoundrc and add:

pcm.pulse {
    type pulse
}

ctl.pulse {
    type pulse
}
Now you you can access the PulseAudio server under the virtual ALSA device pulse:

% aplay -Dpulse foo.wav
% amixer -Dpulse
If you want to make the PulseAudio driver the default, use something like this in the ALSA configuration files:

pcm.!default {
    type pulse
    # If defaults.namehint.showall is set to off in alsa.conf, then this is
    # necessary to make this pcm show up in the list returned by
    # snd_device_name_hint or aplay -L
    hint.description "Default Audio Device"
}
ctl.!default {
    type pulse
}
Unlikely side note: If you select the default ALSA device to be "pulse", you need to make sure that PA doesn't try to open 
the "default" device for its own audio output (otherwise the universe will explode... just like if you type "google" into 
Google...) If you have previously manually edited your default.pa loading module-alsa-sink without special device 
argument this means you have to change it to the raw "hw:0" devices. Example:

load-module module-alsa-sink device=hw:0
load-module module-alsa-source device=hw:0

I have actually seen the pcm.pulse stuff before which basically instructs alsa to let pulse handle the hardware setup, if I am understanding it all correctly.

Offline

#25 2015-10-05 19:42:30

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: PulseAudio vs. Alsa

expat2be wrote:
tknomanzr wrote:

I'm not sure I understand this comment. Your hardware is virtualized in VMware or any other virtual machine for that matter. It has no bearing on actual hardware discussions. If you hardware works yet does not in a virtual machine, then that has to do with the configuration of your virtual machine. If your hardware does not work, then you can hardly expect it to also work in a virtual machine.

That is disputed by the evidence. A USB BL "live session" on the same Lenovo notebook has working audio. A VMware session configured identically for both an "installed" Ubuntu Mate and a BunsenLabs distro yields different audio results. VM Ubuntu Mate audio works. VM BL audio fails.

Comparing a 4.2 kernel to a 3.16 kernel could be comparing apples to oranges depending on your hardware. You should probably start a separate support thread with the output of

lspci | grep Audio
sbin/lsmod
uname -r
/proc/asound/cards

Offline

Board footer

Powered by FluxBB