Sorry your browser is not supported!

I've got an idea! Run with me on this:

A standard music media player plays whatever files or streaming you have access to. You select what you want to listen to (or hit shuffle), and the player plays it. Most media players have a playlist feature where you can throw different songs together to play in a certain order (or again, hit shuffle on it). Basically, a media player only plays what you tell it to play when you tell it to play it.

But what I want to create is a media player that simulates FM radio. I've got 1000+ mp3 music files (and I often find myself spoiled for choice). So I want to arrange them into "stations" such as a country station, alternative, metal, Celtic, classical, soft rock, pop, you get the idea. I haven't actually put pen to paper on the design of this thing, but my idea is to get the program to select several songs from several genres and play them simultaneously. But turn the volume on all of them to 0 except for whatever "station" I'm "tuned" into. Whenever a song ends, whether I'm actually listening to it or not, it simply selects another song from the same genre and starts it. I'm free to jump from station to station whenever I want, but there's always that element of surprise that "oh, I haven't heard this song in a while" and also no commercials or annoying DJs.

So I've got two questions:
1. Is there a limit on how many audio files can be playing at once. Yes, I can just experiment to find this out, but what I really want to ask is...

2. Does anyone know, or has anyone experimented with the performance load something like this can have on an Android system? I've browsed the tutorials and the command library. Sometimes I'll see little tips on conserving resources on a mobile system. Things like how cutting down the frame rate and limiting the number of arrays will conserve battery life. But I don't think I've seen any tips regarding audio commands. Any ideas?

Rather than playing multiple music files at once, you could generate random playlists for all channels, get the duration of each music file with GetMusicDuration(), store the file ID and start and end time for that file in the playlist array for that station. Something like this:



When entering playlist, loop through until rockPlayAtSeconds >= RockStationFileAttributes[arrayIndex, 1] and rockPlayAtSeconds < RockStationFileAttributes[arrayIndex, 2]

You would most likely have to store a file with track info like duration. This example is using AppGameKit Classic, don't know if AppGameKit Studio still has music commands as they are deprecated. So you would have to make a program that loads each individual track and checks duration then storing the filename and duration. You can only have 50 music files in memory, so you couldn't load all at once anyway. You can use SeekMusic() absolute mode to start the track at desired seconds when loaded in.

Very interesting. (Sorry, I've been real busy lately. Haven't had time to come around the forum.) I have actually made a working prototype. Right now the app has two functions: the actual "radio" function and a "reset" function. When the program first starts up it's literally just two buttons, one for each. When you hit the reset button, the program goes into a predetermined directory, raw:/sdcard/Music/radio or thereabouts (I've already forgotten the specifics, it was frying my brain so much to write this thing) and there would be a folder for every station I wanted. The names of these folders would become the names of the stations. From there it would go into each station folder and count how many "band" folders were in it. The purpose of each band having their own folder was that the program would scan how many songs were from each band, determine which band had the most songs, and gradually shuffle in the songs from other bands into a list of songs for any given station. That way you were more likely to hear songs from different bands as the station played on. Each playlist was then saved to a text file as a list, each line being the absolute path to the next song.

The actual radio function, after the reset function was completed, operated on its own text file that kept track of where all these playlists left off from the last time the program was closed. That way if I had a station with a hundred songs, it wouldn't always start from the first song making it so I would never hear the later songs. The station always began on a different part of the playlist. From there, the program generated a virtual button for each station and killed the volume on all of them until I pressed one.

For me, this is going to be an ongoing project. The idea is actually more complicated than what I've described here. But what I have right now WORKS! But yeah, I'll look more into what you've sampled for me. Perhaps it will help me moving forward. I do want to thank you for taking the time to answer my post, Cybermind.

A • Yes. Audio Processors have a finite number of Voices (Sound Samples) that can be played simultaneously.
This will typically be between 128 - 512 Voices.
Virtual Voices can extend what the Hardware is capable of by Virtually Processing and Pre-Mixing to a Hardware Voice for your Audio Processor., but keep in mind these are done via the CPU and the MORE of these you use; the less CPU Processor Time you have for the rest of your application / system.



A • In general Audio can be quite Memory and Processing Intensive.
Something you might be surprised at is, it's possible to simply have a Handle open to an Audio File., as well as having a Memblock that can hold say 1 Second of Audio Data; and do this in Real-Time, without a particularly big performance hit.
This results in the Memory Usage remaining VERY Low... at most say 1-2MB., but beyond this Streaming allows you to do something else; Seamless Transitioning.
If you were saying playing "Song 1" and then clicked to play "Song 2"... well, there is no need to create a new Buffer (Memblock); rather, all that is needed is to open a new File Handler to said next Song; then you're just switching which you're populating the Memblock from.

In this regard you're never "Loading" the Audio per se., so you don't have to wait for it to decompress, store and open a new voice for said Audio; instead, you always have a Voice Active that is populating from the data of the Open Files.

"Between 128 - 512 voices"
Yeah, I'm definitely not going that far with it. I might be playing 20 at the most, tops.

I've been working on this thing for a couple weeks and I've got a good prototype going. It currently has 12 "stations". It doesn't appear to be very intensive on the phone/operating system. According to my phone's settings menu, my app only pulls 2% battery power while my old media player (that I'm also still using) pulls 3%. The only minor issue I've observed in my program is that while listening to a song there are little "hiccups" every now and again. The sound will cut out for a fraction of a second, about as long as it would take you to snap your fingers. Very quick, but definitely noticeable. I assumed it was another station starting another song and perhaps the app was overwhelmed for just that fraction of a second while clearing some memory and filling it back up. "Inconvenience" would be an overstatement. Otherwise, I'm extremely happy with my work.

Educate me though (Raven): I'm interested in some of the things you're saying. I fully intend to build on this program further and maybe you can help steer me in a different, better direction.

1. Define "handle" to an audio file. You capitalize it as if it's a proper programming/operating system term.
2. Define "memblock" in your own words. I'm vaguely familiar with the term. I'm still a little new to AppGameKit, but I'm coming from DarkBASIC and occasionally encountered it, though it never seemed to be applicable in any program I was ever making. It seemed to mean something along the lines of a variable that could be transferred over a network.