The problem was in the Windows firewall. I still don't understand why this was affecting the sound, but disabling the firewall did the trick.

@SGaist Hey so the reference problem is solved. Seems like the file can be opened, the player works but there is no sound :-/. I'll probably open another thread for this issue. Thanks for the help again! EDIT: Or maybe it's working :D. On other devices I got a report that the sound is OK. Will investigate that further!

@iamRahul I figured it out. We need to specify full location path till the file, and specify file type in format. Then it worked for me. if(audioPlaylist.save("file:///C:/MyMusicPlayer/Playlists/global_playlist.m3u","m3u")) { console.log("Playlist Saved") } Adding the filename global_playlist.m3u and format m3u made it working for me.

The Linux backend uses GStreamer. You can take a look at the code and maybe modify it for your purpose.

It seems remarkable to me that the QMediaPlayer can know whether I'm playing back audio with 1, 2, or more channels, but I cannot get that information from it, but I guess that's just the way it is? It seems like some people can get this to work, and others can't, so I wonder if this is another issue of platform differences? (For reference, this is playback either via a wired connection to an MFi device, or directly on an iPad/iPhone, so iOS under the hood.) Anyway, I've given up on displaying mono/stereo channel information in our implementation. (The player will fail to play back audio with three or more channels, so I can at least flag that. It'd be nice to label, but it's not required.) I'll report a bug if I get the time at some point.

Thank you for your help, I've probably identified the problem - one of the input parameters was a char (8 bit). I've tried to fix it using the following code to reformat it so that it can be used properly for 16 bit but I keep getting the same problem /* Function with char as one of the parameters - qint64 XYSeriesIODevice::writeData(const char *data, qint64 maxSize) - same as in the Qt audio example**/ int bitsPerSample = 16; int bytesPerSample = (bitsPerSample / BITS_IN_BYTE); int signalLength = (strlen(data) ) / numChannels / bytesPerSample; short* signal = (short*)malloc(sizeof(short) * signalLength); for(int i = 0; i < signalLength; i++){ int index = i * numChannels * bytesPerSample; memcpy(&signal[i], &data[index], sizeof(short)); } Any suggestions?

hi well you can hook up the AUDIO positionchanged signal to your own method (slot) using connect. http://doc.qt.io//qt-5/signalsandslots.html so it will directly call your method when it changes.

https://drive.google.com/file/d/1SHw3k6gY9pz8cL7skhDUPUf2NrwF4xeE/view

@Cleiton-Bueno thanks for your suggestion. I have disabled audio in my kernel completely now. Now I get the message CameraBin warning: "Could not open audio device for recording." which shows, that I really removed audio support. Unfortunately, this still doesn't solve my basic issue, which is a extremely sluggish video output when the videoRecorder property is enabled in the Camera. That means, the audio encoding was not causing this problem at all. Thx, Jens

Hi and welcome to devnet, You should check what your device support, QAudioDeviceInfo gives you all the various channel counts, sample sizes etc. that are supported by the device you want to use.

The please first update to 5.9.1

I re-built the file system image, this time with Buildroot-2017.02 and Qt version 5.6.2. I ran, on the target board, the audiooutput example that Qt provides and got a lots of pulseaudio warnings. Remembering the above QT_DEBUG_PLUGINS hint, I took a look inside the /usr/lib/qt/plugins/audio directory on the target board and found two plugins: libqtmedia_pulse.so and libqtaudio_alsa.so . Removing the libqtmedia_pulse.so plugin solved the race condition with libqtaudio_alsa.so and solved the problem. In addition, make sure that alsa-lib builds before qt5multimedia (commit 8d7dd837e5e from mainline Buildroot: "qt5multimedia: conditionally add alsa-lib to dependencies").

Hi and welcome to devnet, QAudioInput returns a pointer to a QIODevice that will provide the audio data. Connect the readyRead signal from that QIODevice object to a slot of your class, there you can read the audio data received and make what you want with it. Hope it helps

Hi, Usually, to play sound effect, the QSoundEffect class is used. Wouldn't that fill your need ?

Hi, You should take a look at the bug report system to see if it something known.

Hi, Then that's something you should ask to the QtAV authors. It's not an official Qt module.

Hi, Might be a bit of short answer but… AFAIK, no you can't.

Is it a paid or free program.

Hi, Take a look the QAudioInput example.

Then you either have to play your video through QtMultimedia and use a QAudioProbe or you'll have to do it with some additional hardware.

You're welcome ! Since you have what you need now, please mark the thread as solved using the "Topic Tool" button so that other forum users may know a solution has been found :)

@SGaist Good point about the drawing – that hadn't occurred to me.

@VaL-Doroshchuk Hi! "big buffer" is quite relative and that "big" depends on needs. In my case I'm using audio data to pitch recognition and depending on pitch range to recognize, I'm using 512, 1024 or 2048 samples buffer, so it is apparently 11, 23 and 45ms (more less). Those power-of-two buffer sizes are required by FFT routines. But my app is flexible enough, and when underlaying OS is not capable to keep that buffer size it will portion any audio data size as needed for pitch detection algorithm. (on Android Qt Audio is used and with low level device a delay between data ready call could sometimes be about 100ms) However smaller buffer gives faster app response (displaying pitch in score). And no any glitches was notices even if buffer is set to 64 frames (2ms) And if we take simpler example, which could be passing input mike data to an output device - more quicker we send incoming data to the out - less delay will be in speakers - it means less buffer - faster response.

Then it probably is using the audio plugin which I'm not sure at all is supporting qrc

I see... Had to rebuild the app with 5.5 where WMF backend was present. And the link doesn't seem to provide any rationale for this very odd decision. Of course, I don't care what backed is used, but I do like classes like QAudioProbe actually working.

Then you should check the bug report system

No problem :) Since you have it working now, please update the thread title prepending [solved] so other forum users may know that a solution has been found :) Also, when encountering answer(s) that helped you, please consider up-voting them so that other users may find them more easily. Happy coding !

Good ! Since you have it working now, please update the thread title prepending [solved] so other forum users may know a solution has been found :)

@SGaist Thanks! I didn't see any bug reports that looked relevant. I'll file one.

One last thing, apparently this error only occur in IOS devices

Nsound is also a C++ library and can be used in C++ applications, see http://sourceforge.net/p/nsound/code/HEAD/tree/tags/nsound-0.9.3/src/Nsound/. :) Nick