Data Nodes

A Data Node is defined from the logical grouping of all arcs (or FIFO queues) in the graph sharing a common source Port (see Figure 4.9). The interesting feature that leads us to this logical grouping is that arcs with a common source may in fact share the same FIFO queue, avoiding many unnecessary data copying and moving at the only price of making flow control issues a bit more complex. But then again, these issues should be automatic and transparent to anyone not wishing to understand the details of this low-level layer.

Figure 4.9: DSPOOM Network and Data Nodes

A DSPOOM Data Node acts as a connection slot where several Processing objects can be connected. Out of all the connected Processing objects, only one can be a producer while the rest will act as consumers. In other words, all connected Ports except one must be Inports. As already commented, connected Ports may have different and varying sizes. The amount of data tokens that an Inport needs to process is its only firing rule and these firing rules may be interpreted as sliding windows or regions.

But a Data Node is more than a simple connection slot. First it must be interpreted as a data container as it is here where the physical FIFO queues are actually implemented. The implementation of these FIFO queues in the Data Node admits different solutions but the most immediate is based on a circular buffer with several reading and only one writing region.

The Data Node is also in charge of keeping track of the different regions connected to it. It is the Data Node responsibility to avoid inconsistent situations and notify the flow control entity of any exceptional state. Reading regions may be of any size and advance at any rate. They may also overlap. Therefore, the only unwanted conditions that the Data Node has to avoid are:

1. A reading region reads non-written data.
2. The writing region advances a reading region and overwrites non-read data

Although the Data Node can be understood as an implementation issue that in most cases should be transparent to the user there may be special cases in which the user would like to access a Data Node contents. Some possible reasons for having to do so are:

• A Processing object has to be directly connected to an external data source and this data has to be directly fed to the Data Node. This is a common situation when developing plug-ins for APIs such as VST.
• The contents of a Data Node need to be visualized. In most cases it will be sufficient to offer special Visualizer sink Processing objects that are connected to the Data Node as just another regular Processing object. But in other cases it may impossible to avoid accessing the Data Node directly.
• The state of a Network may have to be passivated. The contents of the Data Node are an important part of the Network state. They may have to be passivated when passivating the Network.

We can therefore conclude as for what the Data Node issue concerns that although it is an implementation detail located in a lower layer than the rest of the Network facilities, it needs to offer a clear and accessible interface as sometimes it will be interesting not to completely hide it from the user.