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

[EvilDragon]

Hm? And what operation would that be?

Turn the volume down to zero, same as on the Pandora...?

 

[pmprog]

Hm? And what operation would that be?

Turn the volume down to zero, same as on the Pandora...?

Well, depending on where the wheel is and the software volume level, apparently you might have to spin it all the way to max, then back to min

 

[comradekingu]

If you have to bring the softvol level along, it makes more sense to draw the wheel down to 0 to re-align them.

Nothing should ever be higher volume than the % of the wheel position.

 

[PowerGod]

For me the volume wheel is useful without software involved... if I want to use software volume I use the pen, or hotkeys...

If it's output is controlled by software I consider the wheel a wasted space on the board...

 

[levi]

I always thought it a little inelegant that the Pandora has both a physical volume control and the mixer app with a volume slider, which as ED says has caused someone to be so confused they sent the unit back in the past.

I'm not sure of the best way to combine the two options are for the Pyra.  I tend to think scrolling the wheel to 0% should always mute the device, but that would mean the software slider would end up disabled, and I'm not sure the best way to square that circle.

 

[WizardStan]

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.

 

[Letalis Sonus]

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.

 

[EvilDragon]

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.

 

[Exophase]

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.

 

[slaeshjag]

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.

 

[EvilDragon]

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.

 

[Letalis Sonus]

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...

 

[Exophase]

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.

 

[bzar]

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.

 

[Christoph.Krn]

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.

 

[_jr_]

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?

 

[EvilDragon]

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

 

[Letalis Sonus]

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...

 

[WizardStan]

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.

 

[TrashyMG]

We'll have to see how everything works when the prototypes are done for any kind of judgement to be made.