Re: [linux-audio-dev] defending simplicity

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] defending simplicity
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Wed Mar 29 2000 - 10:37:09 EEST


Ok. Let's go for float-only LADSPA 1.0.
That at least gives time to experiment with more complex APIs
before fixing them. At then we also would have plenty of plug-ins
to test more complex idea.

>From: Kai Vehmanen <kaiv_AT_wakkanet.fi>
>
>> Don't assume the host can handle and understand the audio data!
>> It doesn't happen in my engine, for example.
>
>Ok, we must be talking about different things... Let's say
>I have a simple host that reads a 8bit mono file, processes
>it with a LADSPA plugin and writes to another file. If
>my host doesn't recognize formats used by the LADSPA plugins,
>how can it fill the plugin buffer? Or are plugins supposed
>to support 8bit data? Converters? What am I missing?

In that case host would know what is the used audio format.
But it should not be necessary to know it.

Having host to know every format mess up the thing, yes.
But if we move all to plug-ins, then user could just build
following network to do the thing:
  disk-reader --> 8bit to float --> dsp --> float to 16bit --> disk-writer

The host only schedules this network but doesn't know about audio
data. This modularizes/separates the scheduler and the audio processing
a nice way.

It is possible to write some of this functionality to host itself.
But if LADSPA is designed so that host has to know about audio formats,
will it cause more mess in my engine?

I think the less messy choise is my approach.

>... and most plugins end up usable only with a limited set of hosts.

That is okay. If one doesn't write host for understanding spectral data,
it cannot use spectral plug-ins. But if this is done otherwise, one
could just use those spectral converter plug-ins without understanding
spectral data.

>And don't say use converters. Converting data is expensive.

Spectral data converter would be needed anyway.
And it is cheaper to convert to double for 4 plug-ins than use
doubles for all 200 plug-ins.

>apps, I've tried to limit converting to two specific places: 1) when
>data enters the system, 2) when it's outputted. I don't want to
>start doing conversion before and after every plugin.

You can do that. Converters are not needed everywhere.
Convert A/D to float, use float plug-ins, and finally convert
float to D/A.

>Oh yes, we convert it to 26 *mono* streams. That's just what I've been
>suggesting.

That is my suggestion too. But one could advantage interleaved data
in efficient recording directly to disk. Keeping LADSPA too simple
would make that impossible.

 -*-

Ok, let's keep the LADPSA now simple.

Juhana


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Mar 29 2000 - 11:12:58 EEST