Triode wrote: > 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 having 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 speculate 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 > prioritisation tweaks will be benefical across a range of hardware and > so I would like to avoid this in the main code base.
Thx for the background info. Makes sense - at least most of it. The main intention was an still is for me to figure out why my setup with squeezelite doesn't seem to run as efficient as squeezeplay. At least that's what the rather large Alsa buffer size and very sensitive behaviour in comparison (on my Touch) indicates. As you can see on the Touch that - as done by the Logitech - you need to allign all involved processes, tasks, threads, IRQs if you start fiddling around with SCHED_FIFO. Or your buffer sizes grow. Logitech put pretty much everything relevant on FIFO-40 and some crucial stuff got a little higher prios. For now squeezelite just puts the output thread on SCHED_FIFO. I'm still not sure if this is sufficiant. That's basically the background of my exercise. One more: Does it make sense to run your kernel on the Touch? Did you just change the usb driver or did you apply more changes? Cheers PS: I neither commented on hearing differences, nor I'd intend to do so. ------------------------------------------------------------------------ soundcheck's Profile: http://forums.slimdevices.com/member.php?userid=34383 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
