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

[Letalis Sonus]

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.

 

[God Ginrai]

* 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

 

[levi]

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.

 

[WizardStan]

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?

 

[comradekingu]

One way ALSA is leaner than pulseaudio is utilizing mixing in hardware.

 

[bzar]

One way ALSA is leaner than pulseaudio is utilizing mixing in hardware.

Is hardware mixing even supported by newer sound cards?

 

[comradekingu]

In terms of Modern the trend is to just have simple DACs, relying on softvol or passive attenuator afterwards in case of external cards.

Corresponding OMAP5 documents are NDA, and don't seem to be open without "contacting your TI representative" so I looked at https://www.ti.com/pdfs/wtbu/OMAP4430_4460_4470_PUBLIC_TRM_Addendum_ABE_HAL_vH.pdf

There is a ABE system in place that offloads some features here and there. It says "Host processor" is running it, clocked at 48-196Mhz, The higher it's clocked, the more advanced the features you can handle. Downmixing 5.1 to headphones (virtual soundstage) and whatnot.

You can have hardware mixing, as 44.1kHz in "low power" mode. It is then sent McPDM where its upsampled to 88.2kHZ 24bit and then onwards to the TWL6040.

There was some choice to program in 48 too, but if its in 44.1kHz, that covers music in CD-format.

 

[skeezix]

Skeezix still plans to enhance that into a central game hub for the Pyra. I don't know how much time he has though, but in my opinion, it's important to have everything (with all features) clearly defined upfront. Code can happen later, but the standards need to be lined out and defined.

Heh, I remember the first time I started the Tournament Hub, I was told adding all those features was monolithic and "Microsoft-y", not very linux like. Still @skeezix maybe we could bang heads again, and make a combined product?

My developer-API is currently C based, and can be found here. I've got another two repos, one for the website, and one for a Qt UI, so cross platform

I thought you just got bored and dumped TH

ED is right on all counts..

- I like the idea of making a "C4A2" thing.. I've got some baseline features in mind to enhance the basic C4A idea, but we should also think about the larger picture .. tieing into stores/repositories, and launchign UIs, and systems for tieing into messaging and all that. Its one of those things you have to start small or get nowhere, but the potential is enormous

- Standards need laying down; the first C4A was a quick hack, put together over a couple weekends, and it shows front to back; I have some proposals for the new one, but its still not thinking future, so need to mull that over

- I don't have much time at all (sigh), but surely I can work on some pieces; hence, I keep thinking of offering up a baseline spec fore review, and coding a C4A server for C4A-stuff, but doubt I could pick up the job for all the pieces of it; definately we'd need a team of people all hacking away.

For C4A, some of the baseline ideas where .. multiple server support (so could be live servers, plus dev and test server instances, so games could go up for testing without being released to public); peopel being able to fire up their own server anytime, so ED could have one, I could have one, anyone at all, and when you fire up a server it coudl be flagged to be hidden, or public announce and servers sharing a list of other known servers etc; and the client needs to be multiple account and multiple server aware .. multiple people on one device, and an account(s) per server; and a tightened down protocol that is extensible and consistent; some ability for push from server, and also push to server and queued pushes for when no connectivity; all that sort of stuff, is a lot of work, but thats mostly C4A-focused.. what about the larger scale of tieing a whole web of app/games together, etc... oh yeah, and self-publish games/apps to C4A (might be nice to tie into repos, so you upload game into a repo and a checkbox or flag in the package says 'hey, hook me into C4a while we're at it') .. ie: keep 'administrivia' out of the loop, just let devs put up a server if they want, or put up a game and join into existing servers, just make it all easier end to end to get games into the system, and players into the games.. still want to get device to device challenges and dynamic tournaments (let peopel create their own tournaments dynamicly, and challenge people, or auto challenge if your score gets beat, etc.); a proper database, so scores can be sorted by device (PC vs Pyra vs Pandora etc), and all sorts of magic...

Anyway, we could fire up a thread if people are interested; its hard ot get enough bodies whipped into a frenzy to discuss this one .. its not super important, and yet it is, in a way; and hey, at least if you look today, people are still doing C4A so we did something right

jeff

 

[pmprog]

I thought you just got bored and dumped TH

Not strictly true - what I got fed up with was having a PND that worked for a handful of people and no idea why it didn't work for a lot of others (and some comments that were made)... It took all the way to releasing my next game - which had the same issue - to find out that I'd included (via copy_libs.sh in codeblocks) a few libraries that shouldn't really have been copied. By the time that'd been figured out, there didn't seem a lot of activity in C4A (or at least the board for it), so I didn't know if it was worth trying to resuscitate and went on to look at a few other projects (that are in various states of incompleteness, though I did release SJKT!)

Shouldn't get this sort of problem on the Pyra (hopefully) partly because of I'll be able to install dev tools using apt-get and partly because I'm a bit wiser now.

Yeah, think it could be worth a thread for planning what's needed, I've started looking at a FunKeyMonkey plugin that could be used to hook out input for an overlay which I'm planning on. I still have far too many projects on my "active" list and not enough time, but hopefully with enough juggling I might get through them

 

[comradekingu]

Challenging other users would be a nice C4A2 feature. Or setting up your own inpromptu-compo.

Each player picks one thing to compete for, among the games that all players share.

And a button to download all the games, or just the required games, from the repo.

 

[God Ginrai]

Anyway, we could fire up a thread if people are interested; its hard ot get enough bodies whipped into a frenzy to discuss this one .. its not super important, and yet it is, in a way; and hey, at least if you look today, people are still doing C4A so we did something right

Fire up that thread and I'll definitely bring some input.

-God Ginrai

 

[Grench]

I have no idea how to make it, but I have a vision of how the audio control should look.


Most mixers for controlling audio functions on a device assume that you're producing the same audio output to all outputs and that each can then be controlled with a simple volume slider.  Each input on a slider to make a central 'root program' that is then fed through volume sliders for each output.


Personally, I would rather have the capabilities of a professional sound board.


Sound from each source can be adjusted still.  That is simple and doesn't need changing.


Sound to each output though - every source should be independently controlled at each output.  Why make it that complicated?  That is the point where you can split different sources to different devices.  It becomes important when considering the multi-functional capabilities of the Pyra.


I want to be able to simultaneously:


-Have a streaming video playing to HDMI with 7.1 audio.


-Have a local game playing on the screen with 2 channel output to headphones.


-Have an incoming phone call notification ring on the Pyra's speakers.


-Carry on a conversation using a Bluetooth headset.


And also be able to blend a bit of the movie audio into the game audio - multitasking.


Maybe add volume from the phone conversation to the Pyra or HDMI output and add a bit of the Pyra's mic input into the outbound audio to the phone call (speakerphone).


Something tells me that the above is a fantasy and that there is not enough DAC to handle it all at once.

 

[txus]

I have no idea how to make it, but I have a vision of how the audio control should look.


Most mixers for controlling audio functions on a device assume that you're producing the same audio output to all outputs and that each can then be controlled with a simple volume slider.  Each input on a slider to make a central 'root program' that is then fed through volume sliders for each output.


Personally, I would rather have the capabilities of a professional sound board.


Sound from each source can be adjusted still.  That is simple and doesn't need changing.


Sound to each output though - every source should be independently controlled at each output.  Why make it that complicated?  That is the point where you can split different sources to different devices.  It becomes important when considering the multi-functional capabilities of the Pyra.


I want to be able to simultaneously:


-Have a streaming video playing to HDMI with 7.1 audio.


-Have a local game playing on the screen with 2 channel output to headphones.


-Have an incoming phone call notification ring on the Pyra's speakers.


-Carry on a conversation using a Bluetooth headset.


And also be able to blend a bit of the movie audio into the game audio - multitasking.


Maybe add volume from the phone conversation to the Pyra or HDMI output and add a bit of the Pyra's mic input into the outbound audio to the phone call (speakerphone).


Something tells me that the above is a fantasy and that there is not enough DAC to handle it all at once.

Except for the blending between devices (AFAIK? please correct me if this is possible!), everything else can be done quite simply and on the fly with pulseaudio.

 

[WizardStan]

PulseAudio does all of that.  It will start a stream against a default target but there's a GUI for moving streams around, and it can then remember those for the future.  Every source has a volume slider, every destination has a volume slider, every destination can mix any number of streams.  I don't think it's possible to have a single source stream played on two different outputs, however.  You could probably create a virtual device which did that, though that'd be a pretty advanced setup.

 

[Letalis Sonus]

 I don't think it's possible to have a single source stream played on two different outputs, however.

You can configure PulseAudio to output on all available devices, though.