When I create an AudioPlayer object and set a URL to an MP3 file\r\nI get an error that says 'No audio data found' even though I can\r\nverify a correct MP3 file is present and can be played through\r\niTunes and can be downloaded.
\r\nHere is the code that I am using
\r\n\r\n var player = Titanium.Media.createAudioPlayer({url: audio_uri});\r\n player.start();\r\n\r\naudio_uri is http://serverdemo.voicebox.com/VBTGetTTSAudio.aspx?TTS=79458.mp3
\r\nThis happens on an iPad/iPhone project with versions 1.4.1 and\r\n1.4.2 continuous.
I think its a problem with your audio file. I threw the link\ninto my working music player and it gave me the error.
It's not the file, I am able to fetch it using createHTTPClient\nand then play that file locally. If I just send the URL, it says\nthere is no audio data.
I have found the problem for my URL while attempting to use\ncreateSound to play the same URL.
TiMediaSoundProxy.m around line 43 of the 1.5.0 nightly\nbuild.
\n\n NSString *ext = [[[url path] lastPathComponent] pathExtension];\n\nFor my URL, which is a fairly common thing to encounter, the\nvalue of ext becomes aspx because that is the file extension of the\nfile that is being called to return the MP3. Using the same logic,\na URL that is not using any file to return audio would have an\ninvalid extension as well. An example would be a streaming audio\nURL that is something like http://www.somestream.com/astream/\nwould fail because the ext variable would not specify the type of\nfile that is present.
\nMy sloppy test was changing that line to this and it would play\nmy file.
\n\nNSString *ext = @\"mp3\";\n\nI assume the preferred way to deal with this would be some sort\nof media type detection and setting the temp ext according to it\nbut an easier would might be to allow developers to specify the\ntype of media we are attempting to play and make the ext variable\nbased on it. Just my opinion...
When calling createAudioPlayer with the same URL, I have a\nsimilar problem.
\nAround line 543 of AudioStreamer.m there is another place that\nlooks like it attempts to guess file type by extension which\nwouldn't work correctly for my URL. The comment directly above that\nline says.
\n\n //\n // Attempt to guess the file type from the URL. Reading the MIME type\n // from the CFReadStream would be a better approach since lots of\n // URL's don't have the right extension.\n //\n // If you have a fixed file-type, you may want to hardcode this.\n //\n\nThis is similar to my comment above about being able to tell the\nmedia object what file type it is trying to stream.