Triode wrote:
> Is the SCHED_FIFO working (the kernel supports PREEMPT?) It should use
> 100% cpu, but only as a lower priority to the output thread. The decode
> thread does have priority inheritance though when it locks the output
> mutex.
>
Come back to that.... Look at this....
Code:
--------------------
[18:42:22.761203] decode_thread:74 streambuf bytes: 516095 outputbuf space:
834575
[18:42:22.763176] write_cb:116 setting track_start
[18:42:22.763425] resample_newstream:180 resampling from 44100 -> 176400
[18:42:22.763621] resample_newstream:201 resampling with
soxr_quality_spec_t[precision: 28.0, passband_end: 0.911510, stopband_begin:
1.000000, phase_response: 0.0, flags: 0x00], soxr_io_spec_t[scale: 0.79]
[18:42:22.977249] process_newstream:123 processing: active
[18:42:22.999909] ALSA snd_pcm_hw_delay:515 SNDRV_PCM_IOCTL_DELAY failed (-32)
[18:42:23.000134] output_thread:488 XRUN
[18:42:23.051325] decode_thread:74 streambuf bytes: 524287 outputbuf space:
971279
--------------------
Previous track still playing from the outbuf. New track coming into
streambuf. Start to decode new track. codec locks outbuf mutex, calls
decode_newstream -> process_newstream -> resample_newstream -> create
soxr instance, which takes time, all the while having locked the
outputbuf, thus causing the underrun?
------------------------------------------------------------------------
JackOfAll's Profile: http://forums.slimdevices.com/member.php?userid=3069
View this thread: http://forums.slimdevices.com/showthread.php?t=99395
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
