Subject: Thanks (and a few minor gripes)
Author: chrget, 2005-03-26 08:24:34
Hello,
just stumbled across lamip yesterday while (once again) searching for a small (but sweet) audio player for possible use on my Sharp Zaurus. Did a quick eval on my desktop, was _very_ pleasantly surprised and decided to dive in head first and build a version to run on the StrongARM -- well, whaddaya know, it works as well, albeit with a little tweaking here and there.
What was a little annoying was the fact that in several cases the plugins were not aware that they should be using the fixed-point versions of the respective libraries (uhm, speex, vorbis and a52dec, I think it was -- possibly adding a --with-fixed-point option to the configure would be nice). In one case there were variable declarations in the middle of a code block, something a gcc < ver3 (yes, these are still used in the embedded world ;) ) doesn't really like.
The use of executables to determine include- and librarypaths is somewhat tricky when cross-compiling, so it would be nice if that could be done without.
And then there's some of the prerequisites I am ... well, a little unhappy about. Since lamip is such an excellent, small and beautiful piece of software, using huge C++ libraries is somewhat annoying. In particular I'm talking about the use of id3lib in the mp3 plugin and libmp4v2 in the mp4 plugin. Both of them are fairly huge monsters, which inflate the resulting plugins to really ugly sizes.
Sice you're already using libmad for mp3 decoding, any particular reason why you're not using libid3tag from the same source or something similarly small (and C)? The same goes for using libmp4v2, why not use libmp4ff that already comes with FAAD2? Granted, it's not as full-featured as libmp4v2, but should do well enough with typical MPEG-4 files.
And then there's the case of the AC3 input plugin that seems to make some serious assumptions about the files it decodes when it comes to sampling rate and number of channels (possibly)? I guess that's probably known and was just a quick hack to get things up and running.
One more thing that might prove nice would be to modularize the data sources as well -- move the access to file, the current libcurl-based network access out of the main program and into a plugin, to make that extendable as well. That way, e.g. an RTSP plugin could be added, or any other access methods that people could think of.
All in all, I'm rather taken with lamip. It is _exactly_ the kind of thing I was looking for. Keep up the good work and, most of all, try to avoid the creeping featuritis that has befallen so many of the other projects.
Thanks again!
Best regards,
Chris.
just stumbled across lamip yesterday while (once again) searching for a small (but sweet) audio player for possible use on my Sharp Zaurus. Did a quick eval on my desktop, was _very_ pleasantly surprised and decided to dive in head first and build a version to run on the StrongARM -- well, whaddaya know, it works as well, albeit with a little tweaking here and there.
What was a little annoying was the fact that in several cases the plugins were not aware that they should be using the fixed-point versions of the respective libraries (uhm, speex, vorbis and a52dec, I think it was -- possibly adding a --with-fixed-point option to the configure would be nice). In one case there were variable declarations in the middle of a code block, something a gcc < ver3 (yes, these are still used in the embedded world ;) ) doesn't really like.
The use of executables to determine include- and librarypaths is somewhat tricky when cross-compiling, so it would be nice if that could be done without.
And then there's some of the prerequisites I am ... well, a little unhappy about. Since lamip is such an excellent, small and beautiful piece of software, using huge C++ libraries is somewhat annoying. In particular I'm talking about the use of id3lib in the mp3 plugin and libmp4v2 in the mp4 plugin. Both of them are fairly huge monsters, which inflate the resulting plugins to really ugly sizes.
Sice you're already using libmad for mp3 decoding, any particular reason why you're not using libid3tag from the same source or something similarly small (and C)? The same goes for using libmp4v2, why not use libmp4ff that already comes with FAAD2? Granted, it's not as full-featured as libmp4v2, but should do well enough with typical MPEG-4 files.
And then there's the case of the AC3 input plugin that seems to make some serious assumptions about the files it decodes when it comes to sampling rate and number of channels (possibly)? I guess that's probably known and was just a quick hack to get things up and running.
One more thing that might prove nice would be to modularize the data sources as well -- move the access to file, the current libcurl-based network access out of the main program and into a plugin, to make that extendable as well. That way, e.g. an RTSP plugin could be added, or any other access methods that people could think of.
All in all, I'm rather taken with lamip. It is _exactly_ the kind of thing I was looking for. Keep up the good work and, most of all, try to avoid the creeping featuritis that has befallen so many of the other projects.
Thanks again!
Best regards,
Chris.
Replies
Author: ciberfred, 2005-03-26 12:22:50
Hi Chris.
Thanks for your message. If you want send me by email things that need to be changes in sources codes, don't wait :). And yes sources code with some declarations in middle of the code still pending..
Well now about additionnal libs.
For the mp3 plugin i use id3lib because there is only this lib when i create the plugin :), if you want add support for the id3lib from the mad project for this plugin you're welcome.
For the mp4 plugin well same thing. menno (the maintener of faad2) create mp4ff but this lib could only build in static instead of dynamic.
For others plugin you should talk a little with people that dev it (speex come from olv and ac3 from geekoe, if i remember right).
about cross-compiling. Well i think of how to give to the plugin dev people the way to retreive CFLAGS and LDFLAGS specific to lamip, and well include all of this in one file is that i think is better. Also cross-compiling is a thing that i don't think at start. Any idea how to improve this with keep it simple way ?
And well time to speak about the reading part. for moment like the channel mapping it's include in the core of lamip instead of extracted in a plugin. Also adding support for rtsp transport is really easy if you look into the src/util_url.c file in the core. I stay in the core because there is not som much 'transport' that really need creating a plugin for this. (hum maybe some samba/nfs or whatever transport could be also created but well there is actually not so much people that need this 'feature' and i prefere to concentrate on the audio part and in the ui instead of the transport one for moment. just a choice because we are not so much to code on lamip.
ciberfred
Thanks for your message. If you want send me by email things that need to be changes in sources codes, don't wait :). And yes sources code with some declarations in middle of the code still pending..
Well now about additionnal libs.
For the mp3 plugin i use id3lib because there is only this lib when i create the plugin :), if you want add support for the id3lib from the mad project for this plugin you're welcome.
For the mp4 plugin well same thing. menno (the maintener of faad2) create mp4ff but this lib could only build in static instead of dynamic.
For others plugin you should talk a little with people that dev it (speex come from olv and ac3 from geekoe, if i remember right).
about cross-compiling. Well i think of how to give to the plugin dev people the way to retreive CFLAGS and LDFLAGS specific to lamip, and well include all of this in one file is that i think is better. Also cross-compiling is a thing that i don't think at start. Any idea how to improve this with keep it simple way ?
And well time to speak about the reading part. for moment like the channel mapping it's include in the core of lamip instead of extracted in a plugin. Also adding support for rtsp transport is really easy if you look into the src/util_url.c file in the core. I stay in the core because there is not som much 'transport' that really need creating a plugin for this. (hum maybe some samba/nfs or whatever transport could be also created but well there is actually not so much people that need this 'feature' and i prefere to concentrate on the audio part and in the ui instead of the transport one for moment. just a choice because we are not so much to code on lamip.
ciberfred
Author: geekoe, 2005-03-28 01:32:52
hi Chris!
the AC3 plugin will get a major overhaul when we have extracted channel mapping into a plugin... I will leave out the channels option from the config file for example... haven't read that forum topic yesterday... otherwise I would have talked to you on IRC about that :)
"All in all, I'm rather taken with lamip. It is _exactly_ the kind of thing I was looking for. Keep up the good work and, most of all, try to avoid the creeping featuritis that has befallen so many of the other projects. "
This is exactly the same reason why I have decided to code some things :)
apropos featuritis and libid3: what do you think of reading tags (most common tags... like id3, ape, vorbis tags,...) in the core? I am still thinking of writing a library which reads all tags and does only a fallback to the input plugin when something failed... that would save some time to write functions reading the same tag format in different plugins.... Originally the idea was to have a lamipSonginfo struct in the effect api to read the Replay Gain informations... well... we should talk about that! It definitely is concerning machines which run with low resources...
regards
geekoe
the AC3 plugin will get a major overhaul when we have extracted channel mapping into a plugin... I will leave out the channels option from the config file for example... haven't read that forum topic yesterday... otherwise I would have talked to you on IRC about that :)
"All in all, I'm rather taken with lamip. It is _exactly_ the kind of thing I was looking for. Keep up the good work and, most of all, try to avoid the creeping featuritis that has befallen so many of the other projects. "
This is exactly the same reason why I have decided to code some things :)
apropos featuritis and libid3: what do you think of reading tags (most common tags... like id3, ape, vorbis tags,...) in the core? I am still thinking of writing a library which reads all tags and does only a fallback to the input plugin when something failed... that would save some time to write functions reading the same tag format in different plugins.... Originally the idea was to have a lamipSonginfo struct in the effect api to read the Replay Gain informations... well... we should talk about that! It definitely is concerning machines which run with low resources...
regards
geekoe
Author: from website ., 2006-08-02 10:55:31
funny ringtones
Author: ciberfred, 2006-08-02 22:48:28
well the 0.0.4 will fix these major warnings/error for a such purpose i hope. will need some tests..