In Python, Pyglet or Pygame are your options.  It looks like Pyglet has easier sound.  Dedicated frameworks are pretty uncommon, and I believe that BGT is the only one.  Options in other languages: SlimDX (maybe misremembering the name, C#), XNA (C#), SDL (C++, Python, others), LWJGL (Java, but lightweight is really untrue because Java), the list goes on.

C/C++ will outdo Purebasic for execution speed, simply because they benefit from over 30 years of research into optimizing compilers and at least a million dollars of invested money.  Given the architecture of the modern microprocessor, C/C++ compilers will actually generate assembly that is faster than anything you can write yourself.  Let me take this time to again remind everyone that execution speed is literally not a factor anymore, however.
Anything in C++ is going to be what you would classify as a setup nightmare.  This is both a  particular shortcoming of windows and not such an easy thing to do in the first place.  Ironically, this is one thing that Linux typically makes very easy.  Allegro and SFML are both on my "particularly bad" list, by which I mean that I couldn't ever get either to work in the first place (I've not touched Allegro in 5+ years).
I can say with a great deal of confidence that an object-oriented programming language with garbage collection is the fastest option.  This argument has been had before, I'm not going to do it again here.  Mostly because I've finally realized that unless you bother learning and developing a game in one, you won't ever believe me anyway.  That is, the people who can be convinced don't need convincing.  I'm just going to say that, if you Google it, you're going to find that most people share this viewpoint for projects where performance is not critical.  performance is not critical for any Audiogame save perhaps MMOs, but I don't believe that it matters there (MMOs=intelligent architecture, not fast language.  Fast language just shaves off a bit of the needed intelligence, and then you find that actually you needed that intelligent architecture and need to implement it in a language that makes you manually manage memory).
A full, complete Audiogame only using the Windows API and DirectX would be around 5000-15000 lines.  500 of this would be reimplementation of the keyboard handling logic via any of several various methods, 1000 of this would be audio handling code possibly including a basic custom mixer, and the rest would be pretty standard game logic.  The major contributions to code size here would actually be saving and loading resources (I'm assuming C/C++, so no easy serialization).  Basic collision checks for a game that does not involve rotation and only uses boxes is about 30 lines.  Basic collision checks for a game that does allow rotation and only uses boxes would be about 150 lines, assuming only the Windos API and DirectX plus the prerequisite knowledge of the mathematics.  This code would include the needed matrix multiplication and formulation code, as well as the inverse computation (which is trivial because it's a rotation matrix).  the biggest challenge to such an undertaking is twofold: the Windows API is huge, and the languages in which it might be reasonable to place this limitation upon oneself require that your code spend a ton of time error checking (no exceptions or logging, so if(x == error) everywhere) and managing memory (it's not uncommon to free an allocated pointer at 3 or 4 different places in a function).  A good example of a sighted game that comes close to doing this is Cube, which is 7 kloc as I recall.  I'm not sure that that number includes Enet.

I can also speak against Java.  I know that CAE had similar experiences to Tward.  You're also talking about requiring end users to download and install a 200 MB runtime which isn't so popular nowadays.  Especially among the blind wherein swing is typically a horrible, horrible thing.  I've got things to say against the java language and I finally know how to say them, but it's the size of a blog post and I don't think most of this crowd would care anyway.  It's my opinion you should, but the things I see with Java can only be seen at the point wherein the language being used for the project has become a triviality (disclaimer: not true if crossing programming paradigms).
I'd suggest against C++ unless you already know it.  C++ will bite you really, really hard if you don't know what you're doing, and the performance overhead of other languages is laughable for this problem.  Ironically, C++ can be one of the best cross-platform languages, but only for certain problems and only if you know what you're doing.  There's an underlying theme here: C++ works if you know what you're doing.  If you don't, well, there are easier things.  Like pulling your teeth out with a dull spoon.

What functionality do I gain by going to C++ that I can't get in Python or just about any other interpreted language with a C FFI?  Python and just about everything else I can think of can access SDL directly, so I fail to understand what is gained.  In the very unlikely event that you need something, you can write only that small subset in C and call it.  This has happened only once (hint: Libaudioverse).
As for cross-platform: not being able to run Java programs on multiple Windows machines is a problem.  But I have yet to see a system that's truly cross-platform without any effort.  Cross-platform bites, bites hard, and doesn't let go.  Looking for the magic cross-platform bullet is like looking for the holy grail-it simply isn't going to happen.

java is an odd thing.
Firstly, Android is a special case in all ways.  When you build your platform from the ground up in Java, Java becomes easy to use on it.  Windows is interesting in that there are different editions of the runtime and, when last I looked, I couldn't figure out which ones actually had the sound libraries.  If you wanted to do a game in java, I'd look at LWJGL.  But that raises a million packaging concerns that aren't so easy, and we can't forget that wonderful runtime.  Minecraft did it and managed to sell millions of copies, so it is possible.
Java is also one of the most widely wanted languages, but I'd argue that programmers who know other things are more highly paid.  I'd be very curious to see data.  It's true that Java is simple, but that doesn't cover it.
Java is a jail and you are the criminal bad programmer.  Java forces you to be a good programmer by making you be Java, irregardless of if there's a better way to express the problem in question.  Every good programmer I know (i.e. has a job, has written code, has done projects of very large size and, in one case, partially owns a company) hates java.  It's true that code is forced to be comprehensible, but that doesn't mean the programmer writing it is a good programmer nor that the method of expression is the best.  Java has only just now begun to add features that have been widely regarded as good for many, many years: among them support for limited multiple inheritance (common pattern for collections libraries), first-class functions (good for just about anything that isn't CPU bound), and a bunch of other things that stem from these.
As a concrete example of Java's jailness, however, consider the getter and the setter.  It is true that these *can* be good practice, but you don't always want or need them.  It's 9 or so lines of code per variable that you would otherwise not have to write for your internal class pairs that never see anything but their partner.  Java even forces code layout to an extent that I've not yet seen anywhere else.  I look at this and I look at checked exceptions.  And when I put them together, I can't help but feel that a major point of Java is making you think by requiring you to write more code.  We've literally begun fixing this by putting code generators in our IDE which, unlike for other languages, is almost needed to be productive.  Not to mention the anti-patterns you have to do to get around checked exceptions for that ten line script (hint: sometimes, it's 10 or more lines that check errors and do nothing at all, but it won't compile without them).
I'd also say that I've seen no evidence of Java being super popular at universities, at least here in the U.S. It's used, but other things are taught.  I know that it used to be, but not so much anymore I think.  The truth is that, unless the job advertisement wants specific technology experience, you know Java if you know literally any other programming language with the concept of the class.

C# is a better choice, though.  Almost everyone has the .net frameworks nowadays.  It even runs on Linux and Mac, if you try hard enough.  Also, C# has a much, much more sane FFI than Java.  Java requires 15 line C++ functions for every C function you want to call or use of a 3rd party library called JNA.  It's painful, to say the least.  The only problem I raelly have with C# is that, because of the VS integration, you've got no command line debugger.  Stepping through your code isn't always needed, but it can be a godsend when nothing else will do.