LMS + SqueezeDSP for Modularised DSP ™ - perfect network clock sync ?

[john61ct]

LMS = Lyrion Music Server, formerly Logitech Media Server, assume here a noisy powerful server out in the garage, also running the HTC, NAS etc.

SqueezeDSP is a convolution plug-in that runs on LMS, and

squeezelite is the protocol stack used for comms between LMS and the renderer ("player") nodes actually putting out music to the many channel amps. Not using LMS' support for UPnP/DLNA, AirPlay etc.

Main SqueezeDSP thread is here

SqueezeDSP plugin for LMS (Lyrion Music Server)

from https://www.audiosciencereview.com/forum/index.php?threads/roon-chaper-alternative-for-qobuz-streaming-applying-eq.69723/post-2556376 Hi I am the developer of the SqueezeDSP plugin for LMS, my goal has been to create a simple to use and install DSP plugin that does what most people want...

www.audiosciencereview.com

but I want to keep this "outside the box" speculative brainstorming thread separate,

keep that cleaner for people with normal brains and use cases 8-D - for more general info on SqueezeDSP, features, dev discussions etc

We can always crosslink posts as appropriate.

Note I am here trying to keep the focus mainly on the systemic "speaker building" side of audio DSP, both "as anechoic as possible" speaker EQ and bass management, including all bandpassing and crossover related functions

even if there may be some overlap with ad-hoc user "preamp type" controls on the one hand, and DRC on the other.

Also, main focus is on always-on implementation, the P in DSP - "convolving" to include PEQ style IIR, as well as FIR, all-pass, whatever types of filters and intra-system timing delays, no worries about processing power nor overall latency.

As opposed to the tools needed for measuring impulses, or filter creation, whether specialised or general, difficult / manual or easy / automatic. Mention of these is appreciated, briefly, extended discussions should get diverted to other threads.

..

OK, so. I've been investigating How To

rather than have one powerful DSP PC running with 12-32 I/O channel DAC / ADC interfacii (very expensive at high SQ)

to use a collection of cheap RPi units distributed in the signal chain, each node handling the convolving / EQ and implementing delays / timing tuning / phase alignment for a smaller subset of channels.

..

The biggest (apparently likely) problem is clock drift between nodes. System and content signal comms would be mostly over wired Ethernet, not more variable wireless protocols.

Apparently Linux has various lower level network based protocols for doing "network clocking", definitely a rabbit hole deserving a separate thread, only those used by LMS / squeezelite should be discussed here, except in passing.

But with LMS over squeezelite, there is a higher-level "sliding smooth sync" mechanism, the server continuously makes micro-adjustments for network jitter that keeps drift of render / player nodes' clocks between 0ms and 8ms.

Run squeezelite with the CLI flag

-d sync=debug

and you can sit and watch the window adjust real-time.

OK, all for now, TBC

yes I'm prolly too excited to sleep now but I'm gonna try...

 

[phofman]

Do you want to use multiple squeezelite renderers to output synchronized multichannel? If so, I do not see how that could be acomplished with the slimproto protocol which uses simple HTTP for pulling blocks of samples from server to the renderer.

 

[john61ct]

I dunno from slimproto, but it is standard for lotsa render nodes to pull the same stream in sync

designed for multi-room like Wiim grouping but that protocol's has too much unpredictability in the timing to work for same-room.

The LMS is constantly exchanging timestamps and making nearly real-time "slewing" micro-corrections, without audible glitches so long as the gap stays under 8ms

Once it goes over 10ms the stream does reset, might be an audible hard skip, but apparently with a good wired same-subnet not too much congestion from other services that rarely happens, at least in the last decade.

Seems worth testing anyway...

 

[john61ct]

Note this is usually simple stereo, but with the SqueezeDSP plugin, apparently allows for mirroring the input streams to the convolver, applying filters, then output / split to the desired multichannels, each sent to the separate (named) MAC address as bandpassed, delayed etc

 

[phofman]

Hm, I do not see any support for multiple renderers within one DSP chain in https://github.com/Foxenfurter/SqueezeDSP . But I may have overlooked it

 

[voodooless]

Better look for something like AES67 or Dante support of your pies to sync multiple channels properly. Also note that this may need some additional support of the switches for the best possible sync.

 

[melomane13]

Not using LMS' support for UPnP/DLNA, AirPlay etc.

Yes, it can, look in plugins

 

[somebodyelse]

Yes, it can, look in plugins

Nobody was saying LMS doesn't support those other protocols, just that those weren't the ones being discussed here.

 

[john61ct]

Yes, it can, look in plugins

I meant, to get such stringent same-system sync you must use SlimProto, the other protocols do not support that

 

[phofman]

I meant, to get such stringent same-system sync you must use SlimProto, the other protocols do not support that

For multiple renderers? IIUC SlimProto uses standard HTTP pull in blocks for passing audio data, I do not see how that could provide synchronization between renderers.

 

[somebodyelse]

I've not dug into the details of what it's doing for sync, but I have heard it do an audible resync when different rooms get too far apart when using dissimilar hardware. In my experience it's good enough to keep rooms you walk between close enough, but not for left/right sync for stereo in one room. There's also the question of the output latency - if that's significantly different between the rooms then you get that as an offset between the rooms. I think squeezelite may allow for that now with the PulseAudio backend IF PulseAudio is correctly reporting the output latency, but that wasn't what I was using at the time (experimenting with .asoundrc EQ?)

 

[phofman]

Analyzing the LMS + squeezeplay source code with copilot - LMS starts all "sync-group" renderers and waits till they report "ready" - they all run alsa loop, playing silence.

Then LMS sends command play_at with individually calculated timestamp for each renderer, based on delay data reported by the renderers. Once each render receives the command, it calculates appropriate amount of silence and and only then it starts consuming the playback samples. So here the synchronization is fairly precise (within ms, IMO).

When playing, every second LMS checks effective time of each player, and when the times differ by more than 10ms (https://github.com/LMS-Community/sl...ec601/Slim/Player/StreamingController.pm#L481 -> https://github.com/LMS-Community/sl...ec601/Slim/Player/StreamingController.pm#L559 , it sends either pauseFor or skipAhead commands). This provides a continuous synchronization of all the renderers - within 10ms. That is fine for multiroom, but definitely way too large for multichannel, let alone for multiband within one speakerbox.

 

[john61ct]

It's a "time-tick mechanism", designed for multi-room synchronization but repurposed here for in a single room system.

Each synchronized group has a shared, continually ticking millisecond counter. LMS periodically sends the clients a timestamped request packet, and each client responds with STAT packets, containing their "jiffies".

Server is constantly tracking renderer players' in real time - playback positions vs round trip RTTs, thus overall latency of each, how far drifting ahead or lagging behind in ms.

If the jiffies from a player is more than 2ms out of sync due to clock drift, the server tells that node to micro-adjust, skip a few audio samples or delay playback slightly to correct the drift.

This process is not audible, and is maintained indefinitely to keep all the nodes aligned within 8ms of the master clock.

If the misalignment reaches 10ms then the resulting stream "reset" to restore sync may be audibly detectable, but apparently is still pretty smooth.

official SlimProto documentation https://lyrion.org/reference/slimproto-protocol

 

[john61ct]

Whoops premature dupe summary.

within 10ms. That is fine for multiroom, but definitely way too large for multichannel, let alone for multiband within one speakerbox.

How about between a collection of LF boxen?

I am likely not pursuing this in production, but would like to test one day anyway if I I get the chance.

Obviously on a fast, uncongested wired same subnet.

Apparently the Wiim equivalent is far inferior, not even predictably stable.

 

[phofman]

If the jiffies from a player is more than 2ms out of sync due to clock drift, the server tells that node to micro-adjust, skip a few audio samples or delay playback slightly to correct the drift.

This process is not audible, and is maintained indefinitely to keep all the nodes aligned within 8ms of the master clock.

If the misalignment reaches 10ms then the resulting stream "reset" to restore sync may be audibly detectable, but apparently is still pretty smooth.

official SlimProto documentation https://lyrion.org/reference/slimproto-protocol

Is that some AI summary? I cannot find those 2ms sync limits on that page. 2ms out of sync + adjustment would not yield 8ms range. Also that reset at 10ms does not make sense as the code reads "resync = send pauseFor/skipAhead if diff > 10ms" which IMO is the micro-adjustment, not a reset. Also even 2ms of dropped samples would produce an audible click, let alone 10ms.

 

[john61ct]

Just from past notes I've taken when googling, certainly may be polluted.

My impression was, between 2-8ms the "slider" adjustments are incremental, just enough to keep the diff shrinking back toward 2ms. Designed to be inaudible, or striving for that.

Does your helper see a different type of correction for under diff <8ms compared to that one?

 

[phofman]

Does your helper see a different type of correction for under diff <8ms compared to that one?

Do you see anything like that in https://github.com/LMS-Community/sl.../Slim/Player/StreamingController.pm#L485-L583 ? I don't.

 

[john61ct]

No, I have no experience with code, even just reading it.

 

[phofman]

AI is very good at analyzing any code it is given.

 

[john61ct]

I try to actively abstain from that as well

except for occasionally silly snippets

https://i.supaimg.com/6d1818d2-9c57-4297-ab20-cb2b0e3334da/8a5c3beb-024b-4914-9dd1-e66599e795de.jpg