Please elaborate the advantages of using Sound Component instead of Player Component 
@>-->---
The mp3s in this case are only 1 second long.
Do you usually hear music on your cell phone? ♫ ♪♪ ♫ ♪♪ ♫ ♪♪ ♫ ♪♪
(I know what is the problem with your project... but I need to answer me this first...)
@>-->---
Before I go off and test, which bitrates do not playback in AI2 ? Audacity only offers encoding upto 320Kbps...
There is a reason why it exists, these mp3s are 1-2 seconds long, player is unnecessary for short files like this, so use sound.
Now you please elaborate the advantages of using player component instead of sound component. 
The afterCompleted event for one.
the reason is only backward compatibility, else that component would have been removed from App Inventor, @ewpatton might want to comment on this
actually there are only disatvantages to use the sound component... only short sound snippets work, and there is less functionality compared to the Player component...
Taifun
2 Likes
This is not true.
On Android, the Sound component is backed by the SoundPool Android class whereas the Player is backed by the MediaPlayer Android class. Here's a StackOverflow post discussing the tradeoffs of each of the internal classes. In a game for example, you would have the background music handled by the Player while sound effects would be played by one or more Sound components to take advantage of both.
3 Likes
Thank you for clarifying, It looks like I had some wrong understanding about the history of sound and player components... I now edited my answer...
Taifun
1 Like
Both components were developed when App Inventor was still at Google, so I only have limited information myself about the specific motivation for the two different implementations, but it makes a reasonable amount of sense given the internals of the two components.
2 Likes
Perfect!
I only see advantages in using the Player component instead of Sound. The 'When Player.completed' Event is a feature that avoids confusion and allows to organize the processing times. I did not see expressed in any of the answers that the Player consumes more resources... which would be a strong argument.
But let's go to what matters, which is to solve the problem »
The question formulated in this topic is confused at the beginning... quotes an Error 703 that could correspond to several contexts. Who asks does not post the file *.aia so that whoever answers can see the project, responds evasively to the questions formulated, does not verify the information given and, in some cases, does not answer the questions formulated... So, in function of having to guess what is happening, several hypotheses have been raised. But I have a guess of what is really happening »
When I asked if the person 'usually Hear Music on Your Cell Phone', the intention was to draw attention to the fact that to play 10 different songs do not need 10 devices. A single cell phone is able to play a list of 10 songs.
What the images of the posted Blocks reveal is that the 'source' of each sound is being definitely defined in the Designer. There is no block that tries to change the audio source... and for this to be possible, it means that an undefined number of audio components have been loaded indiscriminately, each one with its own 'source' »
In this June 2014 discussion I found a response from @Hal_Abelson, who says the following »
In just one of the screens posted by @Hima it is possible to realize that 10 different components of Sound were used... »
... and once the file *.aia was not posted and there is mention for Screen8, Screen9, only God knows how many components Sound have been added to this project!
If AI2 Sound resource is implemented to use an individual Android Soundpool, and Android has a hard limit on the number of sound pools that can be open at once in the entire device, the error 703 should be indicating a stack overflow or something thus, at some point... that's why even if there is the same code in the Blocks, at a certain point the playing is interrupted.
If this hypothesis is correct, the problem has nothing to do with the number of screens, the size of the *.mp3s, the MB of the images, the BitRate of the audio files or other theorians that were postulated depending on the reigning uncertainty. The strategy of defining the 'source' of each sound in the Designer was not a good idea, because whatever the number of sounds present in the project, this requires equal number of 'Sound' components, which ends by causing the Error 703 maybe by a stack overflow.
In summary » the short response is what has already been suggested by @Taifun, in his third response »
» It was suggested again in a later response, with examples of the Blocks to be used »
And it was also suggested by me, with a conceptual example of the Blocks, using the Player component and defining the source of each sound at each click event.
What should solve the problem is to remove all Sound components from the Designer, define a single Player component with the 'source' field blank »
And work the code on Blocks so that at each Click Button Event be defined which sound file will be played by the only [Player1] present »
Perhaps, with these instructions, which do not yet show the full project, @Hima can make his project work fine.
Lito
@>-->---
3 Likes
Thank you @Lito for your detective work... I think, @Hal_Abelson would be the one who could answer the question "why are there the 2 components Sound and Player? And would you choose the same decision nowadays to have 2 components for sounds/music?
In the same old thread, @Hal_Abelson said
The issue here is that each App Inventor sound is implemented to use an individual Android SoundPool, and Android has a hard limit on the number of Sound Pools that can be open at once in the entire device (I think 52 per device). So it won't work to have a lot of Sound Components in any single app. If you want to have a lot of sounds, you'll have to implement your app so that there are a small number of Sound components -- maybe only one Sound component -- and switch the Source property to play different notes.
Yes, it's a pity, that @Hima disappeared...
Taifun
2 Likes
Actually I am always alert Taifun.
Just busy with some work.
Hima
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.