On May 30, 2013 12:39:18 AM Florian Jung wrote: > Hi, > > > what is all this SndFile and SndFileR stuff for? Does > SndFile have a deeper sense, or is that just a plain dumb C++ wrapper > around a C library? > > and SndFileR is for refcounting; has anyone ever evaluated that > refcounting is actually neccessary? Can't we just use as much SndFiles > as we need? > > Of course, using as much as we want might waste resources, but that > shouldn't be that bad nowadays, right? > > I'm asking because my AudioStreams are reading directly from the > SndFile, and on my way of using AudioStreams everywhere (they are much > smarter than SndFiles, they can stretch and sample-rate-convert ), > i'll probably eliminate all uses of SndFileR. Because due to the > stream-i-ness of my AudioStreams, you cannot seek() that much (remember > the FLAC stuttering?), so every single WaveEvent needs its own > AudioStream (aka its own SndFile, which is a private member) anyway. > > Any problems with that? > > Greetings, > flo >
I think it was designed to economize on memory and file resources. If you have many wave parts all using the same wave file name it uses only one SndFile. This could be substantial savings if that one wave file is very long, even if the user may be using only relatively tiny snippets of that file in many small parts. Anyway I guess I'm asking if there is a way for you to preserve the sharing of a sound file until it is necessary to create a unique instance of it, and leave off all processing (clean!) until necessary, that would be great. Well, I know it's a tall order. But maybe unnecessary, read on... I was just thinking, I seem to recall checking but can't remember the results, if we tell libsndfile to open the same file twice (read) should it not give us two independent handles but internally just open the one file? Manipulating handles (locate forward, reverse etc) would be independent but economic, like any good file system? So this might *negate* the need for our SndFileR. The Copy On Write feature could still work here. Hmm. Or were there problems with that concept. Did sndfile allow it. Or was our SndFileR still required because of recording, or did we still require reference counting. I can't recall ATM. Not to mention, opening and manipulating any file: Doesn't any smart system, including libsndfile, buffer a small portion instead of loading the entire thing into memory? Thus, are any fears of resource bloat totally unfounded? I could be way off-course again. It's late. Tim. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
