1
Audio / Re: Custom SoundStream
« on: November 20, 2015, 03:04:54 pm »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.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
You might want to start with writing your own OS then.
QuoteCompiler support for them is still a problemReally? What compiler(s) do you use? And what problems do you have?
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?
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 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.
This solves a lot of problems including the initialisation of all of the elements discussed above
Take a look at the example in the official tutorial, it uses class member std::vector, so there's no need for scary sizeof() calls and static buffers.
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.
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, section 6.7.8
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...