Messages

31

Audio / SoundStream Latency

« on: January 14, 2011, 12:34:51 am »

Thanks for the tip. However, I think I'd be more comfortable using something like pthreads. With that said, how would you solve the producer consumer problem using only mutexes, but without having either thread constantly looping?

pthreads is posix-only. boost is cross platform. sure you want to stick with "something like pthreads"?

32

Audio / SoundStream Latency

« on: January 14, 2011, 12:12:58 am »

l0calh05t, that is exactly right. There is no way around this problem, you can only hope to minimize it by using small buffers.

That being said, I would like to pose a different question. It might be better suited for another thread, but it is for this project so I'll ask it here as well.

I have essentially a producer consumer problem (I produce samples with my synth that are consumed as I stream them to audio output in a different thread). I know this can be solved simply using semaphores. However, SFML only has support for mutexes (if I'm not mistaken).

Can I still solve this problem using only what SFML provides, or should I just go out and get a simple threading library and use its implementation of semaphores?

producer-consumer problems can be solved with mutexes alone, but I would rather recommend having a look at boost::thread and using that (it includes far more powerful concepts such as condition variables)

33

Audio / SoundStream Latency

« on: January 13, 2011, 11:13:35 pm »

Ok, I'll try a different example:

Let's say you have a game where the music changes, depending on some event E (using two buffers, 1 and 2)
At first, the event has not occured, so you are playing music A, and fill buffer 1 with it and enqueue it. While buffer 1 is playing, you have to fill buffer 2, as otherwise this would lead to stuttering when buffer 1 ends before buffer 2 was enqueued.
Now E occurs. But what can you do? Nothing, as buffer 1 and 2 are enqued. So you wait until buffer 1 becomes free, incurring latency (corresponding to buffer 1's length).
When buffer 1 is free, you fill it with music B and enqueue, but music A is still playing while buffer 2 is being emptied, incurring yet more latency (corresponding to buffer 2's length).

Could you have dequed buffer 2 and filled it with music B, while buffer 1 was still playing? No, because it is not really known when buffer 1 will end, and even the smallest delay would result in stuttering.

34

Audio / SoundStream Latency

« on: January 13, 2011, 10:47:32 pm »

Why? I undestand that OpenAL has more latency than PortAudio/ASIO because it doesn't write directly to the sound card, but why do you directly translate these 2048 samples to latency? 128ms is the duration of these 3x2048 samples, I don't see how you end up with latency.

To start playing, a buffer first needs to be filled, that's the whole reason, and also why latency can never be lower than the sound cards minimum buffer size. So a 2048 sample buffer directly results 42ms latency. Using multiple buffers is basically the same as one big buffer in regards to latency, as before the third buffer starts playing, the first needs to be filled (42.6ms), the first needs to play while the second is filled (42.6ms) and then the second needs to play, before the third starts (42.6ms) for a total of 128ms.

It's just the same thing with graphics: When using triple buffering, you will have 1 extra frame (compared to double buffering) of latency (~17ms)

35

Audio / SoundStream Latency

« on: January 13, 2011, 10:36:28 pm »

Although this is true, OpenAL, unlike PortAudio is NOT designed for low latency. PortAudio allows you to use ASIO drivers, which allow for far lower latencies (down to 32 samples with my RME soundcard, for example)

Ok I see. But you're talking about latency in general, right? We're not in the specific context of streaming with small buffers?

Buffer size in fact determines (minimum) latency. Say you are using 3 2048 sample buffers in OpenAL, then this alone creates 128 ms of latency (at 48kHz sampling rate). That is in addition to any internal buffers used by the sound drivers. PortAudio (when using ASIO) writes pretty much directly to the sound card's output buffer, and those 32 samples result 2/3 of a millisecond of latency (again at 48k).

For synths, and other real-time audio programs this is pretty much a necessity, for games, not so much, although it really depends on the game type, a music-based game might very well benefit from <10ms latency.

36

Feature requests / File system functions

« on: January 13, 2011, 07:53:58 pm »

Do not "roll your own". The only reason to ever do so, is if you want to learn how to do it.

Boost is:

• Very well tested, by thousands of people using it in production code
• Licensed with a very permissible license

So there really is no reason not to use it. The most frequent "reason" people don't use it, is because they don't understand how all the "template magic" and "preprocessor tricks" work. Almost as bad as people who don't use the C++ standard libraries, for those "reasons"...

There are alternatives though, as in other libraries which you can use. For example there is POCO (http://pocoproject.org/) which, to many, looks a little "friendlier" than boost. The licensing is similar (actually... it's exactly the same ).

Specifically for filesystems for games, there is also PhysicsFS (http://icculus.org/physfs), which provides a full virtual filesystem. Sadly, it uses a C API, and the internals often use integers (with a *specified* size of 32 bits) for storing pointers, and pointer differences, which makes the whole thing 64-bit incompatible. Guys... do use size_t and ptrdiff_t, please they are there for a reason!

37

Audio / SoundStream Latency

« on: January 13, 2011, 09:53:13 am »

OpenAL is very low-level, in fact the entire streaming algorithm is written in SFML. So I think we can always improve it to make it close to perfect.

Although this is true, OpenAL, unlike PortAudio is NOT designed for low latency. PortAudio allows you to use ASIO drivers, which allow for far lower latencies (down to 32 samples with my RME soundcard, for example)

38

General / Remove OpenGL deprecated features?

« on: August 18, 2010, 10:41:55 pm »

use gl3w http://github.com/skaslev/gl3w

39

Feature requests / Manually setting Z-order

« on: July 21, 2010, 07:53:02 am »

Oh! come on, I manually sort z order (sf::Sprite of course) by std::list.sort().

It really hurts performance!

 :?

Are there any way to improve it?

use a floating point radix sort?

40

Feature requests / First impressions

« on: July 20, 2010, 08:18:02 am »

Mm, why not doubles?

Why doubles?

Every timer, on every system returns an integer in the first place, there is no reason to convert it to a floating point type. btw, even when using a 32 bit integer which will still have precision worth only a couple of days, if you handle the wraparound, you also never lose precision. with 64 bit ints you might as well count in nanoseconds, as it will still last for centuries (doubles: 104 days at nanosecond precision)

41

Feature requests / Add OpenGL context flag and profile version setting

« on: July 15, 2010, 08:56:41 am »

if you were to make a flexible rendering abstraction (as Ogre or Irrlicht use), I am sure someone would take over writing a GL3 or a GLES backend.

42

Feature requests / Add OpenGL context flag and profile version setting

« on: July 14, 2010, 04:21:17 pm »

I'd prefer if you still offered these as an option, but include a warning in the documentation that it may cause problems if SFML-Graphics is used with incorrect flags.

43

Feature requests / First impressions

« on: July 08, 2010, 02:32:38 pm »

So, you say that ~4 hours is the limit for safely storing milliseconds in a float? In other words, numbers higher than ~14400000 may not be accurately stored in a 32-bits float?

If the limit is that low, I agree that this is a problem.

Well, it's actually 4.66 hours and numbers higher than 16777216, but yes, that's the problem.

44

Feature requests / First impressions

« on: July 08, 2010, 01:53:05 pm »

Growing inaccuracy over time.

Theoretically it is true, but I wonder if it is really noticeable.

With a floating point accumulator this can quickly turn into a problem, especially for a game server, since beyond ~4 hours millisecond precision becomes impossible and any time delta information below that precision will be lost as well, causing drift. This does not happen with integer accumulators, but if using an integer accumulator, recieving the deltas in integer format is definitely "easier". Personally I'd avoid floats for time as well, even if it usually isn't  a problem.

45

Feature requests / Mouse capture/grab

« on: July 08, 2010, 12:09:04 am »

There is a clean solution on Windows:

http://msdn.microsoft.com/en-us/library/ms648383%28VS.85%29.aspx