Pyra Audio Driver - PulseAudio


Wally

I am a banana!
Staff member
Joined
Jan 31, 2006
Messages
2,973
Age
33
Location
Melbourne, Australia
Pyra Audio Support thread (Please keep all random chit-chat out of here as this is a thread for OS Developers / Dev board owners to discuss possible implementation and additional features, any random chit-chat will be deleted and repeat offenders may suffer the consequences)

Current Status

(2/01/15) Non existent, no audio output unless USB Soundcard is used. aTc has provided a method for setting up a dummy audio card for now so that the device thinks there's audio there.

Suggested features / scripts for Driver:
OS Volume Control in addition to volume wheel for audio mixing and Microphone volume.

Documentation suggestions:

Volume Wheel usage 

Adjusting Audio

Speaker quality

Headphone jack

Microphone usage

Who is implementing?

No idea.
 
Last edited by a moderator:

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
10,692
Pulseaudio or alsa?
Currently it's pulseaudio and alsa as the two work together, but installing the sound system is the easy part. currently none of the built on sound devices are working properly.. I've been using a USB sound device for all the videos I've made.


It may only need a little effort to get working all I know.  I had both HDMI and analog audio output working on the old crusty TI provided Ubuntu install.. however their mixer setup was not user friendly at all and required to change 40 mixer settings to just get sound to work.
 
Last edited by a moderator:

klapse

Central Scrutinizer
Joined
Aug 30, 2012
Messages
1,932
Location
Germany
Active Pulseaudio on the N900 consumes 12-25% cpu depending on current CPU governor speed. It should be tested whether it is also this bad on the OMAP5 devboard. I don't see any advantage in using PulseAudio.
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
10,692
Active Pulseaudio on the N900 consumes 12-25% cpu depending on current CPU governor speed. It should be tested whether it is also this bad on the OMAP5 devboard. I don't see any advantage in using PulseAudio.
Well the omap5 is considerable faster than the N900 and if people want a better bluetooth audio experience than the pandora manual hacks we may need to use pulseaudio.
Just to add:

- How old is the version of pulseaudio for the N900.. performance issues could have been addressed a while ago.

- just now when running htop, while switching between different programs with sound I haven't seen CPU usage over 3% on any pulseaudio process and generally runs ~ between 1%-2%. Also if you choose to directly use ALSA with a program,the pulseaudio process usage is practically no percentage of the CPU.. So I believe ALSA and Pulse audio can live together in our environment, people/devs can choose ALSA or OSS directly for performance reasons without issues..
 
Last edited by a moderator:

_jr_

Advanced Member
Joined
May 5, 2013
Messages
1,170
If a significant number of apps use ALSA directly (and I suspect a lot of straightforward Pandora to Pyra ports will) providing Pulse just confuses and annoys users, because some apps won't use their pulse configuration. OTOH allowing apps to directly access ALSA is probably a no go if Pyra has to be useable as a phone replacement (e.g. receiving calls while playing games). I personally don't care for using Pyra as a phone and would prefer the non pulse variant, but that is just me. Let's start a poll :)
 

notaz

Certified Guru
Joined
Aug 23, 2005
Messages
4,913
Location
Lithuania
Website
notaz.gp2x.de
I haven't seen CPU usage over 3% on any pulseaudio process and generally runs ~ between 1%-2%.
Considering it's on Cortex-A15, that's quite a lot of cycles wasted for nothing..
Also if you choose to directly use ALSA with a program,the pulseaudio process usage is practically no percentage of the CPU..
Doesn't it take over ALSA API by default?
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
10,692
Considering it's on Cortex-A15, that's quite a lot of cycles wasted for nothing..
True, however it uses pretty much no cycles when not it's not in use.

Doesn't it take over ALSA API by default?
Yeah normally if I choose just ALSA it's using pulseaudio, however if I specifically specify ALSA and the device I want to use it doesn't. My test case was using smplayer and directly calling my alsa playback device.

Notaz, I trust your decision on this matter, personally I'd love to squeeze out as much performance as possible.. However right now the vanilla Debian install we're playing with does have Pulseaudio and Pulseaudio does simplify somethings when dealing with multiple sound sources which may be the case with the Pyra and I believe most modern bluetooth managers use pulseaudio as well.
 
Last edited by a moderator:

WizardStan

Mega GP Mania
Joined
May 24, 2008
Messages
16,733
Pulseaudio would make redirecting audio from and to the cell module extremely simple. Internal speakers, to bluetooth, to file, whatever.
 

ibisum

Well-Known Member
Joined
May 6, 2009
Messages
1,135
Please can we have JACK no matter what happens with PulseAudio (which I think sucks personally but thats just me).  JACK would be wonderful.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
12,290
Location
Somewhere off the coast of the EU
I just hope that whatever we end up with makes it no less likely that I'm able to play my own music while playing games. On Pandora most games allow this, but a few do something to the ALSA stream that borks Deadbeef.
 

LEOXD

Member
Joined
Feb 4, 2014
Messages
121
Age
23
Location
Denmark

slaeshjag

¯\_(ツ)_/¯
Joined
Apr 8, 2010
Messages
2,687
Location
~Stockholm, Sweden
For a number of usability reasons, it makes sense to have Pulseaudio as part of the stock OS image. It will make stuff like connecting bluetooth headsets (and possibly interfacing with the voice feature of the celluar module?) a lot less painful, as such things can be configured dynamically and preferably automatically.
 

Luke-Jr

Member
Joined
Aug 31, 2014
Messages
153
ALSA supports Bluetooth without Pulse, doesn't it? I've only ever had headaches from Pulseaudio, myself... rather avoid needing it. :/
 

pablocrossa

Still Fresh
Joined
Jun 17, 2015
Messages
39
ALSA supports Bluetooth without Pulse, doesn't it? I've only ever had headaches from Pulseaudio, myself... rather avoid needing it. :/
I'm not a big fan of Pulseaudio (as a security guy, I think it's a massively bloated sound system that increases the attack vector for a device); however I run it on all my Debian installs because you will find that all software (such as SDL and other sound-capable libs) is built with Pulseaudio support.

If you want to remove Pulseaudio the community would have to recompile and repackage all 'deb' files that relate to Pulseaudio (which MANY do) from the upstream Debian repo; this puts an unnecessary strain on the community infrastructure (and on any developers that need to patch 'deb' sources to build without the Pulseaudio dependency) for, on a mobile device like this, little gain. Or you ship with a dead Pulseaudio lib that's not in use, which seems sub-optimal.

Additionally Pulseaudio really makes more sense when thinking about:

  • Redirecting audio in a hotplug manner (through HDMI or Bluetooth without resetting the App or subsystem). AFAIK ALSA has trouble with this, but I could be wrong.
  • Sharing the sound subsystem between different processes. AFAIK ALSA isn't great at sharing sound on different competing processes.
  • People that want to use it as a phone benefit from the redirection and added control it provides; it doesn't make sense to change the OS sound system depending on the modem configuration.
  • It's the default in Debian; the less Pyra-specific changes on the userspace side the easier a future OS upgrade will be.
On a more gaming and consumer-oriented device that might have telephony and where the SOC can handle the added cycles without problems, it doesn't seem to be worth the effort to fight against Debian to remove Pulseaudio IMHO. Nokia would not have used Pulseaudio on the N900, which eats the CPU, if there was a more CPU-efficient way to handle call routing that's still sane.
 

slaeshjag

¯\_(ツ)_/¯
Joined
Apr 8, 2010
Messages
2,687
Location
~Stockholm, Sweden
^ It's possible to run a debian system without Pulseaudio. On my laptop, I've nuked it from orbit with rm -Rf and killall pulseaudio. Sound still works fine in all applications I've tried since they have an alsa fallback. I've done this because pulseaudio is a PoS that does the wrong thing 90% of the time, and sometimes just changes what it does wrong for no apparent reason.

The dynamic configuration aspect of pulseaudio is the only argument for it imo, and if it can be made to work decently, then I will let pulseaudio live on my device. On a device like the Pyra, with audio sources can be expected to hot-plug often, the capability makes sense.
 
Last edited by a moderator:

pablocrossa

Still Fresh
Joined
Jun 17, 2015
Messages
39
^ It's possible to run a debian system without Pulseaudio. On my laptop, I've nuked it from orbit with rm -Rf and killall pulseaudio. Sound still works fine in all applications I've tried since they have an alsa fallback. I've done this because pulseaudio is a PoS that does the wrong thing 90% of the time, and sometimes just changes what it does wrong for no apparent reason.

The dynamic configuration aspect of pulseaudio is the only argument for it imo, and if it can be made to work decently, then I will let pulseaudio live on my device. On a device like the Pyra, with audio sources can be expected to hot-plug often, the capability makes sense.
I know, but then you get a dead "Pulsaudio" package installed and, if you nuke with rm -Rf, on an update you'll get the binary back; that's what I meant with "Or you ship with a dead Pulseaudio lib that's not in use, which seems sub-optimal"; Debian is doing the same now with Systemd, you can choose another init system but you still need libsystemd0 and other systemd-related packages installed. I gave up on trying to secure Debian a while back, now you have unnecessary systems, such as Pulseaudio and Systemd, baked into the OS without any way of removing them entirely and still have a functional OS. I will try Gentoo after summer when I have some free time again.


That being said it's always done what it was meant to on my N900 and, if the Pyra has it work like that, it should be OK :) As you said, hot-plugging is really the main reason it's become so prevalent in the desktop Linux landscape :)
 
Top