On Sun, Aug 10, 2014 at 07:11:24PM +0200, Robin Gareus wrote: > It's not that easy. > Record enable is an application state not a position in time. > Rec-arm needs to allocate buffers, prepare files on disk etc etc. > It's not realtime-safe. That is a weak excuse, and it hides the real reason. Which is that Jack transport does not require apps using it to remain ready to run while stopped, nor provides any means for an app to report 'not ready' until it's too late. If you need to start 'on cue', which is a rather common thing in audio engineering, the present system just fails. Sure, repositioning, creating new tracks or arming some of them for recording involves things that can't be done instantly and that are not RT safe. But a few seconds after a well-designed app is last repositioned or reconfigured it should be ready to start or go into recording mode instantly. And to make this useful at all the app should be able to report its readyness to a shared transport control so that 'one or more not ready' can be shown to the user somehow (typically done by flashing the START button). All that is required is 1. split the 'stopped' state in two: ready or not ready to run as configured, 2. require all apps, while stopped, to do whatever it takes to get ready ASAP when reconfigured and report 'not ready' meanwhile. I've proposed this a number of times over the last years, it was ignored each time. (1) is easy enough to implement, (2) is for application authors, not for the Jack team. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
