My response probably sounded a bit aggressive :).
Usually Im not interacting with potentially sensitive topics, but one
get caught from time to time (last time was when I read about
audiophile solder paste).
Anyway, youre right @triode did an extension of slimproto named loc: so
that when p
philippe_44 wrote:
> We know it does, what are you seeking to achieve?
Not wanting to achieve, just to understand.
And not wanting to poke the borax (your knowlewdge of audio software is
vastly superior to mine and I appreciate what you, Micheal and others do
for the LMS community), you state
We know it does, what are you seeking to achieve?
LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos
PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000,
ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi
B3, B2, Pi B+, 2xPi A+, Odroid-C1
My startup for squeezelite is "/bin/squeezelite -m 28:24:ff:1a:0b:7b -d
all=info -b 2:50 -C 3 -o default:CARD=X20 -n squeeze -f
/tmp/sqlog -z" running on Linux
Using "nmon" I could clearly see the loopback adapter would be busy at
~60MB per second for about a second at the start of a tra
posnos wrote:
> Thanks to all for the replies.
>
> Yes I understand that a track doesnt need to be completely in memory,
> the memory buffer pages will follow a LIFO scheme where stale pages are
> reused.
> It was just interesting that various well known contributors on some
> non-slimdevices f
It was just interesting the various well known contributors on some
non-slimdevices forums suggested such a wide disparity in squeezelite
buffer size.
Maybe the reason for the discrepancy is rather simple: it doesn't really
matter. I've been in touch with one of the "give it all the memory you
bpa wrote:
> Players do not need to have full track in memory before playing as for
> example, this would mean some older players couldn't play 3-4hr
> downloaded podcasts. Also waiting for whole file to be downloaded would
> result in significant delay before playing started if player is in a
Paul Webster wrote:
> LMS is designed to serve audio to devices with very limited memory (Slim
> Devices ...) plus Squeezelite happily plays radio streams (which are
> infinite in length).
> It would probably make Sync harder as well.
> So, although I have not checked the code to see if there is
Players do not need to have full track in memory before playing as for
example, this would mean some older players couldn't play 3-4hr
downloaded podcasts. Also waiting for whole file to be downloaded would
result in significant delay before playing started if player is in a
slow connection.
Wh
If a typical WAV track size is ~60MB (worst case ~150MB for some), then
I dont get how a 1 or 2GB input/output buffer size is beneficial.
While some might see a benefit (no disk activity in between tracks) I
would not encourage you to set that high a buffer.
I've seen odd things happen in sit
LMS is designed to serve audio to devices with very limited memory (Slim
Devices ...) plus Squeezelite happily plays radio streams (which are
infinite in length).
It would probably make Sync harder as well.
So, although I have not checked the code to see if there is a special
mechanism in Squeeze
As far as I know, yes it is.
*Living Room:* HifiBerry DAC+ Pro & piCorePlayer
*Attic:* HifiBerry DAC+ RCA & piCorePlayer
*Kitchen:* SB Radio
*Other rooms:* 4x SB Radio
zordaz's Profile: http://forums.slimdevices.com/membe
which is to say it reads the entire track into memory before playback
(assuming buffer is big enough)?
also, with regard to buffers, I have trawled the interwebs and have seen
recommendations of a few 100MB for the input/output buffers all the way
to 1 and 2gb
If a typical WAV track size is ~60
13 matches
Mail list logo
