I set the system up to just play a WAV on a loop with aplay and it took almost 50 minutes but the playback gradually pitched up until there was an xrun and then playback dropped out for a second before resuming pitched down.
@paul Yes but the only reliable way I have to measure the drift I’m seeing is to sync an external device to Ardour’s MIDI clock out and have it read out the BPM.
@moogmusic So nothing was connected other than the audio console, and monitors to the audio consoles? And you aren’t doing anything like creating aggregate devices etc. in your alsa config right?
If that was the case, I would lean towards a bug in the firewire backend (FFADO) honestly. Might be time to get them involved. It would take some time for me to hook my setup up through the Mackie to test again.
SeabladeYeah - I’m starting to think it’s a ffado issue too. The only ALSA configs I have is a virtual device to grab ALSA output and route it to Jack and I was experiencing the problem when I still had PulseAudio doing that so I doubt it’s the problem.
Thanks for your help - I’ll drop an email to the ffado mailing list and update back here if there’s any progress. I hope I can get it working, apart from this issue, it’s a great desk.
OK, so I think (fingers crossed) I’ve fixed it. Basically (as explained here: http://sourceforge.net/p/ffado/mailman/message/27075049/) the xmit_transfer_delay parameter for the OXFORD ffado driver used in early version of the 1640i was set by default to be 11776 which is too large and for recording at 44.1kHz, which I am doing, it needs to be 13162, set in the /usr/share/libffado2/configuration
Phew, that we far deeper than I really wanted to go. Thanks for all the input.
I mean too small.
You know what I mean.