Olivier Guilyardi <ml(a)xung.org> writes: No. That callback has never been implemented and may very likely be removed from the interface. -- joq

Hi Tom, Tom Szilagyi wrote: Thanks for pointing that third option : - convert in the disk thread I'll try and check that out when I'm about to add support for streaming from disk. I ain't that pathologic for a sequencer/drummachine as my application Jackbeat (http://xung.org/jackbeat), where sound files are often small ones. But I want to add configurable support for disk-streaming at some point in the future. For now, loading the sample into memory is a simple and efficient method, which AFAIK is pretty common in trackers, for example. Additionally, because Jackbeat is supposed to support an unlimited number of tracks, it may be required to stream many (16,32,64,..) sound files from disk in parallel, which is not very smart either. The main reason I was afraid of putting the sample rate conversion routines in the realtime Jack thread is CPU load : the best quality libsamplerate converter is pretty heavy. Imagine that with 32 tracks... Now, I could add an option like "Which libsamplerate's converter do you want to use ?", so that people can tweak it according to their CPU power. However, IMHO, converting when loading the sample has the advantage to allow slow CPUs to use the best converter. Currently "loading" means allocating memory, but that could also mean creating temporary files, and streaming from these. Needs a bit more thinking though. Thanks -- og