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


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.
 
Last edited by a moderator:
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
 
Last edited by a moderator:
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 :)
 
Last edited by a moderator:
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.
 
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
 
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.
 
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.
 
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.
 
Back
Top