Mixxx

Bug #1270583
Comment #1

Comment 1 for bug 1270583

Revision history for this message

Daniel Schürmann (daschuer) wrote on 2014-01-19:

We should look exactly to the effect that happens when a certain task is not scheduled in time.
Here my thoughts without additional investigations:

PA Callback -> Audio Droputs
ControllerManager / HIReader / BlkReader -> delayed control commands (worst case isabsolute position scratch: undesired pitch changes)
CachingReaderWorker -> Nothing, because we read ahead and there is probably still something in cache.
EngineWorkerScheduler > depends on the task (TODO)
Main Thread GUI Thread - > delayed control commands (worst case is Mouse scratch: undesired pitch changes) and waveform stuttering
VinylControlProcessor (does it process the Audiostream? (worst case is absolute position scratch: undesired pitch changes)
LibraryScanner: Nothing
VSyncThread: waveform stuttering (It produces signals for the GUI thread, so no need for a higher priority then the GUI thread.
StatsManager: Nothing?
BrowseThread: Nothing?
AnalyserQueue: Nothing?

From this point of view we do not need TimeCriticalPriority for CachingReaderWorker and EngineWorkerScheduler.
IMHO in general we should only have one TimeCriticalPriority task this has to do all things that has to be done within one Audio buffer size duration but under no circumstances more. If we have more than one CPU, we can parallelize (divide) this single thread for the available CPUs. But we must not have two concurrent tasks at TimeCriticalPriority, see https://bugs.launchpad.net/mixxx/+bug/1203249

It would be also nice to have the GUI task at the same priority than the other input task, but for this it is required to remove all long Slots like db access from it.

Maybe we can also combine all controller polling task to one, to avoid thread changes and random concurrency among them.

CachingReaderWorker: Reading the needed chunk for the next audio Cycle is somehow TimeCriticalPriority, but is a blocking call to HD ....

... Many topics to consider.

Currently Mixxx has ~20 threads! In any case to much for such a low latency audio app :-/ -> a lot of room for improvements.

We should look exactly to the effect that happens when a certain task is not scheduled in time.  
Here my thoughts without additional investigations:

PA Callback -> Audio Droputs 
ControllerManager / HIReader / BlkReader -> delayed control commands (worst case isabsolute position scratch: undesired pitch changes) 
CachingReaderWorker -> Nothing, because we read ahead and there is probably still something in cache. 
EngineWorkerScheduler > depends on the task (TODO) 
Main Thread GUI Thread - > delayed control commands  (worst case is Mouse scratch: undesired pitch changes) and waveform stuttering
VinylControlProcessor (does it process the Audiostream? (worst case is absolute position scratch: undesired pitch changes) 
LibraryScanner: Nothing 
VSyncThread: waveform stuttering (It produces signals for the GUI thread, so no need for a higher priority then the GUI thread.  
StatsManager: Nothing?
BrowseThread: Nothing? 
AnalyserQueue: Nothing?

From this point of view we do not need TimeCriticalPriority for CachingReaderWorker and EngineWorkerScheduler. 
IMHO in general we should only have one  TimeCriticalPriority task this has to do all things that has to be done within one Audio buffer size duration but under no circumstances more. If we have more than one CPU, we can parallelize (divide) this single thread for the available CPUs.   But we must not have two concurrent tasks at TimeCriticalPriority, see https://bugs.launchpad.net/mixxx/+bug/1203249

It would be also nice to have the GUI task at the same priority than the other input task, but for this it is required to remove all  long Slots like db access from it.

Maybe we can also combine all controller polling task to one, to avoid thread changes and random concurrency among them.

CachingReaderWorker: Reading the needed chunk for the next audio Cycle is somehow  TimeCriticalPriority, but is a blocking call to HD ....

... Many topics to consider.

Currently Mixxx has ~20 threads! In any case to much for such a low latency audio app :-/  -> a lot of room for improvements.