View unanswered posts | View active topics It is currently Thu Aug 22, 2019 5:01 am



Reply to topic  [ 136 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Linux/FreeBSD/Mac OS X etc sound 

Best audio API
SDL 20%  20%  [ 10 ]
AO 20%  20%  [ 10 ]
OpenAL 29%  29%  [ 14 ]
Semi Portable OSS 12%  12%  [ 6 ]
Non Portable ALSA 10%  10%  [ 5 ]
Non Portable CoreAudio 2%  2%  [ 1 ]
Other 6%  6%  [ 3 ]
Total votes : 49

Linux/FreeBSD/Mac OS X etc sound 
Author Message
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
PulseAudio is not the future, because that's not how these things work. Read: http://insanecoding.blogspot.com/2007/0 ... linux.html

But regardless of all that, libao does PulseAudio too, http://xiph.org/ao/

_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding


Sun Nov 18, 2007 1:55 am
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
I think the SDL port will be using libao, and the windows port using XAudio and maybe DirectSound if Windows 2000 support is in demand. DOS doesn't exist anymore so that rules it out.

_________________
Watering ur plants.


Sun Dec 30, 2007 9:08 pm
Profile
Rookie

Joined: Thu Mar 01, 2007 6:47 pm
Posts: 20
Reply with quote
Post 
Huh, wasn't there a plan to use audiere for sound output? Or was it dropped?

Oh yes, have you looked into portaudio v19? It does only audio I/O, so it's a lot more lightweight than audiere.


Mon Dec 31, 2007 12:44 am
Profile
Reply with quote
Post 
LiquidAcid wrote:
Oh yes, have you looked into portaudio v19? It does only audio I/O, so it's a lot more lightweight than audiere.


Good lord, I need to hire PortAudio's marketing department. Seriously. Or better yet, 4Front needs to.

Trust me, you do not want to use a sound server to play streaming game audio. You may not be familiar with what latency means now, but I guarantee you would be if ZSNES implemented a PortAudio driver.

The whole point of a sound server is to act as a buffer between the sound card and the audio API, allowing for things like software mixing (something ALSA and OSS already do) and broadcasting sound over a network, among other nifty things. To do that requires its own latency that cannot be less than double what you'd get from going directly to ALSA or OSS.


Mon Dec 31, 2007 2:31 am
Rookie

Joined: Thu Mar 01, 2007 6:47 pm
Posts: 20
Reply with quote
Post 
byuu wrote:
Good lord, I need to hire PortAudio's marketing department. Seriously. Or better yet, 4Front needs to.

???

byuu wrote:
Trust me, you do not want to use a sound server to play streaming game audio.

OK, I didn't know portaudio did implement a full sound server. I had the impression it was more like libao. I'm also no fan of soundservers, but I'm using pulseaudio from time to time because of the network streaming capability (of course latency is irrelevant when playing back music).

byuu wrote:
You may not be familiar with what latency means now, but I guarantee you would be if ZSNES implemented a PortAudio driver.

Hey sry, I was just asking if someone consired using this API. I have only worked with OpenAL and FMOD some time ago, so I'm a kind of newbie in this field.

byuu wrote:
The whole point of a sound server is to act as a buffer between the sound card and the audio API, allowing for things like software mixing (something ALSA and OSS already do) and broadcasting sound over a network, among other nifty things.

I know that.

byuu wrote:
To do that requires its own latency that cannot be less than double what you'd get from going directly to ALSA or OSS.

I wad wondering if JACK is an alternate solution to the current problem of high latency. If I'm informed correctly about the current development the ZSNES devs want to use libao for the unix world.

And still wondering where Audiere was dropped.... :-)


Mon Dec 31, 2007 1:47 pm
Profile
Reply with quote
Post 
> ???

Everywhere Linux I go is talking about PortAudio these days ... despite the fact that it won't actually fix anything, it'll just add yet another API to the growing list.

> OK, I didn't know portaudio did implement a full sound server.

It is considered a drop-in replacement for esd. libao is quite an awful API as well -- it's far too limited. I suppose it's great if all you want to do is play WAV files, though. And yes, latency only matters when input is involved. You can delay video as well to compensate for audio, but if you have input it will be very noticeable.

> Hey sry, I was just asking if someone consired using this API. I have only worked with OpenAL and FMOD some time ago, so I'm a kind of newbie in this field.

Well, this was discussed a mere two posts before yours. Sorry if I'm a bad mood about it. The whole Linux sound thing really annoys me, the more I learn about it. My OS of choice has the video/audio/input equivalent of Windows for Workgroups.

> I wad wondering if JACK is an alternate solution to the current problem of high latency.

No, wrapper APIs that perform their own mixing won't decrease latency, quite the opposite in fact.


Mon Dec 31, 2007 2:29 pm
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
I have written off linux as an OS I will personally support. I am using FreeBSD. Linux can't even recognize the raid on my standard Intel southbridge so fuck it. It corrupted my Vista install 3 times now and I am tired of reinstalling it. FreeBSD worked the first time. There are major issues with GRUB. So any *nix development I do now are on FreeBSD.

_________________
Watering ur plants.


Mon Dec 31, 2007 6:41 pm
Profile
Lurker
User avatar

Joined: Sun Jan 30, 2005 10:06 pm
Posts: 109
Location: Wouldn't you like to know?
Reply with quote
Post 
Personally, I use FreeBSD as my main OS and Windows 2000 as a side OS (being that I use it on my laptop for school and in QEMU on my desktop), so it would be great to see sound work for both of those OSes. FreeBSD is really a great choice since they decided to stick with using an OSS-based backend for their audio drivers.

_________________
SNES Sprite Animations, made by an Insane Killer Robot.
I'm a computer programmer (in C++) and a future game designer.


Mon Dec 31, 2007 7:26 pm
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Jul 27, 2004 10:54 pm
Posts: 3901
Location: Solar powered park bench
Reply with quote
Post 
Here's the current situation besides custom implementations such as libao2 which wraps around everything except libao, whatever junk we throw in emulators, and newer stuff like Phonon.

Image

See: http://blogs.adobe.com/penguin.swf/2007 ... ungle.html
Make sure you read the comments.

_________________
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding


Mon Dec 31, 2007 10:43 pm
Profile WWW
ZSNES Developer
ZSNES Developer

Joined: Tue Dec 28, 2004 6:47 am
Posts: 6747
Reply with quote
Post 
Windows never had it this complicated.

_________________
Continuing FF4 Research...


Mon Dec 31, 2007 11:04 pm
Profile
Rookie

Joined: Thu Mar 01, 2007 6:47 pm
Posts: 20
Reply with quote
Post 
byuu wrote:
Everywhere Linux I go is talking about PortAudio these days ... despite the fact that it won't actually fix anything, it'll just add yet another API to the growing list.

I'm frequently reading in the gentoo forums but I didn't encounter a massive wave of portaudio discussion.

byuu wrote:
It is considered a drop-in replacement for esd.

Uhm, are you sure you're not talking about pulseaudio? I skimmed through the portaudio docs and don't find anything about audio server implementation. Maybe you can direct me to the part where they say so.
IIRC the line "... is a drop-in replacement for esd" is found somewhere on the pulseaudio wiki.

byuu wrote:
libao is quite an awful API as well -- it's far too limited.

Then I don't know why you're complaining about another API like portaudio. I don't think libao can fix these fundamental problems without rewritting the entire API. So libao is going to stay this way, even if it has issues with streaming audio. So you either have the choice to avoid the problems (by some dirty hacks) or using another API.

byuu wrote:
I suppose it's great if all you want to do is play WAV files, though. And yes, latency only matters when input is involved. You can delay video as well to compensate for audio, but if you have input it will be very noticeable.

So the problem is that there is no abstracting API that provides low latency, right?
libao does not, SDL does not, etc.

byuu wrote:
Well, this was discussed a mere two posts before yours. Sorry if I'm a bad mood about it. The whole Linux sound thing really annoys me, the more I learn about it. My OS of choice has the video/audio/input equivalent of Windows for Workgroups.

When I had Windows for Workgroups on my computer I didn't even have a soundcard but only this tiny PC speaker :D

byuu wrote:
No, wrapper APIs that perform their own mixing won't decrease latency, quite the opposite in fact.

According to the JACK FAQ (http://www.jackaudio.org/faq) it adds no additional latency to the stream. So either they are lying or we're wrong about the wrapper APIs (because I also had the impression that wrapping had to add additional latency?!).

I proposed JACK because it has OSS, ALSA and MacOS backends, AND because of the low latency claim (I read about low latency first, not about zero like in the FAQ). This way you have audio on all major unix operating systems.


Wed Jan 02, 2008 1:04 pm
Profile
Lurker

Joined: Wed Jul 28, 2004 1:35 am
Posts: 128
Reply with quote
Post 
Nach wrote:
Here's the current situation besides custom implementations such as libao2 which wraps around everything except libao, whatever junk we throw in emulators, and newer stuff like Phonon.

Image

See: http://blogs.adobe.com/penguin.swf/2007 ... ungle.html
Make sure you read the comments.


It's not exactly accurate, since PulseAudio doesn't use ESD, it is (or rather implements the interface of) ESD.

It also has some kind of network transparency, and I don't think it's NAS, but I could be wrong.

Also, a large number of those are meant to also be cross-platform abstractions (especially Allegro, SDL, and NAS, but also GStreamer) - which means there's not really a decent comparison with with what's available on other platforms.


Wed Jan 02, 2008 4:22 pm
Profile ICQ YIM
Reply with quote
Post 
Quote:
Uhm, are you sure you're not talking about pulseaudio?


Oh, good lord ... there's another one? Does it ever end?? My apologies, then. Yes, I was referring to pulseaudio.

Quote:
Then I don't know why you're complaining about another API like portaudio.


On the contrary, I think they're all equally awful. My ideal API would be one that accessed the hardware directly, and was implemented natively on as many platforms as possible. None of that libao -> aRts -> ALSA -> soundcard stuff. OpenAL is the closest thing we have to this, but you're pretty much limited to Creative if you want the hardware drivers, so it's not really a viable solution, either.

Quote:
According to the JACK FAQ (http://www.jackaudio.org/faq) it adds no additional latency to the stream. So either they are lying or we're wrong about the wrapper APIs (because I also had the impression that wrapping had to add additional latency?!).


If it transmits through ALSA, then it's a flat out lie that it adds no latency. And in fact, it makes their low latency claim pointless, since it can never be less than ALSA's latency already.

However, I believe I read that JACK has the ability to utilize the ALSA drivers directly, which bypasses the userland ALSA programming API. If true, that's actually pretty cool. I could see JACK having a lower latency than the ALSA lib in this case. But you're still limited by the fact that the ALSA drivers themselves are, in most cases, subpar to other drivers such as OSS'.


Wed Jan 02, 2008 6:14 pm
Rookie

Joined: Thu Mar 01, 2007 6:47 pm
Posts: 20
Reply with quote
Post 
DataPath wrote:
It's not exactly accurate, since PulseAudio doesn't use ESD, it is (or rather implements the interface of) ESD.

Yep, that's what byuu already mentioned. And I must say that I'm quite happy with pulseaudio, something I way never when using ESD.

DataPath wrote:
It also has some kind of network transparency, and I don't think it's NAS, but I could be wrong.

It's not fully transparent because you have to specify the server where the audio data gets sent to. You can elimate this problem by setting up multiple virtual ALSA devices which encapsulate the different setups. Works without major problems.
I think there was some discussion about implementation of a NAS plugin, but I don't know anything specific. At least I don't remember seeing such a thing in the latest release.

DataPath wrote:
Also, a large number of those are meant to also be cross-platform abstractions (especially Allegro, SDL, and NAS, but also GStreamer) - which means there's not really a decent comparison with with what's available on other platforms.

We should also keep in mind that SDL and Allegro abstract a lot more than just the audio device. They're very different to libao and portaudio which only implement audio i/o and nothing more.


Thu Jan 03, 2008 12:28 pm
Profile
Rookie

Joined: Thu Mar 01, 2007 6:47 pm
Posts: 20
Reply with quote
Post 
byuu wrote:
Oh, good lord ... there's another one? Does it ever end?? My apologies, then. Yes, I was referring to pulseaudio.

I'd like to hear what you think about the portaudio API. Especially since it's not a soundserver implementation.

byuu wrote:
On the contrary, I think they're all equally awful. My ideal API would be one that accessed the hardware directly, and was implemented natively on as many platforms as possible. None of that libao -> aRts -> ALSA -> soundcard stuff. OpenAL is the closest thing we have to this, but you're pretty much limited to Creative if you want the hardware drivers, so it's not really a viable solution, either.

I'd like to see the master of accurate SNES emulation becoming the master of low-latency audio streaming :D
byuu, writing such an API is the perfect job for you (after finishing bsnes) ;-)

byuu wrote:
If it transmits through ALSA, then it's a flat out lie that it adds no latency. And in fact, it makes their low latency claim pointless, since it can never be less than ALSA's latency already.

That's what confused me at first.

byuu wrote:
However, I believe I read that JACK has the ability to utilize the ALSA drivers directly, which bypasses the userland ALSA programming API. If true, that's actually pretty cool. I could see JACK having a lower latency than the ALSA lib in this case. But you're still limited by the fact that the ALSA drivers themselves are, in most cases, subpar to other drivers such as OSS'.

Any proof for these claims? I must say that I started linux audio with OSS drivers and had a lot of trouble getting these to work back then. Then, after quite a long time Windows-only, I came back to linux and started using ALSA. I'm currently driving a emu10k1 (desktop machine), hda-intel (crappy onboard codec in my laptop I'm writing this post from), usb-audio (external DIY DAC) and various old creative labs cards with ALSA.

The only two problems I had:
1) hda-intel produced lower volume than when using Windows: later it became evident that the increased volume in Windows was the real problem (lot of clipping which ruined the sound). I can do the same amplification trick with ALSA but it's not worth the trouble because it doesn't make the sound better.
2) USB bus disconnect problem with the DAC, that revealed to be a user problem (always be careful when soldering sensitive electronics)

I have read the post on the insane coding blog, but I only see ALSA bashing there and no real proof why OSS is so much better than ALSA. At least I think that it's great to have such a flexible API like ALSA.

I'm not saying that OSS is a bad thing. We will see in the future. It's always good to have two (or more) different projects competing with each other. If OSS is really so nice and easy to work with people are going to use it more, putting more pressure on the ALSA developers and ultimately making drivers on both sides better.

What I don't like at all are projects that open-source their product just because they're hoping to increase money flow (and let the community fix their bugs) and then complain about dropping sales...


Thu Jan 03, 2008 1:03 pm
Profile
Reply with quote
Post 
Quote:
byuu, writing such an API is the perfect job for you (after finishing bsnes)


The solution isn't to create yet another API. Instead, we should be improving what we already have and eliminate the older cruft.

Quote:
I have read the post on the insane coding blog, but I only see ALSA bashing there and no real proof why OSS is so much better than ALSA. At least I think that it's great to have such a flexible API like ALSA.


My only experience has been using them. Sure, in applications that don't require much latency, everything is fine. When using libao in ALSA mode, I received terrible latency, >100ms. With OSS through aoss, it had severe problems with blocking, and crackled constantly. With OpenAL through ALSA, bsnes' framerate counter fluctuated between 58-62fps, with crackling the whole time.

The only thing I haven't added was a native ALSA driver. The ALSA API is way too complex for me, it has literally thousands of functions, and the documentation for it is absolutely terrible.

Now, when I loaded OSS4, the OSS driver had the lowest latency I've ever seen, and was smooth as glass. The OpenAL driver had slightly higher latency, but the API is much more developer friendly since you can pull off more tricks with a buffer+polling approach. Puts you more in control of blocking that way. I will say that libao still has bad latency, but it appears to be much better, something like ~60-80ms, but my measurements are obviously highly subjective. It could just be placebo.

Aside from that, the hissing I got when my volume was maxed was gone. And I was also able to get rid of more interference by muting the other inputs on my card, which I also tried with alsasmixer. I have much clearer audio now. The only things that broke from installing OSS4 were ALSA-only apps. Most just took some configuring to fix.

Now of course, your mileage may vary. Perhaps ALSA will work better for you. I have an HDA sound"card" myself.

Quote:
I'm not saying that OSS is a bad thing. We will see in the future. It's always good to have two (or more) different projects competing with each other. If OSS is really so nice and easy to work with people are going to use it more, putting more pressure on the ALSA developers and ultimately making drivers on both sides better.


Well, let's hope. It seems few people even know about OSS vs ALSA. But yes, I agree that competition is humanity's best motivator. Friendly or otherwise.

Quote:
What I don't like at all are projects that open-source their product just because they're hoping to increase money flow (and let the community fix their bugs) and then complain about dropping sales...


Amen to that. I completely agree with you about this. To be honest, I'm afraid the author will try and close up his OSS4 stuff again in the future to try and make more money. I also hate that his binary installer loads a time-restricted shareware application onto your machine. You have to download the source and build from that to avoid the time limit.

However, the code itself is GPL. Just as OSS3 continued even after the author closed it. I see no reason not to upgrade to OSS4 now that it's out, at least on the BSD platforms.

Ultimately, free / open source or not, I typically use the best tool for the job. Eg I use the nvidia binary, because nv is only a marginal improvement upon the vesa driver. Not much of an OSS idealist, I guess :/


Thu Jan 03, 2008 4:22 pm
Trooper

Joined: Wed Mar 01, 2006 8:47 pm
Posts: 550
Reply with quote
Post 
Slightly offtopic: is there *any* Live BSD distro so I can try BSD and OSS4 without installing it to a hard drive?

OpenAL and the improved (multithreaded) version of Jack are the only candidates for now (both having low latency,great sound quality and versatility)
Jack tramples OpenAL when it comes to low latency.
It's not just the 'direct' access to drivers,there's also optimized threading,forced realtime operation and many other clever tricks involved which make Jack achieve its very low latency.By really low I mean something in the range of 10ms is standard fare for Jack on a very old single-core box. Not bad...at all :)
Even WINE now uses Jack as an option for sound output.

If Jack was a Windows API,it could be best described as something better than WDM Kernel Streaming but worse than native ASIO.

_________________
Have a nice kick in da nutz @~@* c//


Sun Jan 06, 2008 9:57 am
Profile
Lurker
User avatar

Joined: Sun Jan 30, 2005 10:06 pm
Posts: 109
Location: Wouldn't you like to know?
Reply with quote
Post 
To answer your question, kick, you might want to try looking into FreeSBIE, it's a FreeBSD-based LiveCD.

I'm just hoping that whatever comes out of all this for sound, that it's as cross-platform as possible. It's good that current versions of ZSNES already work in FreeBSD as well as Linux, and I would hate to see it go down a path where it works with Linux only. (Excluding Windows, obviously)

_________________
SNES Sprite Animations, made by an Insane Killer Robot.
I'm a computer programmer (in C++) and a future game designer.


Sun Jan 06, 2008 8:35 pm
Profile WWW
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
FreeBSD will always be supported as linux doesn't run properly with my system config. As well as I am getting fed up with GNU people and probably will propose we change our license soon.

_________________
Watering ur plants.


Mon Jan 07, 2008 4:11 pm
Profile
Hazed

Joined: Mon Dec 24, 2007 2:03 am
Posts: 51
Location: Russia
Reply with quote
Post 
You can't have mixer and bit perfect transaction the same time. The sound should be distorted for the common sake, but only once, in system mixer, in single API.

Just look the sound stack for Windows Vista. Every sound bit got mixed through the single API. The same API can provide bit perfect copy of the single stream while blocking other streams. Indeed, very cool! Ether you remix you data yourself or every other application gets blocked. Your application can be banned too if the hardware already busy. I hope all OSes will get the same goodness.

_________________
quake2xp audio engineer


Mon Jan 07, 2008 5:15 pm
Profile WWW
Reply with quote
Post 
Quote:
FreeBSD will always be supported as linux doesn't run properly with my system config. As well as I am getting fed up with GNU people and probably will propose we change our license soon.


Good to hear for FreeBSD support, and good luck changing your license. They'll fork it the second you try, and the 0.65% of your userbase (and coincidentally 75% of those who complain publicly) will switch over to the fork, even though it's just stagnated and gained no features since no experienced SNES devs are working on it. But it's free.


Mon Jan 07, 2008 5:19 pm
ZSNES Developer
ZSNES Developer
User avatar

Joined: Tue Aug 17, 2004 5:24 am
Posts: 812
Location: In your garden
Reply with quote
Post 
Their fork won't have any updated code in it, they can have 1.51. That's fine with me but I would prefer to have the latest bug free code.

_________________
Watering ur plants.


Mon Jan 07, 2008 5:48 pm
Profile
Lurker

Joined: Wed Jul 28, 2004 1:35 am
Posts: 128
Reply with quote
Post 
byuu wrote:
Quote:
FreeBSD will always be supported as linux doesn't run properly with my system config. As well as I am getting fed up with GNU people and probably will propose we change our license soon.


Good to hear for FreeBSD support, and good luck changing your license. They'll fork it the second you try, and the 0.65% of your userbase (and coincidentally 75% of those who complain publicly) will switch over to the fork, even though it's just stagnated and gained no features since no experienced SNES devs are working on it. But it's free.


I know it certainly SEEMS that way, but I think it's generally mostly just a couple of squeaky wheels. I think most users of emulation software have more loyalty to the project than to some ideology or license.

Besides, if you really want to give them a taste of their own medicine, release a last GPLed version, but without the IPLROM.


Mon Jan 07, 2008 6:11 pm
Profile ICQ YIM
Reply with quote
Post 
Quote:
I know it certainly SEEMS that way, but I think it's generally mostly
just a couple of squeaky wheels. I think most users of emulation software have more loyalty to the project than to some ideology or license.


Yeah, I was kind of hinting at that. The ones that get so vocal really only make up a fraction of a percentage, but they make more noise than everyone else combined about their ideals and such.

A real shame. I agree with them in general that code I can see and/or modify is ideal compared to closed source apps -- especially for emulators, but with the way they treat people who don't drink their Kool-Aid does much to harm their cause. I actually avoid the GPLv2 for my own software because of them.

Quote:
Besides, if you really want to give them a taste of their own medicine, release a last GPLed version, but without the IPLROM.


Hahah, I like that idea. Make sure to mention in the code that it's not there because it violates the GPL :)

Another good idea would be to make the external IPLROM as difficult to load into the emulator as it is in MESS, bonus points for also requiring the DSP-N data ROMs to play non-DSP games (hi, Arbee ;)
That'll make 95% of users give up trying within the first half hour :)


Mon Jan 07, 2008 9:05 pm
Trooper

Joined: Wed Mar 01, 2006 8:47 pm
Posts: 550
Reply with quote
Post 
pagefault wrote:
FreeBSD will always be supported as linux doesn't run properly with my system config.


On the contrary,I have a similar experience with the much praised BSD: How come common hardware (such as Audigy2 ZS soundcards or ATI graphics cards) doesn't work or doesn't initialize properly in BSD? It seems to work only for those with onboard sound and Intel/NVIDIA graphics while others are SOL :(
Any OS,no matter how secure it may be is useless (as a desktop OS) without sound and hardware graphics acceleration.
Even the dreadful Ubuntu has more hardware support than all of the BSD distros combined.

I even tried the latest release of DesktopBSD,but no luck.

On the other hand,any live linux distro (Knoppix,Ubuntu,Fedora,Freespire,Puppy Linux,...) I put in my drive initializes the hardware correctly and works out of the box.

Is there any other live BSD distro I can try besides FreeSBIE and DesktopBSD?

_________________
Have a nice kick in da nutz @~@* c//


Last edited by kick on Fri Jan 11, 2008 11:47 pm, edited 1 time in total.



Fri Jan 11, 2008 7:21 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 136 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.