Daniel Richard G. wrote:
> Thomas, thank you for your clear description of the issue.
>
> Given that the problem is memory beyond the 2GB barrier, something I
> wanted to try was mmap()'s MAP_32BIT flag. You can sort-of do a malloc()
> by making an anonymous mapping, and so I hacked up safe_malloc() and
> safe_free() (in awelib/malloc.c) accordingly. My patch against the
> awesfx-0.5.1a source (current Ubuntu version) is attached.
>
> The addresses returned are consistently 0x4[0-9a-f]{7}, yet I continue
> seeing the "no memory left" error. Do you think there is something in
> this approach that may allow a solution that doesn't require kernel
> modification, or are we still at the mercy of the kernel's memory
> allocation policy?
Not really, at least not according to my understanding of the situation.
Look,
obviously the kernel has to copy over the sound font from user memory to
kernel
memory anyhow - simply because the user memory where awelib initially
loads the sound font into is released by the Os as soon as the program
is unloaded.
Thus, any user space tools cannot, by construction, control where the
wavetable
will go. It is the kernel that runs out of memory when trying to
allocate persistent
kernel memory for the sound font, not the user space tools.
Thus, this really requires a modification of the kernel emu10k1 driver,
unfortunately.
Greetings,
Thomas
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/183456
Title:
Trying to load a sf2 file with asfxload returns "sfxload: no memory left"
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
