I've recently ported my entire application to 64-bit and everything is working fine except for my audio recorder. Even though the correct parameters (such as sample rate) are being reported when I check the resulting file's information in Quicktime, the file either has consistent gaps, is playing at a much higher speed, or is playing at a much lower speed.
I should note that I explicitly type all of my variables, in that I use descriptive types names such as UInt32 and SInt16 for everything instead of using plain 'int' or 'long
Related
I'm calling glTextureStorage2D to generate a framebuffer in my engine. I'm using Google's Angle on windows and using libglfw3-dev & libgles2-mesa-dev on ubuntu running on the same machine.
Creating 8bit RGBA textures is fine on both platforms but higher bit depth formats such as GL_RGBA32F, GL_RGBA16F, GL_RGBA16F, GL_RGB10_A2, GL_RGBA16I & GL_R11F_G11F_B10F silently fail on Ubuntu and on inspection (using RenderDoc), appear to be defaulting back to a standard RGBA texture.
I'm interested in both ascertaining if, on any given platform, a texture format is available and also, why the set of libraries I'm using don't seem to support these formats when the machine is clearly capable of supporting them. I'm aware that 'glGetInternalformativ' exists on more up to date gl implementations but that's unlikely to be available on the lower spec machines that I'd like to test on.
I tried installing 'libgles3-mesa-dev' but that doesn't exist and besides, the headers for gles3 are all there and everything runs, just silently fails to create the texture formats I'm after.
Any hints as to why this seems to be the case would be appreciated.
i am coding for windows 7 and windows 10 and want to have only a single main binary for my application.
In this application i want to join a path and a file name so that all relative path specs are eliminated.
Now i found out that when using PathCombine() function i am portable but the function itself has the chance by design to create buffer overrun issues under certain input conditions.
For PathCchCombine() the security is improved by an extra parameter providing the results buffer size but its not available on the first mentioned platform (the function is only there on Win8 or higher - maybe provided with api-ms-win-core-path-l1-1-0.dll or just by the Windows KernelBase.dll).
How to solve that so that i can keep a single binary, don't need to provide extra DLLs and still stay save against buffer overruns?
Is there some alternate function for Windows 7 that will just serve me?
indicated solution:
i need to use PathCombine() becaue its the only option that works on Win7.
i have to supply a results buffer of MAX_PATH (smaller is risky, bigger is useless).
i have to accept that even if Win10 might support path length of 32kB or more there is no simple solution (like a single API call) that will work with any of the platform determined limits and/or content determined results length. - there are function variants (thinking of PathAllocCanonicalize) that do dynamic allocations and thus the caller does not need any pre-result knowledge, but all of these functions seem to be available only with Win8 or higher.
I am implementing SMBIOS reading functionality for Windows systems. As API levels vary, there are several methods to support:
trouble-free GetSystemFirmwareTable('RSMB') available on Windows Server 2003 and later;
hardcore NtOpenSection(L"\\Device\\PhysicalMemory") for legacy systems prior to and including Windows XP;
essential WMI data in L"Win32_ComputerSystemProduct" path through cumbersome COM automation calls as a fallback.
Methods 1 and 3 are already implemented, but I am stuck with \Device\PhysicalMemory, as NtOpenSection always yields 0xC0000034 (STATUS_OBJECT_NAME_NOT_FOUND) — definitely not one of the possible result codes in the ZwOpenSection documentation. Of course, I am aware that accessing this section is prohibited starting from Windows Server 2003sp1 and perhaps Windows XP-64 as well, so I am trying this on a regular Windows XP-32 system — and the outcome is no different to that of a Windows 7-64, for example. I am also aware that administrator rights may be required even on legacy systems, but people on the internets having faced this issue reported more relevant error codes for such scenario, like 0xC0000022 (STATUS_ACCESS_DENIED) and 0xC0000005 (STATUS_ACCESS_VIOLATION).
My approach is based on the Libsmbios library by Dell, which I assume to be working.
UNICODE_STRING wsMemoryDevice;
OBJECT_ATTRIBUTES oObjAttrs;
HANDLE hMemory;
NTSTATUS ordStatus;
RtlInitUnicodeString(&wsMemoryDevice, L"\\Device\\PhysicalMemory");
InitializeObjectAttributes(&oObjAttrs, &wsMemoryDevice,
OBJ_CASE_INSENSITIVE, NULL, NULL);
ordStatus = NtOpenSection(&hMemory, SECTION_MAP_READ, &oObjAttrs);
if (!NT_SUCCESS(ordStatus)) goto Finish;
I thought it could be possible to debug this, but native API seems to be transparent to debuggers like OllyDbg: the execution immediately returns once SYSENTER instruction receives control. So I have no idea why Windows cannot find this object. I also tried changing the section name, as there are several variants in examples available online, but that always yields 0xC0000033 (STATUS_OBJECT_NAME_INVALID).
Finally, I found the cause of such a strange behavior, — thanks to you, people, confirming that my code snippet (it was an actual excerpt, not a forged example) really works. The problem was that I did not have Windows DDK installed initially (I do have now, but still cannot integrate it with Visual Studio in a way that Windows SDK integrates automatically), so there was a need to write definitions by hand. Particularly, when I realized that InitializeObjectAttributes is actually a preprocessor macro rather than a Win32 function, I defined RtlInitUnicodeString as a macro, too, since its effect is even simpler. However, I was not careful enough to notice that UNICODE_STRING.Length and .MaximumLength are in fact meant for content size and buffer size instead of length, i. e. number of bytes rather than number of characters. Consequently, my macro was setting the fields to a half of their expected value, thus making Windows see only the first half of the L"\\Device\\PhysicalMemory" string, — with obvious outcome.
I am trying to find out which output formats are supported by a specific audio device in exclusive mode.
To do this, I am using IAudioClient->IsFormatSupported(), which according to the documentation should be usable for this.
Unfortunately, it returns AUDCLNT_E_UNSUPPORTED_FORMAT for almost every format I try to pass, except for default 2-channel, 44.1khz audio.
If I actually try to initialize the audioclient, there are however formats that succeed, but which failed in IsFormatSupported().
Just trying to Initialize every format is not an option because this could result in stopping the audio from other applications.
Has anyone else seen this behavior or know if there is another way to find which formats are supported by a specific audio device?
I have seen this behavior as well. It seems like IsFormatSupported will only accept what is marked as 'supported' in the playback device settings in Windows, but Initialize seems to actually end up asking the drivers if it's indeed possible.
In my specific situation, I have a Xoxar HDAV1.3 setup to use HDMI as output. Two playback devices are always available: Speakers and S/PDIF Pass-through Device. If I try, for example, to request 6 channels for the S/PDIF playback device, IsFormatSupported will reject it (in theory, S/PDIF only supports 2, and that's all I can see in the settings), but calling Initialize will succeed and work (it goes out HDMI after all, for which 6 channels is supported). Talk about misleading device names!
I'm afraid there's no real practical way to work around this issue.
Sound Manager functions such as SndPlay() are deprecated and not available in 64-bit. The AudioServices functions are modern but only seem to deal with files and are not documented to handle this format.
I'm not sure that there is a modern API to play them, perhaps because the format is both quite ancient and complicated, starting out in System 7 and being extended several times since.
What I found written about the 'snd ' resource:
System sound files are simply type 1
'snd ' resources stored with a type of
'sfil' and a creator of 'movr'. The
Mac OS provides the familiar icon for
them and permits playback in the
Finder by double-clicking on them. An
'snd ' is a type of resource which
consists of a series of commands for
use by the Sound Manager. In addition
to digitized sound samples, 'snd '
resources can contain direct
frequency-modulated and wave
table-based sounds. Any number of the
three types can be combined with
various effects to produce complex
sound files. Simple Beep is an example
of a non-digitized 'snd '. There are
two types of 'snd ' resources,
amazingly called type 1 and type 2.
Type 1 is the format described above
and is referred to as the System sound
format. Type 2 is for use with
HyperCard and can contain only a
sampled (digitized) sound. SoundApp
can play both types but will only
convert sampled sounds. For more
information on 'snd ' files consult
Inside Macintosh VI or Inside
Macintosh: Sound. A familiarity with
the Resource Manager would also be
helpful. 8-bit samples are stored as
unsigned bytes, like SoundCap/Edit,
but 16-bit samples are signed, like
AIFF. Stereo 'snd ' resources are also
possible, but Sound Manager 3.0 or
later is required to play 16-bit
samples directly. The possible types
of compression for 'snd ' resources
are the same MACE, IMA and µ-law types
used in AIFF-C files.
Source: http://www-cs-students.stanford.edu/~franke/SoundApp/formats.html#system7
I would think that your best option is to re-record any such sounds into an intermediate lossless format for archival purposes, and then convert them into the best format for the requirements of your app.
Core Audio is definitely what you want. However, I believe you're mistaken on the Core Audio documentation. The table you linked to includes an entry for "NeXT/Sun Audio (.snd, .au)".
You mention that Core Audio "only seems to deal with files", but this isn't true. You can setup a graph with the source being of type kAudioUnitType_Generator and subtype kAudioUnitSubType_ScheduledSoundPlayer.
I wrote a morse code program that mixes multiple audio sources that are generated in memory. It might be a useful example. MTPlayer.m would be a reasonable place to start looking at the code.
Quattro Pro provided a macro command {Play name.snd} where name was a one of three digital files that came with the program. It was a spreadsheet that ran on 640kb + of RAM. The SND files are approx 5kb in size and last a second or so. Borland (who made Quattro Pro) didn't provide sound editing backup but as this was circa 1992, I guess the files would have been fairly easy to obtain. I still have a working copy of that spreadsheet but no means (yet) to backgrade existing sound files for trialling.