# LabStreamingLayer: synchronised data streams for research experiments > The lab streaming layer is a system for unified collection of measurement time series in research experiments, handling networking, time synchronisation and near real time access, with optional central collection, viewing and disk recording. This repository is the super repository that gathers the library, the applications and the language interfaces as submodules. **sccn/labstreaminglayer** — LabStreamingLayer super repository comprising submodules for LSL and associated apps. - Repository: https://github.com/sccn/labstreaminglayer - Stars: 788 · Forks: 196 - Language: HTML - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/sccn-labstreaminglayer ## What the system does The lab streaming layer is described as a system for the unified collection of measurement time series in research experiments, and the README lists what it handles: the networking, the time synchronisation, near real time access, and optionally the centralised collection, viewing and disk recording of the data. That enumeration is the architecture. A stream carries time series, each stream has a name, a type and a sample rate, and every sample carries a timestamp. The library is what lets a device, a task application and a recording program agree on what time it is, so that a stimulus marker recorded by the task application lines up with the EEG response recorded by the amplifier. Time synchronisation is the part that matters most in practice, and it is the part that is genuinely hard to do outside a system like this. When your data comes from three machines with three clocks, you need a shared clock, and you need the offset between them measured accurately enough for the alignment to mean something. The rest of the list is the practical part. Near real time access means a program can subscribe to a stream and receive samples as they are produced, which is how a task application can trigger stimuli from live sensor data. Centralised collection and disk recording mean one machine can record everything the network produces, which is how LabRecorder works. The repository itself is the super repository, comprising submodules for the library and the associated applications. ## The typical experiment setup The README describes the common way to use the system, and it is worth reading because it tells you what the pieces are. You use one or more applications with integrated LSL functionality to stream data from one or more devices, for example EEG equipment and eye trackers, and from a task application such as NBS Presentation or PsychoPy, over the local network, and you record the data with LabRecorder. That is a typical psychology or neuroscience experiment. An amplifier streams EEG, an eye tracker streams gaze, the presentation software streams stimulus markers, and LabRecorder on one machine writes all of it to disk with the timestamps that let you analyse them together. The network is local, and that is a deliberate design point rather than an accident of the examples. The system is built around a multicast discovery mechanism on the local network, so a device that starts streaming is found by the recorder without anyone configuring addresses. That also means the design does not extend naturally to the open internet, where multicast is not generally available and where latency and jitter would undermine the timing guarantees that make the system worth using. For a researcher, the practical consequence is that the participants, the devices and the recording machine need to be on the same network, and that network should be a quiet one if the timing accuracy matters. ## The library that ships with the application, or does not There is a practical wrinkle in the README that will catch anyone starting out, and it is about how the shared library is distributed. Most LSL applications come bundled with their own copy of the LSL library, which on a Windows application is the dynamic library file. However, the README notes that many applications and interfaces, for example the Python one, do not ship with the shared library on Mac or Linux. In those cases it is necessary to install the library separately and make it available to the application or interface, and the README points at the separate library repository for the details. The reason is a packaging difference. The applications for Windows tend to ship a self contained bundle, while the language interfaces on Mac and Linux rely on a system wide or user installed shared library, in the same way that other native libraries do on those platforms. So the setup step depends on your combination of application and operating system, and the README's advice is to check the list of supported devices and follow the instructions for the device you have, and to download the recorder from its release page. ## LabRecorder and the xdf format LabRecorder is the recording application, and the README describes it as the tool that captures what the devices stream. The important detail is the file format. LabRecorder saves data to the Extensible Data Format, which has its own set of tools for loading the data after finishing the recording. The format and its tools live in their own repository, and the format is not a spreadsheet export. That distinction is the one to hold on to. When you record to a format designed for analysis, the timestamps, the stream names, the sample types and the channel information are preserved, and the analysis tools know how to read them. When you convert to a table format first and analyse that, you are working from a lossy copy of the timing information that made the system worth using in the first place. For a study with many sessions and many conditions, that difference compounds. The recording step is where the synchronisation guarantees are established, and the file written there is the record of what actually happened. The recorder is downloaded from its release page, and the repository lists the applications directory in the super repository, so the recorder is one of the submodules rather than a separate download from elsewhere. ## Language interfaces, and where to ask for help The README lists two routes into the data from a scientific computing environment, Python and Matlab, and there is a third worth noting. Python users install the Python interface package with pip and then try some of the provided examples, which live in the interface's own repository. The Matlab interface is described as popular but requiring a little more work to get started, with a pointer to its own readme. The help section is unusually complete, and it tells you something about the project's structure. If you are having trouble, you can read the documentation, search the GitHub issues in the main repository, in the old archived repository, and in the submodule for your application or language interface of interest. You can create a new issue, and the instruction is to use the repository specific to the item you are having difficulty with, for example opening an issue in the LabRecorder repository if that is the problem, and only using the parent repository if you do not know which one fits. There is a Slack channel for users, and the README also mentions a very new forum on the project's own domain. The advice to browse the code when you are not sure what you are looking at is telling. The super repository is a directory of submodules, so following a link into a submodule is how you find the implementation of the thing you care about. ## Citation, layout and maintenance The README asks users to cite the Lab Streaming Layer paper, published in Imaging Neuroscience, and gives a BibTeX entry. ```bibtex @article{kothe2025lab, title={The Lab Streaming Layer for Synchronized Multimodal Recording}, author={Kothe, Christian and Shirazi, Seyed Yahya and Stenner, Tristan and Medine, David and Boulay, Chadwick and Grivich, Matthew I. and Artoni, Fiorenzo and Mullen, Tim and Delorme, Arnaud and Makeig, Scott}, ``` The reason the README gives is worth quoting in substance, since it explains the request. Citing helps track the use of LSL in emerging research and support continued development of the framework. For a project that has existed for well over a decade, that is a real concern: the people maintaining it are doing so as part of their research work. The repository layout reflects the super repository structure. The library is in the LSL directory, the applications are in the Apps directory, the documentation sources are in the docs directory, and the git modules file records the submodules. The build is driven by CMake at the root, the documentation is built with the readthedocs configuration, and there is a shell script for fixing the macOS setup, which is consistent with the shared library differences described earlier. The clang format, clang tidy and codespell configurations suggest the C++ code is held to a consistent style. On maintenance, the last push was on 2026-10-14 and there are no tagged releases in this repository, which is expected for a super repository whose releases live in the submodules. That is also why the README tells you, when you land in a new repository, to read its readme and look at its releases page. ## Conclusion LabStreamingLayer suits a research group running an experiment where several devices and a task application have to produce aligned time series, since the clock synchronisation across streams is the part that is genuinely hard to do yourself and the library does it across the local network. It is the wrong choice for a single instrument that already exports a tidy table, and the wrong choice if your data leaves the machine in real time over the internet rather than over a local network. Verify first which applications you need and install the library for your platform, since the shared library is bundled with some applications and has to be installed separately for others, and record in the xdf format rather than converting afterwards if you want the timestamps to stay trustworthy. ## FAQ ### What is the Lab Streaming Layer? It is a system for the unified collection of measurement time series in research experiments, handling networking, time synchronisation and near real time access, with optional centralised collection, viewing and disk recording of the data. ### What format does LabRecorder save data in? It saves to the Extensible Data Format, which has its own set of tools for loading the data after the recording is finished, rather than to a flat table format. ### Do I need to install the library separately? Most LSL applications bundle their own copy of the library, but many applications and interfaces such as the Python one do not ship the shared library on Mac or Linux, in which case it has to be installed separately and made available to the application. ### Where should I report a problem with LabRecorder? In the repository specific to the item you are having trouble with, for example the LabRecorder repository, and only in the parent repository if you do not know which one fits. The README also points to the documentation, the GitHub issues, a Slack channel and a project forum. ## Sources - [Issues](https://github.com/sccn/labstreaminglayer/issues) - [README](https://github.com/sccn/labstreaminglayer/blob/master/README.md) - [sccn/labstreaminglayer on GitHub](https://github.com/sccn/labstreaminglayer) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sccn-labstreaminglayer