unless I really need to get more morning coffee to be able to read code, this is initializing the first element of the array to zero - not the entire array. IIRC {0} does not equal memset of the entire array to 0.Code: [Select]static int16_t buffer[ 735 ] = { 0 };
unless I really need to get more morning coffee to be able to read code, this is initializing the first element of the array to zero - not the entire array. IIRC {0} does not equal memset of the entire array to 0.
Someone correct me if I got this wrong...
I looked for a formal specification on variable initialization and the C specification corroborates the above code: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf), section 6.7.8 :)
= { 0 } isn't needed.According to this (http://www.cplusplus.com/doc/tutorial/arrays/), all the remaining elements after the one you gave the zero for, "are set to their default values (which for fundamental types, means they are filled with zeroes)". If you used just "= { }", it does so for all elements. However, if you leave this section off, they "are left uninitialized".
As for "735", you were correct to realise that this isn't acceptable as stereo samples are stored in pairs.
"22050 / 60 = 367.5 frames"
22050 is how many samples per second. What is 60? Your frame rate? 22050/60 would then be samples per frame, not "frames". Obviously half of a sample isn't much use.
60 frames/second.At sample rate of 22050, you would need 368 samples (per channel) for one frame. Since 22050 is not divisible by 60 exactly, this may be not be exact but a 368th of a frame should not be too noticable.
Do you know how much it should be for one video frame? 735 (since a stereo sound frame is 2 samples) causes the crash.
...it uses...std::vector...This solves a lot of problems including the initialisation of all of the elements discussed above ;)
Take a look at the example (http://www.sfml-dev.org/tutorials/2.3/audio-streams.php#a-simple-example) in the official tutorial, it uses class member std::vector, so there's no need for scary sizeof() calls and static buffers.
This solves a lot of problems including the initialisation of all of the elements discussed above ;)
Don't be scared. std::vector (http://www.cplusplus.com/reference/vector/vector/) is very simple to use, generally a lot safer than standard arrays, and probably the standard go-to container for most cases.Take a look at the example (http://www.sfml-dev.org/tutorials/2.3/audio-streams.php#a-simple-example) in the official tutorial, it uses class member std::vector, so there's no need for scary sizeof() calls and static buffers.
I'm more scared of the standard library than of those things ;)
At sample rate of 22050, you would need 368 samples (per channel) for one frame. Since 22050 is not divisible by 60 exactly, this may be not be exact but a 368th of a frame should not be too noticable.
You could alternate between using 368 and 367 samples for a frame, or you could consider using higher sample rate (44100 is divisible by 60).
It might also be worth noting that it's highly unlikely that your frame rate is ever exactly 60 frames per second.
Don't be scared. std::vector (http://www.cplusplus.com/reference/vector/vector/) is very simple to use, generally a lot safer than standard arrays, and probably the standard go-to container for most cases.
It was just the "class member" bit that removes the need for the static buffer, by the way.
I'd love if SFML had more thread primitives, conditions and semaphores are really *not* advanced features, and SFML should really provide them in a cross-platform way.What's wrong with using the C++ standard library for that?
QuoteI'd love if SFML had more thread primitives, conditions and semaphores are really *not* advanced features, and SFML should really provide them in a cross-platform way.What's wrong with using the C++ standard library for that?
Compiler support for them is still a problemReally? What compiler(s) do you use? And what problems do you have?
QuoteCompiler support for them is still a problemReally? What compiler(s) do you use? And what problems do you have?
The thing I dislike about SFML is its use of the standard library. I tried to use SDL2 before going to SFML because of that, but SDL2 don't seem to allow me to render the audio (it imposes a power-of-two audio buffer and libretro cores can send audio frames of any length.)C++ > C
I'm scared of what you can't see, like how it manages memory.You might want to start with writing your own OS then.
Compiler support for them is still a problem, and I don't want to bring in boost as a dependency. But then again, it's hard to find a thread library that goes beyond the *nix/Windows world, so I might just unroll my own code for conditions and semaphores.Gcc has had reasonable C++11 support since ~4.7, clang since ~3.4 and visual studio since v2013 and even Intels compiler and IBMs are not too far behind the game. Good C++11 support has been available on most platforms with multiple compilers for years. There's no excuse for not moving to it (IMHO) - especially since it's such a huge improvement over C++98.
You might want to start with writing your own OS then.
Nah, VirtualAlloc and mmap are your friends, it's possible to write/use nice memory allocators on top of them.I don't think it makes sense to reinvent wheels here, especially because a self-written allocator will almost definitely be less efficient than existing solutions. There are heavily optimized allocators for all kinds of scenarios, I would go with the "use" option rather than "write" :)