soundcheck wrote: > Triode. > > Now SCHED_FIFO gets applied only, if -p <xx>is given. Otherwise it's > default SCHED_OTHER > > Patch 4 applies it to output.c AND stream.c . stream thread comes with > output rt_prio += 1 ( Note: I didn't check if rt_prio_max=99 gets > exceeded!). I also added the memlock. > > Patch 4 works pretty well with -c pcm. > > TODO: If codecs get into play, perhaps the codec thread needs to be > placed in between stream and output. > Perhaps it's an idea to introduce "-p > <stream-prio>:<codec-prio>:<output-prio>" to keep all the key threads > most flexible and tunable. > > Cheers
Let me add the ability to set the output thread priority, but I don't think we want to change the other thread priorites - definately not to set the stream thread to a higher priority.... The aim of this is to make the output thread run as soon as it can after the alsa wait routine returns. This occurs after an interrupt from the hardware and will enable us to work with smallest alsa buffers. Its valuable to have sched FIFO on all linux kernels as this means the output thread will preempt all normal activity. We also want it to preempt the other threads within squeezelite. There's a 10s buffer between the output thread and the the other threads, hence we can afford for there to be jitter on when these run as long as the output thread runs at highest priority. Complexity comes from the fact that there's shared memory with the other threads. There's 3 muxtexes to stop multiple threads overwriting each other's data and these have priority inherit set so that if a lower priority thread holds a mutex and the output thread is able to run, the lower priority thread gets its priority boosted to ensure it runs so that the output thread can run. I want to audit the mutex calls again to check I've minimised the other threads holding lock which could impact the output thread, but I think it favors the output process as much as possible at present. The stream and decode thread will only run when there is data from the tcp socket to decode - hence the stream thread blocks on network activity. There's not really much value in priorising this thread above other threads as long as it will run often enough to enable decoding to fill the 10 second buffer. Hence I want to keep this thread and the decode thread at normal priority (and they definately need to be lower priority that the output thread as we don't want the output thread to stop so that input data from the tcp socket can be processed or decoded.) So can you hear a difference altering priorities.... (this subject should be moved to the audiophile forums...). As I discussed with EDO - the primary purpose is to minimse/avoid underruns. I believe this is what we get with the stock configuration which will work with default buffers on touch. With the output device driver and then the output thread haveing highest priority you get the likelihood of metronomic waking of these threads to run for a short time and then sleeping until the output device can consume more. This provides the best real time performance but we can speculat it may cause auidible impact of the metronomic process wakeups. By changing priorities, especially making other more random events get priority over these tasks we probably add randomness to when the output process runs. This will make buffering more marginal and more likely to need to increase buffer size to avoid underruns. This may result in audible improvements, but I supect this is very hardware specific and so I don't want to make this part of the base code as we need it to be general to all hardware... (you are clearly free to experiment). I did add a randomiser function in the later versions of EDO as an experiment with the impact of randomising cpu activity in the output thread, but it met with significant disaproval from some so I gave up on that...... Bottom line - I will keep the priories in the base code simple with the output thread being tunable. I think with this and buffer tuning there's a reasonable space for tweeking - I can't be sure that any other priorisation tweeks will be benefical across a range of hardware and so I would like to avoid this in the main code base. ------------------------------------------------------------------------ Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 _______________________________________________ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
