On 26/9/20 7:35 am, Alan Corey wrote: > What I had in mind was to make Audacity have a hook to call an > external program each time it updates the screen. Then call > something like xwd from the hook and put the frames together later. > No sound that way though, you'd have to mix in the audio file that > Audacity is playing/displaying. xwd can do screen dumps of a specific > window id, which Audacity would have access to since it owns it. Yeah, the best place to ask about that would be the Audacity lists themselves. My understanding is that Audacity does not use ALSA directly: it uses `portaudio` which can use ALSA as a back-end (among others). So the audio interface is already abstracted. AFAIK `portaudio` communicates with ALSA via a thread which would then be communicating progress information back to the main thread running their UI (`wxWidgets`-based). Doing a `fork()` then `exec()` could be quite expensive at the sort of rates they may be repainting the screen at. This is quite a niché application too… which is why "some assembly" may be required. The question then is, how often is this being done? If it's a once-off, use `ffmpeg` with carefully positioned windows and be done with it. Otherwise, it might be worth exploring solutions like `gstreamer`'s visualisation plug-ins to achieve what you're after. https://xkcd.com/1205/ -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
