On May 1, 2013 12:22:10 AM Florian Jung wrote:
> Hi Tim,
>
> i saw that MusE passes a bool doSeek with the fetchData function, and to
> WaveEvent::getAudio.
>
> however, this doSeek bool is not used currently. Only the deactivated,
> not finished, code you wrote for sampling rate conversion would use this
> doSeek.
>
> However, I think I have found a flaw there: doSeek is set if and only if
> the song is seeked. However, if you move a wave event or the wave part
> containing it, the Converters/Audio sources/Whatever do need to seek as
> well!
>
> Is that handled and I just didn't see it? Or would this go wrong here?
>
> I think we have a large problem with random-access in MusE: whole MusE
> tries to randomly-access all kinds of audio- or MIDI streams, while this
> actually is not correct. Streams shall be seek()ed seldomly, and usually
> only advanced, like advanceStreamAndGetSamplesFromIt(int nsamp);
>
> Do you agree here?
Yep. That's why I added that flag.
Go ahead and remove it if you want, or make use of it as you see fit.
It is passed around among a few functions, just follow the trail :)
It was only a single flag hacked in there by me, ultimately to be used here:
off_t AudioConverter::readAudio(MusECore::SndFileR& f, unsigned offset, float**
buffer, int channel, int n, bool doSeek, bool overwrite)
{
...
// Is a 'transport' seek requested? (Not to be requested with every read!
// Should only be for 'first read' seeks, or positional 'transport' seeks.)
// Due to the support of sound file references in MusE, seek must ALWAYS be
// done before read, as before, except now we alter the seek position if
// sample rate conversion is being used and remember the seek positions.
if(doSeek)
{
}
else
{
}
...
}
Yes, the flag *was* required for my converters to work properly.
Yes, seeking before *every* read is baaaad and unnecessary,
although as it stands this does not cause much of a problem
with regular wave files so it was *left* *in* (1).
(1) I believe this could be the cause of the problem I outlined recently
with OGG and FLAC files, remember when I posted about two shared
OGG/FLAC wave parts (on different tracks) overlapping in time and that
where they overlap suddenly the sound is messed up and I was puzzled.
I think *this* may be the reason I was trying to recall at the time - the flag
is not used during regular wave operations (including OGG/FLAC).
Because the ill effect was soooo similar to what I observed with my
stretcher/resampler code (hence the reason I added that flag !!!).
>
> I don't immediately see how one could *easily* (as in "easy and
> understandable code", MusE is far too complex anyway; not as in "quick
> hack") solve this problem:
>
> i) all over MusE, add some bool partWasMoved; property which triggers a
> doSeek in the end. But thats ugly,because it's not easy to understand
> ii) just ignore doSeek completely, and let some logic decide whether we
> want to seek or not. I.e., all streams offer functions for random
> access, and keep around the current playing position. Whenever a
> sample far away from the current playing position is requested, do
> a seek, and when the requested sample is "near", just advance the
> stream.
I don't recall any trouble moving the parts around. If I recall the code
correctly, things are set up properly by the time play is pressed.
Now, if parts are moved while playing, hm maybe a problem, I don't
recall if I tested that scenario...
Mm, in that case maybe you should keep that flag around. After all,
I took the time to make sure it is set in the appropriate places, and
since it is unused right now, why not see if you can use it to your
advantage in readAudio() calls - you just might need it, eh?
Except now, expand on it a wee bit and simply try to find a way to 'invalidate'
the progress of the particular wave part's converter (reset it and force
a seek to an exact or near-exact spot) whenever the part is moved
especially during play. Go ahead and use/create msgXXX audio syncing
functions for that if needed. Problem solved, no?
Also, the flag may be *the* solution for the OGG/FLAC problem...
I know MusE audio code looks like a bitch but it's not that hard,
there is a method to the madness, one can follow it but just needs to
be really thorough in checking usages and understanding.
I'd say audio is probably more straight forward than midi in MusE.
Took me quite a while to understand. But now I can do whole engine
re-writes and so on. Sure, I still find my dumb mistakes and "OMG we're
doing what here?" and so on, as evidenced by the yet more fairly major
fixes pending. Always a learning process too :)
Thanks.
Tim.
>
> while i'd prefer fixing stuff instead of working around, I think that
> unfortunately ii) will be the only way to go, if we want to get ready
> this decade :/
>
> What do you think?
>
> Greetings,
> flo
------------------------------------------------------------------------------
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
