JackOfAll wrote:
> Do you still want me to do that? I already verified that by unlocking
> the outbuf mutex as you first suggested.... problem (XRUN) goes away.
> >
Code:
--------------------
> >
> --- squeezelite-1.6.1/flac.c~ 2014-04-22 21:07:18.000000000 +0100
> +++ squeezelite-1.6.1/flac.c 2014-04-23 20:42:52.722459315 +0100
> @@ -124,12 +124,16 @@
> output.next_sample_rate = frame->header.sample_rate;
> output.fade = FADE_INACTIVE;
> } else {
> + UNLOCK_O;
> output.next_sample_rate = decode_newstream(frame->header.sample_rate,
output.supported_rates);
> + LOCK_O;
> output.next_dop = false;
> if (output.fade_mode) _checkfade(true);
> }
> #else
> + UNLOCK_O;
> output.next_sample_rate = decode_newstream(frame->header.sample_rate,
output.supported_rates);
> + LOCK_O;
> if (output.fade_mode) _checkfade(true);
> #endif
>
>
--------------------
> >
No need then...
Let me look at that in more detail, we should probably make local copies
of the output struct params and the call decode_newstream without the
lock.
I never really looked at the performance of the resample versions on a
low performance cpu - I'll try on a pi and see if I see the same thing.
------------------------------------------------------------------------
Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=99395
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
