Hi,
I've been playing with a Geode LX800 machine and verified squeezelite runs fine on it (post)
Doing this I stumbled upon a hi-resolution album in my library. As I am using SB3s, sox began sucking the life off the machine's CPU… Right now the system is barely capable of transcoding, on a tickelss 2.6.32 kernel with sox, flac and squeezebox server in FIFO RT scheduling mode. Something like 70% of the CPU gets eaten by sox+flac, and SBS takes 5-15% on top of that. There are still some stream interruptions, and I cause one at will by searching in the SBS library via the web interface or iPeng.
I played with an RT_PREEMPT kernel, and the situation did not improve wrt transcoding. Trying to use squeezelite with this kernel I could hear hissing and clipping through my DAC (usb 1.1, synchronous), so from the software player point of view that was a regression.
I was wondering whether going the other direction (a non-preemptible kernel, possibly with a slow 250Hz tick) would be a way ? Usually I go this route on servers but I never considered using a software player on the same machine. Does a software player care much for latency ? Even with an asynchronous DAC behind it ?
The huge toll sox is taking seems to me as the overriding problem regardless of the kernel. I've set it to run single-threaded, with a smaller input buffer (4096 instead of 8192) and this works better. Is there any way of accelerating/streamlining sox to better cope with this small CPU ? (The platform does not have a graphics chip, but it does have some hardware-assisted cyphering capabilities.)
I've been playing with a Geode LX800 machine and verified squeezelite runs fine on it (post)
Doing this I stumbled upon a hi-resolution album in my library. As I am using SB3s, sox began sucking the life off the machine's CPU… Right now the system is barely capable of transcoding, on a tickelss 2.6.32 kernel with sox, flac and squeezebox server in FIFO RT scheduling mode. Something like 70% of the CPU gets eaten by sox+flac, and SBS takes 5-15% on top of that. There are still some stream interruptions, and I cause one at will by searching in the SBS library via the web interface or iPeng.
I played with an RT_PREEMPT kernel, and the situation did not improve wrt transcoding. Trying to use squeezelite with this kernel I could hear hissing and clipping through my DAC (usb 1.1, synchronous), so from the software player point of view that was a regression.
I was wondering whether going the other direction (a non-preemptible kernel, possibly with a slow 250Hz tick) would be a way ? Usually I go this route on servers but I never considered using a software player on the same machine. Does a software player care much for latency ? Even with an asynchronous DAC behind it ?
The huge toll sox is taking seems to me as the overriding problem regardless of the kernel. I've set it to run single-threaded, with a smaller input buffer (4096 instead of 8192) and this works better. Is there any way of accelerating/streamlining sox to better cope with this small CPU ? (The platform does not have a graphics chip, but it does have some hardware-assisted cyphering capabilities.)
