How to play .wav data received using XmlHttpRequest ?
I'm stuck trying to play a .wav file received via XmlHttpRequest. The .wav file comes back as a binary string. It's a complete .wav file, including headers, so not just raw audio data.
I am currently trying to use this .wav data "inline" by encoding it in a data uri "data:audio/wav;base64,..." and setting that string as source in a SoundEffect element, but I get an error message saying the data cannot be decoded. Maybe I need some additional magic incantations with Qt.resolvedUrl or maybe uri is not supported for audio? My insight in the matter is limited.
If all else fails, I guess I could try to use C++ to save the binary data to a file first, then use the source argument in a SoundEffect element to get that file to play, but I was hoping for something more direct really.
If anyone has insights or ideas, please chime in. Thanks!
Hi and welcome to devnet,
Reading from the doc, I'd say that it's currently not supported. So yes you will need a small QObject base class to write the data in a file before using it. It's really not a huge thing to implement.
QtQuick temporarily turns into QtFrustration.
I guess QtQuick can still be useful for the UI, but all other stuff for now will be done in C++.
The SoundEffect qml element kept complaining about decoding errors, and the Audio element didn't produce any audio for unknown and harder-to-debug-than-I-'d-want reasons. These qml elements appear to work just fine with a hard-coded "source" but not when I dynamically change the source property upon receiving a c++ signal. I used absolute file paths, checking status and every other trick I could think of to make it work but to no avail. I guess I miss some basic insights into how QML actually works.
So I finally also tried moving the actual playing of sound to C++ and immediately everything started to work properly (yay!). I'm a little underwhelmed by what I was able to achieve with QtQuick so far. Are network interaction and sound still in development?
Anyway all's well that ends well.
MrKozmon last edited by
That company's bug department really don't work. What kind of laxity is that?
Qt5.8 released yesterday and still QtQuick is QtFrustration, like a joke.
No doc, no solution about XMLHttpRequest.
Since stone age (2011): https://bugreports.qt.io/browse/QTBUG-21909
And some variations since store age: https://bugreports.qt.io/browse/QTBUG-19809
And then they says, "Hey we introduced Qt 5.8RC today, please give us your feedback to make it ready."
Before you say that, first resolve your existing bugs damn idiot
Dont say easy never, same shit happens to me everyday.
I'm really tried
Someone has to hear me
tekojo last edited by
Please stay civil here.
Ranting doesn't get you anywhere.
So I guess you want more functionality on the QML side with XMLHttpRequest?
The bugs you point are categorised as P3 and not assigned. With the amount of P1 and P2 bugs compared to the number of developers, unassigned P3 bugs will most likely never be looked at.
So the bugs need some help. The first thing you could do is ask on the Interest mailing list how you can help, and remember to describe your problem properly. Then maybe comment on the bugs (although they are not assigned, so getting a reply there isn't probable)
MrKozmon last edited by
In commerce there is a phrase you may don't know; the customer is always right. I'm the customer and I don't have to fix your bugs, that's not my job and also I'm not get paid for this, that's you.
QT wants Commercial apps built but won't address problems like the above. Why is this a P3 bug?