I wanna use arrayfire in CPU mode (mkl) only to be able to access data without transmission, as it may happen for GPU data.
Is there a way to have direct access to arrayfire's data memory (only CPU blackened will be used)?
You can access the data of an af::array object by calling the device() member function. This will give you direct access to the data unless it is being referenced by another af::array or it is a sub-array/view into another array. In those cases the data will be copied.
Example:
array data = randu(10);
float* data_ptr = data.device<float>();
data_ptr[5] = 1337;
data.unlock();
af_print(data);
#+RESULTS:
data
[10 1 1 1]
0.6010
0.0278
0.9806
0.2126
0.0655
1337.0000
0.2864
0.3410
0.7509
0.4105
Related
I am trying to program a simple Babymonitor for Windows (personal use).
The babymonitor should just detect the dB level of the microphone and triggers at a certain volume.
After some research, I found the Bass.dll library and came across it's function BASS_ChannelGetLevel, which is great but seems to have limitations and doesn't fit my needs (Peak equals to a DWORD value).
In the examples I found a livespec example which is "almost" what I need. The example uses BASS_ChannelGetData, but I don't quite know how to handle the returned array...
I want to keep it as simple as possible: Detect the volume from the microphone as dB or any other value (e.g. value 0-MAXINT).
How can this be done with the Bass.dll library?
The BASS_ChannelGetLevel returns the value that is capped to 0dB (return value is 32768 in this case). If you adjust your source level (lower microphone level in sound card settings) then it will work just fine.
Another way, if you want to get uncapped value is to use the BASS_ChannelGetLevelEx function instead: it returns floating point levels, where 1 is maximum (0dB) value that corresponds to BASS_ChannelGetLevel's 32767, but it can exceed 1 to detect sound levels above 0dB which is what you may need.
I also suggest you to monitor sound level for a while: trigger only if certain level exists for 2-3 seconds at least (this way you will exclude false alarms).
Here is how you obtain the db level given an input stream handle (streamHandle):
var peak = (double)Bass.BASS_ChannelGetLevel(streamHandle);
var decibels = 20 * Math.Log10(peak / Int32.MaxValue);
Alternatively, you can use the following to get the RMS (average) peak. To get the RMS value, you have to pass in a sample length into BASS_ChannelGetLevel. I'm using 20 milliseconds here but you can play with the value to see which works best for your needs.
var decibels = 0m;
var channelCount = 2; //Assuming two channels
var sampleLengthMS = 20f;
var rmsLevels = new float[channelCount];
var rmsObtained = Bass.BASS_ChannelGetLevel(streamHandle, rmsLevels, sampleLengthMS / 1000f, BASSLevel.BASS_LEVEL_RMS);
if (rmsObtained)
decibels = 20*Math.Log10(rmsLevels[0]); //using first channel (index 0) but you can get both if needed.
else
Console.WriteLine(Bass.BASS_ErrorGetCode());
Hope this helps.
I'm trying to find a way to prevent my strings from being collected by the gc. I'm using a small struct and it is populated using the snippet below. Ideally the table itself would move to an ffi struct but I not there yet (and I suspect that then all my structs will be gc-ed). I can go-around using static sizes but considering the amount of records and other similar structures I may move to ffi, this would be a large waste of RAM).
local ffi = require("ffi")
ffi.cdef[[
typedef struct {
uint8_t ctype;
uint16_t freq;
char* name;
char* icao;
} s_frq;
]]
local s_frq = ffi.typeof("s_frq")
[...]
local frq = s_frq()
frq.ctype = tonumber(fields[1])
frq.freq = freq
frq.icao = ffi.new("char[?]", #icao+1, icao)
frq.name = ffi.new("char[?]", #name+1, name)
db_apt[icao].freqs[#db_apt[icao].freqs+1] = frq
I've read somewhere that:
The latter. Pointers are not followed by the GC. Only references from
local variables, upvalues, Lua tables etc. are considered. This also
means you must not store the only reference to an object allocated
with ffi.new() as a pointer in a struct field.
but then I cannot figure out where I should store my pointers. Creating a lua table to store them side by side with my ffi struc would defeat the purpose of not using large lua tables (because the host application - X-Plane - will crash if receiving an alloc request bigger than 32MB).
Programming on a stm32f4 some strange behaviour is observed:
Data is allocated using realloc, which is called every second or so, as such; ptr = realloc(ptr, sizeof)
Values are read into the data - it has been confirmed that: A) The indexing of the array is correct and B) Immediately following each read of values into memory the array holds the correct values.
Upon reading the array the code fails to produce proper output (outputs 0s the vast majority of the time) if free(ptr) is called in any code following the read. When free(ptr) is not called the code functions properly. It seems that the sequential nature of C breaks down in this instance?
Immediately following each read of values into memory the array holds the correct values regardless of any 'free' calls. Realloc is used because this interrupt is called repeatedly. The 'random pointer' has been set to NULL when initialised, before the pointer is realloced. This is an embedded program on a stm32f4.
Being inexperienced with embedded c I can only speculate, but imagine the cause may be faulty optimisation?
Is this behaviour known? I am aware that it is best practice to avoid malloc ect but due to the large variances in amounts of data potentially being held in this application the flexibility is required.
The code mallocs using pointers contained within a global struct. The following code is the offending material:
structContainingMemoryPointer storedData;
numberOfInts = 0;
// ***********Getdata if interrupt conditions state to do so - contained within interrupt***********
interrupt {
if (SpecificInterrupt) {
numberOfInts++;
storedData.Arrayptr =
realloc(storedData.Arrayptr,
sizeof(int) * storedData.numberOfInts * 2);
// Store the value of actualTemp
storedData.Arrayptr[storedData.numberOfInts - 1] = actualTemp;
// Step through the temperature values array and send to USART
for (arrayStep = 0; arrayStep < storedData.numberOfTempAllocations;
arrayStep++) {
// Convert to string and send
sprintf(valueString, ":%d", storedData.temperature[arrayStep]);
USART_puts(USART2, valueString);
}
}
// ***********free memory*************
free(storedDataStruct.Arrayptr);
storedDataStruct.Arrayptr = NULL;
// End of program, no return from this point to previous points.
I have a question regarding vertex buffers. How does one read the vertices from the vertex buffer in D3D11? I want to get a particular vertex's position for calculations, if this approach is wrong, how would one do it? The following code does not (obviously) work.
VERTEX* vert;
D3D11_MAPPED_SUBRESOURCE ms;
devcon->Map(pVBufferSphere, NULL, D3D11_MAP_READ, NULL, &ms);
vert = (VERTEX*) ms.pData;
devcon->Unmap(pVBufferSphere, NULL);
Thanks.
Where your code is wrong:
You asking GPU to give you an address to its memory(Map()),
Storing this adress (operator=()),
Then saying: "Thanks, I don't need it anymore" (Unmap()).
After unmap, you can't really say where your pointer now points. It can point to memory location where already allocated another stuff or at memory of your girlfriend's laptop (just kidding =) ).
You must copy data (all or it's part), not pointer in between Map() Unmap(): use memcopy, for loop, anything. Put it in array, std::vector, BST, everything.
Typical mistakes that newcomers can made here:
Not to check HRESULT return value from ID3D11DeviceContext::Map method. If map fails it can return whatever pointer it likes. Dereferencing such pointer leads to undefined behavior. So, better check any DirectX function return value.
Not to check D3D11 debug output. It can clearly say what's wrong and what to do in plain good English language (clearly better than my English =) ). So, you can fix bug almost instantly.
You can only read from ID3D11Buffer if it was created with D3D11_CPU_ACCESS_READ CPU access flag which means that you must also set D3D11_USAGE_STAGING usage fag.
How do we usualy read from buffer:
We don't use staging buffers for rendering/calculations: it's slow.
Instead we copy from main buffer (non-staging and non-readable by CPU) to staging one (ID3D11DeviceContext::CopyResource() or ID3D11DeviceContext::CopySubresourceRegion()), and then copying data to system memory (memcopy()).
We don't do this too much in release builds, it will harm performance.
There are two main real-life usages of staging buffers: debugging (see if buffer contains wrong data and fix some bug in algorithm) and reading final non-pixel data (for example if you calculating scientific data in Compute shader).
In most cases you can avoid staging buffers at all by well-designing your code. Think as if CPU<->GPU was connected only one way: CPU->GPU.
The following code only get the address of the mapped resource, you didn't read anything before Unmap.
vert = (VERTEX*) ms.pData;
If you want to read data from the mapped resource, first allocate enough memory, then use memcpy to copy the data, I don't know your VERTEX structure, so I suppose vert is void*, you can convert it yourself
vert = new BYTE[ms.DepthPitch];
memcpy(vert, ms.pData, ms.DepthPitch];
Drop's answer was helpful. I figured that the reason why I wasn't able to read the buffer was because I didn't have the CPU_ACCESS_FLAG set to D3D11_CPU_ACCESS_READ before. Here
D3D11_BUFFER_DESC bufferDesc;
ZeroMemory(&bufferDesc, sizeof(bufferDesc));
bufferDesc.ByteWidth = iNumElements * sizeof(T);
bufferDesc.Usage = D3D11_USAGE_DEFAULT;
bufferDesc.CPUAccessFlags = D3D11_CPU_ACCESS_READ | D3D11_CPU_ACCESS_WRITE;
bufferDesc.BindFlags = D3D11_BIND_UNORDERED_ACCESS | D3D11_BIND_SHADER_RESOURCE ;
bufferDesc.MiscFlags = D3D11_RESOURCE_MISC_BUFFER_STRUCTURED;
bufferDesc.StructureByteStride = sizeof(T);
And then to read data I did
const ID3D11Device& device = *DXUTGetD3D11Device();
ID3D11DeviceContext& deviceContext = *DXUTGetD3D11DeviceContext();
D3D11_MAPPED_SUBRESOURCE ms;
HRESULT hr = deviceContext.Map(g_pParticles, 0, D3D11_MAP_READ, 0, &ms);
Particle* p = (Particle*)malloc(sizeof(Particle*) * g_iNumParticles);
ZeroMemory(p, sizeof(Particle*) * g_iNumParticles);
memccpy(p, ms.pData, 0, sizeof(ms.pData));
deviceContext.Unmap(g_pParticles, 0);
delete[] p;
I agree it's a performance decline, I wanted to do this, just to be able to debug the values!
Thanks anyway! =)
The following is what I use to get the available storage space on an iOS device for my app:
NSDictionary *dict = [[NSFileManager defaultManager] fileSystemAttributesAtPath:#"/var"];
NSNumber *freeSpace = [dict valueForKey:#"NSFileSystemFreeSize"];
However, the value freeSpace does not correspond with the one shown in the Settings app. The value is always greater than the value shown by Settings. For example, freeSpace is approximately 600,000,000 bytes, where Settings shows 357 MB.
Why is this and how can I get the same value as the value shown by Settings?
I have the same result on iPhone5 with iOS 6.1.4.
double freeSpaceMB = -1.;
long long freeSpace =
[[[[NSFileManager defaultManager]
attributesOfFileSystemForPath:NSHomeDirectory()
error:nil] objectForKey:NSFileSystemFreeSize] longLongValue];
freeSpaceMB = (freeSpace * 1.)/ (1024 * 1024);
X - Value from Settings (Usage)
I always get freeSpaceMB = X + 200.
I guess it is something reserve space in iOS. But it is just guessing.
Under iOS 11, there are new volume capacity keys that can be passed to URL.resourceValues(forKeys:) that provide values that match what is available in device settings.
static let volumeAvailableCapacityKey: URLResourceKey
Key for the volume’s available capacity in bytes (read-only).
static let volumeAvailableCapacityForImportantUsageKey: URLResourceKey
Key for the volume’s available capacity in bytes for storing important resources (read-only).
static let volumeAvailableCapacityForOpportunisticUsageKey: URLResourceKey
Key for the volume’s available capacity in bytes for storing nonessential resources (read-only).
static let volumeTotalCapacityKey: URLResourceKey
Key for the volume’s total capacity in bytes (read-only).
From Apple's documentation:
Overview
Before you try to store a large amount of data locally, first verify that you have sufficient storage capacity. To get the storage capacity of a volume, you construct a URL (using an instance of URL) that references an object on the volume to be queried, and then query that volume.
Decide Which Query Type to Use
The query type to use depends on what's being stored. If you’re storing data based on a user request or resources the app requires to function properly (for example, a video the user is about to watch or resources that are needed for the next level in a game), query against volumeAvailableCapacityForImportantUsageKey. However, if you’re downloading data in a more predictive manner (for example, downloading a newly available episode of a TV series that the user has been watching recently), query against volumeAvailableCapacityForOpportunisticUsageKey.
Construct a Query
Use this example as a guide to construct your own query:
let fileURL = URL(fileURLWithPath:"/")
do {
let values = try fileURL.resourceValues(forKeys: [.volumeAvailableCapacityForImportantUsageKey])
if let capacity = values.volumeAvailableCapacityForImportantUsage {
print("Available capacity for important usage: \(capacity)")
} else {
print("Capacity is unavailable")
}
} catch {
print("Error retrieving capacity: \(error.localizedDescription)")
}
Another question got posted yesterday that was closed as a duplicate of this one, and that one demonstrates another way you might have gotten this wrong.
What that questioner did was this:
uint64_t freeSpace = (uint64_t)[fileSystemAttributes objectForKey:NSFileSystemFreeSize];
NSLog(#"Free space in bytes: %lld.",freeSpace);
They treated the object itself (more precisely, the object's address in memory) as the number of free bytes. This is wrong; the object is an NSNumber object, which wraps such a number. The correct code would ask the object for its unsignedLongLongValue, which is of the correct type and therefore large enough to hold the correct value.
I bet that you are using 32-bit integer or float types to store your file system size values. This will fail with large enough file sizes. Instead, use unsigned long long or long double types to store these values.
See the corrected version of this answer for how to read these file sizes accurately. The comments on that answer and others there indicate that this returns a value which matches the free size reported by iTunes and other tools.