Pyra Audio Driver - PulseAudio

[Wally]

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.

 

[comradekingu]

Pulseaudio or alsa?

 

[TrashyMG]

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.

 

[klapse]

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]

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

 

[_jr_]

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]

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?

 

[slaeshjag]

It creates a new device that it maps as default. It's still possible to access the real sound device.

 

[TrashyMG]

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.

 

[WizardStan]

Pulseaudio would make redirecting audio from and to the cell module extremely simple. Internal speakers, to bluetooth, to file, whatever.

 

[ibisum]

Please can we have JACK no matter what happens with PulseAudio (which I think sucks personally but thats just me).  JACK would be wonderful.

 

[TrashyMG]

Easy install from the debian repo.

 

[levi]

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.

 

[comradekingu]

Is https://github.com/i-rinat/apulse an option?

I think lightspark requires pulseaudio too.

 

[LEOXD]

I think lightspark requires pulseaudio too.

Well, it doesn't exactly require it, but...

Sound sup­port using pulseau­dio. If you want to try Lightspark with­out installing the pulse server that’s ok, as Lightspark detects at run­time if the server is avail­able and if not it just politely dis­ables sound.

-- http://allievi.sssup.it/techblog/archives/449

 

[slaeshjag]

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]

ALSA supports Bluetooth without Pulse, doesn't it? I've only ever had headaches from Pulseaudio, myself... rather avoid needing it. :/

 

[pablocrossa]

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]

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

 

[pablocrossa]

^ 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