FAQ
Hi, I'm thinking about writing a system for DJing in python, but I'm
not sure if Python is fast enough to handle the realtime audio needed
for DJing, could a guru shed some light on this subject and tell me if
this is doable or if I'm out of my fscking mind?

Search Discussions

  • Farshid Lashkari at Feb 3, 2006 at 12:30 am

    Levi Campbell wrote:
    Hi, I'm thinking about writing a system for DJing in python, but I'm
    not sure if Python is fast enough to handle the realtime audio needed
    for DJing, could a guru shed some light on this subject and tell me if
    this is doable or if I'm out of my fscking mind?
    What do you mean by DJing? Queueing and playing audio files? If so,
    python should work fine. Check out the PyMedia library for
    playing/mixing audio with python.

    -Farshid
  • Ivan Voras at Feb 3, 2006 at 1:35 am

    Levi Campbell wrote:
    Hi, I'm thinking about writing a system for DJing in python, but I'm
    not sure if Python is fast enough to handle the realtime audio needed
    for DJing, could a guru shed some light on this subject and tell me if
    this is doable or if I'm out of my fscking mind?
    Any and all mixing would probably happen in some sort of multimedia
    library written in C (it would be both clumsy to program and slow to
    execute if the calculations of raw samples/bytes were done in python) so
    there shouldn't be a noticable performance hit.
  • Terry Hancock at Feb 3, 2006 at 6:13 am

    On Fri, 03 Feb 2006 02:35:56 +0100 Ivan Voras wrote:
    Levi Campbell wrote:
    Hi, I'm thinking about writing a system for DJing in
    python, but I'm not sure if Python is fast enough to
    handle the realtime audio needed for DJing
    Any and all mixing would probably happen in some sort of
    multimedia library written in C
    Of which more than one exists. You may have some interest in
    PyMedia, PyGame (SDL), pyogg, pyvorbis packages.

    You might want to try googling for "Python audio libraries",
    that appears to turn up some other results.

    Note that pyogg/pyvorbis will also give you access to
    the embedded metadata in Ogg files, which sounds like it
    might be useful in your application.

    Cheers,
    Terry

    --
    Terry Hancock (hancock at AnansiSpaceworks.com)
    Anansi Spaceworks http://www.AnansiSpaceworks.com
  • Simonwittber at Feb 3, 2006 at 10:35 am

    Levi Campbell wrote:
    Any and all mixing would probably happen in some sort of multimedia
    library written in C (it would be both clumsy to program and slow to
    execute if the calculations of raw samples/bytes were done in python) so
    there shouldn't be a noticable performance hit.
    Actually, manipulating and mixing audio samples can be both fast and
    elegant, in Python, if you use Numeric or a similar library.

    -Sw.
  • Ivan Voras at Feb 3, 2006 at 11:12 am

    simonwittber at gmail.com wrote:

    Actually, manipulating and mixing audio samples can be both fast and
    elegant, in Python, if you use Numeric or a similar library.
    ... at which point you're actually doing it in C, not pure python... :)
  • Fuzzyman at Feb 3, 2006 at 11:28 am

    Ivan Voras wrote:
    simonwittber at gmail.com wrote:
    Actually, manipulating and mixing audio samples can be both fast and
    elegant, in Python, if you use Numeric or a similar library.
    ... at which point you're actually doing it in C, not pure python... :)
    Only in as much as doing anything in Python is *really* doing it in C,
    surely ?

    Come to that, you're **really** doing it in machine code...

    All the best,

    Fuzzyman
    http://www.voidspace.org.uk/python/index.shtml
  • Ivan Voras at Feb 3, 2006 at 11:34 am

    Fuzzyman wrote:

    Only in as much as doing anything in Python is *really* doing it in C,
    surely ?

    Come to that, you're **really** doing it in machine code...
    I've yet to see someone calling

    if a == '5':
    print "it's 5"

    machine code. It's the distinction on which level the program's logic is
    implemented, not at which level it's executed.
  • Fredrik Lundh at Feb 3, 2006 at 11:46 am

    Ivan Voras wrote:

    Come to that, you're **really** doing it in machine code...
    I've yet to see someone calling

    if a == '5':
    print "it's 5"

    machine code. It's the distinction on which level the program's logic is
    implemented, not at which level it's executed.
    uhuh? so why did you just argue that

    if foo.bar():
    bar.aba()

    means "doing it in C" if bar and aba happens to be parts of an extension
    library ?

    </F>
  • Ivan Voras at Feb 4, 2006 at 11:14 pm

    Fredrik Lundh wrote:
    uhuh? so why did you just argue that

    if foo.bar():
    bar.aba()

    means "doing it in C" if bar and aba happens to be parts of an extension
    library ?
    Because "bar and aba happen to be parts of extension library" :)
  • Ivan Voras at Feb 4, 2006 at 11:18 pm

    Ivan Voras wrote:

    Because "bar and aba happen to be parts of extension library" :)
    To end this disussion: I meant "doing it in C" as a colloquial
    expression, not a technical one. The expression holds true for every
    case where a function/class/module/etc is implemented in a lower-level
    language, and "C" was used only as an example.
  • Fuzzyman at Feb 6, 2006 at 11:08 am

    Ivan Voras wrote:
    Ivan Voras wrote:
    Because "bar and aba happen to be parts of extension library" :)
    To end this disussion: I meant "doing it in C" as a colloquial
    expression, not a technical one. The expression holds true for every
    case where a function/class/module/etc is implemented in a lower-level
    language, and "C" was used only as an example.
    I think the point we were trying to make, is that even in 'colloquial
    terms' there is *no difference* between using a part of the standard
    library (e.g. the builtin module md5) and a third party extension
    module written in C.

    All the logic you actually write is in pure python.

    If you write *your own extension module* in C, then you could rightly
    be described as doing it in C.

    All the best,

    Fuzzyman
    http://www.voidspace.org.uk/python/index.shtml
  • Grant Edwards at Feb 3, 2006 at 3:30 pm

    On 2006-02-03, Fuzzyman wrote:

    Come to that, you're **really** doing it in machine code...
    And probably not the machine code emitted by the assembler but
    rather the actual micro-code that's implemented in hardware
    that's running a program that implements the VM for the machine
    code emitted by the assemblers.

    Hell, from the Python point of view it might as well be
    tortoises all the way down.

    --
    Grant Edwards grante Yow! Dehydrated EGGS are
    at STREWN across ROULETTE
    visi.com TABLES...
  • Grant Edwards at Feb 3, 2006 at 3:19 pm

    On 2006-02-03, Ivan Voras wrote:
    simonwittber at gmail.com wrote:
    Actually, manipulating and mixing audio samples can be both fast and
    elegant, in Python, if you use Numeric or a similar library.
    ... at which point you're actually doing it in C, not pure python... :)
    If that's the way you want to look at it, there is nothing that
    can be done in pure python. Both the built-ins and the basic
    operators and sematics are implimented in C. Unless you're
    running Jython on a platform that has a hardware JVM, I
    suppose. But noboby in this discussion is doing that.

    --
    Grant Edwards grante Yow! Should I get
    at locked in the PRINCICAL'S
    visi.com OFFICE today -- or have
    a VASECTOMY??
  • Andrew Gwozdziewycz at Feb 3, 2006 at 3:32 pm

    If that's the way you want to look at it, there is nothing that
    can be done in pure python. Both the built-ins and the basic
    operators and sematics are implimented in C.
    What makes python a powerful programming language? It's the fact that
    it bundles up all sorts of c-code into a nice easy to use language.
    When you write _any_ python, you are taking a peice of c here, a piece
    of c here, and when you import a "pure python" module, you're really
    just importing more c, because it's all being built from c.

    What makes a builtin faster? It's the fact that there's less work to
    be done before it's called. As more work needs to get done to find the
    builtins that make it possible to run, execution time increases. Plain
    and simple.

    So, to answer the original posters question, Use python to peice
    together the things you need. You're development time will be fast,
    and you will probably see some good results.




    --
    Andrew Gwozdziewycz <apgwoz at gmail.com>
    http://ihadagreatview.org
    http://plasticandroid.org
  • Ivan Voras at Feb 3, 2006 at 7:03 pm

    Grant Edwards wrote:
    On 2006-02-03, Ivan Voras wrote:

    simonwittber at gmail.com wrote:
    Actually, manipulating and mixing audio samples can be both fast and
    elegant, in Python, if you use Numeric or a similar library.
    ... at which point you're actually doing it in C, not pure python... :)
    If that's the way you want to look at it, there is nothing that
    can be done in pure python.
    I think people who say that deliberately misunderstand the point. Python
    is suitable for some things, not for others. So is C.
  • Terry Hancock at Feb 3, 2006 at 8:35 pm

    On Fri, 03 Feb 2006 20:03:01 +0100 Ivan Voras wrote:
    Grant Edwards wrote:
    On 2006-02-03, Ivan Voras wrote:

    simonwittber at gmail.com wrote:
    Actually, manipulating and mixing audio samples can be
    both fast and >>elegant, in Python, if you use Numeric or
    a similar library. >
    ... at which point you're actually doing it in C, not
    pure python... :)

    If that's the way you want to look at it, there is
    nothing that can be done in pure python.
    I think people who say that deliberately misunderstand the
    point. Python is suitable for some things, not for
    others. So is C. --
    To me, "doing it in C" implies that I must write some C
    code.

    In this case, that won't be required at all. Everything the
    OP wants to do can be done exclusively by writing Python
    code. He will, of course, be *using* some extension
    libraries which might in turn have been written in C (or
    Fortran, assembly language, or ADA for that matter -- but
    practically speaking, C).

    This will be true whether he uses PyMedia, PyGame, Numeric
    or all three.

    Indeed, as an implementation matter only the "glue code"
    will be interpreted in Python -- but the OP will not have to
    write anything but such "glue code".

    For me, who no longer writes *any* C code, not having to
    write the C code is a big win. And I think this is the PoV
    relevant to the OP.

    Cheers,
    Terry


    --
    Terry Hancock (hancock at AnansiSpaceworks.com)
    Anansi Spaceworks http://www.AnansiSpaceworks.com
  • Grant Edwards at Feb 3, 2006 at 8:39 pm

    On 2006-02-03, Ivan Voras wrote:

    Actually, manipulating and mixing audio samples can be both fast and
    elegant, in Python, if you use Numeric or a similar library.
    ... at which point you're actually doing it in C, not pure python... :)
    If that's the way you want to look at it, there is nothing that
    can be done in pure python.
    I think people who say that deliberately misunderstand the
    point. Python is suitable for some things, not for others. So
    is C.
    People who say what?

    --
    Grant Edwards grante Yow! Do you need
    at any MOUTH-TO-MOUTH
    visi.com resuscitation?
  • Ivan Voras at Feb 3, 2006 at 10:24 pm

    Terry Hancock wrote:

    To me, "doing it in C" implies that I must write some C
    code.
    Ok, perhaps it is a bit imprecise :)
    In this case, that won't be required at all. Everything the
    OP wants to do can be done exclusively by writing Python
    code. He will, of course, be *using* some extension
    libraries which might in turn have been written in C (or
    Fortran, assembly language, or ADA for that matter -- but
    practically speaking, C).

    This will be true whether he uses PyMedia, PyGame, Numeric
    or all three.
    This, of course, is what I am talking about. Python is a great glue
    language, but not exactly suitable for lots of bit twiddling or DSP by
    itself (itself=only with modules from the standard distribution) :)
  • Tom Anderson at Feb 3, 2006 at 4:37 pm

    On Fri, 3 Feb 2006, Ivan Voras wrote:

    Levi Campbell wrote:
    Hi, I'm thinking about writing a system for DJing in python, but I'm
    not sure if Python is fast enough to handle the realtime audio needed
    for DJing, could a guru shed some light on this subject and tell me if
    this is doable or if I'm out of my fscking mind?
    Perhaps surprisingly, it is:

    http://www.python.org/pycon/dc2004/papers/6/

    At least, you can certainly mix in realtime in pure python, and can
    probably manage some level of effects processing. I'd be skeptical about
    decoding MP3 in realtime, but then you don't want to write your own MP3
    decoder anyway, and the existing ones you might reuse are all native code.
    Any and all mixing would probably happen in some sort of multimedia
    library written in C (it would be both clumsy to program and slow to
    execute if the calculations of raw samples/bytes were done in python)
    Clumsy? Clumsier than C? No, python isn't as good with binary data as it
    is with text or objects, but on the whole program scale, it's still miles
    ahead of C.

    My advice would be to tackle the task in the same way you'd tackle any
    other: write it in pure python, then fall back to native code where it's
    unavoidable. When i say 'pure python', i don't mean 'not using any native
    modules at all', obviously - if someone's written an MP3 decoder, don't
    eschew it because it happens to be in C. Also, bear in mind that resorting
    to native code doesn't automatically mean writing in C - you can start
    doing stuff like moving from representing buffers as lists of ints to
    using NumPy arrays, using the functions in the standard audioop module,
    whatever; if that's not fast enough, rewrite chunks of the code in pyrex
    (a derivative of python that can be compiled to native code, via
    translation to C); if it's still not fast enough, go to C.

    Oh, and before you start going native, try running your program under
    psyco.

    tom

    --
    Throw bricks at lawyers if you can!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedFeb 3, '06 at 12:16a
activeFeb 6, '06 at 11:08a
posts20
users11
websitepython.org

People

Translate

site design / logo © 2022 Grokbase