Thank you, Joshua, for getting back to me. I have submitted the build with this particular sound in MP3 format (the rest are still in OGG format).
About the internal storage, when I install the game built with 934 with all sound in OGG, this particular sound won’t play, but if I install the same game built with 840, all OGG file plays perfectly fine. So I’d have to say the issue is unrelated to internal storage…
Naomi [import]uid: 67217 topic_id: 31697 reply_id: 127510[/import]
>> About the internal storage, when I install the game built with 934 with all sound in OGG, this particular sound won’t play, but if I install the same game built with 840, all OGG file plays perfectly fine. So I’d have to say the issue is unrelated to internal storage.
Bummer. I was a hoping it would be something simple. [import]uid: 32256 topic_id: 31697 reply_id: 127515[/import]
The original files that were in the app that B&N rejected were .m4a and the largest was 118 kb. After reading the audio documentation carefully I saw that only .mp3 and another file type were supported for android devices. So I converted them all to .mp3 and only then was my app accepted. Of course those files were much bigger, the largest being 718kb. I don’t know what happened because I already had an app approved with .m4a’s and in the store. [import]uid: 40033 topic_id: 31697 reply_id: 127414[/import]
@Pixin, the 210KB OGG file plays fine on NOOK Color & Tablet (and all other Android device) when the game is built using daily build 840. However, when I build the game using the daily build 934, the 210KB OGG file won’t play (even though all other OGG files that are 28KB or less play perfectly fine for me.) So… if you are wondering about your app you’ve already released, I don’t think you need to worry about it.
That said, if you are releaseing an updated version using more recent daily build (for NOOK HD/HD+ support), I’d like to know how it goes especially if your MP3 files include the large 718KB MP3 file – and if 718KB MP3 file plays perfectly fine on NOOK device after updating your app using daily build 934, then we can eliminate the speculation about the file size being an issue.
Naomi [import]uid: 67217 topic_id: 31697 reply_id: 127451[/import]
Update:
I just got approved my 2 apps for NOOK HD using Mp3 instead of OGG. So there you go.
@Pixin: I personally split the audio channels into mono, that saves you half of the file size. Then I use 22khz for the encoding. It really doesn’t make much different with that tiny speaker the Nook has. And if that is not enough I would suggest that you make a loop instead of a full song for the audio.
I hope this helps.
[import]uid: 12407 topic_id: 31697 reply_id: 127463[/import]
Thanks Adrian, and congrats, that’s exactly how I minimize my audo files (22, mono, trim to loop) sometimes even less than 22 if I can get away with it. That’s not even a full song, and the same file as .m4a is only 84kb!
Naomi, I just submitted an update today for HD so I’ll let you know. I see Adrian’s were approved with mp3s too. [import]uid: 40033 topic_id: 31697 reply_id: 127472[/import]
Naomi, thank you for submitting your OGG file to us. We won’t have time to look into this issue this week. So, as a work-around, I hope you won’t mind switching over to MP3 like Adrian has at the moment.
One more thing. You might want to double check if your device’s internal storage is low on space. This is because audio files are extracted to internal storage because our current audio APIs cannot access files inside of an APK (which is really a zip file). If internal storage runs out of space, then the audio file will fail to be extracted, which will prevent it from being played. [import]uid: 32256 topic_id: 31697 reply_id: 127507[/import]
Thank you, Joshua, for getting back to me. I have submitted the build with this particular sound in MP3 format (the rest are still in OGG format).
About the internal storage, when I install the game built with 934 with all sound in OGG, this particular sound won’t play, but if I install the same game built with 840, all OGG file plays perfectly fine. So I’d have to say the issue is unrelated to internal storage…
Naomi [import]uid: 67217 topic_id: 31697 reply_id: 127510[/import]
>> About the internal storage, when I install the game built with 934 with all sound in OGG, this particular sound won’t play, but if I install the same game built with 840, all OGG file plays perfectly fine. So I’d have to say the issue is unrelated to internal storage.
Bummer. I was a hoping it would be something simple. [import]uid: 32256 topic_id: 31697 reply_id: 127515[/import]
Has there been any progress with OGGs so far?
I realise you had mentioned it couldn’t be looked at last week, but we are having similar problems loading OGGs where every other file type loads ok. [import]uid: 84115 topic_id: 31697 reply_id: 128430[/import]
Not yet. We’re going to look into using Android’s OpenSL to see if we can get much more reliable audio decoding, audio playback, and for reducing audio latency.
In the mean-time, the only work-around is to use MP3 files instead of OGG. [import]uid: 32256 topic_id: 31697 reply_id: 128456[/import]
I just talked to our audio expert and he said that this issue will only happen with large OGG files if you use the [lua]audio.loadSound()[/lua] function. The reason is because that function loads the entire audio file into memory and the OGG decoder often guesses wrong on the actual size of the audio sound, so it typically allocates much more memory than needed to hold sound. The MP3 decoder does not have this issue, which is why switching to MP3 works around this issue.
That said, you can continue to use large OGG files, but it is recommended that large audio files be streamed instead of fully loaded into memory. Especially on devices with limited memory, which unfortunately there are too many Android devices like this. You can stream audio from file via our [lua]audio.loadStream()[/lua] function.
http://docs.coronalabs.com/api/library/audio/loadStream.html
One more thing, you can also lower the amount of memory required for OGG file playback by lowering the bit-rate to 22 or 11 kHz… and switching to mono instead of stereo. Doing so will always improve performance because it’s less audio data for the CPU to load and decode.
I hope this helps! [import]uid: 32256 topic_id: 31697 reply_id: 128465[/import]
Has there been any progress with OGGs so far?
I realise you had mentioned it couldn’t be looked at last week, but we are having similar problems loading OGGs where every other file type loads ok. [import]uid: 84115 topic_id: 31697 reply_id: 128430[/import]
Not yet. We’re going to look into using Android’s OpenSL to see if we can get much more reliable audio decoding, audio playback, and for reducing audio latency.
In the mean-time, the only work-around is to use MP3 files instead of OGG. [import]uid: 32256 topic_id: 31697 reply_id: 128456[/import]
I just talked to our audio expert and he said that this issue will only happen with large OGG files if you use the [lua]audio.loadSound()[/lua] function. The reason is because that function loads the entire audio file into memory and the OGG decoder often guesses wrong on the actual size of the audio sound, so it typically allocates much more memory than needed to hold sound. The MP3 decoder does not have this issue, which is why switching to MP3 works around this issue.
That said, you can continue to use large OGG files, but it is recommended that large audio files be streamed instead of fully loaded into memory. Especially on devices with limited memory, which unfortunately there are too many Android devices like this. You can stream audio from file via our [lua]audio.loadStream()[/lua] function.
http://docs.coronalabs.com/api/library/audio/loadStream.html
One more thing, you can also lower the amount of memory required for OGG file playback by lowering the bit-rate to 22 or 11 kHz… and switching to mono instead of stereo. Doing so will always improve performance because it’s less audio data for the CPU to load and decode.
I hope this helps! [import]uid: 32256 topic_id: 31697 reply_id: 128465[/import]
Hi,
I currently have an app in the Nook market, which I am trying to make compatible with the new Nook tablets. After compiling with the Build 935 as instructed on the Nook Developer Site, I am facing an issue with the audio where the mute button stops working. My app got rejected by Nook because of this problem. The same code base works perfectly on the Stable build.
All my audio files are MP3 files and I am using audio.loadStream().
Is there an issue with the daily build 935? Should I be using a different build for Noom HD support?
[import]uid: 50371 topic_id: 31697 reply_id: 129859[/import]
Hi,
I currently have an app in the Nook market, which I am trying to make compatible with the new Nook tablets. After compiling with the Build 935 as instructed on the Nook Developer Site, I am facing an issue with the audio where the mute button stops working. My app got rejected by Nook because of this problem. The same code base works perfectly on the Stable build.
All my audio files are MP3 files and I am using audio.loadStream().
Is there an issue with the daily build 935? Should I be using a different build for Noom HD support?
[import]uid: 50371 topic_id: 31697 reply_id: 129859[/import]
I use mp3 with .loadSound and was accepted for Nook HD 2x. I’m not familiar with Noom. (heheh) [import]uid: 40033 topic_id: 31697 reply_id: 129920[/import]
Everyone,
The OGG file issue was solved as of daily build #937. It turned out that the OGG decoder was taking way too much memory when loading a file. So, please feel free to switch back to using OGG files. And thank you for reporting this issue to us. [import]uid: 32256 topic_id: 31697 reply_id: 129930[/import]
I use mp3 with .loadSound and was accepted for Nook HD 2x. I’m not familiar with Noom. (heheh) [import]uid: 40033 topic_id: 31697 reply_id: 129920[/import]