So, what's the actual state of the software?


PulseAudio almost has the right idea, with it's per-device and per-channel volume sliders.  What would be good is an additional "master" volume on top of that.  You could have (actual volume) = (device volume)*(master volume)/100 thus allowing you to set headphones to, for example, 10%, speakers to 100%, hdmi (when working) to 50%, and the hardware wheel drives the master volume.  That way I don't accidentally blow my eardrums out when I plug my headphones in without adjusting the volume wheel but can still get full volume from the speakers.

Such a thing would require some custom volume daemon though, I'm not aware of any that has this approach.
 
Being a front end of ALSA, you can get all the master volume control you need by simply creating a proper ALSA config beneath it. ALSA is quite powerful, many people easily oversee many of its more advanced features simply due to its poor documentation and rather complex configuration.

However, I'd still recommend configuring it as an ALSA passthrough (if we use it at all) - PulseAudio's own mixer is one hell of a CPU hog.
 
PulseAudio only uses a lot of CPU when it's mixing multiple streams with different bitrates into one.

That's where ALSA also needs a lot of CPU.
 
PulseAudio only uses a lot of CPU when it's mixing multiple streams with different bitrates into one.

That's where ALSA also needs a lot of CPU.

I just tried running a single program with audio open (it was DraStic using SDL, 44.1KHz/16bit) Pulse consistently used about 2% CPU time on my i5-2500K (quad core Sandy Bridge currently @ 1.6GHz. Although not exactly a "lot" it's IMO still too much. I'd like to see what the percentage would be running on Pyra @ ~500MHz and 1.5GHz.

EDIT: Still uses same percentage with the CPU locked at 3.6GHz vs locked at 1.6GHz. Not sure if this means that the CPU usage is frequency independent here or what.
 
Last edited by a moderator:
The the moment, pulseaudio is using "too much". Part of that could be that it's currently running the hardware at double the sampling rate of the input. For example:

[12:51:44 | 2015-07-31] <@EvilDragon> Well, Pulseaudio also needs 30% CPU time while mixing... could be wrong setting though (like mixing everything to 48kHz or something like that).

I remember seeing other percentages in other reports, but I can't find that in my logs atm.
 
PulseAudio only uses a lot of CPU when it's mixing multiple streams with different bitrates into one.

That's where ALSA also needs a lot of CPU.

I just tried running a single program with audio open (it was DraStic using SDL, 44.1KHz/16bit) Pulse consistently used about 2% CPU time on my i5-2500K (quad core Sandy Bridge currently @ 1.6GHz. Although not exactly a "lot" it's IMO still too much. I'd like to see what the percentage would be running on Pyra @ ~500MHz and 1.5GHz.

EDIT: Still uses same percentage with the CPU locked at 3.6GHz vs locked at 1.6GHz. Not sure if this means that the CPU usage is frequency independent here or what.
What is your Pulse output setting set to?

If it's set to 48kHz, it also needs to downsample, even if you only run one stream.

You can check that with:

pacmd list-sinks
BTW: 

PulseAudio has 65537 different volume steps... should be accurate enough for anyone.
 
I messed around a lot with ALSA, partly due to driver bugs that required workarounds. My current asoundrc file has over 600 lines with only a minimal amount of comments, it includes stuff like custom volume controls (software mic boost), LADSPA plugins (5.1 upmix with an elaborate lowpass filter for the subwoofer), customizable default input/output devices via environment variables , and dmix/dsnoop mixers for 12 channels at 32bit 44.1kHz. Of course I hardly use all of the 12 channels available through my hardware at the same time, but I do have quite a bunch of programs running that want to output some audio data all the time.

Everything is like it should be, despite the float transitions required by LADSPA (LADSPA plugins only accept float samples) I can't see any noticeable CPU loads caused solely by audio. Yet PusleAudio manages to cause quite some impressive CPU usage while only using its basic 5.1 upmix settings (or even its default stereo setup), no matter what kind of remix algorithm I chose. I really like the additional features that PulseAudio offers, but whatever I did, I only ran into totally exaggerated CPU usage...
 
What is your Pulse output setting set to?

If it's set to 48kHz, it also needs to downsample, even if you only run one stream.

You can check that with:

pacmd list-sinks
BTW: 

PulseAudio has 65537 different volume steps... should be accurate enough for anyone.

It's 44.1KHz, there shouldn't be any resampling  going on.
 
In my opinion, the ideal daemon should work like this:

* Normally, the hardware wheel is enabled and changes the software master volume.

* If the software master volume is changed, it should disable the hardware wheel.

* To reenable the hardware wheel, you need to move it to the current software setting and then it picks it up and takes over again.

* On shutdown, the daemon saves whether the hardware wheel was currently enabled and disabled and should behave accordingly on startup.

This is the best solution of both worlds.

If you never touch the software controls, the wheel works exactly the same as before.

If you touch the software controls, moving the hardware wheel won't make a sudden volume change.

I'd modify "To reenable the hardware wheel, you need to move it to the current software setting" to "To reenable the hardware wheel, you need to move it to the current software setting or zero". No sound should always be no sound. This would enable the apparently typical use case of always moving the wheel to zero before raising it to a comfortable volume I do myself as well.
 
I'd modify "To reenable the hardware wheel, you need to move it to the current software setting" to "To reenable the hardware wheel, you need to move it to the current software setting or zero". No sound should always be no sound. This would enable the apparently typical use case of always moving the wheel to zero before raising it to a comfortable volume I do myself as well.

Possibly "To reenable the hardware wheel, you need to move it to a value <= the current software setting" for faster emergency-quieting, too.
 
Did I miss something or does this still assume without hard evidence that the software mechanism will always be capable of low latency response to wheel changes?
 
I messed around a lot with ALSA, partly due to driver bugs that required workarounds. My current asoundrc file has over 600 lines with only a minimal amount of comments, it includes stuff like custom volume controls (software mic boost), LADSPA plugins (5.1 upmix with an elaborate lowpass filter for the subwoofer), customizable default input/output devices via environment variables , and dmix/dsnoop mixers for 12 channels at 32bit 44.1kHz. Of course I hardly use all of the 12 channels available through my hardware at the same time, but I do have quite a bunch of programs running that want to output some audio data all the time.

Everything is like it should be, despite the float transitions required by LADSPA (LADSPA plugins only accept float samples) I can't see any noticeable CPU loads caused solely by audio. Yet PusleAudio manages to cause quite some impressive CPU usage while only using its basic 5.1 upmix settings (or even its default stereo setup), no matter what kind of remix algorithm I chose. I really like the additional features that PulseAudio offers, but whatever I did, I only ran into totally exaggerated CPU usage...

Well, if you're willing to help out here to get a proper ALSA configuration going that supports stuff like hot-plugging, easily directing audio streams to various outputs, etc., then I'm perfectly fine using ALSA instead of PulseAudio.

We already had a fight to get the relatively simple Pandora audio configuration to work properly with ALSA, so for me doing this for the Pyra would be a nightmare.

Basically, what needs to work is:

  • Only show useful volume sliders (the TWL has about 60 different volume settings, of which most are not being used by us)
  • Automatically switch to headphones or HDMI as default output when headphones/HDMI are plugged in (and do that also for already running audio streams), but let the user easily change that
  • Easy way (with sliders) to change the volumes of the different audio streams that are currently running.
That's why I think PulseAudio is useful (as it can do all these things), but if you think ALSA can do it as well and help us do it, I'm also happy :)
 
As I said before, you can make PulseAudio use ALSA directly: https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device

That should preserve the features of PusleAudio like per-application audio controls, but it lets ALSA do the mixing. (At least I think that's how you do it, got to take a closer look on what I exactly did the last time I managed to get it to work...)

EDIT: nope, that would be using the PA mixer on top of the ALSA mixer...
 
Last edited by a moderator:
Did I miss something or does this still assume without hard evidence that the software mechanism will always be capable of low latency response to wheel changes?

Yes, that's the assumption being made.  Without hard evidence all we can do is make assumptions.  I'm not sure what exactly you're driving at.
 
We'll have to see how everything works when the prototypes are done for any kind of judgement to be made.
 
Last edited by a moderator:
Hm, now that I think about it...

Only show useful volume sliders (the TWL has about 60 different volume settings, of which most are not being used by us)
IIRC, all available volume controls are being defined by using ALSA setup scripts. Their syntax is a PITA, but it shouldn't be hard to get a custom setup script that only defines what's needed. Most GUI programs ignore most volume controls and only use what they recognize, anyway.

Automatically switch to headphones or HDMI as default output when headphones/HDMI are plugged in (and do that also for already running audio streams), but let the user easily change that
That would be the tricky part.

Easy way (with sliders) to change the volumes of the different audio streams that are currently running.

That's something I never really understood, it shouldn't be hard to add this feature to ALSA - imagine a simple softvol passthrough plugin that communicates with a central volume daemon to get its volume value. One could probably hack something similar together to get the dynamic switching to work.

The issue with ALSA is that AFAIK pretty much everything is being done by the program, it has no central process. When a program is started and it initializes libasound, it processes the whole config and creates a static setup based on that. Everything dynamic requires a plugin that has all possibilities already defined and does some inter-process communication stuff to act within those limited possibilities.
 
* Nubs: Work. They use the same userspace and settings as in the Pandora, but there's not yet an UI implemented to set it up.

I think all userspace controls should be dropped and moved to the input daemon. That will make it compatible with mainline, and must be done early so nothing depends on the old stuff. So quite some work here.
Such things can be improved in the future. We also improved a lot of the Pandora over time, so the Pyra doesn't need to be perfect from the beginning.
Honestly, I'm with Notaz on this one.  If you don't make the change for something as basic as this in the early stages, then software that comes out during that time will rely on old stuff.  This means that you have to support both the old and new methods of input indefinitely or drop support for the old method, thus breaking already released software, neither of which is a good choice.

-God Ginrai
 
The only issue I've had with ALSA on Pandora is if I'm playing music via Deadbeef, many applications I subsequently launch lose their audio (even if Deadbeef is paused).  I'm not sure whose fault that is, but I'd like to be able to listen to my own music while playing and still get game sounds.

I understand that pulseaudio out-of-the-box is meant to resolve issues like that, but if ALSA could be configured to mix sources properly, that would be fine for me as well.
 
I'm not sure whose fault that is, but I'd like to be able to listen to my own music while playing and still get game sounds.

As I recall, that's a result of the way the Pandora's ALSA implementation handles OSS emulation: poorly.  Modern implementations probably solve that.

The thing that I think about regarding Pulse and "too much CPU" is what exactly is it doing?  It's remixing channels, right?  Even when you don't hear anything it's still mixing nothing and nothing to get more nothing at a different frequency, but that still needs to be done.  And then I ask myself "how does ALSA do this? It doesn't have a daemon, where is the mixing occurring?" and I don't know the answer to that yet because I haven't read the code and I can't find anything that really explains it, but this all leads me to another thought: what if the PulseAudio daemon is taking up 2-4% CPU while the collective CPU usage of every application that outputs audio is down 2-4%?  Things that used to happen in the application via the ALSA .so are now unified in the PA daemon, for better or for worse, at least down somewhat to attribute pulse's increase.  Can anyone confirm that that is definitely not the case?
 
Back
Top