Triode wrote:
> If this is constantly a problem, then we can perhaps put a small sleep
> in the decode process to avoid it hogging the cpu... The thread should
> be lower priority than the output thread and be preempted but I am not
> sure if this is completely effective.
>
> Edit - does something like this do anything useful:
>
> >
Code:
--------------------
> >
> --- a/decode.c
> +++ b/decode.c
> @@ -113,6 +113,8 @@ static void *decode_thread() {
>
> if (!ran) {
> usleep(100000);
> + } else {
> + usleep(100);
> }
> }
>
--------------------
> >
I tried this code change, but the glitch remained. I also increased the
value of usleep to 1000 in the else clause, but that still didn't
eliminate the click. I am building with make OPTS="-DRESAMPLE", stopping
the squeezelite service and copying the binary over the top of
/usr/bin/squeezelite and then restarting the squeezelite service.
It's certainly a CPU overload issue, since I can also avoid glitches
with the same 40ms ALSA buffer length by resorting to "-u hM:1.5"
instead of "-u vM:1.5". I suspect the linear phase filter also uses
lower CPU due to the ability to exploit symmetry in the impulse response
to reduce computation.
BTW, I have been running all these experiments with "cpupower
frequency-set -g performance" in effect, so nothing more to gain there.
----------------------
"Dreamer, easy in the chair that really fits you..."
------------------------------------------------------------------------
dsdreamer's Profile: http://forums.slimdevices.com/member.php?userid=12588
View this thread: http://forums.slimdevices.com/showthread.php?t=98544
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
