JACK instead of Pulseaudio?


Restarting an app is no easy way.


Assuming I'm playing a game through speakers and want to plugin my headphones.


Restarting the game to do that is not really userfriendly ;)
 
Isn't the headphone jack and speakers usually the same output? With a switch that gets pressed when you plug a headset in?
 
Restarting an app is no easy way.


Assuming I'm playing a game through speakers and want to plugin my headphones.


Restarting the game to do that is not really userfriendly ;)
While I entirely agree with that in principle, that does leave me with a question.


Does that mean that there will not be a hardware switch that diverts the audio signal from the speakers to the headphones when they are plugged in like there is on the Pandora?


- Neelix


Edit: heh :ph34r:   by Silent-Hunter  :)
 
Last edited by a moderator:
There is a hardware switch that recognizes when you plug something in. But it's not just one audio device - it has multiple audio streams, afaik.


Of course, you can set ALSA up to route all streams everywhere so it behaves as one and implement code to silent the speakers when the something is pluged into the headset port - but then again, this can be done more easy with a Pulseaudio setup where you can give priorities to outputs so when a headset is plugged in it automatically switches to that if you like.
 
Ideally the Pyra would be able to:

Play a game on the local screen with audio through the speakers or headphone jack with voice inputs/controls.

Watch a movie on the HDMI output with audio over HDMI (2nd screen, 2nd audio output).

Answer an incoming phone call via a bluetooth headset (3rd audio input/output).

Is there any physical reason it could not do all of the above simultaneously using Pulse audio?
 
Maybe Pulse is more suitable then! I'm concerned about being able to receive telephone calls while I am playing games. Will that work?
 
Maybe Pulse is more suitable then! I'm concerned about being able to receive telephone calls while I am playing games. Will that work?
 Most likely. Although the thought of getting a call when gaming is steering me to the wifi only model.
 
It should just be a matter of nixing the code that handles incoming calls, and then that won't happen, while you can still send and receive texts on it if you want to, and use the GPS.  I've no idea how the code will be implemented to do all that, but not having the code to pick up the phone when it rings shouldn't affect the underlying ability to send the other AT commands to handle texts.
 
Well, I don't wanna miss any calls. XD I should be able to pause the game right?
 
Well, technically that's up to the game's authors.  To be honest on Pandora I don't know if it's possible to alt-tab out of a framebuffered game and then back in successfully - I recall having to use savestates and quit before fiddling with my music in the past.
 
Maybe a phone app could be made that can hijack a framebuffer layer much like notaz's system info tool does. It still won't be ideal as a game may still continue to run in the background.
 
On a 1.6GHz Atom netbook Pulse used something like 15-20% CPU time just sitting there. It was abysmal. Something anywhere remotely close to that on Pyra would be unacceptable. This was 2009-2010, maybe it's gotten much better since then.

On my desktop today (Linux Mint 17) I still get audio glitches if I'm listening to music and some other program decides to make a sound effect. It'd be nice to not have to worry about that. On Pyra I don't even think I'd ever care about having multiple programs mix audio. It'd be nice to have a way to simply mute everything but the active program, but it could be tricky determining what active means. Then there shouldn't ever be a reason for anything to resample or mix unless the program's requested a sample rate that the hardware or driver doesn't support.
 
I don't recall seeing cpu usage like that using it on the devboard. I have it disabled at the moment, but that was because of a kernel issue, which is now fixed in the 4.0 RC5 kernel that aTc just pushed. Once I upgrade my kernel I will enable it again and see how it performs.

I know most power users will most likely disable pulseaudio, Like EvilDragon mentioned earlier I see the benefits of easily routing audio to different devices. like HDMI, bluetooth, speaker/headset...etc
 
Last edited by a moderator:
I quite often listen to music on my Pandora while playing games.  That limits what games I can play, because some won't start with alsa already in use, and the ones that do work effectively mute their audio.  It'd be nicer to be able to have game sfx and background music at the same time sometimes.
 
I don't remember it taking up anywhere near that on my BeagleBoard, at least not while idle. I just went to look and it would seem that something is unquestionably corrupt because I can't get it to start. I probably did an updated many months ago that broke it. I don't really pay much attention to what it's doing, so long as it keeps sorting my mail. I'll try to make it work again but I'm not too motivated to put a lot of effort into it.

Not in any way a fair comparison, but on my 3.4Ghz i5, when not doing anything pulseaudio is way down near the bottom of my list of active processes, it doesn't even register 1/100th a percent of CPU, but when I start to play a video it still usually sits at 0.0% but sometimes jumps to 0.7%
 
On a 1.6GHz Atom netbook Pulse used something like 15-20% CPU time just sitting there. It was abysmal. Something anywhere remotely close to that on Pyra would be unacceptable. This was 2009-2010, maybe it's gotten much better since then.
For what it's worth, I'm using a 1.6Ghz Atom netbook now,  and Pulse is sitting pretty constantly at 4% CPU time just sitting there.

- Neelix
 
Just made a quick check on my 1,3GHz Atom-Notebook:

While idling, it was 0,0% CPU all the time.

When playing audio via SMPlayer (using pulse), it was between 0,7 - 1% CPU.

When playing video via SMPlayer (using pulse), it was between 1 - 2% CPU.

When playing video via SMPlayer (using PulseAudio ALSA Emulation with resampling), it used about 5% CPU.

So yep, it definitely depends on the setup and whether it needs to resample or not.

But resampling shouldn't be much better with ANY audio system.

On a 1.6GHz Atom netbook Pulse used something like 15-20% CPU time just sitting there. It was abysmal. Something anywhere remotely close to that on Pyra would be unacceptable. This was 2009-2010, maybe it's gotten much better since then.
For what it's worth, I'm using a 1.6Ghz Atom netbook now,  and Pulse is sitting pretty constantly at 4% CPU time just sitting there.

- Neelix
Something doesn't seem right here. It was at 0,0% on my 1,3GHz Atom right now and at only 1% playing an MP3.
 
Pulse shouldn't be doing anything when it is... well... not doing anything. Idling at 4% definitely seems suspicious but I don't know where to begin investigating why.
 
Perhaps I should also mention that I'm still using Ubuntu 10.04 Lucid Lynx,   so it's possible that the issue has been solved in subsequent versions that have never been backported to lucid

- Neelix
 
Back
Top