Mem address crash discussion (split from DSP code 2)

[Youlean]

The memory address has nothing to do with the stream speed, it is only a pointer to the heap.
Excuse me if I insist, but your code only wastes resources, to process an empty buffer,
even if you emit only poiter memory.
So the point is, why have the value of a pointer to memory, at stream speed?

Edit: the mem create primitive, have some problem with alignment when retriggered.

actually this reminded me one "hack" I've found some time ago. Using Analyser prim it is possible to extract the address of mem-array (addresses of two arrays - one contains addresses of mems and the other contains their sizes as floats) and then read/write to/from mem-array. It was however super-unstable.

Perhaps Malc could add Mem to address prim and Mem-array to address prim that have stream outputs. That way, when address changes it is instantaneously passed to streams which makes reading/writing mems in ASM much more stable. At the moment We have to route the address trough green or ruby, which (I suspect) causes occasional crashes because they run on different threads and may be out-of-sync with streams.

I guess that you should read thread before asking the questions...

[Tronic]

hehe, I've read the whole thing,
and I'm telling you that once you have a memory address,
can easily write and read it from Assembler primitive.

[Youlean]

hehe, I've read the whole thing,
and I'm telling you that once you have a memory address,
can easily write and read it from Assembler primitive.

Well than I don't get it.
I am sure that KG will tell us what he actually want...

[Tronic]

Just to clarify the concept:
the memory created by the DLL is allocated in the heap, so can not be changed by any other thread, or program,
can only be cleared and released from the same DLL,
then safely and stable for the whole life of the DLL thread instance.
As I said, the primitive Mem Create has some problems in aligning the memory when it is recreated,
thus having a memory address that is not correct.

[Exo]

As I said, the primitive Mem Create has some problems in aligning the memory when it is recreated,
thus having a memory address that is not correct.

Can you expand on this?

[Tronic]

As I said, the primitive Mem Create has some problems in aligning the memory when it is recreated,
thus having a memory address that is not correct.

Can you expand on this?

Here on my machine, it reads a memory index wrong,
it seems that always read a 4 bytes before or after the actual start index.
and some time you disable and enable the audio primitive it crash, or show zero value,
but if you retrig the memory it read wrong memory place.

try this simple read memory schematic.

mem_allignment_issue.fsm

(1.13 KiB) Downloaded 775 times

Sorry for this OT.

[Exo]

Thanks Tronic, I am not sure how that schematic proves your case.

There maybe some misunderstanding though. You have the mem input set to 4 "mem[4]" , this is in samples not bytes so the input mem is 16 bytes. Also the mem input is a copy of the external mem and so you cannot get any info about the original address from it.

Maybe you are aware of these but it is not obvious to me how the schematic is proving the issue.

[MyCo]

There is no alignment issue, the memory is always 16Byte aligned, that is required for using aligned SSE memory operations (eg. movaps). As Exo pointed out: the memory size is in Bytes, so you have to allocate at least 4 bytes to use any float operation (prefixed with "f" eg. fld, fst,fstp,...) on it. And when you would want to use SSE instructions on it (might be possible in the future) you would have to allocate at least 16 Byte.

To the problem "allocating memory at stream priority": I don't see that as a problem. Green code run between stream code execution. That means, there is no stream code running when the green is running and vice versa. When you trigger a new memory allocation, the next time the stream is processed, it should get the current address.

However, there is a major problem in the "MemAddress" primitive that makes it at the moment hard to use: It always outputs an address. Even when you have no memory connected it spits out an address. So eg. when you have a stream code using the Memory through MemAddress, your stream code might trigger a memory access violation because it uses random Addresses (or old Addresses). The MemAddress primitive should output 0 when:
- You place a new one
- Disconnect a memory from it
- Load a schematic with it in it (until a memory connected to it triggers it)
- When a connected memory is deleted

I wrote Malc about this issue, but maybe he hasn't seen it because of other requests in the same mail

[KG_is_back]

Also at high trigger-rate / CPU-intensive green processing the green may not get updated in time before next ASIO buffer is processed by streams. That may include the address from the to-address prim, in which case wrong address is used by the stream = crash (or at least a bug in best case scenario).
The prim should have a stream output, which would work more reliably. There might be some some hidden cross-thread voodoo which makes this kind of stuff more complicated.

EDIT:
Also the mem is 32bit aligned, even 64bit aligned (at least on my machine, DUNNO if it's machine specific), but to use SSE operations 128bit alignment is necessary. It can be hacked by making the mem be 16 bytes bigger and rounding the address up to nearest multiple of 4. It would be cool if it was either 128bit aligned by default or optionally.

[tulamide]

EDIT:
Also the mem is 32bit aligned, even 64bit aligned (at least on my machine, DUNNO if it's machine specific), but to use SSE operations 128bit alignment is necessary. It can be hacked by making the mem be 16 bytes bigger and rounding the address up to nearest multiple of 4. It would be cool if it was either 128bit aligned by default or optionally.

That's what I did in the ruby solution, just that 15 additional bytes is already sufficient, and the address needs to be a multiple of 16
But that works only if the memory block you get is not fragmented. Frame creation in Ruby seems to be safe regarding this, I don't know about the primitive.
To summarize, to be able to make use of SSE you need:
- An address that is divisible by 16
- 16 byte alignment. Always blocks of 16 byte of memory need to be adjacent physically.
- A non-fragmented memory block (else the 16 byte alignment could be broken)