Install sox tool with mp3 support:
apt-get install sox apt-get install libsox-fmt-mp3 sox file.mp3 file.wav
Basically that is all, but if you need to check resulting wav file parameters like channels, sample rate, precision, duration, bit rate, etc…, use soxi command:
(more…)
First, I tried Valgrind tool using the following command:
valgrind --tool=memcheck --leak-check=yes ./app
With some large QT application started for some short period I got the following output:
==7090== HEAP SUMMARY:
==7090== in use at exit: 5,623,365 bytes in 36,268 blocks
==7090== total heap usage: 32,454,680 allocs, 32,418,412 frees, 12,822,939,874 bytes allocated
................................
==7090== LEAK SUMMARY:
==7090== definitely lost: 20,163 bytes in 74 blocks
==7090== indirectly lost: 60,053 bytes in 1,273 blocks
==7090== possibly lost: 396,167 bytes in 2,169 blocks
==7090== still reachable: 4,834,822 bytes in 31,576 blocks
==7090== suppressed: 0 bytes in 0 blocks
==7090== Reachable blocks (those to which a pointer was found) are not shown.
==7090== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==7090==
==7090== For counts of detected and suppressed errors, rerun with: -v
==7090== Use --track-origins=yes to see where uninitialised values come from
==7090== ERROR SUMMARY: 20905 errors from 1583 contexts (suppressed: 15 from 2)
When I left this app running for the night (approximately 16 hours), I got the following summary:
==3816== HEAP SUMMARY:
==3816== in use at exit: 7,746,701 bytes in 36,248 blocks
==3816== total heap usage: 827,800,342 allocs, 827,764,094 frees, 105,404,761,516 bytes allocated
..................................
==3816== LEAK SUMMARY:
==3816== definitely lost: 19,835 bytes in 38 blocks
==3816== indirectly lost: 59,805 bytes in 1,237 blocks
==3816== possibly lost: 396,167 bytes in 2,169 blocks
==3816== still reachable: 6,958,734 bytes in 31,628 blocks
==3816== suppressed: 0 bytes in 0 blocks
==3816== Reachable blocks (those to which a pointer was found) are not shown.
==3816== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3816==
==3816== For counts of detected and suppressed errors, rerun with: -v
==3816== Use --track-origins=yes to see where uninitialised values come from
==3816== ERROR SUMMARY: 13022 errors from 1574 contexts (suppressed: 10 from 2)
It means that the app leaks about 0.126 MB/hour ( (6958734 – 4834822) / 16 / 1024.0 / 1024.0) and totally for the night 2.02 MB, and probably it is not a leak, because the app has pointers to the allocated memory (it is reachable), but it does not clean exit.
To figure out how it works I built the following trivial program:
int main()
{
int *a = new int[100];
}
with debug information and started the tool:
g++ -g -o ex ex.cpp
valgrind --tool=memcheck --leak-check=yes ./ex
In the output the tool shows line number 3 where memory leak is occurred:
==22042== Memcheck, a memory error detector
==22042== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==22042== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==22042== Command: ./ex
==22042==
==22042==
==22042== HEAP SUMMARY:
==22042== in use at exit: 73,104 bytes in 2 blocks
==22042== total heap usage: 2 allocs, 0 frees, 73,104 bytes allocated
==22042==
==22042== 400 bytes in 1 blocks are definitely lost in loss record 1 of 2
==22042== at 0x4C2B800: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22042== by 0x40061B: main (ex.cpp:3)
==22042==
==22042== LEAK SUMMARY:
==22042== definitely lost: 400 bytes in 1 blocks
==22042== indirectly lost: 0 bytes in 0 blocks
==22042== possibly lost: 0 bytes in 0 blocks
==22042== still reachable: 72,704 bytes in 1 blocks
==22042== suppressed: 0 bytes in 0 blocks
==22042== Reachable blocks (those to which a pointer was found) are not shown.
==22042== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==22042==
==22042== For counts of detected and suppressed errors, rerun with: -v
==22042== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Links:
Another alternative is calling mallinfo() function in C++ code. The following code gets something like total heap size of the process:
int usedmem = mallinfo().uordblks;
Using this function I wrote a QT widget that shows memory usage in application status bar:
#include <QLabel>
#include <malloc.h>
class MemoryStatusWidget : public QLabel
{
public:
MemoryStatusWidget(QWidget *parent = nullptr);
public:
void timerEvent(QTimerEvent *) override;
};
MemoryStatusWidget::MemoryStatusWidget(QWidget* parent)
: QLabel(parent)
{
startTimer(1000);
}
void MemoryStatusWidget::timerEvent(QTimerEvent *)
{
int usedmem = mallinfo().uordblks;
setText(tr("Memory Usage:%1 MB").arg(QString::number((double)usedmem / (1024 * 1024), 'f', 3)));
}
Just in case if you need to detect leaks on Windows (where Valgrind doesn’t work and will never work by design), give Deleaker a try. By the way it can be integrated with Qt Creator, see video on YouTube.
Below I provided parameters of three Android phones I tested my Lines game with:
| Android Version | Screen Resolution | Pixel Ratio | DPI | Screen Size |
|---|---|---|---|---|
| 4.4? | 320×496 (480×744/706) | 1.5 | 156.89 | 52×80 mm |
| 4.4? | 360×592 (540×888/850) | 1.5 | 160.19 | 57×94 mm |
| 6.0 | 360×592 (720×1184/1136) | 2.0 | 160.19 | ~68×123 mm |
| N/A | 800×1232 | 1.0 | 188.3295 | 108×166 mm |
Screen Resolution column contains the information in the following format: <logical resolution> (<physical resolution>/<physical height available for applications in portrait orientation>.
DPIs with ‘~’ sign are measured manually because QT (or some Android API) provides incorrect Screen Size.
QML DropShadow is an interesting effect that acts in a very simple way. It works fine in my application and produces the following result:
The only disadvantage of DropShadow effect is that is slows down my application from 60 FPS to 30 FPS on Android Phone. The following code demonstrates how I use it with StackView:
Lines 3D is a fun logical game with different difficulty levels. While “Beginner” level is an easy to play relaxing game, the “Professional” and “Expert” levels are good exercises for your brain where you can apply your knowledge in the area of the probability theory. There is also some specific “Baby” level for babies, allowing them to move balls and do not worry about the result.
For IT professionals, there is auto-play mode for testing the application performance and stability. To start Lines 3D game in auto-play mode first install Lines 3D game from Windows Store, start it and select the following game options:
Lines 3D game is a UWP application based on “XAML App for OpenGL ES (Universal Windows)” VS2015 project template (written in C++/VS2015 using OpenGL ES 2.0 and elements of OpenGL 3.0). You can install Lines 3D from Windows Store and play for free, or at least see the game screenshots.
Game logic and OpenGL rendering engine in Lines 3D are cross-platform. Their code uses STL, OpenGL and abstract C++ interfaces for doing the following tasks:
All the graphic controls, including the main windows, application bar (main menu), dialogs, message boxes and advertising are written using XAML and Windows-specific code.
Fist install MySQL client libraries and check their location:
apt-get install libmysqlclient-dev find / -name '*libmysqlclient*'
Then install SQLite:
sudo apt-get install sqlite3 libsqlite3-dev
Extract GDAL sources and configure supported modules (MySQL and SQLite are not compiled by default, so we need to specify them explicitly):
unzip gdal211.zip cd gdal-2.1.1/ ./configure --with-sqlite3 --with-mysql
this will output “MySQL support: yes” and “SQLite support: yes” along with other information.
In my previous post Testing XAML App for OpenGL ES on Windows 10 Mobile Device I described the changes I made to UWP application based on “XAML App for OpenGL ES (Universal Windows)” template to demonstrate some strange effect related to the transparency of the image drawn with OpenGL ES in SwapChainPanel. But I did yet another experiment with this application and got some beautiful pictures that demonstrate what happens if I make the scene completely transparent with the following code:
void SimpleRenderer::Draw()
{
glEnable(GL_DEPTH_TEST);
glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
...
}
Today I played a bit with a UWP application based on “XAML App for OpenGL ES (Universal Windows)” template and realized that there is some specific bug probably related to the interaction between SwapChainPanel and OpenGL surface. First, I made the cube transparent by changing two lines of code in the vertex shader:
const std::string vs = STRING
(
uniform mat4 uModelMatrix;
uniform mat4 uViewMatrix;
uniform mat4 uProjMatrix;
attribute vec4 aPosition;
attribute vec3 aColor;
varying vec4 vColor;
void main()
{
gl_Position = uProjMatrix * uViewMatrix * uModelMatrix * aPosition;
vColor = vec4(aColor, 0.1);
}
);
There are two main options in the Windows Store how to hide the app from public but make it available for specific users or beta testers: Package flights and Promotional codes. Below I briefly describe how I used Promotional codes with my app by the example of Lines 3D game.
According to the Microsoft guide, in my submission on the Pricing and availability page in Distribution and visibility I chosen Hide this app and prevent acquisition. Customers with a promotional code can still download it on Windows 10 devices. Then I generated one promotional code and got so called “Redeemable URL” or the app activation link in other words.
