PulseAudio vs. Alsa

johnraff · 2015-10-16 04:18:48

@tknomanzr If we end up staying with volti (there has been some talk of switching to volumeicon-alsa or pnmixer) that loop looks like a handy way of at least trying to get the right card set up, and wouldn't be hard to do in bash. Maybe a bl-configure-volti script that could run from bl-welcome if the user agrees. There's no need for it to enter any static values in ~/.config/volti/config, though, as we're already shipping a configured version of that file in bunsen-configs. If anything is different from default it can only mean the user changed it him/herself, so we should leave it alone.

Last edited by johnraff (2015-10-16 04:19:15)

tknomanzr · 2015-10-16 05:59:46

OK. Just so I understand...you would still need to write in the card_index and control = Master value under the appropriate card and the rest would be setup already?

I can say, volumeicon-alsa did set stuff up on my laptop correctly. I qualify that with the fact that I did not see the double notification bug that has been reported. Of course, I haven't seen it yet. I have not yet tested pnmixer at all. I'll leave it up to you all what you want to do.

I just know wrapping volti would be a ton easier than running through stack traces 4 modules deep in volti. I can actually get it to fire up briefly by upping the card_index value by 1 in its source. Then all the gtk stuff throws another assertion. I just have to admit, that would be a bit beyond me at this point to fix. I might just pop over to its github and put in a request to actually use aplay -l since he is already gathering the variables, instead of depending on a static config for the card index. It's the only thing preventing it from being everything needed.

I understand all the rest being static as it can be changed via the gui once you have volti running. I just feel like automating that process would be a far better approach to a piece of software, than just throwing an assert and exiting the script, particularly when you consider the data is already there to be worked with.

johnraff · 2015-10-16 08:26:11

Here's what we have in volti's config file at the moment:

[card-0]
control = Master

[global]
mixer_show_values = 1
scale_increment = 1.0
card_index = 0
icon_theme = Faenza
scale_show_value = 0
mixer = pavucontrol
show_tooltip = 1
notify_position = 0
keys = 0
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 = 0

So I think we've already got the other things you mentioned covered. It would just remain to change the Card-0 to Card-1 if necessary, right?

tknomanzr · 2015-10-16 14:16:28

Right, otherwise the Master channel in the mixer won't be set up right.

Head_on_a_Stick · 2015-10-17 11:10:41

Surely the Master channel should be selected from pavucontrol?

I thought the whole point of PA/pavucontrol was to eliminate the need for individual text-file configuration and replace it with an end-user GUI.

Editing the volti configuration file may work for cases in which the user just wants the analogue (or headphone) output but doesn't work for multimedia or other set ups.

tknomanzr · 2015-10-17 13:47:24

Correct, once you actually get Volti to run, pavucontrol should handle it all. The difficulty lies in the unfortunate decision by volti's developer to NOT use the information he grabs from aplay -l to automate the whole thing. He chose to read the audio sink info from that configuration file for whatever reason.

It may come down to deciding not to use volti. However, if we should continue with it, the easiest way I can see to override its unfortunate behavior on certain sound sets is to wrap the whole thing up in a script that overrides it's assertion behavior (which is to print the assertion then exit), if it doesn't find a correct audio sink on whatever card is specified in it's configuration file by default. We have no way to guarantee what sound setup a user has. The correct way to have programmed it would be to start at card_index = 0 and keep trying to start, if fails then up card_index by 1 and try again until all available card_indexes are exhausted, and only then exit the program.

It is easy enough to edit that configuration file by hand. However, it is also rather not elegant in the fact that all the info that is needed is already there and instead of automating the whole thing for the user, it depends on user intervention for the fix.

Note, in most cases, the script would only ever need to run once, at first boot. It should be able to determine which audio sink the user is using and get volti to start up. Once set, and volti successfully run, it's configuration would be set and would not ever be needed again, provided the user doesn't change up their audio configuration significantly. However, if I were to choose to use, say HDMI speakers on a new monitor, I could simply run the script again to fix it.

Once volti is running, pavucontrol will handle things like it should. This is only about getting volti to start that first time successfully.

hhh · 2015-10-17 15:55:28

tknomanzr wrote:

It may come down to deciding not to use volti.

This. We used Volti in the last ISO release because it is part of Debian stable and volumeicon-alsa in jessie has a visual bug when using xfce4-notifyd, but it has not been a success. #! used pnmixer and I see little reason not to go back to that...
https://forums.bunsenlabs.org/viewtopic.php?id=315

Hopefully your work on this will be applicable to sound in general and will not have been a waste of your time.

tknomanzr · 2015-10-17 16:22:10

Nah. It has been fun and I learned. That's what matters. Plus, I finally reached the point where maybe I can't fix the code but at least I could dissect it and figure out why it wasn't working out for us. And one day, when I decide to do my own coding thing, I will keep in mind how important automation and UX design is.

I had a mentor some years back in programming. His thing was industrial automation and he really drilled into me the importance of using the machine for what is was built for, and automating everything that you can. Machines don't make mistakes. People can and do. If you have already gathered the needed info, then there is no longer a reason to depend on user input. Just automate it and make it work.

It still gives me something to do because I can learn python-gtk and see if I can figure out how to make the darn thing work the way I think it should.

Horizon_Brave · 2015-10-20 23:39:31

Audio is something I never really paid much attention to but now that mine isn't working (BL in Virtualbox), I now have a very healthy interest!

Can someone give a brief rundown of the issues here? How / what are the players in this? What is the difference between pulseaudio, ALSA, volti etc.. Are these graphical tools for audio drivers? Which are the underlying Audio drivers themselves?

Horizon_Brave · 2015-10-20 23:42:48

Actually I found a great article that answers a lot of my questions..
How Linux Audio Works

Nice image of the abstraction

I'm trying to get a more fundamental level of knowledge of how the Linux/UNIX OS works...

How does this Volti fit into this? What's the main issue at hand here?

Last edited by Horizon_Brave (2015-10-20 23:54:53)

damo · 2015-10-21 00:47:34

Horizon_Brave wrote:

...
Can someone give a brief rundown of the issues here? How / what are the players in this? What is the difference between pulseaudio, ALSA, volti etc.. Are these graphical tools for audio drivers? Which are the underlying Audio drivers themselves?

There are several posts in the forums about this stuff. Did you read them? For example...
Understanding audio in Linux
Getting Sound working in BL

nobody · 2015-10-21 00:50:52

hhh wrote:

tknomanzr wrote:
It may come down to deciding not to use volti.
This. We used Volti in the last ISO release because it is part of Debian stable and volumeicon-alsa in jessie has a visual bug when using xfce4-notifyd, but it has not been a success. #! used pnmixer and I see little reason not to go back to that...
https://forums.bunsenlabs.org/viewtopic.php?id=315
Hopefully your work on this will be applicable to sound in general and will not have been a waste of your time.

I would like to favour this return over messing with that volti thing. volti chose to do something nobody ought to do, that is instead of using proper APIs from pulse or alsa it's parsing some user-readable command line output (I'm relying on tknomanzr's analysis here).

Thing is, it doesn't support pulseaudio, or anything else besides ALSA for that matter. If that's not an issue, I'd use this program which is written in nice C against a clean API over the volti hack any time.

IMHO such a change could also warrant to implement a pulse/alsa config such as this. Since systemd is the default in Debian: Perhaps we could rely on applications requiring pulse (such as skype) triggering the start of the pulse daemon through systemd socket activation? That way, we would not have to run the pulse daemon as an auto-start daemon.

Horizon_Brave · 2015-10-21 01:05:54

damo wrote:

Horizon_Brave wrote:
...
Can someone give a brief rundown of the issues here? How / what are the players in this? What is the difference between pulseaudio, ALSA, volti etc.. Are these graphical tools for audio drivers? Which are the underlying Audio drivers themselves?
There are several posts in the forums about this stuff. Did you read them? For example...
Understanding audio in Linux
Getting Sound working in BL

Thanks so much! I'll add them to my reading list.

tknomanzr · 2015-10-21 02:05:23

nobody wrote:

hhh wrote:
tknomanzr wrote:
It may come down to deciding not to use volti.
This. We used Volti in the last ISO release because it is part of Debian stable and volumeicon-alsa in jessie has a visual bug when using xfce4-notifyd, but it has not been a success. #! used pnmixer and I see little reason not to go back to that...
https://forums.bunsenlabs.org/viewtopic.php?id=315
Hopefully your work on this will be applicable to sound in general and will not have been a waste of your time.
I would like to favour this return over messing with that volti thing. volti chose to do something nobody ought to do, that is instead of using proper APIs from pulse or alsa it's parsing some user-readable command line output (I'm relying on tknomanzr's analysis here).
Thing is, it doesn't support pulseaudio, or anything else besides ALSA for that matter. If that's not an issue, I'd use this program which is written in nice C against a clean API over the volti hack any time.
IMHO such a change could also warrant to implement a pulse/alsa config such as this. Since systemd is the default in Debian: Perhaps we could rely on applications requiring pulse (such as skype) triggering the start of the pulse daemon through systemd socket activation? That way, we would not have to run the pulse daemon as an auto-start daemon.

Here is the constructor for the AlsaControl class for Volti:

def __init__(self, card_index, control, main_instance):
        """ Constructor """
        try:
            self.main = main_instance
            self.card_index = card_index
            self.control = control
            self.channel = alsa.MIXER_CHANNEL_ALL
            self.mixerlist=[]
            self.open()
            self._check_version()
        except Exception, err:
            log.Warn("can't open %s control for card %s, trying to select first available mixer channel\n" % (
                self.control, self.get_card_name()))
            try:
                control = self.get_mixers(self.card_index)[0]
                self.main.control = control
                self.reopen(self.card_index, control)
                self._check_version()
            except Exception, err:
                log.Warn("can't open first available control for card %s\nerror: %s" % (
                    self.get_card_name(), str(err)))

And also a class method for AlsaControl that shows that Volti does indeed get a list of available cards:

def get_cards(self):
        """ Returns cards list """
        cards = []
        acards = alsa.cards()
        for index, card in enumerate(acards):
            try:
                self.get_mixers(index)[0]
            except IndexError:
                cards.append(None)
            else:
                cards.append(acards[index])
        return cards

In the constructor we can see both the warning and the assertion in the try/except loops. Volti's config will default to card_index = 0, which works if you actually have a valid sink on that card_index. However, it is not uncommon, especially for laptops for card_index = 0 to end up and HDMI port that is not being used.

Also, main.py's constructor shows Volti pulling this value out of preferences.py, which would be where Volti opens and reads its config file and gets the card_index from. As I go through the source, I can see numerous calls to the static variable card_index, which should instead be referring to an index of a list similar to what get_cards is creating. I got as far as creating this list in the constructor for AlsaControl and when an exception occurred upping the list_index by 1 and attempting to run the constructor again. Given enough time, I could probably thread my way through the numerous modules for Volti and get it working. My initial tests showed that I could in fact get Volti to fire up then all the gtk stuff would get me, so the UI would also need to be notified of the change.

In short, I could probably eventually get it to work, but if pnmixer will suit BL's needs it could be a purely intellectual exercise based on what I believe proper software design ought to look like. The ideal setup would create a list of Alsa cards and utilize that list throughout the program. I hope this post will be enough of the source to show you all what I am talking about.

nobody · 2015-10-21 15:01:28

^ I applaud your effort, but I think we'd prefer to ship an unaltered program instead of patching up a dead project…not my say though, I'd like to stay away from desktop questions…

Perhaps you'd like fork it, improve it, add pulse support or something, and call it frankenmixer

tknomanzr · 2015-10-21 15:53:48

LOL. Maybe one day. Even though it's written in python, it is fairly complex. I have some ideas and will work on them when I am able. I have no issue with you changing, as it does have a problematic implementation. I just wanted you to see the source so you could maybe get the gist of what I was saying.

However, your comment about starting pulseaudio via systemd got me to thinking that this entire system could potentially be written in systemd, or at least all the autostart stuff. If am ever going to learn systemd then I am going to have to actually use it to do stuff. I've been mucking about with systemd-nspawn today and have a very basic debian system built. Once I figure out how to get networking running in the container, I should be able to build up a system from console. My goal is to start the majority of stuff up via systemd unit files.

johnraff · 2015-10-22 03:43:57

nobody wrote:

hhh wrote:
#! used pnmixer and I see little reason not to go back to that...
https://forums.bunsenlabs.org/viewtopic.php?id=315
I would like to favour this return over messing with that volti thing...
Thing is, it doesn't support pulseaudio, or anything else besides ALSA for that matter.

pnmixer was used in #! along with pulse. In what sense does it not support pulseaudio?

tknomanzr · 2015-10-22 04:58:55

I understood him to be referring to Volti.

johnraff · 2015-10-22 05:21:36

We'll have to wait for nobody to clarify this, but I thought this looked as if "it" and "this program" were pnmixer...

nobody wrote:

Thing is, it doesn't support pulseaudio, or anything else besides ALSA for that matter. If that's not an issue, I'd use this program which is written in nice C against a clean API over the volti hack any time.

tknomanzr · 2015-10-29 02:48:43

I have been playing with the entire pulseaudio suite tonight. I installed the following packages from debian's repos:

pasystray
paman
paprefs
pavumeter
paucontrol

Below, I have posted a screenshot to show all of the apps open, their integration into pasystray and also how pasystray allows for selecting various servers (assuming one was setup to broadcast across the network), sinks, sources, and even audio streams. I have no way atm to test it against USB sound devices but it should detect them, assuming proper setup in the kernel. I am unsure if you all would consider it cruft, but it is a very comprehensive suite that should solve BL's sound problems, assuming you wanted to stick with a PA setup. Atm, its statistics show it consuming roughly 201 kb of memory for the sound stream to mocp in a terminal. I may consider this my goto as it seems like it will solve numerous potential issues. I will let you all know how it works out on my laptop, which is the one that generally needs intervention of some sort to get sound working.

Last edited by tknomanzr (2015-10-29 02:49:00)

#41 2015-10-16 04:18:48

Re: PulseAudio vs. Alsa

#42 2015-10-16 05:59:46

Re: PulseAudio vs. Alsa

#43 2015-10-16 08:26:11

Re: PulseAudio vs. Alsa

#44 2015-10-16 14:16:28

Re: PulseAudio vs. Alsa

#45 2015-10-17 11:10:41

Re: PulseAudio vs. Alsa

#46 2015-10-17 13:47:24

Re: PulseAudio vs. Alsa

#47 2015-10-17 15:55:28

Re: PulseAudio vs. Alsa

#48 2015-10-17 16:22:10

Re: PulseAudio vs. Alsa

#49 2015-10-20 23:39:31

Re: PulseAudio vs. Alsa

#50 2015-10-20 23:42:48

Re: PulseAudio vs. Alsa

#51 2015-10-21 00:47:34

Re: PulseAudio vs. Alsa

#52 2015-10-21 00:50:52

Re: PulseAudio vs. Alsa

#53 2015-10-21 01:05:54

Re: PulseAudio vs. Alsa

#54 2015-10-21 02:05:23

Re: PulseAudio vs. Alsa

#55 2015-10-21 15:01:28

Re: PulseAudio vs. Alsa

#56 2015-10-21 15:53:48

Re: PulseAudio vs. Alsa

#57 2015-10-22 03:43:57

Re: PulseAudio vs. Alsa

#58 2015-10-22 04:58:55

Re: PulseAudio vs. Alsa

#59 2015-10-22 05:21:36

Re: PulseAudio vs. Alsa

#60 2015-10-29 02:48:43

Re: PulseAudio vs. Alsa

Board footer