@327, there's a reason for that. Trust me, stereo panning sounds horrible. You can do 3D and stereo panning with stereo sounds, but not downmixing them to stereo completely destroys the auditory illusion. Your not supposed to pan/use 3D/etc. with stereo audio or multi-channel audio in general.

@328, i really don't understand why it destroys the auditory illusion. When sounds are hrtf and mono they sound nice, however when they are mono and not hrtf they sound meh. For me, having a sound without hrtf and in mono is just lowering the sound quality.
@329, i know about the direct source, but that's not what i need. Thanks for the answer anyway.

@331, i understand.

Yeah, it's in the release notes.  I had to yank the ability to read object properties because insert essay about how shared_ptr isn't a trivial layout type and something something something spinlocks that results in reading them possibly causing audio glitching.

Seriously, there are things man was not meant to know, and the subtleties of lockfree and waitfree programming for hard realtime requirements are worse than Lovecraft.

Hi all, does synthizer support ogg formats in the latest version?

No, i am not in to ogg, i was just asking, because i need to know if i need to convert the sounds or not, but thanx for the information

@339
Yeah, but I have reservations about that still frankly, being as there are outstanding fixes for it from months ago.  It is hard for me to be excited about taking a dependency on stb_vorbis but also we forked it when it's apparently easy to break and not getting quick maintenance.  The only reason it's still in the running at the moment is that I know BGT used it (strange as that is to say, but BGT's audio worked well enough for lots of people).

I didn't realize you were still hoping for this to be done in the near future, but I probably won't put it in 1.0.  There's enough instability in the library that I am really not thrilled by the idea of adding more until after Synthizer gets used in a larger project or something like that.  Again, we have MP3.  Maybe dr_mp3 will prove to be unstable or something but it hasn't yet, and I've gotten quick fixes from mackron before.  I may consider sponsoring him to finish dr_vorbis further along, we'll see.

Synthizer's thread safety guarantee is that all calls into synthizer are threadsafe unless otherwise documented, so it's fine, yes.  The Python bindings don't have cases where a python call is more than one C function, so you should be good to have all sorts of fun.

You won't need that thread pool trick yourself long term as Synthizer is going to add it.  But that's a ways off, so you'll want to implement this right.  To do so, you need something called an LRU cache, and to compute the size of the cache as you add to it so that you can keep the decoded assets under an estimated target ram usage.  I would also suggest limiting the thread pool to max(cores/4, 1) which may seem surprising, except that most things for reporting cores will report double the cores the machine actually has due to hyperthreading.  Idk how far you want to go with this yourself, but the Synthizer plan was to allow hinting: you say "I think I'm going to need this asset in the near future", it starts decoding in the background, if you need it before it's done then it blocks on the decoding finishing.

Synthizer will eventually let you tell it approximately how much memory to use.  For your reference it's channels*length_in_samples*2 for the approximate amount used by a buffer.

AN LRU cache is a least recently used cache, which can tell you which item was least recently used.  If you're going to cache buffers, you need an eviction strategy that can release buffers if/when the cache gets too full.  So it's something like track the bytes the cache uses and start dropping the least recently used entries off the back.  LRU caches are a common need and you should be able to just find a library for it.

Don't expect any of this in Synthizer before 1.0.  At the moment, unless it's a bug or very small, it's not happening unless it's in the GitHub milestone already.  But I will put it there as getting all of this right is subtle, and Synthizer internally has some more flexibility than I will ever expose in the public API. Plus performance, of course.

But out of curiosity, how big is your directory?  I am very surprised that you're taking 86 seconds single-threaded and 31 seconds multithreaded.  This doesn't exactly sound like a bug given that it works, but I would have expected that to be much faster so maybe I need to work on it.  Eventually there'll be benchmarks and stuff but that hasn't happened yet.

yeah, that's probably not right.  I'll look into this.  I don't know specifically how MP3 compares to ogg, but it decoded fine on iPod nanos from 10 years ago, so it should probably be faster than that.  My bet is that I need to buffer I/O or something.

@347
Yeah this is an almost-bug.  Wave files should be almost as fast as your disk can read data.  It should be like 10 seconds at most, single-threaded. I will find/make a test corpus and look into this once I bring other projects to rest.  I suspect there's going to be some easy win somewhere that makes this way better.