>>the only problem i see is that the port can only serve one "view" of >>the file at a time. if you wanted to play two copies of the same >>sound, but offset from one another, you'd need different copies of the >>same client. JACK doesn't scale well for this kind of thing, so .... > >That's probally something that would be pretty common. > >>LADSPA! >> >>pretty well. it would basically be like taking the disk streaming code >>from ardour, removing the transport dependent stuff from it (which is >>a large part of it), and packaging it as a LADSPA plugin. > >What's your ballpark estimate on what kind of effort this would be? >That looks like the way to start since you probally have solved most >of the issues that would come up.
I think I could write a reasonably working example in 2 days if I had a day to think about it first. Ardour has sample code, as does ecasound, alsaplayer and a few other programs that do threaded-disk i/o. The tricky part is to use that stuff in a thread that services every instance of the plugin, rather than one thread per instance. there is, however, a really tricky problem with doing this in LADSPA: there is no support for string variables, so there is no way to set the filename to be used. --p
