Subject: Re: [linux-audio-dev] LAAGA - key issues
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Mon Apr 30 2001 - 00:17:50 EEST
On Sat, 28 Apr 2001, Jim Peters wrote:
> Perhaps I should add to this. You were concerned about using system
> calls (disk access and so on) in the audio server. If an MP3 player
> (for example) is split into two parts as I suggest here, then the
> plugin part would just take care of picking up audio from a SHM buffer
> somewhere, and the external process would take care of reading the
> disk, decoding the MP3s and filling the buffer. This external process
True, we've had a few long discussions about this topic here on LAD
(Benno's original proof-of-concept multitrack recorder, Evo, ardour's
first implementations).
> We can easily provide a standard plugin to just pipe audio from a SHM
> buffer, and have a standard library that could be used from an app to
> fill it. However, the advantage for an MP3 player of having its own
> special plugin would be that if the MP3 player was stopped, or
> fast-forwarded or whatever, then it could signal to its plugin to skip
Yup, this is precily what I meant in my earlier post with the "LAAGA stub
client API" (3). Ie. we have stub/standard plugin that is able to
communicate with the client-side library functions (shmem). We can also
provide the basic start/stop/etc commands using this standard library.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Mon Apr 30 2001 - 00:09:14 EEST