Menu
▾
▴
libvisual-devel
|
From: Gustavo S. B. <gu...@gs...> - 2004-07-13 01:13:31
|
Hello,
I've commited a new input plugin: mplayer. It can use data exported by mplayer
audio filter "export" (mplayer -af export).
After 3 commits (sorry! I'm really distracted today) it's stable.
I also did small changes to esd and alsa. The focus was to ensure pointers
were not null and to use visual_log() instead of fprintf().
Any comments?
PS: There is a way to get input plugin parameters? I'll need that.
Here is the first revision with a bit more explanation:
revision 1.1
date: 2004/07/12 23:51:12; author: gsbarbieri; state: Exp;
Added mplayer input plugin.
Background:
Mplayer has an export filter which export it's buffer to a file
using mmap().
TODO:
* Implement option to change shared file. Current implementation
uses default mplayer value (~/.mplayer/mplayer-af_export)
* Support different number of channels (current is fixed to 2),
different buffer size (current is 512 samples) and different
format (current is 16bits signed).
BUGS:
* Some mplayer audio output system changes the rate mplayer calls
its export filter, leading to low update rate. Know problematic
output system: esd. Know to work right: alsa, oss. This is not
a big issue since you can use libvisual own esd input plugin and
get it right. NOTE: This is a mplayer bug.
=============================================================================
--
Gustavo Sverzut Barbieri
---------------------------------------
Engenharia de Computacao 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: gsb...@ja...
ICQ#: 17249123
GPG: 0xB640E1A2 @ wwwkeys.pgp.net
|
|
From: Dennis S. <sy...@yo...> - 2004-07-13 16:29:07
|
On Mon, 2004-07-12 at 22:13 -0300, Gustavo Sverzut Barbieri wrote: > Hello, > > I've commited a new input plugin: mplayer. It can use data exported by mplayer > audio filter "export" (mplayer -af export). > > After 3 commits (sorry! I'm really distracted today) it's stable. > > I also did small changes to esd and alsa. The focus was to ensure pointers > were not null and to use visual_log() instead of fprintf(). > > Any comments? > > PS: There is a way to get input plugin parameters? I'll need that. Hello, Thanks a LOT for commiting your mplayer plugin and for replacing the fprintfs with visual_logs! However you've forgotten to update the ChangeLog file, please do update it ! :) Plugin parameters is being worked out, but the lack of time is slowing me down. But it'll be there soon! Btw, please don't do too much NULL checking within the plugins. If someone goes wrong all down at this layer something is majorly borked within libvisual itself or the user is creating hacky code. The abstraction system, VisInput, VisMorph, VisActor do handle most of the situations. Thanks anyway ;) Cheers, Dennis > > > Here is the first revision with a bit more explanation: > > revision 1.1 > date: 2004/07/12 23:51:12; author: gsbarbieri; state: Exp; > Added mplayer input plugin. > > Background: > Mplayer has an export filter which export it's buffer to a file > using mmap(). > > TODO: > * Implement option to change shared file. Current implementation > uses default mplayer value (~/.mplayer/mplayer-af_export) > * Support different number of channels (current is fixed to 2), > different buffer size (current is 512 samples) and different > format (current is 16bits signed). > > BUGS: > * Some mplayer audio output system changes the rate mplayer calls > its export filter, leading to low update rate. Know problematic > output system: esd. Know to work right: alsa, oss. This is not > a big issue since you can use libvisual own esd input plugin and > get it right. NOTE: This is a mplayer bug. > ============================================================================= > > |
|
From: Gustavo S. B. <gu...@gs...> - 2004-07-13 17:24:19
|
Em Tuesday 13 July 2004 13:28, Dennis Smit escreveu: > On Mon, 2004-07-12 at 22:13 -0300, Gustavo Sverzut Barbieri wrote: > > Hello, > > > > I've commited a new input plugin: mplayer. It can use data exported by > > mplayer audio filter "export" (mplayer -af export). > > > > After 3 commits (sorry! I'm really distracted today) it's stable. > > > > I also did small changes to esd and alsa. The focus was to ensure > > pointers were not null and to use visual_log() instead of fprintf(). > > > > Any comments? > > > > PS: There is a way to get input plugin parameters? I'll need that. > > Hello, > > Thanks a LOT for commiting your mplayer plugin and for replacing the > fprintfs with visual_logs! > > However you've forgotten to update the ChangeLog file, please do update > it ! :) Done! > Plugin parameters is being worked out, but the lack of time is slowing > me down. But it'll be there soon! Ok. > Btw, please don't do too much NULL checking within the plugins. If > someone goes wrong all down at this layer something is majorly borked > within libvisual itself or the user is creating hacky code. The > abstraction system, VisInput, VisMorph, VisActor do handle most of the > situations. Thanks anyway ;) That's why I always do NULL checking, to know if there's something wrong. If everbody code it right we are not humans... so errors may appear and better catch them as soon as possible. Since most of segfaults are caused by null pointers I think worth checking for them always... -- Gustavo Sverzut Barbieri --------------------------------------- Engenharia de Computacao 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: gsb...@ja... ICQ#: 17249123 GPG: 0xB640E1A2 @ wwwkeys.pgp.net |
|
From: Dennis S. <sy...@yo...> - 2004-07-14 15:07:57
|
> > Btw, please don't do too much NULL checking within the plugins. If > > someone goes wrong all down at this layer something is majorly borked > > within libvisual itself or the user is creating hacky code. The > > abstraction system, VisInput, VisMorph, VisActor do handle most of the > > situations. Thanks anyway ;) > > That's why I always do NULL checking, to know if there's something wrong. If > everbody code it right we are not humans... so errors may appear and better > catch them as soon as possible. > > Since most of segfaults are caused by null pointers I think worth checking for > them always... Well it's ok with me, but I always used a kinda 'don't do too much check at the low level' because at that layer it should JUST WORK or die hard (and be reported) *hehe*. But then again, it's ok with me! Cheers, Dennis |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X