Subject: [linux-audio-dev] ardour design question
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri May 26 2000 - 17:36:20 EEST
I just added support to ardour for non-interleaved cards. I still have
to work on the slightly more difficult issue of the sample size, so
that ardour can be used on 16bit cards (and 20bit), instead of just
24bit cards.
One thing that I could do that would make this much easier to
implement, and more importantly from my perspective, is to require
that the "tape format" matches the chosen "device format". That is, if
you are using a "tape" that is using 32 bit samples (or 24-in-32 like
all current 24 bit soundcards do), you are required to use a soundcard
that can handle this. Contrarily, if you are using a 16 bit soundcard,
the "tape" must use 16 bit samples.
In theory, I could convert the data before sending it the card, but
I'd rather spend those CPU cycles running LADSPA plugins than do
int32->int16 conversions, for example. It would be even worse if I
supported endianness swaps too.
Given that most people will be able to use the same soundcard for
different occasions when they use ardour, and given that the "tapes"
are just directories containing conventional soundfiles (RIFF/WAVE
right now) so that external conversion programs can be used, this
seems to me like an acceptable compromise.
Ardour will give you a nice warning, and perhaps even suggest "sox" as
a solution, if you try to mix/match tape+hardware formats.
The key design goal is to be able read data from the soundfile into
memory, and then copy that directly to the soundcard without any
conversion. Likewise for the other direction.
What do you all think ? Does this sound OK ? If so, I can probably
have ardour running on 16 bit interleaved soundcards sometime next
week. Otherwise, it will take a bit longer, but not much :)
--p
This archive was generated by hypermail 2b28 : Fri May 26 2000 - 19:45:27 EEST