Wondering about locking model in ResamplingAudioSource

[dinaiz]

Allright. I must be doing something wrong then. Thanks a lot
I don't actually use the ResamplingAudioSource directly, but I use the AudioTransportSource, which internally uses a ResamplingAudioSource. Maybe that's part of the problem ?

EDIT : When you say "pretty good", do you mean it sound the same as the original, non resampled file, unless you're realmly really splitting hairs, or do you mean the quality loss is acceptable for you ?

[TheVinn]

Well, compile SimpleDJ and listen for it yourself:

https://github.com/vinniefalco/AppletJUCE

One of the vertical sliders controls the resampling rate.

[dinaiz]

OK thanks ! I didn't see that simpleDJ was an app of yours ^^

[gekkie100]

I see this thread started more than a year ago. In the meantime the ResamplingAudioSource::setResamplingRatio changed into this:

Code: Select all

void ResamplingAudioSource::setResamplingRatio (const double samplesInPerOutputSample)
{
    jassert (samplesInPerOutputSample > 0);

    const SpinLock::ScopedLockType sl (ratioLock);
    ratio = jmax (0.0, samplesInPerOutputSample);
}


Could someone explain me (as i like to learn a bit more about the different kinds of locking) why you want to use a SpinLock and not a normal Lock (critical section) in this situation.

[dinaiz]

Could someone explain me (as i like to learn a bit more about the different kinds of locking) why you want to use a SpinLock and not a normal Lock (critical section) in this situation.

IMHO, just for performance reasons . From the doc :

Note that unlike a CriticalSection, this type of lock is not re-entrant, and may be less efficient when used it a highly contended situation, but it's very small and requires almost no initialisation. It's most appropriate for simple situations where you're only going to hold the lock for a very brief time.

The difference between a re-entrant and a non re-entrant lock is that in the former case, the same thread can aquire the lock multiple times, while in the later case, that situation would create a deadlock.

HTH

[gekkie100]

The difference between a re-entrant and a non re-entrant lock is that in the former case, the same thread can aquire the lock multiple times, while in the later case, that situation would create a deadlock.

Ok thanx, so don't use it if there is a chance that the same thread will acquire the lock more than once, but isn't that just the case with ResamplingAudioSource when the ratio is updated in realtime?

[dinaiz]

Ok thanx, so don't use it if there is a chance that the same thread will acquire the lock more than once, but isn't that just the case with ResamplingAudioSource when the ratio is updated in realtime?

Well, in my mind, that is not possible : if a thread starts changing the ratio, this thread will be locked by the SpinLock. During that time, how could it change the ratio again ? (I'm no multithread specialist, and I might be wrong, but in the end, it seems to work, doesn't it ? )

[dinaiz]

Ok thanx, so don't use it if there is a chance that the same thread will acquire the lock more than once, but isn't that just the case with ResamplingAudioSource when the ratio is updated in realtime?

Well, in my mind, that is not possible : if a thread starts changing the ratio, this thread will be locked by the SpinLock. During that time, how could it change the ratio again ? (I'm no multithread specialist, and I might be wrong, but in the end, it seems to work, doesn't it ? )

[TheVinn]

ResamplingAudioSource should make synchronization the responsibility of the caller. Or at least, it should be a template parameter (so we can do away with the locking).

[dinaiz]

ResamplingAudioSource should make synchronization the responsibility of the caller. Or at least, it should be a template parameter (so we can do away with the locking).

Yeah why not pass the critical section as a template parameter, like in Arrays ?