[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summer of Code

Salam, Ahmed,
I just assume you are refering to me in your below paragraph. FYI, i
have not been programming C in a very long time (except for a very
simple program). I do program in a higher level languages, such as C#,
Javascript and Perl. With that in mind, here goes. Let me break the
issues into several topics.

1. 1 file per ayah
To me, this is a major barrier if we would like other people to
contribute to the project (in terms of audio - assuming we are
expecting people to contribute, otherwise, it would be a different
story). Even if people will not contribute, it will make them very
difficult to have their own audio preference. For example, some famous
qaris (don't have tpo mention name here) are well known to recite
continously for several verse. This will make it almost impossible to
support in current libquran design. In my application, i just store
the following information about the audio (for each ayah): filename,
start time, end time. For continuus ayah, i just put -1 in the
start/end time. Then, the application will have to know how to handle
it. Users can create their own data file for the audio, so they can
listen to their favourite qaris.

2. Portability
I'm curious, is the current library portable enough to be ported to
platform other than *nix?

3. Audio support in the Library
My opinion is, not to have build in support in the library. It should
be able to handle the data about the audio, as mentioned in no 1.
Playing the audio will be up to the application. I think this will
make the library more portable. The application may not be that
portable, since we need to create application for our target platform
ie KDE, GNOME, Ms Win* etc. Application can use whatever method easier
to it (using libspeex/libogg, gstreamer, karts,directx, or even using
component model like bonobo,kparts or COM - I use media player to play
the audio). By having something like this, the application can be
created using higher level languages by glueing multiple technologies
at the same time. We don't have to wait for libquran to support
protected wma file format - just ask media player to do it.

So, that is my view on the library. It should be simple and portable,
then more people will be using it. I think because the library itself
is tied to certain technologies, it forces application developer to
rewrite the library. You can look at the related project; jquran and
c#. Both application does not use the library at all; they just use
the data files. As for me, right now my application does not use
anything from the project, even though I try my best to make it
compatible to it.

Regards.


On 3/13/07, Ahmed Ghoneim <ahmed dot ghoneim at gmail dot com> wrote: 
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
Developer at arabeyes dot org
http://lists.arabeyes.org/mailman/listinfo/developer