Apparently SDK 3.1.2 has a built in discrimination about certain audio.caf files being passed to AVAudioplayer.
Some files that worked fine with SDK 3.0.1 get a returned content null from AVAudioplayer using exact same code on simulator or iphone with SDK 3.1.2.
All files are 16-bit Integer, Big Endian, Mono, 22.050 KHz, Data rate 352.8 Kbits/s.
All files have same rwx permissions and ownerships and have similiar size and duration ~7 secs.
How do I get visibility to what is different about files that work and ones that don't and convert or fix the ones that don't work?
I tried running "afconvert -f caff -d LEI16#22050 input.caf output.caf" to try and get SDK 3.1.2 to accept file with no luck.
Found out that 3.1.2 requires 11025hz in caf lpcm to work correctly.
afconvert -d "BEI16#11025" test2.caf test2_cool.caf solved my issues.
Related
Moved from here, because it's about compiling software.
My original problem: I want to play Super Mario Galaxy 2 with another player. But whatever keys I assign to move the cursor, it instead moves it all the way to the corner (or edge) of the screen. Linux theoretically has the ability to have multiple cursors (at least the display system "X" allows it), but from a research it looks like I would have to make major changes to the system to actually use it. And even then I doubt that Dolphin would support it.
My current problem: Relative motion of a cursor from keys is present in the current betas of Dolphin, but I can't get it installed. There are no regular installers for it, instead there are source downloads and this tutorial.
I installed the dependencies, downloaded the beta, created and entered the "Build" directory, but when I try cmake .., I get this output:
-- Detected architecture: x86_64
-- X11 support enabled
-- Xrandr found
-- Found avcodec: /usr/include/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libavcodec.so
-- Found avformat: /usr/include/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libavformat.so
-- Found avutil: /usr/include/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libavutil.so
-- Found swresample: /usr/include/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libswresample.so
-- Found swscale: /usr/include/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libswscale.so
-- libav/ffmpeg found, enabling AVI frame dumps
-- libevdev/libudev found, enabling evdev controller backend
-- Using named pipes as controller inputs
-- Watching game memory for changes
-- Enabling analytics collection (subject to end-user opt-in)
-- Using static enet from Externals
-- Using static xxhash from Externals
-- Using shared zlib
-- Using static lzo from Externals
-- Using shared libpng
-- Using shared LibUSB
-- Found SFML 2.4 in /usr/include
-- Using shared SFML
-- Using shared miniupnpc
-- Could NOT find MBEDTLS (missing: MBEDTLS_VERSION_OK)
-- Using static mbed TLS from Externals
-- Using shared libcurl
-- Using static DiscordRPC from Externals
-- libsystemd found, enabling traversal server watchdog support
-- Using static gtest from Externals
-- Could NOT find OpenSLES (missing: OPENSLES_LIBRARY OPENSLES_INCLUDE_DIR)
-- ALSA found, enabling ALSA sound backend
-- PulseAudio found, enabling PulseAudio sound backend
-- BlueZ found, enabling bluetooth support
CMake Error at Source/Core/DolphinQt/CMakeLists.txt:1 (find_package):
Could not find a configuration file for package "Qt5" that is compatible
with requested version "5.9".
The following configuration files were considered but not accepted:
/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake, version: 5.7.1
-- Configuring incomplete, errors occurred!
See also "/home/fabian/dolphin_beta/dolphin-emu/Build/CMakeFiles/CMakeOutput.log".
See also "/home/fabian/dolphin_beta/dolphin-emu/Build/CMakeFiles/CMakeError.log".
The output of apt-file search Qt5Config.cmake is:
libaccounts-qt5-dev: /usr/lib/x86_64-linux-gnu/cmake/AccountsQt5/AccountsQt5Config.cmake
libphonon4qt5-dev: /usr/lib/x86_64-linux-gnu/cmake/phonon4qt5/Phonon4Qt5Config.cmake
libsignon-qt5-dev: /usr/lib/x86_64-linux-gnu/cmake/SignOnQt5/SignOnQt5Config.cmake
libtelepathy-qt5-dev: /usr/lib/x86_64-linux-gnu/cmake/TelepathyQt5/TelepathyQt5Config.cmake
qtbase5-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake
To be safe I installed all five of these packages. I also installed version 5.10 of Qt5-default from here, later also 5.11. I also installed qtbase5-private-dev, libreadline-dev and tried to install libpolarssl-dev, but the page gave error messages for all four servers (the Taiwanian one just loads forever, the others give 404). Then I tried the Qt installer and selected the latest stable version (5.11 I think) once and 5.9 once.
None of these steps helped, I still get the same output as at the beginning.
Here is a copy of CMakeOutput.log from when I last tried installing: https://pastebin.com/EP5qDGE9
Here is a copy of CMakeError.log from when I last tried installing: https://pastebin.com/9p4Ni0jE
My specs:
Debian 9.5
Cinnamon 3.2.7
Linux Kernel 4.9.0-8-amd64
Installed packages: https://pastebin.com/DeYAvJtu
Many thanks to the user dugan on linuxquestions.org! He solved my problem here.
I just had to install Qt from a different source (I used the Qt installer, as mentioned in the question), to have a different version of it in another location. The reason for that is that many programs on Debian rely on an earlier version of Qt, so just updating it would break a lot, that's also why Synaptic&Co. don't update it.
Then I had to add the binary to the PATH variable, like so:
export PATH=/home/fabian/Qt/5.11.2/gcc_64/bin:$PATH
Then I was able to just install Dolphin beta regularly, like the tutorial says it.
When I am trying to sourceCpp, it gives a warning:
ld: warning: text-based stub file
/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd
and library file
/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation
are out of sync. Falling back to library file for linking.
But the function actually works. Just wondering how to solve this warning.
Using MacOS Mojave 10.14.2, the fix for me was to use the solution from this comment on GitHub:
export SDKROOT=macosx10.14
Put the line above in your ~/.bash_profile. Replace 10.14 with your specific version of MacOSX Xcode tools. Find out what version you have by doing:
xcrun --show-sdk-path
It will print something like:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
Just grab the last word, make it all lower caps and replace it in the export command above.
Update Sep 2019
In the latest release, they removed the version number from the sdk. Just grab the full path and export it as SDKROOT, like this:
export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
Update Aug 2021
To avoid having to continuously update the exported value whenever you upgrade your OS, you can place the xcrun command directly in the shell script:
export SDKROOT=$(xcrun --show-sdk-path)
I had this problem while compiling Go code on my Mac too.
The tld files were out of sync in /System/Library/Frameworks/.
The solution:
Just links the recent frameworks from MacOSX.sdk to /Library/Frameworks/
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework /Library/Frameworks/CoreFoundation.framework
Edit: this seems to have stopped working post 10.13.16. Trying it will not hurt your mac after the re-install but i'm not sure how to fix it going forward.
Came across this recently, just remove the command line tools for mac and re-install.
$ rm -rf /Library/Developer/CommandLineTools
$ xcode-select --install
After these steps you will see a pop to install the new version of the tools.
Reinstalling may help, but also may not.
It's Apple's fault and they need to fix it with another command line tools update.
Just ignore the warning for now.
(See a bunch of other people experiencing the issue here: https://github.com/vim/vim/issues/3445 and here: https://github.com/golang/go/issues/26073)
I think this has nothing to do with Rcpp.
This is related to your system.
I show first lines of one tbd file below. It is just a text file. You can open it using a text editor.
--- !tapi-tbd-v3
archs: [ i386, x86_64, x86_64h ]
uuids: [ 'i386: 17321B27-67AB-3D26-B9DF-A69624B1C82B', 'x86_64: 358C547D-E227-3228-8218-62327F4605C8',
'x86_64h: 945E5C0A-86C5-336E-A64F-5BF06E78985A' ]
platform: macosx
install-name: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
current-version: 1452.23
compatibility-version: 150
exports:
- archs: [ i386 ]
symbols: [ '$ld$add$os10.5$.objc_class_name_NSObject', '$ld$add$os10.6$.objc_class_name_NSObject',
'$ld$add$os10.7$.objc_class_name_NSObject', '$ld$hide$os10.4$.objc_class_name_NSArray',
'$ld$hide$os10.4$.objc_class_name_NSCalendar', '$ld$hide$os10.4$.objc_class_name_NSData',
...
As I understand, the tbd file contains the version and location of the real library file. It is like a "link". (Just my personal understanding. Please correct me if this is wrong.)
After the upgrade of Xcode, your tbd file and real library are out of sync. Then you got the warning.
I think you can ignore this warning for now, since your compiler has fallen back and found the correct library.
The dates of CoreFoundation and CoreFoundation.tbd show that the latter is much older. This suggests it can be ignored. The out of sync problem can easily be cured by deleting the .tbd file. It is not needed and if not present cannot generate the out of sync error.
I use CoreFoundation and IOKit on 10.13.6 and this is a simple solution avoiding reloading CommandLine tools or setting links or trying to export SDKs etc.
John
If you previously set SDKROOT in your ~/.bash_profile or ~/.zshrc you either need to update it whenever you update macOS or delete (if you do not need it).
This was the case for me export SDKROOT=macosx10.14 was in my ~/.bash_profile, after I updated to macOS Catalina 10.15.7 so it was causing the problem.
If you choose to update, it will look like this (based on previous answers)
export SDKROOT="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"
I have tried a lots of advice to help to set up the CDB debugger in Qt Creator but when using it that thing still takes ages to load up local variables.
My setup:
Windows 10 64-bit
Qt 5.6 (installed with sources)
Qt Creator 3.6.1
Microsoft Visual Studio 14 (2015) (both 32-bit and 64-bit compilers)
Windows SDK (for debugging tools = CDB)
The General tab in Options->Debugging lists auto-detected sources:
Source: Q:/qt5_workdir/w/s
Target: C:\Qt\5.6\Src
My symbols server and cache are set up in CDB Paths like this:
srv*http://msdl.microsoft.com/download/symbols
cache*C:\Qt\CDB-symbols-cache
On first run of the debugger it populates this directory with 70mb of (presumably downloaded) data but it does not seem to change afterwards on subsequent runs.
I suspect either the sources being loaded takes a long time (although I have a SSD) or that the CDB is re-downloading the symbols instead of using the cache. Any advice?
EDIT: As per request, result of .sympath command on my system:
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred
srv*
I had the same problem with QtCreator 4.12 which was solved by removing AppData\Roaming\QtProject\default.qws as suggested by Abstraction in the comments above.
I had the same issue with QtCreator 4.0.2 and VS 2015. Here is what I did.
Downloaded the microsoft symbol package from symbol packages
Copied it to a local folder(D:\Symbols)
In QtCreator , Tools->Options->Debugger->CDB Paths select "Insert Symbol Server" and select the local folder. Will look like the below screen.
I tried all the above and did not worked, however one thing worked: renaming the file default.qws
Usually it would take 10 seconds to load the debugger and it went to 10 minutes. Analyzing deeper I found out that the problem is with the breakpoints: if a breakpoint is on a file which is not part of the project, the debugger attempts to resolve the breakpoint for each loaded module/DLL, making the process incredibly slow.
The solution is to edit the file default.qws and remove those breakpoints which are set to files that don't exists anymore and you will get the speed as before.
I recently upgraded to Architect version 0.9.7 on my Win 7 machine. However, after starting Architect, the RJ console wouldn't launch and I got the error message:
‘Launching the R Console was cancelled, because It seems starting the R engine failed.”
Please make sure that R package 'rj' (2.0 or compatible) is installed and
that the R library paths are set correctly for the R environment
configuration 'Embedded R Server'.
I installed the packages ‘rj’ and ‘rj.gd’ through the RTerm run console (which does happen to work) within Architect using the command suggested on www.walware.de:
install.packages(c("rj", "rj.gd"), repos="http://download.walware.de/rj-2.0")
Then, I restarted windows, and restarted Architect. Same error message. I zoomed in on the details of the error message and noticed the following line:
SEVERE: Path to rj package not found. Use R_LIBS or java property
'de.walware.rj.rpkg.path' to specify the location.
So I opened an RTerm run console to check whether any of my .libPaths() locations contains the directories ‘rj’ or ‘rj.gd’. Oddly enough, they do. My first .libPaths path contains both packages. So that doesn’t seem to be the reason.
How could this be fixed?
I received prompt and helpful feedback from Open Analytics (thanks!), who informed me that the problem is due to changes in Java 8. With Java 7, Architect works fine. The next release of Architect will incorporate the changes in Java 8.
In order to get it work with Java 7, enforce the use of a specific Java Runtime, by using the -vm argument in the architect.ini file as follows:
-vm
C:\Program Files\Java\jre7\bin\javaw.exe
(mind the line break, which is required)
This is particularly useful if you have several Java versions on your system where the default Java is not suitable for use with Architect. The architect.ini file is found directly at the top level of the installation folder of Architect. You can find out where this is by looking at the Properties of the Architect shortcut on your desktop.
N.B. the -vm argument should be put before the -vmargs argument otherwise it is simply ignored!
N.B. examples of -vm specification on GNU/Linux and Mac OS X:
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Linux_Example
http://wiki.eclipse.org/Eclipse.ini#-vm_value:_Mac_OS_X_Example
I am trying to start working with OpenCL. I have two NVidia graphics card, I installed "developer driver" as well as SDK from NVidia website. I compiled the demos but when I run
./oclDeviceQuery
I see:
OpenCL SW Info:
Error -1001 in clGetPlatformIDs Call
!!!
How can I fix it? Does it mean my nvidia cards cannot be detected? I am running Ubuntu 10.10 and X server works properly with nvidia driver.
I am pretty sure the problem is not related to file permissions as it doesn't work with sudo either.
In my case I have solved it by installing nvidia-modprobe package available in ubuntu (utopic/multiverse). And the driver itself (v346) was installed from https://launchpad.net/~mamarley/+archive/ubuntu/nvidia
Concretely, I have installed nvidia-opencl-icd-346, nvidia-libopencl1-346, nvidia-346-uvm, nvidia-346 and libcuda1-346. Not sure if they are all needed for OpenCL.
This is a result of not installing the ICD portion of Nvidia's openCL runtime. The ICD profile will instruct your application of the different openCL implementations installed on the system as multiple implementations from different vendors can coexist. Whe your application does not find the ICD information it gives the Error -1001.
Run your program as root. In case of success: you have trouble with cl_khr_icd- extension to load the vendor driver.
If you not running X11, you have to create device files manually or by (boot-)script:
ERROR: clGetPlatformIDs -1001 when running OpenCL code (Linux)
Same problem for me on a Linux system. Solution is to add the user to the video group:
# sudo usermod -aG video your-user-name
Since I just spend a couple of hours on this, I thought I would share:
I got the error because I was connected to the machine per remote desktop (mstsc). On the machine itself everything worked fine.
I have been told that it should work with TeamViewer by the way.
Dont know if you ever solved this problem, but I had the same issue and solved it in this post: ERROR: clGetPlatformIDs -1001 when running OpenCL code (Linux)
Hope it helps!
I have solved it in Ubuntu 13.10 saucy for intel opencl by created link:
sudo ln -s /opt/intel/opencl-1.2-3.2.1.16712/etc/intel64.icd /etc/OpenCL/vendors/nvidia.icd
I just ran into this problem on ubuntu 14.04 and I could not find ANY working answers anywhere online including this thread (though this was the first to show up on google). What ended up working for me was to remove ALL previous nvidia software and then to reinstall it using the .run file provided on the nvidia website. Installing the components through apt-get seems to fail for some reason.
1) Download CUDA .run file: https://developer.nvidia.com/cuda-downloads
2) Purge all previous nvidia packages
sudo apt-get purge nvidia-*
3) Install all run file components (you will likely have to stop X or restart in recovery mode to run this)
sudo sh cuda_X.X.XX_linux.run
This is because OpenCL has the same brain damaged one library per vendor setup that OpenGL has. A likely reason for the -1001 error is that you have compiled with a different library than the linker is trying to dynamically load.
So see if this is the problem run:
$ ldd oclDeviceQuery
...
libOpenCL.so.1 => important path here (0x00007fe2c17fb000)
...
Does the path point towards the NVidia-provided libOpenCL.so.1 file? If it doesn't, you should recompile the program with an -L parameter pointing towards the directory containing NVidia's libOpenCL.so.1. If you can't do that, you can override the linker's path like this:
$ LD_LIBRARY_PATH=/path/to/nvidias/lib ./oclDeviceQuery
For me, I was missing the CUDA OpenCL library, Running sudo apt install cuda-opencl-dev-12-0 solved it.
You should get number of platforms, allocate the memory for platforms, again get this platforms and then create context from this platform. There is good example:
http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=71
This might be due to querying clGetPlatformIDs by multiple threads at the same time