Re: Summer of Code

["Ahmed Ghoneim" <ahmed dot ghoneim at gmail dot com>]

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