Re: PROBLEM: Race between upload and playback in ff-memless

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dmitry

> I wonder if we can't simply leave the FF_EFFECT_PLAYING flag as is
> when updating an effect. Although we still may skip over them in
> ml_get_combo_effect() is play_at is in the future. Should we
> immediately stop updated effects?

Thinking more about it, you need to combine both approaches. If the updated effect should be playing according to the new play_at time (i.e. effect with zero delay), the FF_EFFECT_PLAYING should be left unchanged and the timer will update the force on the next tick as the check will pass (see below for possible issue). If that time is in the future, you need to both clear the flag and stop the force which should fix both the stop behavior and the update behavior inconsistency between single and multiple forces (provided it is desired from backward compatibility perspective).

One additional thing I noticed. mm_ff_upload() with zero delay will set play_at to jiffies and call ml_schedule_timer(). ml_schedule_timer()
will then read a fresh value of jiffies and ignore effects whose play_at is before that value. If the jiffies would be increased between those two reads, no timer would be set for that effect so update would not happen. Is there something which I am missing which would prevent that?

With regards
Jiri



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux