First newspost coming FROM the Pyra!


Good to see progress on the Pyra front, i just hope the media will get the facts properly about the project this time...

QMMP, Audacious and Deadbeef can the do same as foobar2000, maybe because those programs are using similar open source libraries to do the same job in a different way.

E.g- SID plugin on foobar2000 is using sidplay-residfp while QMMP uses libsidplayfp. All programs are using libFLAC for decoding.
 
Hmm from foobar2000's FAQ directly:
So far the Pandora itself is my best Audio player, but that is just because the amplifier can drive my high end Sennhieser headphones with out a headphone preamplifier. Hopefully the Pyra will have similar sound capabilities.

I'm still wishing for an update on this too. Audio quality and quantity was a big deal with the Pandora.
 
Hmm from foobar2000's FAQ directly:

Does foobar2000 sound better than other players?
No. Most of “sound quality differences” people “hear” are placebo effect (at least with real music), as actual differences in produced sound data are below their noise floor (1 or 2 last bits in 16bit samples). foobar2000 has sound processing features such as software resampling or 24bit output on new high-end soundcards, but most of the other mainstream players are capable of doing the same by now.
https://www.foobar2000.org/FAQ

Which I'm pretty sure Audacious and Deadbeef can handle just fine.

I didn't rule out placebo. Though I think you did reinforce my claim of hearing better somewhat regarding 24 bits, since I do have a couple of vinyl rips (one with so much dynamic range my below avg pc speakers can't play it without distortion. I keep it stored.)

Though I trust your notion that Audacious and Deadbeef will do the on-the-go job just as well.

Pandora and Pyra have a ARM CPU, just like smartphones and most onboard computers in modern cars, while foobar2000 expects x86, the architecture of desktops, compatible notebooks and most servers. You can get around that only with emulation, which uses up a lot of power and inserts bugs, and the fastest emulation for ARM -> x86 is Exagear Desktop which can only emulate a x86 Linux system, so you have to put Wine on top of that.

Does ARM as opposed to x86 mean we won't be able to play native linux games, like, idk, stuff on GOG?
What about using Wine and installscripts to get compatibility to so much games that don't have it, despite notorious bugs?
Not that I'm really knowledgeable about any of that, I just know it exists. (that's why I'm asking:oops:)

And I'd also like to know the exact sizes and speeds of the eMMC... PLS8 chips...
Are these important? I would like to know if you have the time\feel for it. If the answer is lenghty or thread hijacking PM can be used..?
 
Does ARM as opposed to x86 mean we won't be able to play native linux games, like, idk, stuff on GOG?
Perhaps some games, Many old games have open sourced engines and if it's DOS we have DOSBOX. It's just a matter of extracting the data files and copying them to a specific folder. On the Pandora there is quite a bit of selection of games that run this way.
What about using Wine and installscripts to get compatibility to so much games that don't have it, despite notorious bugs?
Well for one WINE isn't an emulator it's actually what the initials mean. So you need something to emulate an x86 processor... There is a couple ways of doing it, but right now the best solution I've seen is Exagear Desktop, it provides an x86 linux environment you can run native x86 program from, also WINE. Since emulation is involved on top of running WINE, I'd say performance is around early to mid 2000 era on the OMAP5.
 
Actually while WINE does stand for "Wine is not an emulator" it actually is an emulator by definition and it took years but the WINE faq now admits that it is in fact an emulator by definition.
 
Actually while WINE does stand for "Wine is not an emulator" it actually is an emulator by definition and it took years but the WINE faq now admits that it is in fact an emulator by definition.
Well it still doesn't provide a way of running x86 code on ARM without an additional emulation layer... yet...
 
Is there a difference between emulation and mimicry? Are some comedians emulators?
 
Actually while WINE does stand for "Wine is not an emulator" it actually is an emulator by definition and it took years but the WINE faq now admits that it is in fact an emulator by definition.

I would say that depends on the definition. But the problem is that the term "emulation" is often misleading as it's often associated with massive overhead and performance trade-off. But running a program with wine is not necessarily much slower than running it natively. Wine is basicly just a set of libraries and tools that let the programs run within a unix-like system.

Or as the Wine-FAQ says,
Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.

So I like the term "compatibility layer" much more here.
 
So I like the term "compatibility layer" much more here.
See, that it's part of why I was having trouble correcting my definition of emulator. I was reading about emulators on Wikipedia and it seemed like they were saying a compatibility layer is a type of emulator, which I don't really agree with (then again, I am not a programmer, so what do I know). If the people behind it want to call it an emu, let 'em. Did it really matter what we call it, it isn't a typical emulator as the term is usually understood as it relates to gaming. For the record, I don't pronounce gif like the peanut butter brand either.
 
Wine is basicly just a set of libraries and tools that let the programs run within a unix-like system.

Or as the Wine-FAQ says,

Wine's "emulator" is really just a binary loader that allows Windows applications to interface with the Wine API replacement.

So I like the term "compatibility layer" much more here.

As an aside, a few months ago I was trying to find texts describing how WINE works, without much success (I believe I lack both patience and skill -- which are related -- for web search); I was thinking of the technical details of creating an Android compatibility layer and whether syscall translation (using ptrace, probably) would be necessary for seemingly Android-only kernel components like Binder/OpenBinder, and so wondered how WINE does syscall translation. It does not help that I am knowledgeable only, really, about GNU/Linux and know little to nothing about Windows (internals) or Android (anything/everything), having avoided both, nearly completely, for at least five years.

What I have concluded, cautiously, is that WINE does indeed use ptrace, probably for syscall translation, but that this is a marginal use. Instead, it mainly implements two layers of interfaces (the Windows API, which well behaved applications are supposed to use and which has a very high degree of backwards compatibility, and the Native API, which applications should leave alone and which is not officially documented and is unstable within and between Windows releases). Apparently, the Windows kernel interface to userspace, unlike the Linux kernel, has no guarantee nor even suggestion of stability, with all syscalls coming from DLLs provided as part of the OS (which I found intriguing*), with none from well-behaved applications.

This suggests that any well-behaved application run via WINE that either uses OpenGL rather than Direct3D, or which does not use a hardware graphics API, should experience no overhead whatsoever, in theory, compared with the same application running on Microsoft Windows. This is likely the origin of claims that certain applications (presumably those not using Direct3D, and therefore without overhead from translation to OpenGL) run faster on GNU/Linux via WINE than on Windows, as the Linux kernel is often said to be more efficient (though I have never sought out benchmark tests). If, in normal operation, WINE has no overhead, and does not actually translate anything (Direct3D aside), being simply a reimplementation of the APIs/libraries (with a foreign-to-Linux calling convention and executable format) that come with the base Windows system, then it is in no way an emulator in a conventional sense.

Of course, it is quite possible that I have misunderstood something fundamental: as I said, I did not have much joy when trying to find out the details of all this.


*Linus Torvalds has spoken at length about his efforts to keep compatibility for syscalls, while saying that basic system libraries like GLIBC have been cavalier with compatibility. Microsoft Windows seems to have the opposite phenomenon: the kernel breaks compatibility all the time, but is always provided along with DLLs, that should never be bypassed, that fix compatibility. I am not sure which arrangement is better, but would it suggest that Microsoft have an easier time, theoretically, when cleaning up cruft in their kernel?
 
Did it really matter what we call it, it isn't a typical emulator as the term is usually understood as it relates to gaming.

FWIW, when I first came across emulators, they were pretty useless for gaming because (a) they weren't as optimised as today's emulators and (b) any emulator running on the latest hardware can only emulate a cutting edge machine that's say three or four years old today, so this being the mid 80s, it could only emulate things that barely ran games, but it could run a mean Lotus 1-2-3 ;)
 
just a spontaneous thought as the pi 3 was released recently, any possibility that SoC could be acquired for an alternative cpu board in the near future? it's fully open iirc and 64bit quad core (even if only at 1.2ghz) is interesting
 
Except his wishes have taken up 8 or 9 pages in a different thread and he continually posts them everywhere. JUST STOP. We have what we have. Either you want it or you don't.
But wasn't that a thread revolving around that certain topic ?
 
Back
Top