[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alsa-devel
Subject:    [alsa-devel] Re: pcm_plugin and pcm_* converging to the same API: Was:   Re: ALSA & aRts (Re: aRts C
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-04-26 14:29:47
[Download RAW message or body]

   Hi!

On Wed, Apr 26, 2000 at 01:22:32PM +0200, Benno Senoner wrote:
> Stefan, is right that the only easy way to redirect audio streams to
> soundservers it to use the pcm_plugin API.
> 
> Jaroslav said with the new PCM API only the pcm_open call will differ
> when using the two methods.
> I think that is the key to the success.
> 
> solution of all redirection problems:
> 
> - apps should ALWAYS  use of pcm_plugin_open instead of pcm_open 
> except for strong resons like low-latency performance etc.
> but if that app decide to use the pcm_open directly, give the user a way to
> choose the pcm_plugin_open version when opening the audio device,
> in order to allow painless redirection to soundservers, network etc.  
> 
> comments ?
Fine with me.

> Stefan: changing the ALSA API to to packetized protocol is just
> silly, since it will add nice communication overhead plus
> will be unusable for low latency apps.  
> I'd suggest to implement the ALSA -> Arts protocol consersions inside
> the pcm_plugin layer, that keeps the ALSA apps simple.

I think you got me wrong (or I described not too clearly what I meant). I
don't want to change the protocol, just a part of the API. The situation
we're talking about is this:

a) an application wants to output data
b) the pcm_plugin layer provides only a write call (maybe non-blocking)
   without giving you an idea *when* you can write

One traditional solution is, that the application select()s the fd, and
writes when select returns. That way, it has 0% CPU usage. Other possible
solutions are polling, threading or complete blocking.

ALSA provides the snd_pcm_file_descriptor() function, so you can effectively
select(), as X11 provides the X11 fd, as aRts could provide the aRts fd.

However the semantics for a native ALSA file descriptor will be:
- select for write 
- do non-blocking pcm_write

while the native aRts fd semantics would be:
- select for read
- call the arts_next_event(fd)
- do non-blocking arts_write

As you see, this behaviour differs in a way that you can't encapsulate the
aRts behaviour into the ALSA behaviour, while maybe people will want to use
select() (as a popular programming technique for doing wait for I/O).

Then, again, we may also forbit select() generally as programming technique
for sound I/O, which also allows shm/semaphore extension without problems
later.

Any opinions on the select() or no select() in the API issue? Regardless if
we're talking about putting select() in pcm_plugin stuff or supporting all
the other functions by aRts?

   Cu... Stefan

Relevant was that passage:
> > There are problems with 3, namely that the apps can get the file descriptor
> > directly. To illustrate: aRts currently uses a packet oriented protocol.
> > If apps want to write, but the stream is currently filled, they would need
> > to select *for reading*, to get a notification when they can write again.
> > 
> > What I'd suggest here is if we want to encourage using this layer, the ALSA
> > API should maybe look somewhat more like the X11 API. You can get the file
> > descriptor, but if you do, you have to select for whatever the API tells you
> > (e.g. it tells you if you should select for reading or writing), and if you
> > got something, you have to call snd_process_next_event(fd) maybe similar
> > to XNextEvent, XConnectionNumber.
> > 
> > There will be problems with sound servers which use shared memory and
> > semaphores for instance for communication (I thought about supporting this
> > some day for aRts).
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
------
To unsubscribe from <alsa-devel@alsa-project.org> mailing list send message
'unsubscribe' in the body of message to <alsa-devel-request@alsa-project.org>.
BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs

[prev in list] [next in list] [prev in thread] [next in thread]