Spout nodes problem

With reference to the Spout nodes. The sender Help patch works OK, but only if another sender is running when it is started. Otherwise it will only be detected if the sender name can be entered manually into a receiver. It won’t show up in Resolume for example.

I have traced this to creation of the SpoutSenderNames memory map using the function “MemoryMappedFile.CreateOrOpen”. It appears that if the map does not already exist (created by another Spout sender) it is lost and a receiver will not find it. This doesn’t happen if a new map is created with “MemoryMappedFile.CreateNew” and then opened with “MemoryMappedFile.OpenExisting”. Then a receiver finds it OK.

Attached is the “SpoutSender.cs” source file. I am not familiar with C# so it would be good if somebody could look this over and progress to fixing the problem.

Edit :
Somehow this ended up on the beta forum instead of the alpha forum. Anyway here it is.

SpoutSender.zip (2.8 kB)

hei leadedge,

thanks for your investigation and report. i’m hoping to have a look at this within the next days and will come back to you here.

OK thanks a lot,

The modified file should drop in and compile OK. I have had it working.

meanwhile a probably unrelated question:
i can’t find a documentation of the memory structure that needs to be written per sender. in the code i found it is:
uint SharedHandle;
uint Width;
uint Height;
uint Format;
uint Usage;
byte Description;

the first three make sense, but what are valid values for Format and Usage and is Description even correct? if so what length is the byte array supposed to be?

The texture structure goes back to the original sender shared memory devised by Elio Wahlen together with Frederik Tilkin with “Wyphon”. I kept it the same with Wyphon compatibility in mind. The definition is not in the documentation but you will find it in the Spout SDK file “SpoutSenderNames.h”.

struct SharedTextureInfo {
unsigned __int32 shareHandle;
unsigned __int32 width;
unsigned __int32 height;
DWORD format; // Texture pixel format
DWORD usage; // not used
wchar_t description{128}; // Wyhon compatible description (not used)
unsigned __int32 partnerId; // Wyphon id of partner that shared it with us (not used)
};

Usage, description and partnerId are not used but could be used for something else in the future. Format is the format of the shared DirectX texture and can be set to memory so that a receiver knows what it is receiving.

If it is defined, it should be whatever format the sender is using. The defaults are D3DFMT_A8R8G8B8 (21) for DirectX 9 and DXGI_FORMAT_B8G8R8A8_UNORM (87) for DirectX 11. Then the receiver can read and use this information. At at the moment there is nothing specific done other than display the format by SpoutPanel.exe when selecting a sender by a receiver, but it might be used in future for DirectX to DirectX texture processing, or for other DirectX applications which require the texture format.

There are a limited number of formats that can be used for sharing textures, particularly between DirectX 11 and DirectX 9. These include DXGI_FORMAT_R16G16B16A16_FLOAT, DXGI_FORMAT_R16G16B16A16_SNORM and DXGI_FORMAT_R10G10B10A2_UNORM. There has been some interest in floating point textures, so this could become important when that is pursued further.

Meanwhile the format can be set to zero and it will still work OK, the receiver will then assume the default formats and it is not necessary for the receiver to know whether the source is DirectX 9 or DirectX 11. The only thing necessary is the handle (or pointer) to the texture and it will be shared OK for both DirectX 9 and DirectX 11 for the compatible formats.

For field widths, the description is 256 bytes and all others are 4 bytes - 256 + 24 = 280 bytes. The sender name defines the name of the memory map itself.

Let me know if that is not clear or if there is anything else you need to know.

thanks again for the extensive answer that explains everything very well.

regarding your initial report: i was indeed unaware of the “ActiveSenderName” feature about which i learned from looking at the code you provided. to my understanding the problem had nothing to do with the different MemoryMap open/create methods though… so please check latest alpha if everything works as expected now.

while at it again i simplified the code a bit, you can see it here:

I checked the latest alpha and it is working perfectly. I also recompiled and it works fine. I am still not sure why a memory map is not retained after if it is created and not specifically closed. This led me on a wild goose chase. But I can see the changes you have made.

For the “active sender” it is working OK. For texture format, this can be provided easily if it becomes necessary in the future.

I am very happy that you have solved this and I am sure it will be easy for people to use.

Feel free to contact me at any time using the email address on my GitHub - https://github.com/leadedge - if you don’t have it through the forum.

perfect, thanks again for the hints!