On 3/27/08, Adam Bark <[EMAIL PROTECTED]> wrote:
> Hi, I've looked through the issues with ALSA on the wiki, you mention that
> we need a fast array library, would it be quick enough to implement using C
> arrays through ctypes do you think? Is this a viable avenue to explore for
> GSoC what else do you think needs doing to the ALSA library to get it up to
> standard?

The problem is not data representation (arrays could be stored as
ctypes arrays, python arrays, python lists or python strings), but
manipulating that data fast enough.  Python doesn't have the
processing grunt to run an inner loop over any of these arrays for
realtime audio processing (on a fast computer, perhaps a small number
of channels could be processed, but at the expense of the rest of the
application).

By "fast array library" I really mean implementing the channel mixing
function in C (or Pyrex, or numpy, ...) code.  This not my first
preference, because it introduces another dependency when there are
still other avenues to explore.

I believe my current ALSA code is incorrect.  This is due to me
writing it in a hurry, and ALSA lacking any kind of useful
documentation.  Someone with time and will could implement this more
carefully, especially with respect to older ALSA libraries, and
seeking assistance from the ALSA developers as well.

There are also many other audio servers to consider: PulseAudio in
particular looks promising and seems to be the default for the next
Fedora and Ubuntu releases at least.

Alex.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

  • GSoC Adam Bark
    • Re: GSoC Alex Holkner

Reply via email to