Audio glitch in the last second of track. fw: I2S-4MFlash-1331

[robjordan]

I just updated to fw: I2S-4MFlash-1331, 16-bit version. My first update for probably a year, though I've been using squeezelite-esp32 for about 3 years. My hardware is a WROVER board I built myself, with interface to an I2S DAC. Since update I've noticed a problem I've not experienced before. With a playlist in LMS, there is an audible glitch in the final second of a track, at exactly the moment squeezelite connects to LMS to request the next track. Evidently there is decoded data still buffered and playing, but the act of connecting to the server is disturbing the playout of the buffered data.

Telnet output:

[22:42:58.760] output_thread_i2s:498 Output state is 1
[22:42:59.017] write_cb:141 setting track_start
[22:42:59.455] _output_frames:65 start buffer frames: 49152
[22:42:59.457] _output_frames:150 track start sample rate: 96000 replay_gain: 0
[22:42:59.458] output_thread_i2s:498 Output state is 2
[22:43:00.453] grfs_handler:795 scroller current size 1280 (w:210)
[22:43:00.481] grfs_handler:795 scroller current size 1352 (w:210)
[22:47:30.908] stream_thread:337 end of stream (99931241 bytes)
[22:47:33.438] decode_thread:100 decode complete
[22:47:33.489] codec_open:283 codec open: 'f'
[22:47:33.490] stream_sock:508 connecting to 192.168.1.19:9000
[22:47:33.499] stream_sock:582 header: GET /stream.mp3?player=c8:2b:96:87:87:6c HTTP/1.0

[22:47:33.594] stream_thread:264 headers: len: 493
HTTP/1.1 200 OK
Server: Logitech Media Server (8.1.1 - 1610364019)
Connection: close
Content-Type: audio/x-flac
Set-Cookie: Squeezebox-albumView=; path=/
Set-Cookie: Squeezebox-expandPlayerControl=true; path=/
Set-Cookie: Squeezebox-expanded-MY_MUSIC=1; path=/
Set-Cookie: Squeezebox-expanded-FAVORITES=1; path=/
Set-Cookie: Squeezebox-expanded-PLUGINS=1; path=/
Set-Cookie: Squeezebox-expanded-PLUGIN_MY_APPS_MODULE_NAME=1; path=/
Set-Cookie: Squeezebox-expanded-RADIO=0; path=/

[22:47:34.073] write_cb:141 setting track_start
[22:47:38.193] _output_frames:150 track start sample rate: 96000 replay_gain: 0
[22:47:40.836] output_thread_i2s:498 Output state is 0
[22:47:41.448] visu_handler:1232 Stopping visualizer

Judging by eye only, the glitch happens just about at stream_sock:508 connecting to 192.168.1.19:9000.

Is it an issue anyone else has experienced?

[robjordan]

On reflection, maybe this only occurs in 96000 bps content. Let me see if I can reproduce in 44100 content.

[robjordan]

Sure enough, I can't reproduce with 44100 bps content. I guess maybe 96k is just over-stressing the platform. This 'feature' might have always been there; I don't play 96000 material often. So I doubt it's a regression in the new firmware.

[robjordan]

Closing as the issue only arises with 96000 bps content.