Hi folks.

Ts been a while.

I think I brought this issue up some time a back. Don't know if there've
been anything done in that area.

I think I mentioned that I use the buffers of squeezelite as full-track
RAM buffers.
Something like "-b 10000:400000" would allocate a huge 400MB output
There's usually plenty of RAM, even on machines like RPI, to store a
track into that output buffer.
The OS itself usually allocates less then 50MB.

Basically all streaming and DSP work can be done at the beginning of
playback - call it "bulk-processing". 
During playback there'd be just minor activities ongoing. 
And that's actually how it works. At 44.1/16 with flacs I experience CPU
loads in the range of 0.3-0.7%
after a few seconds high load in the beginning of a track.
Without bulk-processing you usually face loads around 2-4% throughout
the playback. Factor 5
I'd consider plausible.

Now. The issue when starting a playlist is that the end of a track is
not recognized properly.
squeezelite loads more then just a single track if the buffer is larger
then the final track size.

That leads to an odd behavior.

E.g. the pointer for "next track" will refer to the track after the next
track, because the next track is 
already partially processed. 

Do you guys think there'd be a way that squeezelite loads and/or
processes just one track at time, 
no matter how big the output buffer and/or the playlist is?

Or another - a 2nd best option - might be to not shift the "next-track"
pointer, before a track is 
actually being played back.

Can this be handled by squeezelite at all or are we looking at a LMS


:::'  my audioblog  - latest series: RaspBerry PI - \"The Audio Engine\"
' (http://soundcheck-audio.blogspot.com):::
soundcheck's Profile: http://forums.slimdevices.com/member.php?userid=34383
View this thread: http://forums.slimdevices.com/showthread.php?t=97046

unix mailing list

Reply via email to