You are not logged in.
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
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
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
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
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
cat /proc/asound/cards
FTFY
Offline
I was able to get everything working in volti with this configuration in ~/.config/volti/config
[card-0]
control = Master
mask_lock = 0
[global]
mixer_show_values = 1
scale_increment = 1.0
card_index = 1
icon_theme = Default
scale_show_value = 0
mixer = pavucontrol
show_tooltip = 1
notify_position = 0
keys = 1
toggle = mute
mixer_internal = 0
notify_body = <span font_desc="14" weight="bold">{volume}</span>
<small>{card}</small>
<small>{mixer}</small>
keys_backend = xlib
run_in_terminal = 0
notify_timeout = 2.0
show_notify = 1
[card-1]
control = Master
mask_lock = 0
mask_control = 2047
Relevant changes were: add control = Master to the [card-1] section. It was what was throwing the error when I attempted to access volti's preferences. Changed mixer to pavucontrol, mixer internal = 0, run in terminal = 0. With the preferences working again, I could have changed this all in the gui. I am providing the file for reference as volti is not currently configured to use pavucontrol.
Offline
wondering if it might not be wise to set the sound config up as a separate script, called bl-sound-config, say.
This sounds like the way to go, as it might take quite some tinkering to get it right. When it's all shiny and sparkling it can be triggered from bl-welcome as needed.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Anyway, I threw a ton at you. Sometimes in Linux you end up in a rabbit hole and sometimes you and up in an entire dang warren of them.
Offline
This bug affects me...
https://bugs.launchpad.net/xfce4-volumed/+bug/883485
My aplay -l...
~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CX20561 Analog [CX20561 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: CX20561 Digital [CX20561 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
On my hardware (Lenovo T500), uninsalling pulseaudio and pavucontrol and installing alsa-base (kmod) is the easiest solution. The other solution is to install the BL backport of xfce4-volumed, but this hasn't been tested by us enough...
http://pkg.bunsenlabs.org/debian/pool/m … 4-volumed/
I don't care what you do at home. Would you care to explain?
Offline
I have done quite a bit of research on this in the past few days and have some things to report. It should in theory be possible to properly have more automated sound setup by allowing PA to handle the configuration. This would conform to behavior we have come to expect where stuff "just works" with sound.
The relevant stuff that needs to be setup will be in /etc/asound.conf and should look like this per PA's wiki:
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
}
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
However, when I attempt to start volti by intentionally starting it with a config setup to the default card, which in Alsa would be card 0, I get this error:
tknomanzr@test:~$ [alsactrl.py:__init__:41] can't open Master control for card HDMI, trying to select first available mixer channel
[alsactrl.py:__init__:49] can't open first available control for card HDMI
error: list index out of range
[main.py:init_keys_events:142] org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Hal was not provided by any .service files
Traceback (most recent call last):
File "/usr/bin/volti", line 53, in <module>
volti = main.VolumeTray()
File "/usr/lib/volti/volti/main.py", line 124, in __init__
self.watchid = gobject.io_add_watch(fd, eventmask, self.update)
TypeError: an integer is required
The part that interested me most was this:
The name org.freedesktop.Hal was not provided by any .service files
Now, when I start volti up with what I know to be the proper card, I don't get an assertion error but do get the same warning about HAL.
As a quick test I tested volumeicon-alsa out with the same process. volumeicon allows you to either specify card = default or an integer. I left it set to card = default. It fired up and threw no warnings about HAL in its output, which tells me that the fault is not with PA, it is with volti's code.
We have three ways to go about this:
1. Fix volti so that it uses dbus calls instead of HAL. HAL is deprecated in Jessie and HAL's packages are not available in the repos.
2. Script around the problem as we have been talking about.
3. Switch to volumeicon-alsa.
I can definitely tell you that setting /etc/asound.conf to be what I listed above resulted in me having proper sound without having to touch volumeicon's config file.
I was actually quite surprised that volti made it into Jessie considering how close to the deadline it was running. It looks to me like it escaped tester's attention if it was referring to libraries that are no longer in use in Debian. I will leave it up to the dev team to figure out how you all want to proceed.
Offline
The idea of automagically trying to configure BL users' audio during installation is a noble one, but I suspect it is not worth the effort. Is audio setup really a problem for many people? I doubt it. I know from experience if the defaults don't work on a given installation, it can be a big pain in the butt to get audio working (in both Linux and Windows). But it seems to work pretty well out of the box for most people.
Also... the thread title "pulseaudio vs alsa" is a bit misleading. Pulseaudio sits above alsa in the audio stack, i.e., if you're going to use pulseaudio, you need alsa running. It's not a case of one versus the other.
Also(2)... one comment in this thread mentioned pulseaudio as being installed by default in Debian, suggesting that as an argument for including it as part of BL. But I'm fairly sure it is not installed in a bare-bones Debian install, so that particular argument is invalid.
Ben
Offline
Yay, your first post. We get reports of sound issues, yes, and I wanted some feedback. Pulse is installed by default in jessie GNOME, but that wasn't the point. We're discussing how to best implement a default sound configuration.
Also... the thread title "pulseaudio vs alsa" is a bit misleading. Pulseaudio sits above alsa in the audio stack, i.e., if you're going to use pulseaudio, you need alsa running. It's not a case of one versus the other.
Yeah yeah, professor, I'm aware, Alsa vs. Alsa+PulseAudio. I needed a brief title.
I don't care what you do at home. Would you care to explain?
Offline
Pulseaudio sits above alsa in the audio stack, i.e., if you're going to use pulseaudio, you need alsa running.
Yes and no. If you are using pulse on top of OSS or FFADO you don't need ALSA. It all depends on your soundcard and setup.
Last edited by Snap (2015-10-14 07:42:42)
Offline
one comment in this thread mentioned pulseaudio as being installed by default in Debian, suggesting that as an argument for including it as part of BL. But I'm fairly sure it is not installed in a bare-bones Debian install, so that particular argument is invalid.
Quite correct. Pulse Audio was default in the last CrunchBang release, but of course there's nothing so basic about it as to consider it a Debian default. (Comment edited.)
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Hi: I thought that ALSA or OSS is always needed to work together with the sound card.
I did not know that PA can take over the tasks from ALSA?
Please help me to understand- thanx
Offline
@beerstein - To my understanding:
ALSA does not depend on PulseAudio to work.
PusleAudio is dependant on ALSA to work.
PA adds features to ALSA that not all people need.
However I may be wrong.
Debian 12 Beardog, SoxDog and still a Conky 1.9er
Offline
Also discussed yesterday in a nice explanation by snap, see link
Ben
Offline
PA is capable of dynamically determining available audio sinks and changes to them. Basically, ALSA is your low level interface to the kernel and PA is your higher level interface to user space. It is supposed to make things more user friendly, which I think it accomplishes once it's up and running. The issue with users no having working sound ootb arises from how Volti's code is structured which is something I will approach in my next post.
Offline
I took apart volti's source the other day to have a look at what it is really doing. Here is a rough draft of what it actually does. Please note it is very simplified as I don't at this point 100% understand the gtk calls:
1. Gets a list of available audio sinks from aplay -l
2. Binds to the card specified in ~/.config/volti/config as the card_index.
3. It then tries to set everything up for that particular card. If it fails to set anything up, it simply throws an assertion and fails to start.
I would love to see this code improved up on because it is already pulling the list from aplay -l, then most unfortunately not making use of that list, instead making use of a static config file. The HAL stuff is a red herring. That stuff has to do with multimedia key mapping.
What I would suggest is a script that would run at first boot that would do the following things unless somebody can fix volti's behavior:
PSEUDO CODE:
1. Grab the list of audio sinks from aplay -l
2. Open and read ~/.config/volti/config. In particular, card_index, which should default to 0. <-- Back this file up in case changes get made to it.
LOOP:
3. Build a try/catch statement and attempt to start volti.
4. If volti throws an assertion, catch it, up the card_index variable by one, write that value back into the card_index value in ~/.config/volti/config, then save it.
Once you have saved a card index other than zero, an entry to the config should be added that looks like this:
[card-1]
control = Master
That is all that is needed. Volti will write the rest of the values in this section that it needs once it successfully starts.
5. REPEAT unti volti starts successfully.
Since we are already managing the file programmatically, we might also check the following values are correct before ending the script:
icon_theme: set it to BL defaults. Mine says Faenza.
mixer = pavucontrol
mixer_internal = 0
keys_backend = xlib : <-- Don't set to HAL
Or anything else you feel is needed to ensure a default running behavior for volti in BunsenLabs.
6. Possibly run some tests for audio out to make sure you can hear stuff.
7. Clean up.
Once volti is up and running, pavucontrol should manage audio sinks dynamically. Any issues from there for 95% of sound systems could probably be accomplished by tweaking volti's config. For instance, I have not touched upon audio inputs yet. However, I am fairly sure they will work as I have been known to use my phone as an audio out device on this machine.
I could probably accomplish all of this in python and this would be much easier on me than interpreting all of the gtk stuff that volti has built into it. Unfortunately, the kids are out for fall break so it may take me some time before I can sit down and really focus on this again.
Offline