2016-01-23 0:45 GMT+01:00 Tim E. Real <[email protected]>:
>
> > Tim, can you post your jack session settings here and a wave file that
> > causes error?
>
> It happens with any sound file (ogg, wav, flac) with a different
> samplerate.
> I simply tired to open various files in /usr/share/sounds,
> most of them are at different samplerates than my Jack setup of 44100Hz.
>
> Although I have not looked at the code, when I heard about the
> automatic resample-on-import feature I was skeptical:
> As far as I recall we do not store whole waves in memory. (Nor should we.)
> So I was wondering how the resampling feature was even possible?
> Where is the new wave being stored?
> In memory, or a new file?
> If it's a file, well OK. Although there may be issues with that as well,
> as I mentioned some time ago. (Where to store them, folders etc.)
>
When we add wave files (either import or recording) we force a creation of
a project so we always have a location to store "our" wave files, which
means that it is quite ok to resample and store the file to disk. This is
also what happens as far as I understand the code.
> -----
> A quick note also:
> There is code in MusE that I think would be essentially ready to go,
> with reexamination and so on, that does automatic resampling
> on-the-fly using SRC.
> The code was last tested years ago and working fine!
> The thing is, I had to disable it at the time because of a MusE flaw:
> We were using shared event lists.
>
> This made my efforts come to a screeching halt, because we cannot
> use shared soundfile handles!
>
> But then Florian added non-shared event lists. I helped finish that work.
>
> It means the door is now open for me to try that resampling code again.
> Yes, it /can/ work now!
>
> An immediate benefit of the non-shared event lists was this:
> Wave events that point to the same /compressed/ sound file
> can now be played even if they overlap.
> This was not possible before and had nasty results like severe
> denormal chugging which ground MusE to a halt.
> The problem was that our wave events wanted to keep switching
> the single shared soundfile position back and forth among the
> various events, which is a no-no, compressed files need to
> 'progress' naturally without being told to jump around like that,
> and the same with pitch/time shifters.
>
> So you see, non-shared event lists cured all that.
> It was a huge undertaking.
>
> But Florian took resampling /much/ farther in his branch
> (that I mentioned recently) - he added beat matching,
> pitch shifting, time stretching etc.
>
Oh I hadn't understood that, cool. Time has probably made it hard but it
would be awesome if this could be resurrected.
>
> So although I can try to resurrect my resampling code, I must also
> keep in mind the possibility of merging some of Florian's work,
> and how it might fit in. IIRC It is radically different in that it uses
> something he called 'extended ticks'.
>
> My primary goal with my code was for resampling of imported audio files.
> But the work was a good learning and starting point for pitch shifting,
> time stretching and so on, and I tried to keep the architecture open
> for that eventuality.
>
Regards,
Robert
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
