Menu
▾
▴
libvisual-devel
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-05 08:36:07
Attachments:
libvisual-alsa.patch
|
Hello! Here is a small hacky ALSA capture plugin for libvisual. Have no idea if it will work but it works for me with alsa-lib 1.0.5, recording source set to "Mix" i.e. everything that goes through codec. Tested applications: madplay and mplayer. You may test it and if it works, you're lucky :) Please note I am not ALSA programmer and can not provide much support if something goes wrong... -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 15:38:12
|
Vitaly this is super cool! Thanks a lot I tried writing an ALSA plugin before but gave up after failing twice *shame* :) Thanks a lot for this. I've put the ALSA plugin into CVS, it has some small issues and I'll look into that! But overall this is just superB! How is your scivi openGL plugin going nowadays and what have you been up to ? Cheers, Dennis On Mon, 2004-07-05 at 11:35 +0300, Vitaly V. Bursov wrote: > Hello! > > Here is a small hacky ALSA capture plugin for libvisual. Have no idea > if it will work but it works for me with alsa-lib 1.0.5, recording > source set to "Mix" i.e. everything that goes through codec. > Tested applications: madplay and mplayer. > > You may test it and if it works, you're lucky :) Please note I am > not ALSA programmer and can not provide much support if something > goes wrong... > |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 19:55:40
|
Vitaly, If you have some time could you look into the following: at: http://libvisual.sourceforge.net/LIBVISUAL_TODO * Fixes in some GL plugins that show odd behavior after another GL plugin has been running (better state setting). (everyone!!!) This is tiresome to debug but some GL plugins show up really odd after another had run before (in the same execution) using plugin switches. This is probably easier to monitor when you adapt the xmms plugin to only show GL plugins and show them randomly... My knowledge about GL is (still) very limited (I'm planning to read the openGL red book when I'm on vacation!) :) And I'm kinda unable to really solve this easily. Thanks, Dennis |
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-05 21:20:04
|
On Mon, 05 Jul 2004 21:54:47 +0200 Dennis Smit <sy...@yo...> wrote: > > Vitaly, > > If you have some time could you look into the following: > at: http://libvisual.sourceforge.net/LIBVISUAL_TODO > > * Fixes in some GL plugins that show odd behavior after another GL > plugin has been running (better state setting). (everyone!!!) Yes, I've already seen this, tried to reproduce this and failed. And I thought it was fixed... > This is tiresome to debug but some GL plugins show up really odd > after another had run before (in the same execution) using > plugin switches. This is probably easier to monitor when you > adapt the xmms plugin to only show GL plugins and show them > randomly... Now I see. :) Indeed, this is due to settings left by prev. plugin. Even worse, If a plugin allocates, say, a (large ;) texture and does not release it during cleanup, texture will still reside in video memory. Just like with madspin plugin: there is glGenTextures() call and no glDeleteTextures(). The same will be with other data like lists. Looks like the only way to reset it nicely (everything is set to defaults in any condition on any hw/sw) is to delete GL context and create a new one. And here goes a problem with SDL. To make it work right now, you can destroy and create whole window or render surface in SDL words. This is a bad behavior... Each plugin change (well, gl-to-gl at least) the window will be recreated. Another way to solve this problem is to use CVS version of SDL in 1.3 branch. Pros and cons are pretty obvious. Does anybody know then 1.3.0 will be released??? And the last way -- get rid of SDL and write everything ourselves or rip off some code from Scivi ;), get potrability problems and rewrite everythin to SDL back again when it will be released.. Dennis, I really don't know what to do with it... :) -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-07-05 21:36:51
|
On Tue, 2004-07-06 at 00:02 +0300, Vitaly V. Bursov wrote: > On Mon, 05 Jul 2004 21:54:47 +0200 > Dennis Smit <sy...@yo...> wrote: > > > > > Vitaly, > > > > If you have some time could you look into the following: > > at: http://libvisual.sourceforge.net/LIBVISUAL_TODO > > > > * Fixes in some GL plugins that show odd behavior after another GL > > plugin has been running (better state setting). (everyone!!!) > Yes, I've already seen this, tried to reproduce this and failed. > And I thought it was fixed... > > > This is tiresome to debug but some GL plugins show up really odd > > after another had run before (in the same execution) using > > plugin switches. This is probably easier to monitor when you > > adapt the xmms plugin to only show GL plugins and show them > > randomly... > Now I see. :) Indeed, this is due to settings left by prev. plugin. > > Even worse, If a plugin allocates, say, a (large ;) texture and does > not release it during cleanup, texture will still reside in video > memory. Just like with madspin plugin: there is glGenTextures() > call and no glDeleteTextures(). The same will be with other data > like lists. Would you mind to clean this kind of things up anyway if I gave you CVS access to libvisual CVS ? > Looks like the only way to reset it nicely (everything is set to > defaults in any condition on any hw/sw) is to delete GL context > and create a new one. > > And here goes a problem with SDL. To make it work right now, > you can destroy and create whole window or render surface in > SDL words. This is a bad behavior... Each plugin change (well, > gl-to-gl at least) the window will be recreated. Yeah that is totally bummer, but if that is the only way for now... > Another way to solve this problem is to use CVS version of SDL > in 1.3 branch. Pros and cons are pretty obvious. Does > anybody know then 1.3.0 will be released??? For libvisual-xmms we can't use SDL 1.3. SDL 1.3 is a must tho if it's not just only because off the offscreen buffers... > And the last way -- get rid of SDL and write everything ourselves > or rip off some code from Scivi ;), get potrability problems and > rewrite everythin to SDL back again when it will be released.. HEhe... > Dennis, I really don't know what to do with it... :) Alright, thanks a lot tho for the comment, it really cleared things up! Cheers, Dennis |
|
From: Vitaly V. B. <vit...@uk...> - 2004-07-06 00:18:55
|
On Mon, 05 Jul 2004 23:36:33 +0200 Dennis Smit <sy...@yo...> wrote: > On Tue, 2004-07-06 at 00:02 +0300, Vitaly V. Bursov wrote: > > On Mon, 05 Jul 2004 21:54:47 +0200 > > Dennis Smit <sy...@yo...> wrote: > > > > > > > > Vitaly, > > > > > > If you have some time could you look into the following: > > > at: http://libvisual.sourceforge.net/LIBVISUAL_TODO > > > > > > * Fixes in some GL plugins that show odd behavior after another GL > > > plugin has been running (better state setting). (everyone!!!) > > Yes, I've already seen this, tried to reproduce this and failed. > > And I thought it was fixed... > > > > > This is tiresome to debug but some GL plugins show up really odd > > > after another had run before (in the same execution) using > > > plugin switches. This is probably easier to monitor when you > > > adapt the xmms plugin to only show GL plugins and show them > > > randomly... > > Now I see. :) Indeed, this is due to settings left by prev. plugin. > > > > Even worse, If a plugin allocates, say, a (large ;) texture and does > > not release it during cleanup, texture will still reside in video > > memory. Just like with madspin plugin: there is glGenTextures() > > call and no glDeleteTextures(). The same will be with other data > > like lists. > > Would you mind to clean this kind of things up anyway if I gave > you CVS access to libvisual CVS ? Sure. SF's anon cvs isn't working again.... My SF login: vitalyvb > > Looks like the only way to reset it nicely (everything is set to > > defaults in any condition on any hw/sw) is to delete GL context > > and create a new one. > > > > And here goes a problem with SDL. To make it work right now, > > you can destroy and create whole window or render surface in > > SDL words. This is a bad behavior... Each plugin change (well, > > gl-to-gl at least) the window will be recreated. > > Yeah that is totally bummer, but if that is the only way for now... glPush* / glPop functions can also be used but it will have slight side effect like making stacks 1-entry shorter. And I am not sure if everything can be saved/restored.. > > Another way to solve this problem is to use CVS version of SDL > > in 1.3 branch. Pros and cons are pretty obvious. Does > > anybody know then 1.3.0 will be released??? > > For libvisual-xmms we can't use SDL 1.3. SDL 1.3 is a must tho if it's > not just only because off the offscreen buffers... Hmm.... I was wrong. Current CVS version won't help here. They do not create more contexts... /* * Create a render target with the given size and attributes. ... * Currently this function does not create a new OpenGL context. ... */ extern DECLSPEC SDL_RenderTarget * SDLCALL SDL_GL_CreateRenderTarget ... > Alright, thanks a lot tho for the comment, it really cleared > things up! My pleasure :) -- Vitaly GPG Key ID: F95A23B9 |
×
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