hi Triode,
as you know i just love squeezelite :) now it does all i ever dreamt it
would do (FLAC's and DSF) and with Erland's plugins for Trackstat and
Dynamic playlists ... it just allows me to enjoy my collection in a
wonderful way.
As you know couple of months ago i bugged you with inserting 'pauses' so
that DAC could syncup to new sampling frequency and your solution works
perfect for me. However I was still always feeling it takes 'longer'
then i expect and it is hard to measure difference by hand between 0.4
and 1sec.
Anyhow to get to the point I realised when i serve my squeezelite pc
based player from another server (via ethernet/powerlan which is 40mbit
bandwidth) i skip from song to song in a heartbeat whereas when same
squeezelite player is served from the server where squeezelite runs it
takes at least a second adn sometimes little longer which is very
noticable lag.
Then i looked at squeezelite logs and realised that SL understands when
its serving local files and instead of going via network kstreaming
approach it just reads file locally off of the hard drive. All cool . I
thought its brilliant idea that should make any delays/lags 100 times
shorter then going via network. Yet my own experience was different. I
thought i mustve screwed something up. Installed new linux box, new
squeezebox server (tried both 7.8.1 and 7.9.0) with same result.
Then I decided to search source code for 'local file recognitions'
portions of the code and try to disable that to see what happens. All
works BEATIFULLY - i can see from the log that it takes about 0.1seconds
max for new song to start playing which feels INSTANTANEOUS :) basically
INSTANT :)! though its still going via slim proto to server etc on the
same machine. Therefore i think there must be bug that adds almost 1sec
when 'local file' is being played.
I can live with this (with these changes) but think it suggests that
going from song to song (by clicking on next song in squeezebox browser
window or on ipod/ipad via ipeng) adds almost a second of pause when
reading local file rather then going via network/slimprotocol to server
who runs on the same machine to serve the same file.
here are the (admit-ably stupid) changes i made to source code to
disable recognition of 'files serv
> >
Code:
--------------------
> > --- squeezelite/slimproto.c 2014-06-07 16:59:15.933346727 +0800
> +++ ../squeezelite/slimproto.c 2014-06-07 16:39:54.806679650 +0800
> @@ -313,7 +313,8 @@ static void process_strm(u8_t *pkt, int
> LOG_WARN("unknown codec requires autostart >= 2");
> break;
> }
> - if (ip == LOCAL_PLAYER_IP && port ==
LOCAL_PLAYER_PORT) {
> + if (ip == LOCAL_PLAYER_IP && port ==
LOCAL_PLAYER_PORT && 0 == 1) {
> +// zh if condition never becomes true due to added 0 ==1 - just minimizing
removing if/else completely
> // extension to slimproto for LocalPlayer - header is filename not http
header, don't expect cont
> stream_file(header, header_len, strm->threshold * 1024);
> autostart -= 2;
> @@ -831,8 +832,8 @@ void slimproto(log_level level, char *se
> getsockname(sock, (struct sockaddr *) &our_addr, &len);
>
> if (our_addr.sin_addr.s_addr == serv_addr.sin_addr.s_addr) {
> - LOG_INFO("local player");
> - strcat(var_cap, ",loc");
> +// zh LOG_INFO("local player");
> +// zh strcat(var_cap, ",loc");
> }
>
> // add on any capablity to be sent to the new server
>
--------------------
> >
Hope you can take a look at ... i didnt attach log files as this is
really easy to hear - now from the moment i click on next and new song
starts playing seems instant and i see from the log what i hear (about
0.1seconds). With local files being served that was always about
1-1.2seconds.
basically - next is clicked at:
17:11:33.929114] decode_flush:190 decode flush
and next song starts playing at:
17:11:34.039310] _output_frames:144 track start sample rate: 44100
replay_gain: 38144
which is about 0.1seconds :) :) :)
btw, my harddrive is in perfect condition and if it was root cause for
serving files directly via filesystem it would be also slow serving it
via more complicated route (LMS server in the same machine talking to
squeezelite via TCPIP)
thanks in advance for looking into it :)
best regards,
Gaha
Code:
--------------------
[17:11:21.607565] write_cb:116 setting track_start
[17:11:21.607604] resample_newstream:220 disable resampling - rates match
[17:11:21.607610] process_newstream:123 processing: inactive
[17:11:21.608920] _output_frames:59 start buffer frames: 57344
[17:11:21.608948] _output_frames:144 track start sample rate: 44100
replay_gain: 38144
[17:11:33.929114] decode_flush:190 decode flush
[17:11:33.929155] output_flush:414 flush output buffer
[17:11:33.936517] codec_open:218 codec open: 'f'
[17:11:33.936561] stream_sock:383 connecting to 127.0.0.1:9000
[17:11:33.936604] stream_sock:412 header: GET
/stream.mp3?player=38:60:77:72:a4:2e HTTP/1.0
[17:11:33.961066] stream_thread:176 headers: len: 118
HTTP/1.1 200 OK
Server: Logitech Media Server (7.9.0 - 1401275007)
Connection: close
Content-Type: audio/x-flac
[17:11:34.029700] write_cb:116 setting track_start
[17:11:34.029738] resample_newstream:220 disable resampling - rates match
[17:11:34.029745] process_newstream:123 processing: inactive
[17:11:34.039262] _output_frames:59 start buffer frames: 409600
[17:11:34.039310] _output_frames:144 track start sample rate: 44100
replay_gain: 38144
--------------------
------------------------------------------------------------------------
gahabana's Profile: http://forums.slimdevices.com/member.php?userid=62064
View this thread: http://forums.slimdevices.com/showthread.php?t=97046
_______________________________________________
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
