Thanks for your help and response... FYI, here's a few bug reports/feature-missing things:
(1) I finally figured out those flashing squares that appear every time gst123 changes songs. It's album-art images, displayed in an X window! These need to stay up longer, as only by forcing the audio device to be busy and playing back a giant directory of files, I was able to actually see that these are windows containing images, and not some weird new display-glitching bug caused by KDE's "Smooth Tasks" widget. To be useful, the display of the image needs to be held for a certain amount of time after you're sure the window-system has actually rendered the image. Perhaps a single integer option --albumart-time -- when set to 0 image display is suppressed, otherwise, an integer like 1000 which would hold the album-art image for 1 second. (And yes, I realize that a fix for this issue is easily had in my script "play-cd" (shorthand for play sound only @ 44.1, vs "play-tv" w/ X/Video @ 48k): | #!/bin/sh | args="`/bin/ls -d $*`" | export DISPLAY='' | exec gst123 -a alsa=mythcd $args ) (2) Sometimes video windows come up at the wrong size (tiny). You can resize them with the window manager and resize it back and get the correct aspect. Or you can quit and run it again and find it sized correctly. (3) Is there a way to create a specific, stable, window-name for the video window created, perhaps settable as commandline parameter. That way for captions, you don't really need to worry about "overwriting" the video with transparent letters like you would on an actual TV caption. Instead, wrap your program in an external program such as Python, or WINTERP (*) that "captures" the video window (much like a window manager would, or how "mplayer" windows are displayed insider wrappers like smplayer kmplayer etc) and parses the time-data-stream information continuously output by gst123. Below the video window you stick a text widget and display caption text independently of the video. There's really no need to overlay and worry about transparency mapping through letters and slowing down the rendering, and all that potential, hardware-dependent fail. Stick the text in a GUI toolkit where all the region and language issues can be handled appropriately... Such tools are happy to update a few times a second to display new captions while X is off rendering the video (or stepping out of the way) in the most efficient, platform-independent manner available. Niels http://nielsmayer.com PS: (*) I just got my old dead opensource project http://nielsmayer.com/winterp/ ( ftp://ftp.x.org/contrib/devel_tools/winterp.lsm ) 99%fully running/ported to the latest Linux/Gcc/X courtesy of PlanetCCRMA having the following packages openmotif-2.3.2-5.1.svn.fc12.ccrma.x86_64 openmotif-devel-2.3.2-5.1.svn.fc12.ccrma.x86_64 ... one of the nice things it provides (and I'm happy i'll no longer need to supply my own version-of) is expect-5.43.0-19.fc12.x86_64 -- a portable way to talk to existing tty-based programs as if they were running it a terminal. Except they're not actually running in a terminal, they're being controlled by a GUI. Probably nothing more than anybody does with Python, or Java, or Ruby, or Perl, or ... these days ... however, for line-based, or s-expression-based results (e.g. multiple lisp or scheme-based systems talking to each other) the asynchronous subprocess facility WINTERP provides is potentially more elegant for the application writer comfortable with putting parentheses before the functor. Anyways, w/o taking up much of my time, I want to put it up on sourceforge, salvage the interesting parts, and see what happens -- at this point as yet another "background" task/distraction. However running code speaks, and this is running code. I'm just happy to have some simple winterp-based utilities back and running again: win-grep ( http://nielsmayer.com/winterp/scrnsnaps/grep-br.gif ) and win-dircmp ( http://nielsmayer.com/winterp/scrnsnaps/dircmp.gif ). And for doing music/midi stuff, the XmGraph widget can't be beat: it's quite awesome in interactive mode, as well as its intelligent graph layout: http://nielsmayer.com/winterp/scrnsnaps/graphcalc.gif http://nielsmayer.com/winterp/scrnsnaps/grph-whier.gif ( http://nielsmayer.com/winterp/examples/grph-whier.lsp ) http://nielsmayer.com/wwweasel/node24.htm ). ANd lets not forget WINTERP's path-based-"animation" facilities to make arbitrary interactive controllers and displays (beyond what a prebuilt "widget' might provide) that move smoothly with built-in double-buffering: http://nielsmayer.com/winterp/scrnsnaps/xtango/hanoi.gif http://nielsmayer.com/winterp/scrnsnaps/xtango/test-dial.gif http://nielsmayer.com/winterp/scrnsnaps/xtango/test-gauge.gif http://nielsmayer.com/winterp/scrnsnaps/xtango/test-knob.gif ... FYI, this is all it takes to talk to an asynchronous subprocess -- such as running&controlling gst123 ... http://nielsmayer.com/winterp/examples/subcalc.lsp (simple UI to run "bc" as an asynchronous subprocess, to perform, for example, infinite precision and size arithmetic as a "background process"): (setq subproc-pty (exp_spawn "bc" "bc")) ;create subprocess, the bc(1) calculator (setq subproc-pid (exp_get_pid)) (setq input-cb (xt_add_input ;XtAppAddInput() subproc-pty :READ_LINE_TO_STRING '(;; READ_LINE_TO_STRING fires callback once per line, binding line to FDINPUTCB_STRING (send list-w :add_item FDINPUTCB_STRING 0) ;XmListAddItem() (send list-w :set_bottom_pos 0) ;XmListSetBottomPos() ) )) _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev