Gamer125 / fofix

Automatically exported from code.google.com/p/fofix
0 stars 0 forks source link

Get rid of unmaintained PyOGG and PyVorbis #601

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Still looking for a viable replacement for PyOGG/PyVorbis that allows sound
buffer modifications.

While pygame.mixer.Sound plays OGG files fine, it doesn't allow us to
manipulate sound. e.g. pass a buffer to pitchbend then update buffer before
pygame.mixer.Sound plays it.

Perhaps we could use pymedia.audio.sound or more go down to the C level and
use AVBin (a minimal ffmpeg wrapper)?

Original issue reported on code.google.com by evily...@gmail.com on 25 Feb 2009 at 5:27

GoogleCodeExporter commented 9 years ago
PyOGG/PyVorbis: if we get it to work under windows, we should stay with it (as 
it
works fine under linux py2.5 and py2.6, and it is in all major distros)

PyMedia seems very outdated too: last update 3 years ago
pygame.mixer.Sound: is NOT streaming the file -> needs much RAM!, don't know how
pitchbend works, but isnt there Sound.get_buffer()
pygame.Music: streaming, but only 1 File at a time
pyglet/Avbin: can stream multiple files, but afaik is not in the major linux 
distros?

Original comment by max26...@gmail.com on 25 Feb 2009 at 6:03

GoogleCodeExporter commented 9 years ago
http://www.zak.co.il/a/stuff/gpl/misc/eng/pythonsound.html I just found this 
project
analysing Python sound modules. It appears to cover the things you guys need it 
to,
and there may be more actively developed options available than pyOgg etc...One
criteria is minimum compatibility with XP and Linux.

Original comment by evilbobt...@gmail.com on 25 Feb 2009 at 6:12

GoogleCodeExporter commented 9 years ago
While pygame.mixer.Sound (as of pygame 1.8) has a get_buffer() method, it has no
set_buffer() method... Am i missing something?

pymedia is outdated? Let's ditch it then.

Indeed, to my knowledge, avbin isn't packaged for major linux distros.

While PyOGG/PyVorbis does seem to work well with python2.5, at least not under
GNU/Linux, it seems to be a pain in the ass under Windows... Moreover, iirc it
doesn't work on my 64bit machine... I haven't take the time to isolate the 
issue tho.
Perhaps it's related to something else e.g. Numeric.

Original comment by evily...@gmail.com on 25 Feb 2009 at 6:18

GoogleCodeExporter commented 9 years ago
Thanks for the link altho it doesn't give much hope... 
For a second I thought snack was a good candidate until he gives details about 
it's
[in]efficiency.

Original comment by evily...@gmail.com on 25 Feb 2009 at 6:28

GoogleCodeExporter commented 9 years ago
Keep in mind I haven't yet given up on trying to get pyogg/pyvorbis packaged 
(and
running!) nicely under Windows for 2.5/2.6.

I may track down the person who built the 2.4 binaries to see what they did.

pitchbend works by calling a function of SDL_mixer that is not exported through
pygame to set a processing callback on the audio stream.  In pitchbend, said 
callback
is written in C++ using a rather sub-optimal sound library.  I envision the 
sox-based
successor to pitchbend being something that sits on a directly Python-accessible
level between the source of the sound (currently 
ogg.vorbis.VorbisFile().read()) and
passing it to be output (currently through some black magic with 
pygame.sndarray).

With pitchbend the real dependency is on continuing to use pygame for audio 
output,
but I am trying my darnedest to get rid of pitchbend.  pyogg/pyvorbis really do 
not
play into the way things are done right now as far as effects go, but they were 
going
to with the new way I was thinking of implementing effects.

@evilynux: on your 64-bit system, try running:
# [snip]
import ogg.vorbis
import sys
sys.stdout.mode = 'wb'
f = ogg.vorbis.VorbisFile(sys.argv[1])
while True:
  data, bytes = f.read()[:2]
  if bytes == 0:
    break
  sys.stdout.write(data[:bytes])
# [snip]
and piping it to "play -t s2 -r 44100 -c 2 -".  If it works, the blame lies 
squarely
with Numeric.  (If it's a Windows machine, pass "-u" to Python to put stdout in
binary mode.)

Original comment by john.stumpo on 25 Feb 2009 at 11:20

GoogleCodeExporter commented 9 years ago
evilynux: for pyVorbis: try numpy, if it doesn't work, try pygame 1.9.0pre
for me updating to the new pygame (1.8.1 seemms to have a problem in sndarray) 
helped
on Fedora 64-bit
(guitar, drums, rhythm-files play fine now - but i dont know if that is/was 
your problem)

Original comment by max26...@gmail.com on 26 Feb 2009 at 11:46

GoogleCodeExporter commented 9 years ago
Thanks for the suggestions John and max26199. I'll try as soon as possible (I'm
currently at my office with 32bit CPUs).

John: If wish i could give you a hand w/ using [lib]SoX instead of libsndobj... 
Is
there anyone selling free time?

Original comment by evily...@gmail.com on 26 Feb 2009 at 2:23

GoogleCodeExporter commented 9 years ago
evilynux: If you use my test code, remove the sys.stdout.mode line.  It was
accidentally left in from before I figured out the whole "passing -u to Python" 
thing.

I now have working 2.6 builds of pyogg and pyvorbis (working enough at least to 
do
that test without crashing - I must resolve some numpy-related issues to make 
them
work in FoFiX).  I still need to build glewpy, but for some reason it's working 
right
now without it.

Check my mediafire folder for updated 2.6 dependency module builds.  (The 2.5 
ones
are currently still broken.)

Original comment by john.stumpo on 26 Feb 2009 at 8:53

GoogleCodeExporter commented 9 years ago
I now have audio completely working under 2.6 using pyogg, pyvorbis, and numpy!

Unfortunately, due to a bug in pygame's stable releases, things will not work 
quite
right without modifying it slightly (specifically pygame._numpysndarray).  It is
already fixed upstream.

Since I'm now getting crashes (for which my debugger blames pygame) when 
py2exe'd
with 2.6 (though curiously not when running from source...), I'm probably going 
to
build the latest pygame svn and try that in order to fix both problems.  I will 
make
and upload a 2.6 Windows build of the latest pygame svn for the benefit of those
lacking the proper tools.  (pygame provides a nice automated service for 
obtaining
prebuilt Mac and Windows binaries of their latest svn, but unfortunately they 
only
provide 2.4 and 2.5 binaries for Windows, though they do provide a 2.6 Mac 
package.)

I haven't the time tonight, though.  Next time I work on FoFiX, the first thing 
I am
going to do is test the great abundance of changes in my working copy under 2.4 
as
well as 2.5 and 2.6, and (if they work under all three) commit those that do not
place extra demands on dependency modules.  (I know you have been wanting to see
precisely what I have been doing for quite some time...)

Original comment by john.stumpo on 27 Feb 2009 at 3:39

GoogleCodeExporter commented 9 years ago
Indeed, using pygame 1.9 from SVN did the trick!
Guitar sound not working with python2.5 and/or numpy: really 64bit-specific?

That said, there's a new bug: fullscreen doesn't scale the window. In my case, 
that
means a 800x600 game window over a 1024x768 black background. (That's a very 
annoying
problem).

Original comment by evily...@gmail.com on 27 Feb 2009 at 4:28

GoogleCodeExporter commented 9 years ago
I now have a 2.6 Windows build of pygame r1954 in my mediafire, so all 
dependencies
are now satisfied under 2.6 on Windows.  (Except for glewpy, but all remaining
references to it in FoFiX are unreachable.)  I can now run without problems from
source or binary under 2.6 on Windows.

Once I test under 2.4 tomorrow, I will (finally!) commit those changes I have
accumulated that do not interfere with proper functioning under 2.4.

(Perhaps a temporary branch is in order for the non-2.4-compatible changes?)

Original comment by john.stumpo on 28 Feb 2009 at 5:41

GoogleCodeExporter commented 9 years ago
r1114 includes changes related to this issue.

Original comment by john.stumpo on 28 Feb 2009 at 6:36

GoogleCodeExporter commented 9 years ago
good job john!
thanks to your pyogg, pyvorbis and pygame builds for py2.6, audio works fine
(what was the problem with the old 2.5 pyogg modules? what did you change to 
make it
work?)

here's a list of all required modules for Windows Python 2.6, if somebody wants 
to
add that to the Wiki:
Python 2.6.1.1
(http://downloads.activestate.com/ActivePython/windows/2.6/ActivePython-2.6.1.1-
win32-x86.msi)
PIL-1.1.6 (http://effbot.org/downloads/PIL-1.1.6.win32-py2.6.exe)
numpy-1.2.1 (http://www.mediafire.com/download.php?nywcy0yy2mz)
PyOpenGL-3.0.0c1 
(http://downloads.sourceforge.net/pyopengl/PyOpenGL-3.0.0c1.win32.exe)
pyogg-1.3 (http://www.mediafire.com/download.php?qlw2hwyy0rz)
pyvorbis-1.5a (http://www.mediafire.com/download.php?i21ewawljtw)
pygame-1.9.0a0-rev1954 (http://www.mediafire.com/download.php?dnynwa5iem3)

but note: due to FoFiX's current OpenGL implementation, the game will run much 
slower
than with the old PyOpenGl-2.x (~120fps -> 50fps on my system)

Original comment by max26...@gmail.com on 28 Feb 2009 at 7:31

GoogleCodeExporter commented 9 years ago
I don't really see much point in our recommendation of ActivePython, as the only
extra dependency that we have atop the official Python release that AP provides 
is
pywin32.

Don't forget the optional rtmidi and psyco dependencies
(http://www.mediafire.com/download.php?njrzmkyztfg and
http://www.voidspace.org.uk/downloads/psyco-1.6.win32-py2.6.exe).

Also, I needed to make a slight modification to pyOpenGL
(http://www.mediafire.com/download.php?imhidzjjman).

When it comes to the other 2.4 deps, pysqlite2 is now in the standard library as
sqlite3, we phased out Numeric, glewpy appears unnecessary, and I am trying my 
best
to finish pitchbend's successor.

I think I will add a wiki page for running under 2.6.

Original comment by john.stumpo on 28 Feb 2009 at 8:13

GoogleCodeExporter commented 9 years ago
Wiki page added:
http://code.google.com/p/fofix/wiki/RunningUnderPython26

Original comment by john.stumpo on 28 Feb 2009 at 9:48

GoogleCodeExporter commented 9 years ago
Generalized the issue, it's not python-specific. Lowering the priority as we 
still
manage to build them.

Original comment by evily...@gmail.com on 17 Jun 2009 at 2:54