From: Chris C. <ca...@al...> - 2004-06-16 07:51:40
|
On Wednesday 16 Jun 2004 8:42 am, Richard Bown wrote: > On Wednesday 16 June 2004 07:44, Richard Bown wrote: > > I'm rebuilding latest CVS right now with optimisations. > > Ok so at least now I'm doing a fair test. Then while you're doing fair tests, please can you: cvs update -r more_audio_hacking -D 2004-06-13 to get the version without the file read thread, and build that with the same options and compare? > On the test composition I got some problems with "JACK losing > sample frames" until I tweaked the buffers. That's troubling, we shouldn't be seeing xruns at all -- I would expect mountains of "The audio subsystem is failing to keep up" or whatever it is before we get actual xruns (except for the odd random one on startup). > Currently running at: > > Event Read Ahead: 320ms > Audio Mix Buffer: 160ms > Audio file read: 320ms And JACK is at 512x2 / 48KHz? > I can now have 12 tracks of smallish (3-4secs) repeating blocks > playing with on the laptop with no problems. The size of the > samples is much bigger than the small file cache size still. That's good. I'd like to know whether that's also possible with the 2004-06-13 branch. > With > long audio samples (1m+) playback is much more sluggish - I can add > say 4-5 tracks off a long sample and RG becomes very slow to update Actually I think this is entirely GUI-bound -- try it on HEAD if you have a copy hanging around -- I'm thinking it's related to the volume-level adjustments I did last week or whenever, with updates on instrument parameter box changes. My test composition with long samples is awfully slow to update whether I'm playing it or not. Chris |