JackOfAll wrote: > 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?
Hum - yes that's possible, though not sure how long creating a single soxr instance will be. Try with UNLOCK_O LOCK_O before and after the decode_newstream call in your favorite codec. (how wimpy is this 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
