@evalon: “which computer configuration”
The experiment was on a Tyan dual Opteron workstation. Pretty old and slow by modern standards, but very stable. Two dual core 1.8GHz processors, 16GB RAM. Not running a -RT patched kernel, but there were so many errors that wouldn’t help until the errors were down into the just occasional category.
If I get a chance this weekend I may try again but with something more reasonable, like jackd running at 384k or 192k and zita-a2j resampling to 96k. Just to make sure the jackd configuration with dummy backend works correctly at all before going to such a high sample rate.
“What I’ve been thinking is that a feasible way to do this could be to load and edit the .wav files into Ardour, and then again save the file as a 1.536 MHz file - or as a 384 kHz file (if this is possible).”
Ardour always works at a single sample rate, so to end up with a 384k file it would create the output file at the same sample rate as all the session source files, then run a script after to generate a lower sample rate copy.
But, without hardware running at 1.536M you would be working without being able to hear what you are doing. Not sure what the point of using a DAW is if you can’t listen to your work, you might as well use SoX and just do everything offline. That said, I think what you proposed could work. I’ll also see if I can try that this weekend, I generated three 1 minute long source files at 1,536,000 sample rate using SoX and loaded them into ARdour, I will see if export works, then use off line sample rate conversion to convert the generated output file back to base rate.
My original attempt was with no plugins active, just three mono channels connected to a stereo main bus. I would think that assuming any plugins you want to use can calculate parameters for such a high sample rate, the processor utilization is going to be very high.
“I’ve inquired with the main programmer helping here about ALSA and ASIO and he is not immediately familiar with this”
That is in direct conflict with your earlier statement:
“a programmer which I understand has some experience also with audio devices.”
" have previously been employed with a major audio company making e.g. soundcards and sound processors"
ALSA is the only Linux audio API in current use, and ASIO has been used by every professional multi-channel sound card on Windows since at least the mid or late '90’s. Anyone not familiar with ALSA has never worked on audio programming on Linux, and anyone not familiar with ASIO has never worked on professional multi-channel audio on Windows. The fact that the “main” programmer does not have expertise in the problem domain should throw up some red flags regarding how quickly you could expect to have working and stable drivers.
“saving the files to a .wav format (or if there is a better format?) and loading them from there”
ALSA and ASIO are a layer lower than that. Those two API’s are different ways of describing how the software which reads data from a wav file then presents that data to the audio hardware, or how to retrieve audio data from the hardware so it can be saved to a wav file. The ALSA or ASIO driver runs as part of the OS kernel, and implements the appropriate API for use by software such as Ardour, and has the required logic to copy the data to and from the hardware. The programmer needs to understand the hardware, kernel driver programming, and have a list of required functions to implement the API. None of those tasks individually is difficult for an experienced programmer, but there is a learning curve involved.
