Subject: Re: [linux-audio-dev] LAAGA - key issues
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Sat Apr 28 2001 - 22:06:52 EEST
Jim Peters wrote:
> Certain types of applications will probably not need to provide
> plugins - for example a simple record-to-disk application can lag a
> little behind real-time so long as the intermediate buffer is big
> enough to cope. Similarly an MP3 player can get a little ahead of
> real-time. Both of these would probably benefit from their own
> plugin, though, for maximum control.
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
would normally get a little ahead, keeping the buffer full. Note that
the external process is doing all the disk accesses, not the plugin.
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
ahead in the buffer, skipping over however many seconds of
pre-processed data had been accumulated there (so as users we don't
have to wait several seconds for the player to respond).
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Sat Apr 28 2001 - 22:54:59 EEST