Message-ID:
<CA+Q62MA2U4j7tH7+=e=+uK7nQm0WRn545btsz+62ZMtjCR4uww at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
And even if we were willing to use FUSE,
- I’m going to guess that Android doesn’t normally support it (at
least for apps), and,
Android doesn’t support it as far as I know.
While I half-recall something about Android being ported to run on BSD
or something (not that it matters, since FUSE has versions for more
than just Linux), Android mostly runs on Linux, and Linux supports
FUSE, so Android SUPPORTS FUSE… but FUSE requires a kernel module
which Google apparently doesn’t require, so…
Vendor-dependent, in essence. Regardless, a brief search suggested
that there are FUSE compiles for Android, so that part isn’t the
issue, the apparent lack of a requirement for it is the issue.
I don’t know enough about
FUSE’s permission requirements about whether it is compatible with
Android’s security model. But anything needs to be in userland and
live in Android’s app sandbox. My hunch is that FUSE won’t work
without rooting your device.
For at least some devices, yes. I suppose that we could try to figure
out a test to see if FUSE is present, but would that really be worth
the effort without a fall-back?
But I don’t think FUSE helps here. There are really 2 different
problems which got entangled.
The first problem is that all assets inside an apk are basically
inside a zip, and the standard C ways of accessing a file are useless.
You must use their special APIs to read anything (AssetManager). (And
I have nightmare performance problem stories about this API too.)
Wait, wait, wait… are you saying that the “best” API is only
supported for resource files that you’ve stuffed into your package?
Please tell me that I misread what you were trying to imply.
If ordinary files ARE supported, and the API doesn’t do something
weird, then FUSE would almost guaranteed work IF you could run it…
but if only packaged files are supported then it would be futile
regardless.
But the other problem is that you really want access to Android’s
native decoder system in my very strong opinion. You get multiple
benefits if you use Android’s decoder system:
I don’t properly recall the email that I originally replied to, but
from you mentioning this I’m guessing: the good-latency API doesn’t
interact with the Android audio decoder that you’re talking about,
does it?
also remember that Android has a pathetic apk max size limit
of like 50MB).
Actually I think that sorta/kinda makes sense, what with cell-modem
data-plan charges, but I’ll concede that if I were implementing a
packaging system I’d allow packages to provide files & folders to
other packages, to be hard or soft linked into their “virtual
package”, so it also sorta doesn’t make sense to me…
Anyway, the only way to acces Android’s native decoders is through
their file or URI API. I think they did this partly because they
conflated the AssetManager problem with the decoder API. (The
abstraction leaked.)
Unfortunately I think that this gets at the real fix that’s required:
someone needs to fix the Android implementation (from my perspective,
preferable to a trivially pipeline-able memory-mapping-based system).
That way we could get sensible latency on plenty of handsets in, oh, a
few years. I’m thinking it’s not going to happen from just us.> Date: Fri, 4 Apr 2014 01:29:22 -0700
From: Eric Wing
To: SDL Development List
Subject: Re: [SDL] Mix_PlayChannel Android lag