S3,
> >> We could do in more lower level than the current libquran. Let it just > >> return the audio data along with it's mime type (it could be mp3, > >> speex, or anything). The playing of the audio is the responsibility of > >> the frontend, not libquran's.
IMHO the current approach is better, playing/rendering the audio is of course the responsibility of the frontend , but the library should provide a standard interface and be consistent with regards to the type of data it returns. right now the PCM buffer is excellent, any kind of frontend should be able to hanlde it, plus it lowers the barrier to entry for new frontends (read easier to develop). And most importantly, we could always change the encoding/format of data without requiring *huge* changes to the clients, merely a recompile against the new lib. This is an area that i think don't any fragmentation. One Text, One Audio format.
> >> In this way, people could use libquran also when they don't need the > >> audio data. Today they should have libspeex in order to compile. > >> > > > >Nice idea, so that we needn't force an install of the audio data.
Right now the *don't* need the audio data to run, you could run it just fine without it. You do need the libspeex plus libogg though, but thats a no biggie, it's almost standard on *nix and it's only a couple of dll on win32
> Last time, i suggested something like this to M Yousif. It would be > better to be more flexible. I suggested to use something like > gstreamer or karts for audio handling, so that we don't have to worry > about supporting every audio type exist. That would be gstreamer's > job. Another thing that is not flexible in current audio handling is > the requirement of 1 file per ayah. the approach that I took for my > web application was we only store certain information about the audio. > Info that we need (in the library) are for every ayah, where is the > audio file, it's start time and it's end time. Then it is up to the > application to play it. I've uploaded the application, but I need to > fixe a few things before announcing it. I don't know why M Yousif didn't like the idea bit IMHO, gstreamer will increase the dependencies of libquran which something I personally don't like.
I concur, gstreamer would me make life very difficult for people porting libquran to win32 i.e. me. please give some thought to the cross-platform-ness of this. while gstreamer is almost native to *nix and gnome, it's a pain in the neck to run under win32, and no cygwin is out of the question, when i say win32 i mean *native* win32, that is Mingw, right now the current scheme speex/ogg works perfect under win32 with Mingw
I guess your approach in handling the audio files seems better.
again, if the current scheme stays, the libquran passes PCM buffer, so the frontend does not know/care if it's from a single file or from a position within a larger one. but i would guess it would make creating audio sets harder for volunteers, but then again i don't have much experience creating them. could you please provide more info on your solution? Thanks to all, Ahmed Ghoneim
_______________________________________________ Developer mailing list [email protected] http://lists.arabeyes.org/mailman/listinfo/developer
