Try removing the line starting with ARequest.Headers.Add
This isn't necessary and is likely to cause an error as the server isn't going to let you set that anyway.
Did you find it helped? I found that it didn't really seem to make a difference one way or the other. The on-site reference works, and the off-site doesn't, either way. But removing it generates a different error, which seems odd.
I tried your second link again but that still has the ARequest.Headers.Add line again. The error it is giving is that "you are not allowed to do that", so, well, don't do that 
1 Like
@AndrewSimard did you happen to look at this? Can you make a Delphi method that embeds the JS needed inside of it? It might solve the issue.
Yes, but we'd rather not introduce an unnecessary (and sketchy) dependency for something that we can fix ourselves. Can you update your g3q link with a copy of the project without the headers.add statement? I'd like to see the new error message.
done!
FWIW, both of these hosting accounts have the same IP and they're on the same WHM account and server. So testing on your own server would also be helpful.
I should add that I'm only going through all of this simply because I'd rather load these files on another server rather than the one that will be hosting the XData service.
Using the HTTPS links for the apps, both can load the HTTPS mp3 
Using the HTTPS links for the apps, neither can load the HTTP mp3. This is expected.
Using HTTP links for the apps, both can load the HTTP and HTTPS mp3.
There are plenty of solid reasons why content might be hosted in a different place than either the app or the REST API server. Hence the reason to get this sorted out properly. Good job!
So, for posterity, can we conclude the fix boiled down to just adding the header to Apache?
And NOT adding the header in the client connection, which wasn't there originally anyway?
Well, it looks like this is an accurate explanation. I've got it all working. I just hope this is a general solution and isn't dependent on some quirks of the hosting server I'm on.
I'm able to create a list of buffers that I can load, and I can play them in sequence.
I can also load the first buffer, start playing it, then load up the rest asynchronously without any interference of what's playing, which is really cool to be able to do without having to use threads or tasks!
So thanks for all the help in getting this resolved!
1 Like
You're welcome. On to the next challenge!
1 Like
Hard to debug these things remotely. I assume line 268 is the last line, and it is the one that is failing?
I've had problems before with TWebHTTPRequest.Create(), maybe change from NIL back to Self or something other than NIL and see if that helps? Just a guess though. Your debug line seems to suggest everything is in order, so maybe not a problem there, but the error seems to hint at there being something wrong with the data?
I think I'd need to see more of the code? How/where is FAudioContext declared? Maybe it isn't in a way that gives access to FAudioContext.DecodeAudioData?
Also, new challenges usually imply new threads, just for our sanity!
Sorry, it looked related. It's not.
Something is not getting blocked and the destructor is being called before the sequence of operations completes. So the audio context is gone. Strangely, the call to fill the buffer a little above it worked.
These async ... awaits can really be challenging when they happen in the wrong order....
There one minute, gone the next! Particularly amusing (or frustrating) when you learn that JavaScript is not multithreaded, so nothing should have happened between two consecutive lines of code 
Also, in Delphi-land we're rather particular about freeing up allocated resources - one of the core principles of Delphi coding, if there were such a list. In JavaScript, this is the exact opposite. Often, it just doesn't care. It'd rather haul around dead weight than take the time to free it. I don't know who invented "garbage collection" but I'm not a fan.....
1 Like
Well, js may not be multi-threaded, but it can sure do things in strange orders.
I see the use of strings of closures in js to be quite common. Closures can be done in Delphi, but they're so verbose that most people don't bother with them; forgetabout running them together! I think if they were easier to express in Delphi, I'd probably use them more. But when I've looked at them in Java, the closer I looked, the more they resemble recursive coding, and that can get mind-numbing pretty quickly. Something here is getting unwound earlier than I think, and since there's no actual thread involved, there's no way to say, "when this mess ends, then close it down".